Felipe Balbi wrote:
I am getting kernel-panic as logged below. Seems issue is not yet solved completely.
Will post review comments later.
To reproduce,
1. Use bulk-mux case by doing the change in musb_schedule() as below,
/* use bulk reserved ep1 if no other ep is free */
if (/*best_end < 0 && */ qh->type == USB_ENDPOINT_XFER_BULK) {
OR just revert below patch.
usb: musb: fix BULK request on different available endpoints
2. Connect a HS hub to root hub.
3. Connect two USB sticks to the hub.
4. Mount them to say m1 and m2 in current directory
5. Perform multiple copies between them,
$ cp m1/50mb m2/50
$ cp m1/55mb m2/55
$ cp m1/60mb m2/60
$ cp m2/50mb m1/50
$ cp m2/55mb m1/55
$ cp m2/60mb m1/60
Detach both the sticks after some time (say 5 sec) OR remove the module
if it's modular build. You get the kernel panic as shown below.
--Ajay
Kernel Log----------------
musb_h_tx_flush_fifo 124: Could not flush host TX fifo: csr: 2003
Unable to handle kernel NULL pointer dereference at virtual address 00000026
pgd = c0004000
[00000026] *pgd=00000000
Internal error: Oops: 17 [#2]
Modules linked in: musb_hdrc(-) [last unloaded: musb_hdrc]
CPU: 0 Tainted: G D (2.6.28-rc8-omap1-05308-g0df936a-dirty #61)
PC is at musb_giveback+0x10/0x1c8 [musb_hdrc]
LR is at 0xc7ad6a40
pc : [<bf020760>] lr : [<c7ad6a40>] psr: 60000093
sp : c79cde28 ip : c79cde50 fp : c79cde4c
r10: 00000000 r9 : 00000000 r8 : 00000000
r7 : c7b518d0 r6 : 00000000 r5 : c7b51994 r4 : c7b51994
r3 : 00000000 r2 : 00000000 r1 : c7ad6a40 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 87b64018 DAC: 00000017
Process scsi_eh_7 (pid: 711, stack limit = 0xc79cc2e0)
Stack: (0xc79cde28 to 0xc79ce000)
de20: c7b51994 c7b51994 00000000 c7b518d0 00000000 00000000
de40: c79cde74 c79cde50 bf02095c bf02075c 0000007c 00002003 c7b51994 c7923668
de60: d80ab110 c7ad6a40 c79cdeac c79cde78 bf020adc bf020924 00000000 00000006
de80: c03da4f8 c79cdf0c c787c520 00000000 c7ad6a40 c7b51800 80000093 00000001
dea0: c79cdeec c79cdeb0 bf0210bc bf0209f4 c7843cb0 c03d2140 0699d4d8 0000007c
dec0: c7ad0cc8 c7b51800 00000000 c7ad6a40 ffffff98 ffffff98 00000000 00000000
dee0: c79cdf14 c79cdef0 c01f2eb0 bf020f54 a0000093 00000000 c7ad6a40 ffffff98
df00: 00000000 00000000 c79cdf34 c79cdf18 c01f37cc c01f2e1c c79a3b4c c79a3800
df20: c79cdfac c79cc000 c79cdf44 c79cdf38 c01f417c c01f3780 c79cdf5c c79cdf48
df40: c0200148 c01f4148 c79a3800 c79a3800 c79cdf74 c79cdf60 c01ff50c c020011c
df60: c7917e40 c79a3800 c79cdf84 c79cdf78 c01d0e10 c01ff4a0 c79cdfdc c79cdf88
df80: c01d26c0 c01d0df0 00000000 c03d2140 c79cdfb4 c79cdfa0 c0065c0c c0065bd4
dfa0: 00000000 c7843c80 c79cdfa8 c79cdfa8 c02c8968 c004b0ac c7917e4c c7917e4c
dfc0: c79a3800 c01d259c 00000000 00000000 c79cdff4 c79cdfe0 c0061614 c01d25a8
dfe0: 00000000 00000000 00000000 c79cdff8 c0050f98 c00615cc 01000000 40000000
Backtrace:
[<bf020750>] (musb_giveback+0x0/0x1c8 [musb_hdrc]) from [<bf02095c>] (musb_advance_schedule+0x44/0xd0 [musb_hdrc])
[<bf020918>] (musb_advance_schedule+0x0/0xd0 [musb_hdrc]) from [<bf020adc>] (musb_cleanup_urb+0xf4/0x10c [musb_hdrc])
r7:c7ad6a40 r6:d80ab110 r5:c7923668 r4:c7b51994
[<bf0209e8>] (musb_cleanup_urb+0x0/0x10c [musb_hdrc]) from [<bf0210bc>] (musb_urb_dequeue+0x174/0x1b0 [musb_hdrc])
[<bf020f48>] (musb_urb_dequeue+0x0/0x1b0 [musb_hdrc]) from [<c01f2eb0>] (unlink1+0xa0/0xac)
[<c01f2e10>] (unlink1+0x0/0xac) from [<c01f37cc>] (usb_hcd_unlink_urb+0x58/0x74)
r9:00000000 r8:00000000 r7:ffffff98 r6:c7ad6a40 r5:00000000
r4:a0000093
[<c01f3774>] (usb_hcd_unlink_urb+0x0/0x74) from [<c01f417c>] (usb_unlink_urb+0x40/0x44)
r7:c79cc000 r6:c79cdfac r5:c79a3800 r4:c79a3b4c
[<c01f413c>] (usb_unlink_urb+0x0/0x44) from [<c0200148>] (usb_stor_stop_transport+0x38/0x64)
[<c0200110>] (usb_stor_stop_transport+0x0/0x64) from [<c01ff50c>] (command_abort+0x78/0x8c)
r5:c79a3800 r4:c79a3800
[<c01ff494>] (command_abort+0x0/0x8c) from [<c01d0e10>] (__scsi_try_to_abort_cmd+0x2c/0x30)
r5:c79a3800 r4:c7917e40
[<c01d0de4>] (__scsi_try_to_abort_cmd+0x0/0x30) from [<c01d26c0>] (scsi_error_handler+0x124/0x2f4)
[<c01d259c>] (scsi_error_handler+0x0/0x2f4) from [<c0061614>] (kthread+0x54/0x80)
r7:00000000 r6:00000000 r5:c01d259c r4:c79a3800
[<c00615c0>] (kthread+0x0/0x80) from [<c0050f98>] (do_exit+0x0/0x6ac)
r5:00000000 r4:00000000
Code: e1a0c00d e92dddf0 e24cb004 e1a0e001 (e5d01026)
---[ end trace 5c7734a4d32486f5 ]---
sd 6:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 971390
sd 6:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 7950
FAT: unable to read inode block for updating (i_pos 126214)
sd 6:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 7950
FAT: unable to read inode block for updating (i_pos 126216)
sd 6:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 7950
FAT: unable to read inode block for updating (i_pos 126213)
Sergei, was this fixed ??
By me? No. I have enough work to do rather than fixing this corner case.
E.g. I'm still busy fixing ISO Tx DMA which is certainly more important (and
complex) task.
Where's the new version of this patch ?
What? This is hardly even connected to my patch -- especially this one.
WBR, Sergei
--
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
