[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111118135221.GC12433@phenom.dumpdata.com>
Date: Fri, 18 Nov 2011 08:52:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Ian Campbell <Ian.Campbell@...rix.com>
Cc: ANNIE LI <annie.li@...cle.com>,
"jeremy@...p.org" <jeremy@...p.org>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"kurt.hackel@...cle.com" <kurt.hackel@...cle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Paul Durrant <Paul.Durrant@...rix.com>
Subject: Re: [Xen-devel] Re: [PATCH 2/3] xen/granttable: Grant tables V2
implementation
> > + xen_raw_printk(str);
> > + panic(str);
>
> I expect you've just copied this style from elsewhere but I really
> dislike this duplication of prints. If panic is not useful here we
> really ought to address that at the root instead of going around
> patching things to print every panic message twice. I thought
> earlyprintk was supposed to solve this problem. Perhaps a generic
> early_panic_print could be added to the panic code?
We are using this combo in swiotlb-xen and as well in the xen pci.
We could declere a 'xen_raw_panic' that would do the job?
The problem is that panic() uses the "late" printk mechanism (so
it goes through the buffer that ends up not beign flushed) and the
panic never sees the light. The 'xen_raw_printk' is synchronous..
But I wonder if the panic surfaces if 'earlyprintk=xen' is used?
At which point it might be that the those extra xen_raw_printk
become pointless?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists