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? Thanks, Maulik -- 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
