Can't reattach USB devices (Lenovo bug?)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Can't reattach USB devices (Lenovo bug?)

Evilham
Hello,

at first I thought I had found a regression in CURRENT (2020-01-19), and now I'm not so sure since, before reporting I rolled back a recent BIOS upgrade and that got rid of the issue.

First of all, the hardware: Lenovo ThinkPad A485 (AMD Ryzen
processor).

The issue (BIOS v1.28[1]) being that any USB device: would work on
first plug, but if unplugged and plugged again, it wouldn't work
(see dmesg below).

Downgrading to BIOS v1.24 results in the issue disappearing.

How should this be dealt with? Could this be something FreeBSD
needs better support for? or is it entirely on Lenovo?
If the former, how can I help provide more information/testing(*)?
If the latter, should I inform Lenovo of the issue? If anyone has
experience with that, I'd appreciate pointers as to how to provide
them with information in a way that makes it somewhat likely that
things get solved.

[1]: BIOS Release notes:
https://download.lenovo.com/pccbbs/mobiles/r0wuj60w.txt
(*): Helping spot bugs and provide information/testing is why I'm
running CURRENT after all

Just FTR: I also experienced random kernel panics [2] with
versions v1.22 and v1.16 of the BIOS, so maybe Lenovo is being
unreasonable/unreliable about BIOS upgrades.
In any case I am curious as to how other OS deal with this class
of issues and how FreeBSD could (if possible at all) work better
in these cases.

[2]: Kernel panic solved by BIOS upgrade (to v1.24) see:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351

Also FTR, this was the contents of dmesg with BIOS v1.28 and CURRENT as of 2020-01-19:
(notice there are multiple disconnect and reconnect attempts of
different devices)

ugen1.2: <ALCOR USB Hub 2.0> at usbus1 (disconnected)
uhub4: at uhub1, port 1, addr 1 (disconnected)
ugen1.3: <BTC USB Multimedia Keyboard> at usbus1 (disconnected)
ukbd0: at uhub4, port 2, addr 2 (disconnected)
ukbd0: detached
uhid0: at uhub4, port 2, addr 2 (disconnected)
uhid0: detached
ugen1.4: <ALCOR USB Hub 2.0> at usbus1 (disconnected)
uhub5: at uhub4, port 4, addr 3 (disconnected)
ugen1.5: <SteelSeries SteelSeries Rival 310 eSports Mouse> at
usbus1 (disconnected)
uhid1: at uhub5, port 1, addr 4 (disconnected)
uhid1: detached
ums0: at uhub5, port 1, addr 4 (disconnected)
ums0: detached
ukbd1: at uhub5, port 1, addr 4 (disconnected)
ukbd1: detached
uhub5: detached
uhub4: detached
ugen1.2: <ALCOR USB Hub 2.0> at usbus1
uhub4 on uhub1
uhub4: <ALCOR USB Hub 2.0, class 9/0, rev 2.00/7.02, addr 1> on
usbus1
acpi_ec0: EcCommand: no response to 0x84
uhub4: 4 ports with 4 removable, self powered
acpi_ec0: EcCommand: no response to 0x84
acpi_ec0: EcCommand: no response to 0x84
acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE
usbd_setup_device_desc: getting device descriptor at addr 2
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 2
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 2
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 2
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 2
failed, USB_ERR_TIMEOUT
ugen1.3: <Unknown > at usbus1 (disconnected)
uhub_reattach_port: could not allocate new device
ugen1.2: <ALCOR USB Hub 2.0> at usbus1 (disconnected)
uhub4: at uhub1, port 1, addr 1 (disconnected)
uhub4: detached
usbd_setup_device_desc: getting device descriptor at addr 1
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 1
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 1
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 1
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 1
failed, USB_ERR_TIMEOUT
ugen1.2: <Unknown > at usbus1 (disconnected)
uhub_reattach_port: could not allocate new device
usbd_setup_device_desc: getting device descriptor at addr 1
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 1
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 1
failed, USB_ERR_TIMEOUT
usbd_setup_device_desc: getting device descriptor at addr 1
failed, USB_ERR_TIMEOUT
--
Evilham
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Can't reattach USB devices (Lenovo bug?)

Hans Petter Selasky-6
On 2020-01-20 13:12, Evilham wrote:

> Hello,
>
> at first I thought I had found a regression in CURRENT (2020-01-19), and
> now I'm not so sure since, before reporting I rolled back a recent BIOS
> upgrade and that got rid of the issue.
>
> First of all, the hardware: Lenovo ThinkPad A485 (AMD Ryzen processor).
>
> The issue (BIOS v1.28[1]) being that any USB device: would work on first
> plug, but if unplugged and plugged again, it wouldn't work (see dmesg
> below).
>
> Downgrading to BIOS v1.24 results in the issue disappearing.
>
> How should this be dealt with? Could this be something FreeBSD needs
> better support for? or is it entirely on Lenovo?
> If the former, how can I help provide more information/testing(*)?
> If the latter, should I inform Lenovo of the issue? If anyone has
> experience with that, I'd appreciate pointers as to how to provide them
> with information in a way that makes it somewhat likely that things get
> solved.
>
> [1]: BIOS Release notes:
> https://download.lenovo.com/pccbbs/mobiles/r0wuj60w.txt
> (*): Helping spot bugs and provide information/testing is why I'm
> running CURRENT after all
>
> Just FTR: I also experienced random kernel panics [2] with versions
> v1.22 and v1.16 of the BIOS, so maybe Lenovo is being
> unreasonable/unreliable about BIOS upgrades.
> In any case I am curious as to how other OS deal with this class of
> issues and how FreeBSD could (if possible at all) work better in these
> cases.
>
> [2]: Kernel panic solved by BIOS upgrade (to v1.24) see:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351
>
> Also FTR, this was the contents of dmesg with BIOS v1.28 and CURRENT as
> of 2020-01-19:
> (notice there are multiple disconnect and reconnect attempts of
> different devices)
>
> ugen1.2: <ALCOR USB Hub 2.0> at usbus1 (disconnected)
> uhub4: at uhub1, port 1, addr 1 (disconnected)
> ugen1.3: <BTC USB Multimedia Keyboard> at usbus1 (disconnected)
> ukbd0: at uhub4, port 2, addr 2 (disconnected)
> ukbd0: detached
> uhid0: at uhub4, port 2, addr 2 (disconnected)
> uhid0: detached
> ugen1.4: <ALCOR USB Hub 2.0> at usbus1 (disconnected)
> uhub5: at uhub4, port 4, addr 3 (disconnected)
> ugen1.5: <SteelSeries SteelSeries Rival 310 eSports Mouse> at usbus1
> (disconnected)
> uhid1: at uhub5, port 1, addr 4 (disconnected)
> uhid1: detached
> ums0: at uhub5, port 1, addr 4 (disconnected)
> ums0: detached
> ukbd1: at uhub5, port 1, addr 4 (disconnected)
> ukbd1: detached
> uhub5: detached
> uhub4: detached
> ugen1.2: <ALCOR USB Hub 2.0> at usbus1
> uhub4 on uhub1
> uhub4: <ALCOR USB Hub 2.0, class 9/0, rev 2.00/7.02, addr 1> on usbus1
> acpi_ec0: EcCommand: no response to 0x84
> uhub4: 4 ports with 4 removable, self powered
> acpi_ec0: EcCommand: no response to 0x84
> acpi_ec0: EcCommand: no response to 0x84
> acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE

^^^ my best guess is this is ACPI related :-(

ACPI has own debugging flags and options.

--HPS
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Can't reattach USB devices (Lenovo bug?)

Evilham
On dl., gen. 20 2020, Hans Petter Selasky wrote:
> ^^^ my best guess is this is ACPI related :-(
>
> ACPI has own debugging flags and options.
>
> --HPS

Thank you, now reading handbook/acpi-overview.html in order to try
to get more info.
--
Evilham
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"