Bug 1813530 - kernel 5.5.x suffers from an usb cmd detection bug
Summary: kernel 5.5.x suffers from an usb cmd detection bug
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-14 09:21 UTC by customercare
Modified: 2020-05-14 14:43 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-14 14:43:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmesg 5.4.19 WORKING USB (73.08 KB, text/plain)
2020-03-14 11:31 UTC, customercare
no flags Details
not working usb 5.5.9-200.fc31 and prior in 5.5.x (72.03 KB, text/plain)
2020-03-14 11:31 UTC, customercare
no flags Details

Description customercare 2020-03-14 09:21:08 UTC
### 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 ...

Comment 1 customercare 2020-03-14 10:19:32 UTC
Bug confirmed for 5.5.7

Comment 2 customercare 2020-03-14 10:45:30 UTC
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.

Comment 3 customercare 2020-03-14 10:49:34 UTC
Update: fix in 5.5.9-2 not stable ...

Comment 4 Steve 2020-03-14 10:53:26 UTC
(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

Comment 5 Steve 2020-03-14 11:03:26 UTC
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

Comment 6 Hans de Goede 2020-03-14 11:07:30 UTC
(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.

Comment 7 customercare 2020-03-14 11:30:46 UTC
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..

Comment 8 customercare 2020-03-14 11:31:15 UTC
Created attachment 1670066 [details]
dmesg 5.4.19 WORKING USB

Comment 9 customercare 2020-03-14 11:31:50 UTC
Created attachment 1670067 [details]
not working usb 5.5.9-200.fc31 and prior in 5.5.x

Comment 10 Steve 2020-03-14 11:43:06 UTC
(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"?

Comment 11 customercare 2020-03-14 12:09:22 UTC
5.5.9-100 fc30 was already tested and failed too.  

it not a matter of os version.

Comment 12 Steve 2020-03-14 12:11:26 UTC
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
$

Comment 13 Steve 2020-03-14 12:13:46 UTC
(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.

Comment 14 customercare 2020-03-14 14:12:57 UTC
(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).

Comment 15 customercare 2020-03-14 14:29:59 UTC
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.

Comment 16 Steve 2020-03-14 16:36:46 UTC
(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

Comment 17 Steve 2020-03-14 16:41:44 UTC
What happens if you suspend and resume?

Comment 18 customercare 2020-03-14 16:46:37 UTC
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 :(

Comment 19 customercare 2020-03-29 16:18:15 UTC
Problem is confirmed for 5.5.10.fc30 and 5.5.13-1.surface (the prebuild kernel for surface devices )

Comment 20 Neal 2020-04-06 22:55:47 UTC
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.

Comment 21 customercare 2020-04-29 20:55:28 UTC
UPDATE: tested Kernel 5.5.18 USB Typecover reconnect problem still persists

Comment 22 Neal 2020-04-30 22:47:03 UTC
Updating to Kernel 5.6.7 seems to have fixed this issue for me.

Comment 23 customercare 2020-05-14 14:42:06 UTC
Fixed in (at least) 5.6.11


Note You need to log in before you can comment on or make changes to this bug.