WARN_ON at line 380 in kernel/smp.c under 2.6.32.2 + TuxOnIce + KDB
Pedro Ribeiro
I've been asked by Nigel Cunningham of TuxOnIce to forward this bug here.
While resuming from hibernate (using TuxOnIce) I'm seeing the WARN_ON
at line 380 in kernel/smp.c trigger from a kmap_high call right after
secondary processors have been brought down (the previous message is
"CPU1 is down").
I only have pictures of the backtrace (readable but not very good
quality, sorry).
http://img51.imageshack.us/img51/2312/stacktrace1.jpg
http://img195.imageshack.us/img195/3646/stacktrace2.jpg
At first I thought this was related to my battery saving script
messing with /proc/sys/vm/dirty_writeback_centisecs, but I'm not sure
right now, it still happens with the default value, so I'm clueless.
Mind you, this does not impede the resume - it just dumps this stack
trace and continues resuming happily.
Some information which might be helpful:
lspci -vv, http://pastebin.com/m2c217b4e
dmesg, http://pastebin.com/m491ab4db
.config, http://pastebin.com/m2e4352fe
(the pastebin links are good for a month)
My hardware is a Lenovo T400, and I'm using 2.6.32.2 + TuxOnIce + KDB patches.
Thanks for your help,
Pedro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Peter Zijlstra
> Hi all,
>
> I've been asked by Nigel Cunningham of TuxOnIce to forward this bug here.
>
> While resuming from hibernate (using TuxOnIce) I'm seeing the WARN_ON
> at line 380 in kernel/smp.c trigger from a kmap_high call right after
> secondary processors have been brought down (the previous message is
> "CPU1 is down").
>
> I only have pictures of the backtrace (readable but not very good
> quality, sorry).
> http://img51.imageshack.us/img51/2312/stacktrace1.jpg
> http://img195.imageshack.us/img195/3646/stacktrace2.jpg
>
> At first I thought this was related to my battery saving script
> messing with /proc/sys/vm/dirty_writeback_centisecs, but I'm not sure
> right now, it still happens with the default value, so I'm clueless.
>
> Mind you, this does not impede the resume - it just dumps this stack
> trace and continues resuming happily.
If you'd enable frame pointers the strack traces would be clearer, but
it looks like a bug in tux on ice, doing kmap_high() with IRQs disabled
or something like that.
Pedro Ribeiro
> On Tue, 2009-12-22 at 16:51 +0000, Pedro Ribeiro wrote:
>> Hi all,
>>
>> I've been asked by Nigel Cunningham of TuxOnIce to forward this bug here.
>>
>> While resuming from hibernate (using TuxOnIce) I'm seeing the WARN_ON
>> at line 380 in kernel/smp.c trigger from a kmap_high call right after
>> secondary processors have been brought down (the previous message is
>> "CPU1 is down").
>>
>> I only have pictures of the backtrace (readable but not very good
>> quality, sorry).
>> http://img51.imageshack.us/img51/2312/stacktrace1.jpg
>> http://img195.imageshack.us/img195/3646/stacktrace2.jpg
>>
>> At first I thought this was related to my battery saving script
>> messing with /proc/sys/vm/dirty_writeback_centisecs, but I'm not sure
>> right now, it still happens with the default value, so I'm clueless.
>>
>> Mind you, this does not impede the resume - it just dumps this stack
>> trace and continues resuming happily.
>
> If you'd enable frame pointers the strack traces would be clearer, but
> it looks like a bug in tux on ice, doing kmap_high() with IRQs disabled
> or something like that.
>
>
Thanks for your reply.
I enabled frame pointers, is this more useful?
http://img684.imageshack.us/img684/5118/dsc01206m.jpg
http://img96.imageshack.us/img96/5493/dsc01207k.jpg
http://img33.imageshack.us/img33/7470/dsc01208lp.jpg
Regards,
Pedro
Peter Zijlstra
> On Tue, Dec 22, 2009 at 5:20 PM, Peter Zijlstra <pet...@infradead.org> wrote:
> > If you'd enable frame pointers the strack traces would be clearer, but
> > it looks like a bug in tux on ice, doing kmap_high() with IRQs disabled
> > or something like that.
> I enabled frame pointers, is this more useful?
> http://img684.imageshack.us/img684/5118/dsc01206m.jpg
> http://img96.imageshack.us/img96/5493/dsc01207k.jpg
> http://img33.imageshack.us/img33/7470/dsc01208lp.jpg
Those read more clearly indeed, thanks!
It really looks like what I said above, in that tux on ice is calling
kmap() from an inappropriate context.
Nigel Cunningham
Peter Zijlstra wrote:
> On Tue, 2009-12-22 at 19:16 +0000, Pedro Ribeiro wrote:
>> On Tue, Dec 22, 2009 at 5:20 PM, Peter Zijlstra <pet...@infradead.org> wrote:
>
>>> If you'd enable frame pointers the strack traces would be clearer, but
>>> it looks like a bug in tux on ice, doing kmap_high() with IRQs disabled
>>> or something like that.
>
>> I enabled frame pointers, is this more useful?
>> http://img684.imageshack.us/img684/5118/dsc01206m.jpg
>> http://img96.imageshack.us/img96/5493/dsc01207k.jpg
>> http://img33.imageshack.us/img33/7470/dsc01208lp.jpg
>
> Those read more clearly indeed, thanks!
>
> It really looks like what I said above, in that tux on ice is calling
> kmap() from an inappropriate context.
Ah, I know now what's going on now. You're right. In working around a
reported problem, I've triggered the warning. I'll give it some more
consideration.
Nigel
Nigel Cunningham
Peter Zijlstra wrote:
> On Tue, 2009-12-22 at 19:16 +0000, Pedro Ribeiro wrote:
>> On Tue, Dec 22, 2009 at 5:20 PM, Peter Zijlstra <pet...@infradead.org> wrote:
>
>>> If you'd enable frame pointers the strack traces would be clearer, but
>>> it looks like a bug in tux on ice, doing kmap_high() with IRQs disabled
>>> or something like that.
>
>> I enabled frame pointers, is this more useful?
>> http://img684.imageshack.us/img684/5118/dsc01206m.jpg
>> http://img96.imageshack.us/img96/5493/dsc01207k.jpg
>> http://img33.imageshack.us/img33/7470/dsc01208lp.jpg
>
> Those read more clearly indeed, thanks!
>
> It really looks like what I said above, in that tux on ice is calling
> kmap() from an inappropriate context.
I've finally gotten around to looking at this problem properly, and Pete
is exactly right. I'll send a test fix to Pedro separately.
Regards,
Nigel