I wrote a patch [0] for the finalize code issue. With that my X201i is working fine on current master besides an regression introduced in commit 7f5efd90e598320791200e03f761309ee04b58a3 [1]. With that regression USB and SD card is not working anymore and it raises the following errors:
[ 17.986754] usb 1-1: device not accepting address 2, error -110 [ 18.110095] usb 1-1: new high-speed USB device number 3 using ehci-pci [ 18.200089] usb 2-1: device not accepting address 2, error -110 [ 18.323421] usb 2-1: new high-speed USB device number 3 using ehci-pci [ 34.200083] usb 1-1: device not accepting address 3, error -110 [ 34.200169] usb usb1-port1: attempt power cycle [ 34.413364] usb 2-1: device not accepting address 3, error -110 [ 34.413439] usb usb2-port1: attempt power cycle [ 34.636752] usb 1-1: new high-speed USB device number 4 using ehci-pci [ 34.850085] usb 2-1: new high-speed USB device number 4 using ehci-pci [ 45.293417] usb 1-1: device not accepting address 4, error -110 [ 45.416732] usb 1-1: new high-speed USB device number 5 using ehci-pci [ 45.506783] usb 2-1: device not accepting address 4, error -110 [ 45.630088] usb 2-1: new high-speed USB device number 5 using ehci-pci [ 56.173393] usb 1-1: device not accepting address 5, error -110 [ 56.173445] usb usb1-port1: unable to enumerate USB device [ 56.386753] usb 2-1: device not accepting address 5, error -110 [ 56.386845] usb usb2-port1: unable to enumerate USB device
Additionally there are some IRQ errors inside the kernel messages like
can't derive routing for PCI INT A PCI INT A: no GSI
for different devices which seem related to the change in [1].
Cheers, Matthias
[0] https://review.coreboot.org/#/c/coreboot/+/25914/ [1] https://review.coreboot.org/#/c/coreboot/+/22859/
On 29/04/18 14:14, Kyösti Mälkki wrote:
On Sun, Apr 29, 2018 at 1:35 PM, Nicola Corna nicola@corna.info wrote:
April 28, 2018 5:59 PM, "Nico Huber" nico.h@gmx.de wrote:
Yes, that's very likely a problem. It looks like the whole finalize code path of the X201 was untested all the time (even on resume). I don't remember if EHCI debug works in SMM? If it does, you could enable log- ging for the SMI handler as well (if you want to debug it).
Nico
Attached you can find the log with the SMM debug enabled, but it doesn't seem to me much different from the non-debug log.
Nicola
DEBUG_SMI does not output to EHCI, I have considered it too unstable.
You can try your luck with attached patch to have DEBUG_SMI=y output on EHCI debug. EHCI console code does not take precautions against someone else touching the same register set so it's likely to fail once payload and/or OS loads its EHCI driver, possibly making USB media and keyboard unusable as well.
Kyösti