Re: [Oops] on 2.6.23-rc9 sysRq Show Tasks (t)

Previous thread: [PATCH 2/2] Colored kernel output (run3) by Jan Engelhardt on Saturday, October 6, 2007 - 1:10 pm. (5 messages)

Next thread: [PATCH] net/core: split dev_ifsioc() according to locking by Jeff Garzik on Saturday, October 6, 2007 - 1:42 pm. (3 messages)
From: Ahmed S. Darwish
Date: Saturday, October 6, 2007 - 1:14 pm

Hi all,

Pressing sysRq+T always produce an Oops for every running system task (94 
Oopses, that's a record ;)).
The bug is 100% reproducable. Should I begin bisecting/investigating the 
issue or it's a known problem ?

$ ver_linux
Linux darwish-laptop 2.6.23-rc9 #23 Sat Oct 6 21:48:45 EET 2007 i686 GNU/Linux
 
Gnu C                  4.0.3
Gnu make               3.81beta4
binutils               2.16.91
util-linux             2.12r
mount                  2.12r
module-init-tools      3.2.2
e2fsprogs              1.38
Linux C Library        3.6
Dynamic linker (ldd)   2.3.6
Procps                 3.2.6
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               5.93
udev                   079

[  226.309874] SysRq : Show State
[  226.309948]   task                PC stack   pid father
[  226.310105] init          S c1465b64     0     1      0
[  226.310195]        c1465b54 00000082 00000286 c1465b64 c04255c0 c03c3ec0 00000000 00000286 
[  226.310414]        c1465b64 fffd689a 0000000b 00000000 c02e8fda c1537040 00000292 c0425ab4 
[  226.310664]        c0425ab4 fffd689a c0123cd0 c14634f0 c04255c0 00000800 c1465f9c c0176bf5 
[  226.310914] Call Trace:
[  226.310995]  [<c02e8fda>] schedule_timeout+0x4a/0xc0
[  226.311075]  [<c0123cd0>] process_timeout+0x0/0x10
[  226.311148]  [<c0176bf5>] do_select+0x375/0x4b0
[  226.311231]  [<c01760e0>] __pollwait+0x0/0x100
[  226.311302]  [<c0117a50>] default_wake_function+0x0/0x10
[  226.311379]  [<c0138bad>] __lock_acquire+0x74d/0x1130
[  226.311452]  [<c01c0278>] do_get_write_access+0x2c8/0x570
[  226.311538]  [<c0164a39>] poison_obj+0x29/0x60
[  226.311613]  [<c0139997>] mark_held_locks+0x67/0x80
[  226.311684]  [<c01663dd>] kmem_cache_free+0xad/0xf0
[  226.311755]  [<c0139b64>] trace_hardirqs_on+0x104/0x170
[  226.311832]  [<c0138bad>] __lock_acquire+0x74d/0x1130
[  226.311903]  [<c0138bad>] __lock_acquire+0x74d/0x1130
[  226.311981]  [<c0138bad>] __lock_acquire+0x74d/0x1130
[  226.312052]  [<c01aefb6>] ...
From: Ahmed S. Darwish
Date: Saturday, October 6, 2007 - 1:52 pm

Shame, This is not an Oops at all. Really sorry.

/me wondering about my look now posting a normal message as an Ooops a day 
before the stable release :(.

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
-

From: Alexey Dobriyan
Date: Saturday, October 6, 2007 - 2:12 pm

Start with some old kernel, like mmm.. 2.6.0. The fact that same behaviour
was present there may make you think about faulty assumptions you've
-

From: Ahmed S. Darwish
Date: Sunday, October 7, 2007 - 12:39 pm

Yeah I understood my mistake (not an Oops, a normal behaviour). 
Thanks for your advice :).

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
-

Previous thread: [PATCH 2/2] Colored kernel output (run3) by Jan Engelhardt on Saturday, October 6, 2007 - 1:10 pm. (5 messages)

Next thread: [PATCH] net/core: split dev_ifsioc() according to locking by Jeff Garzik on Saturday, October 6, 2007 - 1:42 pm. (3 messages)