Re: kernel/panic.c warn_slowpath_common printk timestamp weirdness

[Valdis.Kletnieks@vt.edu]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

On Wed, 21 Jul 2010 06:36:41 PDT, Arjan van de Ven said:
> On 7/21/2010 5:54 AM, Valdis.Kletnieks@vt.edu wrote:
> > Seeing this on my Dell Latitude.  The timestamps from the 'cut here' and
> > WARNING lines are different even though they're issued by sequential lines 
in
> > panic.c - but then the printk timestamps remain identical even through an
> > *entire second* WARN call.  Is somebody blocking clock interrupts and faili
ng
> > to re-enable them, or is something different going on here?
> >
> > [42875.543219] ------------[ cut here ]------------
> > [42875.544006] WARNING: at lib/plist.c:57 plist_check_head+0x47/0x114()
> >    
> 
> > [42875.544006] WARNING: at lib/plist.c:57 plist_check_head+0x47/0x114()
> > [42875.544006] Hardware name: Latitude E6500
> >    
> 
> > [42882.428016] ------------[ cut here ]------------
> > [42882.428016] WARNING: at lib/plist.c:57 plist_check_head+0x47/0x114()
> >    
> 
> 
> Maybe I have not have had coffee yet.. but I don't see the one second 
> jump in the three cases you mailed...

I mean the value stays nailed down, even through a second WARN call - it outputs
two entire WARN tracebacks with the exact same timestamp.  Even if the same
timestamp gets used for the traceback, I'd expect the next 'cut here' to have a
new timestamp, and the second WARN trace to have a different timestamp as
well.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]