### THIS ISSUE IS AN UPSTREAM BUG ### I declare this an upstream bug, because a different kernel made by the surface-kernel team, has the same bug in kernel 5.5.8-1 . 1. Please describe the problem: The usb stack seems to have a major flaw in version 5.5.x . Device: "Surface Pro 4" The Surfaceseries Keyboard "TypeCover" is detected on boot, as it should: [ 2.103526] usb 1-7: Product: Surface Type Cover [ 2.107058] input: Microsoft Surface Type Cover Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input1 [ 2.158660] input: Microsoft Surface Type Cover Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input2 [ 2.158821] input: Microsoft Surface Type Cover Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input3 [ 2.158898] input: Microsoft Surface Type Cover as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input4 [ 2.158937] input: Microsoft Surface Type Cover Touchpad as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input5 [ 2.158977] input: Microsoft Surface Type Cover as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input6 [ 2.159003] input: Microsoft Surface Type Cover as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input7 [ 2.159030] input: Microsoft Surface Type Cover as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input8 [ 2.159103] hid-generic 0003:045E:09C0.0001: input,hiddev96,hidraw0: USB HID v1.11 Keyboard [Microsoft Surface Type Cover] on usb-0000:00:14.0-7/input0 [ 2.309997] input: Microsoft Surface Type Cover Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input10 [ 2.361784] input: Microsoft Surface Type Cover Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input11 [ 2.361873] input: Microsoft Surface Type Cover Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input12 [ 2.361935] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input13 [ 2.361998] input: Microsoft Surface Type Cover Touchpad as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input14 [ 2.362083] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input15 [ 2.362151] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input16 [ 2.362208] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0001/input/input17 [ 2.362350] hid-multitouch 0003:045E:09C0.0001: input,hiddev96,hidraw1: USB HID v1.11 Keyboard [Microsoft Surface Type Cover] on usb-0000:00:14.0-7/input0 but afterwards, not monitored correctly. Removing and Adding this usb device does not get recognized at all in 5.5.8. I.E. after removing the device, it's still found by lsusb: Bus 002 Device 002: ID 045e:090c Microsoft Corp. SD Card Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 045e:09c0 Microsoft Corp. Surface Type Cover Bus 001 Device 003: ID 1286:204c Marvell Semiconductor, Inc. Bluetooth and Wireless LAN Composite Device Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub But the typecover got physically removed seconds ago. DMESG does not give report about usb changes, so the typecover get rendered useless until the next reboot. (which can be tricky when you can't issue a reboot anymore ;) ) The same procedure for the same device and typecover work with 5.4.19 . AFAIK: an external usb mouse gets recognized correctly. 2. What is the Version-Release number of the kernel: 5.5.8-100 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 : Yes, <= 5.4.19 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Boot device with 5.5.8 or 5.4.19 and remove&reattach the typecover, 100% reliable bug. 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. WORKING WITH 5.4.19 : [ 138.887360] usb 1-7: USB disconnect, device number 2 [ 144.481230] usb 1-7: new full-speed USB device number 4 using xhci_hcd [ 144.608858] usb 1-7: New USB device found, idVendor=045e, idProduct=09c0, bcdDevice= 0.07 [ 144.608864] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 144.608868] usb 1-7: Product: Surface Type Cover [ 144.608871] usb 1-7: Manufacturer: Microsoft [ 144.619902] input: Microsoft Surface Type Cover Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input24 [ 144.671914] input: Microsoft Surface Type Cover Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input25 [ 144.672494] input: Microsoft Surface Type Cover Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input26 [ 144.672765] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input27 [ 144.673030] input: Microsoft Surface Type Cover Touchpad as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input28 [ 144.673480] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input29 [ 144.673750] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input30 [ 144.674014] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input31 [ 144.674607] hid-multitouch 0003:045E:09C0.0004: input,hiddev96,hidraw0: USB HID v1.11 Keyboard [Microsoft Surface Type Cover] on usb-0000:00:14.0-7/input0 NOT WORKING in 5.5.8-100: ... some tumbleweed rolling by.... aka no output of usb activity at all ...
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