On Tue, Apr 06, 2010 at 05:28:07PM +0530, Maulik wrote: > Hi, > > I am getting the following dump with g_serial under the following scenario. > > Setup: - OMAP4430 board running Linux (latest mainline) > > OMAP4 acts as a serial usb gadget and enumeration is done against a Linux PC > Host. > > microcom is run on the OMAP side and minicom on the Host (Linux) PC side. > > I can type in characters from both the sides and this works. > > When trying to send large files (400 KB) with minicom from Host PC to OMAP > board, I get the below dump. > > BUG: scheduling while atomic: microcom/597/0x00000104 > Modules linked in: g_serial > > Pid: 597, comm: microcom > CPU: 0 Not tainted (2.6.34-rc3-00243-g7da23b8-dirty #2) > PC is at _raw_spin_unlock_irqrestore+0x24/0x50 > LR is at gs_unthrottle+0x50/0x54 [g_serial] > pc : [<c0262690>] lr : [<bf000fdc>] psr: 60000013 > sp : dfc8de48 ip : dfc8de58 fp : dfc8de54 > r10: 00000000 r9 : 00000001 r8 : 7fffffff > r7 : dfdf6800 r6 : dfc8dec4 r5 : a0000013 r4 : dfea0a00 > r3 : 00000000 r2 : 00000001 r1 : a0000013 r0 : dfea0a00 > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 10c53c7d Table: 9fe9404a DAC: 00000015 > [<c002b72c>] (show_regs+0x0/0x50) from [<c00475bc>] > (__schedule_bug+0x58/0x70) > r5:dfdf6830 r4:dfc8de00 > [<c0047564>] (__schedule_bug+0x0/0x70) from [<c02601ac>] > (schedule+0x84/0x50c) > r5:dfdf6830 r4:dfc8c000 > [<c0260128>] (schedule+0x0/0x50c) from [<c0260f68>] > (__mutex_lock_slowpath+0x164/0x1e4) > [<c0260e04>] (__mutex_lock_slowpath+0x0/0x1e4) from [<c0261010>] > (mutex_lock+0x28/0x3c) > r8:dfdf68a4 r7:dfdf6800 r6:20000113 r5:dfdf6830 r4:dfdf6830 > [<c0260fe8>] (mutex_lock+0x0/0x3c) from [<c019ee38>] > (tty_throttle+0x1c/0x54) > r5:dfdf6830 r4:dfdf6800 > [<c019ee1c>] (tty_throttle+0x0/0x54) from [<c019dbb0>] > (n_tty_receive_buf+0xdec/0xe44) > r5:0000002e r4:00000000 > [<c019cdc4>] (n_tty_receive_buf+0x0/0xe44) from [<c019ff08>] > (flush_to_ldisc+0xf4/0x170) > [<c019fe14>] (flush_to_ldisc+0x0/0x170) from [<c019ffd0>] > (tty_flip_buffer_push+0x4c/0x5c) > [<c019ff84>] (tty_flip_buffer_push+0x0/0x5c) from [<bf001c54>] > (gs_rx_push+0x130/0x1d8 [g_serial]) > r5:000000b6 r4:dfea0a00 > [<bf001b24>] (gs_rx_push+0x0/0x1d8 [g_serial]) from [<c0053098>] > (tasklet_action+0xa0/0x15c) > [<c0052ff8>] (tasklet_action+0x0/0x15c) from [<c005353c>] > (__do_softirq+0x9c/0x12c) > r7:00000001 r6:00000018 r5:00000103 r4:dfc8c000 > [<c00534a0>] (__do_softirq+0x0/0x12c) from [<c005361c>] (irq_exit+0x50/0x70) > [<c00535cc>] (irq_exit+0x0/0x70) from [<c0029090>] (asm_do_IRQ+0x90/0xc8) > [<c0029000>] (asm_do_IRQ+0x0/0xc8) from [<c0029c08>] (__irq_svc+0x48/0xbc) > Exception stack(0xdfc8de00 to 0xdfc8de48) > de00: dfea0a00 a0000013 00000001 00000000 dfea0a00 a0000013 dfc8dec4 > dfdf6800 > de20: 7fffffff 00000001 00000000 dfc8de54 dfc8de58 dfc8de48 bf000fdc > c0262690 > de40: 60000013 ffffffff > r5:fa240100 r4:ffffffff > [<c026266c>] (_raw_spin_unlock_irqrestore+0x0/0x50) from [<bf000fdc>] > (gs_unthrottle+0x50/0x54 [g_serial]) > [<bf000f8c>] (gs_unthrottle+0x0/0x54 [g_serial]) from [<c019ee10>] > (tty_unthrottle+0x48/0x54) > r5:dfdf6830 r4:dfdf6800 > [<c019edc8>] (tty_unthrottle+0x0/0x54) from [<c019c680>] > (check_unthrottle+0x1c/0x20) > r5:dfc8dedc r4:00000000 > [<c019c664>] (check_unthrottle+0x0/0x20) from [<c019cbd0>] > (n_tty_read+0x54c/0x638) > [<c019c684>] (n_tty_read+0x0/0x638) from [<c0198424>] (tty_read+0x88/0xd0) > [<c019839c>] (tty_read+0x0/0xd0) from [<c00ac888>] (vfs_read+0xb8/0x164) > [<c00ac7d0>] (vfs_read+0x0/0x164) from [<c00ac9f8>] (sys_read+0x44/0x70) > r8:000ddb08 r7:00002001 r6:dfc72aa0 r5:00000000 r4:00000000 > [<c00ac9b4>] (sys_read+0x0/0x70) from [<c002a100>] > (ret_fast_syscall+0x0/0x30) > r8:c002a2a8 r7:00000003 r6:00000003 r5:000ddb08 r4:00002001 > > > Looks like the tasklet "gs_rx_push()" calls tty_flip_buffer_push() which > in turn leads to a call to tty_throttle(). This calls mutex_lock() > which can sleep. > > So we have a code that sleeps in a tasklet and hence this bug. Is my > understanding correct? > > What should be the right way to handle this? This has come up before, and I thought we resolved it :( Or did I miss a patch that should have been applied? Can you look at the archives to see what happened last time we discussed it? thanks, greg k-h -- 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
