Bug 1813530
| Summary: | kernel 5.5.x suffers from an usb cmd detection bug | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | customercare | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | rawhide | CC: | airlied, bskeggs, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, masami256, mchehab, meltdown03, mjg59, steved, y9t7sypezp | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2020-05-14 14:43:15 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
customercare
2020-03-14 09:21:08 UTC
Bug confirmed for 5.5.7 Bug CONFIRMED in 5.5.9-100 BUT.. with the kernel-surface line 5.5.9-2 kernel, it works. So Fedora may be one patch level away from a fixed kernel. Update: fix in 5.5.9-2 not stable ... (In reply to customercare from comment #2) > Bug CONFIRMED in 5.5.9-100 > > BUT.. with the kernel-surface line 5.5.9-2 kernel, it works. So Fedora may > be one patch level away from a fixed kernel. Thanks for your report. Could you attach complete logs for the 5.5.9 and 5.4.19 Fedora kernels after removing and reattaching the Type Cover in both cases: $ journalctl --no-hostname -k > dmesg-5.5.9.txt $ journalctl --no-hostname -k > dmesg-5.4.19.txt To attach logs to this bug report, click the "Add an attachment" link at the top of the page. For the record: How to use your Surface Type Cover https://support.microsoft.com/en-us/help/4023477/how-to-use-your-surface-type-cover kernel-5.5.9-200.fc31 is currently in updates-testing: # dnf update kernel --enablerepo=updates-testing kernel-5.5.9-200.fc31, kernel-headers-5.5.9-200.fc31, & 1 more https://bodhi.fedoraproject.org/updates/FEDORA-2020-90a64eda89 (In reply to customercare from comment #2) > Bug CONFIRMED in 5.5.9-100 > > BUT.. with the kernel-surface line 5.5.9-2 kernel, it works. So Fedora may > be one patch level away from a fixed kernel. Interesting, where are you getting the kernel-surface kernel from? And can you provide a pointer to the sources for that kernel, specifically which patches they and on top of the regular kernel? AFAIK there is a bunch of stuff in there like the IPTS support which cannot be added to regular Fedora kernels as it is not upstream. But a simple bugfix for something like this should be something which can get upstream. see comment 3 .. the euphoric "fixed" was a bit too soon, unfortunatly. I will now install 5.5.9-200.fc31. on a fc30.. systems boots quite normal. Result: NOT FIXED in 5.5.9-200 :( dmesg logs will be attached right after this message.. Created attachment 1670066 [details]
dmesg 5.4.19 WORKING USB
Created attachment 1670067 [details]
not working usb 5.5.9-200.fc31 and prior in 5.5.x
(In reply to customercare from comment #7) > see comment 3 .. the euphoric "fixed" was a bit too soon, unfortunatly. > > I will now install 5.5.9-200.fc31. on a fc30.. There a version for F30: kernel-5.5.9-100.fc30, kernel-headers-5.5.9-100.fc30, & 1 more https://bodhi.fedoraproject.org/updates/FEDORA-2020-57216f2e13 This should have installed it: # dnf update kernel --enablerepo=updates-testing Could you change the "Version" at the top of the bug report from "rawhide" to "30"? 5.5.9-100 fc30 was already tested and failed too. it not a matter of os version. There is a "disconnect" message with 5.4.19: $ grep -A5 'USB disconnect' dmesg-5.4.19.txt Mär 14 12:26:55 kernel: usb 1-7: USB disconnect, device number 2 Mär 14 12:27:02 kernel: usb 1-7: new full-speed USB device number 4 using xhci_hcd Mär 14 12:27:02 kernel: usb 1-7: New USB device found, idVendor=045e, idProduct=09c0, bcdDevice= 0.07 Mär 14 12:27:02 kernel: usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Mär 14 12:27:02 kernel: usb 1-7: Product: Surface Type Cover Mär 14 12:27:02 kernel: usb 1-7: Manufacturer: Microsoft But with 5.5.9 there is no "disconnect" message: $ grep -A5 'USB disconnect' dmesg-5.5.9.txt $ (In reply to customercare from comment #11) > 5.5.9-100 fc30 was already tested and failed too. > > it not a matter of os version. Thanks. They should be essentially the same. BTW, here is a debugging tip. In a full-screen terminal window run: $ journalctl -f That will show any changes in the log as you attach and detach devices. (In reply to Steve from comment #12) > But with 5.5.9 there is no "disconnect" message: > > $ grep -A5 'USB disconnect' dmesg-5.5.9.txt It's because, there is none.. like i wrote, the kernel does not detect the disconnect or suppresses it ( because it falsely gets marked as not removeable). Remember the 5.4er bug with nvidia pci audio devices.. I have the suspicion, something similar may happend to the usb device recognition. -> I.E. <- if the device is marked as a HUB, it gets initalized on boot, but you won't get any disconnect message from it nor would one be expected by the device driver. What if this happens to a removeable device like a hid? The kernel would ignore the disconnect, because it's impossible for a hub on a mainboard to disconnect. The physical removal will depower the device, once reconnected it gets power, but no init signal/sequence and it won't work, because it's no longer configured. And that's exactly what we can see atm. lsusb shows the physical disconnected device, because the actual disconnect msg got ignored. The typecovers internal functions like "capslock led" or "Function led" in this case, work both, because it's powered on on reattachment. If it's really marked as HUB or something else with the same consequences is hard to say without the code and even with it, it would be hard. my last kernel work was with grsec 15years ago. (In reply to customercare from comment #15) ... > -> I.E. <- if the device is marked as a HUB, it gets initalized on boot, but > you won't get any disconnect message from it nor would one be expected by > the device driver. ... Hubs are logged as such: $ grep -i hub dmesg-5.4.19.txt Mär 14 13:24:24 kernel: usbcore: registered new interface driver hub Mär 14 13:24:24 kernel: hub 1-0:1.0: USB hub found Mär 14 13:24:24 kernel: hub 1-0:1.0: 12 ports detected Mär 14 13:24:24 kernel: hub 2-0:1.0: USB hub found Mär 14 13:24:24 kernel: hub 2-0:1.0: 6 ports detected $ grep -i hub dmesg-5.5.9.txt Mär 14 13:21:29 kernel: usbcore: registered new interface driver hub Mär 14 13:21:29 kernel: hub 1-0:1.0: USB hub found Mär 14 13:21:29 kernel: hub 1-0:1.0: 12 ports detected Mär 14 13:21:29 kernel: hub 2-0:1.0: USB hub found Mär 14 13:21:29 kernel: hub 2-0:1.0: 6 ports detected What happens if you suspend and resume? It was an example, to illustrate the problem. The device does not suspend and resume, it hibernates with a reboot, as suspend on a Surface Pro is not fully implemented for this type of hw. A real problem, when you wanne make use of it :( Problem is confirmed for 5.5.10.fc30 and 5.5.13-1.surface (the prebuild kernel for surface devices ) Did this get reported to the linux-usb kernel mail list? I am having the same issue on Archlinux starting with kernel 5.5.7. UPDATE: tested Kernel 5.5.18 USB Typecover reconnect problem still persists Updating to Kernel 5.6.7 seems to have fixed this issue for me. Fixed in (at least) 5.6.11 |