Created attachment 1662436 [details] dmesg.txt 1. Please describe the problem: The Kingston 32GB USB key does not work when connected to the laptop, the key does never get mounted and dmesg reports some errors. 2. What is the Version-Release number of the kernel: 5.4.17-200.fc31 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : No 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 1) Connect the USB key to the laptop 2) Wait 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Attached below
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 31 kernel bugs. Fedora 31 has now been rebased to 5.5.7-200.fc31. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 32, and are still experiencing this issue, please change the version to Fedora 32. If you experience different issues, please open a new bug report for those.
Hello, The bug is not resolved, still occurs on 5.5.7-200.fc31. I'll add the updated dmesg.log.
Created attachment 1667746 [details] 5.5.7-200.fc31 kernel dmesg.txt
Hello, After the Fedora 32 the issue still occurs on kernel 5.6.13-300.fc32. I'll add a new dmesg.log file.
Created attachment 1690534 [details] 5.6.13-300.fc32 kernel dmesg.txt
Thanks for updating your report. The kernel is repeatedly detecting the USB device and disconnecting: $ fgrep -A7 'usb 2-1:' -m1 dmesg.txt mai 21 16:02:15 kernel: usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd mai 21 16:02:15 kernel: usb 2-1: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 0.01 mai 21 16:02:15 kernel: usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 mai 21 16:02:15 kernel: usb 2-1: Product: DataTraveler 3.0 mai 21 16:02:15 kernel: usb 2-1: Manufacturer: Kingston mai 21 16:02:15 kernel: usb 2-1: SerialNumber: [removed] mai 21 16:02:15 kernel: usb 2-1: Set SEL for device-initiated U2 failed. mai 21 16:02:16 kernel: usb 2-1: USB disconnect, device number 2 $ fgrep 'usb 2-1: USB disconnect' dmesg.txt | wc -l 53 For the record: $ fgrep 'DMI:' dmesg.txt mai 22 01:00:35 kernel: DMI: Dell Inc. XPS 13 7390/0377MH, BIOS 1.5.1 03/26/2020
mai 22 01:00:35 kernel: DMI: Dell Inc. XPS 13 7390/0377MH, BIOS 1.5.1 03/26/2020 AFAICT, that model* doesn't have any USB type A ports**, so how are you connecting the Kingston USB flash drive to the Dell? * XPS 13 7390 2-in-1 Setup and Specifications https://topics-cdn.dell.com/pdf/xps-13-7390-2-in-1-laptop_setup-guide_en-us.pdf ** USB type A ports have a rectangular shape: https://en.wikipedia.org/wiki/USB_hardware#Connectors
(In reply to Steve from comment #7) > AFAICT, that model* doesn't have any USB type A ports**, so how are you > connecting the Kingston USB flash drive to the Dell? I am using the USB-C to USB-A adapter provided with the Laptop. It seems to be similar to this one: https://www.dell.com/en-us/shop/dell-adapter-usb-c-to-usb-a-30/apd/470-abne/pc-accessories
Created attachment 1690979 [details] Sony Vaio 5.6.6-300 Same issue occurs in an Sony Vaio laptop which has USB-A ports. This rules out any problem with the Dell adapter.
Thanks for your followup reports. Your test with the Sony Vaio laptop also rules out a problem with Thunderbolt ports. I suggest updating the bug summary to something like this: Kingston USB key repeatedly disconnected after "Set SEL for device-initiated U2 failed."
I have the same model USB flash drive, and it works as expected with 5.6.13-200.fc31.x86_64. There is a difference, however: doesn't work: kernel: usb 2-1: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 0.01 ^^^^ works: kernel: usb 3-11: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10 ^^^^ As a practical matter, if you actually need a USB flash drive, I would suggest getting another one. And, as the above results suggest, it is impossible to tell what is inside until the kernel attempts to configure the device. Indeed, I have USB flash drives for which the label on the device shows a different brand from what "lsusb -v" shows.
(In reply to Steve from comment #11) > ... bcdDevice= 0.01 ... According to the USB 2.0 specification that is the: "Device release number in binary-coded decimal" The specification doesn't say anything about the format of the device release number, but a number beginning with "0" suggests that the device is a prototype or a pre-release model. It could also be a counterfeit model. With those possibilities in mind, I would return the device to the vendor, if possible. Table 9-8. Standard Device Descriptor Universal Serial Bus Specification Revision 2.0 April 27, 2000 https://www.usb.org/sites/default/files/usb_20_20190524.zip
That sounds really odd to me. The USB key works as intended on Windows. If there is anything I could do to help, please let me know!
(In reply to Julien Humbert from comment #13) > That sounds really odd to me. The USB key works as intended on Windows. Thanks for checking that. > If there is anything I could do to help, please let me know! I suggest updating the bug summary: 'Kingston USB key repeatedly disconnected after "Set SEL for device-initiated U2 failed."' You could also try a 5.7 kernel from here: https://bodhi.fedoraproject.org/updates/?packages=kernel Click the "Builds" tab for a kernel and follow the link to Koji. To install, download kernel-core and kernel-modules to an empty directory and run: # dnf install kernel*.rpm NB: The 5.7 kernels are pre-release, so take appropriate precautions.
Created attachment 1693775 [details] Dell XPS 7390 5.7.0-0.rc7.1.fc33 dmesg
Still failing with 5.7.0 kernel on the Dell XPS 13 laptop. Unfortunately root is needed to get kernel logs on Android devices, but the Kingston USB key works on the Nvidia Shield TV (2015 edition) which uses a 4.9.140 kernel.
Thanks for testing with 5.7.0-0.rc7.1.fc33 and with the other hosts. This problem might get more attention with an upstream bug report under Drivers/USB: https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=USB&order=bug_id&product=Drivers&query_format=advanced Although Android kernels may be very different from Fedora kernels, the Android kernel version can be found on phones and tablets under "Settings" -> "About ...".
Created attachment 1710656 [details] Patch to add NO_LPM quirk Hi, I reported the bug on the upstream kernel Bugzilla here: https://bugzilla.kernel.org/show_bug.cgi?id=208257 Alan Stern kindly helped me found out what was going wrong and discovered that disabling Link Power Management fixed the issue and wrote the attached patch. Would it be possible to build a test kernel, or could you help me out building one? Thanks
Hi there, Anyone able to help me test the provided patch? Upstream is asking me to test it to see if the problem is fixed. Any help on this topic would be greatly appreciated.
Hi there, Fedora 33 is around the corner, but this bug is still present. Could anyone help test the patch so it gets integrated into the kernel ?
(In reply to Julien Humbert from comment #20) > Fedora 33 is around the corner, but this bug is still present. Could anyone > help test the patch so it gets integrated into the kernel ? I have prepared a Fedora kernel test-build with the patch added, this is currently building here: https://koji.fedoraproject.org/koji/taskinfo?taskID=54473681 Note it takes a couple of hour for the build to complete. See here for some generic instructions on installing a kernel test-build directly from koji (the Fedora buildsystem): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
(In reply to Hans de Goede from comment #21) > (In reply to Julien Humbert from comment #20) > > Fedora 33 is around the corner, but this bug is still present. Could anyone > > help test the patch so it gets integrated into the kernel ? > > I have prepared a Fedora kernel test-build with the patch added, this is > currently building here: > https://koji.fedoraproject.org/koji/taskinfo?taskID=54473681 > > Note it takes a couple of hour for the build to complete. > > See here for some generic instructions on installing a kernel test-build > directly from koji (the Fedora buildsystem): > https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Thank you for the build and the instructions! I've tested the build and I was able to read and copy to the Kingston USB flash drive! Until the change is integrated into the mainline kernel, which could take some time, could this patch be integrated to the Fedora kernel?
I expect the patch to be merged upstream now soon and then to get added to the stable 5.8.y / 5.9.y series relatively quickly. So I do not think it is necessary to carry this as a downstream patch. In the mean time you can add: "usbcore.quirks=0951:1666:k" to your kernel commandline as a workaround. You can do this by running: sudo grubby --update-kernel=ALL --args="usbcore.quirks=0951:1666:k"