Prev: [PATCH 4/7] x86, xsave: make init_xstate_buf static
Next: [PATCH] x86: Do not try to disable hpet if it hasn't been initialized before
From: Valdis.Kletnieks on 21 Jul 2010 13:40
On Wed, 21 Jul 2010 06:36:41 PDT, Arjan van de Ven said:
> On 7/21/2010 5:54 AM, Valdis.Kletnieks(a)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.

 | 
Pages: 1
Prev: [PATCH 4/7] x86, xsave: make init_xstate_buf static
Next: [PATCH] x86: Do not try to disable hpet if it hasn't been initialized before