Hello.
My 3.16.7 panicked yesterday when I was working with a Thorlabs DCC1545M camera (inside it's actually an IDS UI-154x/UI-554x sensor, if that matters).
>From USB point of view, it's a simple USB 2.0 device with 1 config, 1 IF and 2 bulk EPs.
As long as I was working with it using my USB 2.0 port (Intel C600/X79 EHCI), everything was fine.
But when I tried to plug it into USB 3.0 port (ASMedia ASM1042) I've got a kernel panic. I just had enough time to take a picture of the screen with my phone before the computer automatically rebooted. (I attach the photo to this mail). Also CupsLock and ScrollLock indicators were blinking synchronously.
After reboot I tried to the same again, and got another error: the system just hung (even SysRq didn't work). I used the reset button and decided that I'm done testing the tensile strength of my system. I did, however, try to reproduce the error with another USB 3.0 controller of my MB (Texas Instruments TUSB73x0) and everything worked fine. So I guess it's an ASMedia problem.
I tried to debug the xhci-hcd.ko with GDB, but it showed me wrong lines in the source code:
RIP: 0010:[<ffffffffa00ea006>] [<ffffffffa00ea006>] handle_tx_event+0x2e6/0x12f0 [xhci_hcd]
0x000000000000fd50 + 0x2e6 = 0x10036
0x10036 is in handle_tx_event (../include/uapi/linux/usb/ch9.h:487).
482 * Returns true if the endpoint is of type control, otherwise it returns false.
483 */
484 static inline int usb_endpoint_xfer_control(
485 const struct usb_endpoint_descriptor *epd)
486 {
487 return ((epd->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
488 USB_ENDPOINT_XFER_CONTROL);
489 }
490
491 /**
actually handle_tx_event is in (drivers/usb/host/xhci-ring.c:2244).
[<ffffffffa00eb2c6>] xhci_irq+0x2b6/0xa10 [xhci_hcd]
0x0000000000011040 + 0x2b6 = 0x112F6
0x112f6 is in xhci_irq (../drivers/usb/host/xhci-ring.c:2626).
2621 handle_port_status(xhci, event);
2622 update_ptrs = 0;
2623 break;
2624 case TRB_TYPE(TRB_TRANSFER):
2625 ret = handle_tx_event(xhci, &event->trans_event);
2626 if (ret < 0)
2627 xhci->error_bitmask |= 1 << 9;
2628 else
2629 update_ptrs = 0;
2630 break;
actually (xhci-ring.c:2626) is not xhci_irq but xhci_handle_event.
I'm a GDB virgin, so maybe you'll get more accurate info. My guess is that some instruction in handle_tx_event (xhci-ring.c:2244) dereferenced a null pointer.
I'm using OpenSuSE 13.2 x64. Uname -a looks like this:
Linux Hyperon-SuSE 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17 18:00:44 UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux
I attach these files to this e-mail:
17-45-32.crash
17-45-32.verbose.crash
17-55-42.crash
17-55-42.verbose.crash
Output of 'journalctl' and 'journalctl -o verbose' for first crash (panic) and second crash (hang).
lsusb.txt
lsusb_3.txt
Output of lsusb with camera attached to USB 2.0 and 3.0 port, respectively.
hwinfo.txt
lscpu.txt
lsmod.txt
lspci.txt
lspci_v.txt
lspci_vv.txt
lspci_vvv.txt
hardinfo_report.html
Dumps of corresponding utilities.
Relevant files:
https://yadi.sk/i/fgCGsHwlebwRN
Screen photo
https://yadi.sk/d/QsrZkUKnebwRr
Tarball with logs
Cheers,
Daniil
--
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
