On Wed, 12 May 2010, Ole Reinhardt wrote: > Hello! > > I'm using linux 2.6.31.6 on a Freescale i.MX27 (arm9) platform. For > communication purposes the device uses the g_serial gadget to connect to > a pc (running Windows XP, but with Linux on the other side the same > problem occurs). > > I just patched u_serial.c with the patch found in > > http://marc.info/?l=linux-usb&m=126405382220848&w=2 > > There still exists another "BUG: scheduling while atomic" problem in the > inter-operation between u_serial.c and fsl_udc_core.c. See the log > below... > > The problem occurs just in rare conditions where dma_pool_alloc will > call schedule_timeout whil beeing in an atomic situation. This might > happen when the /dev/ttyGS0 device is opened. gs_open is atomic > > That's the call chain > > dma_pool_alloc is called from fsl_build_dtd(), called from > fsl_req_to_dtd(), called from fsl_ep_queue(), called from gs_start_rx, > called from gs_start_io(), called from gs_open() > > This bug can easily reproduced by connecting the board with a windows or > linux host, opening the device on the host side and hold it open on the > host side. > > On the board side just use this simple shell script to constantly open > and close the device. This is needed as the bug is only triggered in the > rare conditions where dma_pool_alloc has to sleep. > > Test script: > > #!/bin/sh > while [ 1 ] ; do > echo "Hello world" > /dev/ttyGS0 > done > > This bug seems to be specific to the i.MX UDC driver in combination with > g_serial. > > Can anyone give me a hint how to fix this bug? Sorry, I'm neither an > expert in the gadget drivers nor in the UDC driver itself but will do my > very best to fix this bug. I'm a little bit in a hurry as our customers > just make some trouble :) > > I'm not shure if this is a bug in g_serial or in the udc driver. I would > assume the udc driver should not schedule while calling fsl_ep_queue, > right? That's right. The fix should be simple: Change the GFP_KERNEL in that dma_pool_alloc() call to GFP_ATOMIC. It wouldn't be surprising if the same sort of bug occurs at other places in that driver. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
