fsl_udc_core: BUG: scheduling while atomic

[Sergej.Stepanov at ids.de]

Hi Mattheew,

such oops you can get also with spi.
For such problem helps to compile your kernel with other preemption
model:
 - preempt
 - standard
 - !!! but not voluntary preemption !!!
The other possibility: check your board, may be it has some memory
problems.

Regards
Sergej.


Am Mittwoch, den 11.05.2011, 17:37 -0400 schrieb Matthew L. Creech:
> Hi,
> 
> My MPC8313-based board, running a 2.6.37 kernel, is occasionally
> hitting this bug while doing RNDIS-based communication:
> 
> BUG: scheduling while atomic: lighttpd/1145/0x10000200
> Call Trace:
> [c6a8b910] [c00086c0] show_stack+0x7c/0x194 (unreliable)
> [c6a8b950] [c0019e28] __schedule_bug+0x54/0x68
> [c6a8b960] [c02b04e8] schedule+0xa4/0x408
> [c6a8ba50] [c02b0988] _cond_resched+0x38/0x64
> [c6a8ba60] [c0080e8c] dma_pool_alloc+0x5c/0x2a4
> [c6a8bac0] [c01c57b0] fsl_req_to_dtd+0x68/0x24c
> [c6a8bb00] [c01c5b68] fsl_ep_queue+0x1d4/0x264
> [c6a8bb20] [c01c7eec] eth_start_xmit+0x278/0x344
> [c6a8bb50] [c01fdbc8] dev_hard_start_xmit+0x520/0x680
> [c6a8bba0] [c02122a4] sch_direct_xmit+0x68/0x1e0
> [c6a8bbc0] [c01fdf20] dev_queue_xmit+0x1f8/0x3c4
> [c6a8bbe0] [c022d684] ip_finish_output+0x2d4/0x328
> [c6a8bc10] [c022db08] ip_local_out+0x38/0x4c
> [c6a8bc20] [c022e3cc] ip_queue_xmit+0x2cc/0x360
> [c6a8bca0] [c0241844] tcp_transmit_skb+0x7cc/0x838
> [c6a8bd00] [c0244434] tcp_write_xmit+0x8c4/0xa34
> [c6a8bd60] [c0237618] tcp_sendmsg+0x900/0xbd4
> [c6a8bdd0] [c0256088] inet_sendmsg+0x74/0x8c
> [c6a8bdf0] [c01ea498] sock_aio_write+0x130/0x14c
> [c6a8be50] [c00855fc] do_sync_write+0xb0/0x110
> [c6a8bef0] [c0086294] vfs_write+0xdc/0x17c
> [c6a8bf10] [c008642c] sys_write+0x54/0x9c
> [c6a8bf40] [c000f2cc] ret_from_syscall+0x0/0x38
> 
> This seems similar to a bug from 2010:
> 
> http://www.spinics.net/lists/linux-usb/msg31354.html
> 
> which concludes that the fsl_udc_core driver is wrongly using
> GFP_KERNEL in fsl_build_dtd().  However I'm not sure what an
> appropriate fix is, since just replacing it with GFP_ATOMIC causes
> allocation failures.  Any helpful tips?
> 
> Thanks
> 
> -- 
> Matthew L. Creech
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev