More info:
BUG: scheduling while atomic: more/0x7200546f/101
Stack:
239afd20 00000001 00000018 239afefc 00000ff9 22001cb4 22155cc0 238698f0
7200546f 00000065 00989680 00000000 239ae000 00000008 00000074 0000000a
00000001 00000018 239afefc 00000ff9 2397fec8 00000001 00000000 00000000
Call Trace:
[<22001cb4>] ret_from_intr+0x1c/0x40
I can get this with thttpd as well with:
while [ 1 ]; do curl http://[ipaddress] > /dev/null; done
yields
BUG: scheduling while atomic: thttpd/0xfff90000/46
Stack:
2389ba30 00000001 00000016 00000000 00000005 22001cb4 22155cc0 23869b50
fff90000 0000002e 00989680 00000019 2389a000 00000008 2389ffa8 00000009
00000001 00000016 00000000 00000005 2389c0f4 2389c018 23894fac 00000000
Call Trace:
[<22001cb4>] ret_from_intr+0x1c/0x40
[<22000000>] _start+0x0/0x50
[<220ea494>] skb_release_data+0x88/0xf4
[<220ea494>] skb_release_data+0x88/0xf4
[<220ea260>] kfree_skbmem+0x84/0xf0
[<220ea1e8>] kfree_skbmem+0xc/0xf0
[<2211b0a0>] tcp_cong_avoid+0x14/0x38
[<220ea1e8>] kfree_skbmem+0xc/0xf0
[<220094fc>] __call_console_drivers+0x64/0x88
[<2200ed70>] __do_softirq+0x28/0x3c
[<220095b8>] _call_console_drivers+0x98/0xb0
[<22026488>] handle_IRQ_event+0x5c/0xc8
[<220aeb80>] vscnprintf+0xc/0x38
[<220ae8c0>] vsnprintf+0x37c/0x630
[<22009904>] release_console_sem+0x110/0x2b0
[<22009c98>] vprintk+0x1d0/0x3b8
[<22009b30>] vprintk+0x68/0x3b8
[<22001728>] do_IRQ+0x40/0x54
[<22009ea0>] printk+0x20/0x34
[<220aec78>] sprintf+0x28/0x3c
[<22001cb4>] ret_from_intr+0x1c/0x40
[<220055f4>] scheduler_tick+0x18/0xa8
Reverting to the 2.4 kernel doesn't produce these messages, but I
think that's just because
the checking isn't in there. It still barfs, but silently.
This is on a microblaze spartan3E 1600.
Any ideas?
thanks,
jim
Jim Van Vorst wrote:
I get this a lot as well:
# more /proc/partitions
<< /proc/partitions >>
major minor #blocks name
31 0 768 mtdblock0
31 1 256 mtdblock1
31 2 256 mtdblock2
31 3 128 mtdblock3
31 4 4096 mtdblock4
31 5 1024 mtdblock5
31 6 BUG: scheduling while atomic: sh/0x00000008/47
Stack:
23effc08 2200ed08 23e9140c 00000000 00000000 22001c54 22161ca0
23c9d8ec
00000008 0000002f 01c9c380 0000000e 23efe000 00000008 00000000
00000000
23efffbd 23e9140c 00000000 00000000 2397ff1c 00000000 00000000
23e91c54
Call Trace: [<2200ed08>] [<22001c54>] [<2215daa4>] [<2200ed08>]
[<220016b4>]
9216 mtdblock6
31 7 1424 mtdblock7
I then tried enabling CONFIG_PREEMPT:
# more /proc/partitions
<< /proc/partitions >>
maBUG: scheduling while atomic: more/0x7200546f/54
Stack:
238efd34 00000000 2397ff1c 00000000 22001758 22001dd4 2217dcb0
238818f0
7200546f 00000036 221b9bf0 00000000 00000008 238ee670 238ee474
0000001b
00000000 238eff78 00000000 2397ff1c 00000000 00000000 00000000
238efe24
Call Trace: [<22001758>] [<22001dd4>]
jor minor #blocks name
31 0 768 mtdblock0
31 1 BUG: scheduling while atomic: more/0x7200546f/54
Stack:
238efda0 00000000 2397ff1c 00000000 22001758 22001dd4 2217dcb0
238818f0
7200546f 00000036 00989680 00000000 00000008 00000020 00000005
00000001
0000000f 238eff78 00000000 2397ff1c 00000000 00000000 00000000
238efe90
Call Trace: [<22001758>] [<22001dd4>]
256 mtdblock1
31 2 256 mtdblock2
31 3 128 mtdblock3
31 4 4096 mtdblock4
31 5 1024 mtdblock5
31 6 9216 mtdblock6
31 7 1424 mtdblock7
Woohoo! Crashes in more instead of sh...
I don't get these all the time but it's very easy to replicate.
Sometimes my board keeps going, sometimes it freezes.
It's not just more or cat. Basically any command will do it.
I don't remember getting these with the 2.4 kernel.
John Williams wrote:
Hi Chun Yeow,
Thanks for the report - we'll look into it and let you know via the
list.
Thanks again,
John
Yeoh Chun Yeow wrote:
Dear all,
I compile the 2.6 kernel in the petalogix distribution. My file
system is in romfs format.
I have found "BUG: scheduling while atomic: sh/0x00000008/43" in
my kernel execution.
BUG: scheduling while atomic: sh/0x00000008/43
Stack:
27efeac4 27ece5cc 245d1d20 00000001 0000005b 24001ed4 2418a0e4
244ea1c4
00000008 0000002b 0ba0f600 27efea30 00000008 245d15e0 245d15e0
2459e000
27ece5cc 245d1d20 00000001 0000005b 27effc30 00000000 00000000
27efebb4
Call Trace:
[<24001ed4>] ret_from_intr+0x1c/0x40
After I enable in CONFIG_PREEMPT, thing get better.
But, now when I doing the ping, the following bugs occur:
bytes from 199.20.6.174 <http://199.20.6.174>: icmp_BUG:
scheduling while atomic: ping/0x00000002/62
Stack:
2465fc14 27cb28b0 000000c0 00000000 27d1e120 241a7f9c 241ab0a8
27d1b1d8
00000002 0000003e 2465e000 000000a2 240166c0 7fffffff 00000000
2465fc8c
2465fce0 2465fd18 00000000 00000000 27cb28b0 000000c0 00000000
2411b36c
Call Trace:
What is the reason behind that? Any ideas?
Please advice. Thanks
regards,
chun yeow
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page :
http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/