Understanding of kernel stack print

[Valdis.Kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140318/4414da30/attachment-0001.bin