On Tue, 18 Mar 2014 11:35:06 +0530, meenakshi aggarwal said:
Also i want to know the significance of *0x84/0x9c*
" __schedule_bug+*0x84/0x9c*"
That's saying that __schedule_bug is 0x9c bytes long, and we were at 0x84 bytes into it. So even without a disassembly, we know we were down towards the end of the function.
[ebe09b70] [c064c1c0] __schedule+0x510/0x5e0 [ebe09c80] [c064aea4] schedule_timeout+0x164/0x1d0 [ebe09cc0] [c064bb10] wait_for_common+0xd0/0x1b0 [ebe09d00] [c004db58] kthread_create_on_node+0xa8/0x140 [ebe09d70] [c00a42cc] _cpu_down+0x1ec/0x4e0 [ebe09de0] [c002d8a0] disable_nonboot_cpus+0x90/0x160 [ebe09e10] [c004044c] kernel_restart+0x1c/0x90 [ebe09e20] [c004069c] sys_reboot+0x1cc/0x250
So we were in the reboot() syscall, and one of the functions did something that put the thread in "atomic" context - basically "We're doing something important taht can't be interrupted or other threads run that might mess things up".. Which is OK as long as you don't try to call the scheduler. Unfortunately, wait_for_common() tried to call the scheduler.... What kernel version is this? I thought most of the schedule-while-atomic bugs had been hunted down and fixed.