Several issues on AMD Promontory [1022:43bb]
Hi Joe, I’ve had several issues on AMD Promontory [1022:43bb] XHCI controller, apparently you are the right guy to ask ;) Board: ASUS PRIME B350M-A BIOS version: 3203 Here are the issues: 1. The port stops responding after plugging high speed devices several times. The XHCI resumes then immediately suspend. [ 134.602886] xhci_hcd :02:00.0: // Setting command ring address to 0xff73b001 [ 134.606312] xhci_hcd :02:00.0: xhci_resume: starting port polling. [ 134.606318] xhci_hcd :02:00.0: xhci_hub_status_data: stopping port polling. [ 134.606346] xhci_hcd :02:00.0: xhci_suspend: stopping port polling. [ 134.606435] xhci_hcd :02:00.0: // Setting command ring address to 0xff73b001 [ 134.626860] xhci_hcd :04:00.0: // Setting command ring address to 0xfffd9001 [ 134.630717] xhci_hcd :04:00.0: xhci_resume: starting port polling. [ 134.630722] xhci_hcd :04:00.0: xhci_hub_status_data: stopping port polling. [ 134.630726] xhci_hcd :04:00.0: xhci_hub_status_data: stopping port polling. [ 134.630738] xhci_hcd :04:00.0: xhci_suspend: stopping port polling. [ 134.630760] xhci_hcd :04:00.0: // Setting command ring address to 0xfffd9001 [ 140.834823] xhci_hcd :02:00.0: // Setting command ring address to 0xff73b001 [ 140.838220] xhci_hcd :02:00.0: xhci_resume: starting port polling. [ 140.838226] xhci_hcd :02:00.0: xhci_hub_status_data: stopping port polling. [ 140.838266] xhci_hcd :02:00.0: xhci_suspend: stopping port polling. [ 140.838362] xhci_hcd :02:00.0: // Setting command ring address to 0xff73b001 [ 140.858908] xhci_hcd :04:00.0: // Setting command ring address to 0xfffd9001 [ 140.862745] xhci_hcd :04:00.0: xhci_resume: starting port polling. [ 140.862754] xhci_hcd :04:00.0: xhci_hub_status_data: stopping port polling. [ 140.862760] xhci_hcd :04:00.0: xhci_hub_status_data: stopping port polling. [ 140.862787] xhci_hcd :04:00.0: xhci_suspend: stopping port polling. [ 140.862811] xhci_hcd :04:00.0: // Setting command ring address to 0xfffd9001 [ 322.468521] xhci_hcd :02:00.0: // Setting command ring address to 0xff73b001 Use XHCI_RESET_ON_RESUME quirk can workaround this issue. But maybe a little overkill? 2. XHCI failed to suspend. USB ports stopped to work after that. [ 549.114587] xhci_hcd :02:00.0: WARN: xHC CMD_RUN timeout [ 549.114608] suspend_common(): xhci_pci_suspend+0x0/0xc0 returns -110 [ 549.114638] xhci_hcd :02:00.0: can't suspend (hcd_pci_runtime_suspend returned -110) [ 549.116744] usb usb3: root hub lost power or was reset [ 549.116746] usb usb4: root hub lost power or was reset XHCI_RESET_ON_RESUME quirk cannot workaround issue. 3. Can’t detect high speed devices after plugging super speed device. Unlike 1., the HC is totally unresponsive to high speed devices. No interrupt gets generated. Super speed devices can still be correctly detected though. All three issue can still be reproduced with or without your patch, "[PATCH v8] xhci : AMD Promontory USB disable port support” So I guess we need more quirks to support Promontory properly. Kai-Heng-- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
"Illegal Request" with JMicron JMS567-based USB3 HDD enclosure
Hi all, I'm observing the following error with a JMS567-based USB3 HDD enclosure: sd 6:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sd 6:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current] sd 6:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb It's reproducible with Linus' master - I tested with 2db767d988. Looking into drivers/usb/storage I see there is already a bunch of UNUSUAL_DEV entries for the JMS567 but my device (Icy Box IB-254U3) has a different USB product ID: Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. When I add an UNUSUAL_DEV entry for this ID too, the issue seems to go away. But I'm not sure what is the proper way to add this: * US_FL_BROKEN_FUA seems to be the important quirk but I see some other JMS567 entries also use US_FL_NO_REPORT_OPCODES. Is there a way to test if this quirk is needed for my device? The enclosure seems to work OK even without this. * While normally the device is used via UAS (so I added the UNUSUAL_DEV to unusual_uas.h), it's possible to use it in mass storage mode too (e.g. by building a kernel without CONFIG_USB_UAS), and when I do so, I get the same "Illegal Request", so I should add an UNUSUAL_DEV in unusual_devs.h too, right? * What values should I use for bcdDeviceMin and bcdDeviceMax? I only have two such enclosures bought at different times and both have bcdDevice = 1.14 so should I specify bcdDeviceMin = bcdDeviceMax = 0x0114 or should I use 0x and 0x as some other UNUSUAL_DEVs do? Best regards, David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
