Created attachment 172668 [details]
dmesg output from Intel NUC running 10.3-RELEASE
Had 10.2-RELEASE running stable on an Intel NUC (i5) for the past six months. Decided to upgrade to 10.3-RELEASE using freebsd-update.
On the first boot with the new kernel I began experiencing problems with the USB subsystem -- specifically, neither my USB keyboard nor USB mouse work anymore. Instead I get several warnings in the logs (and on the console):
Jul 18 12:16:47 ren kernel: usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
Jul 18 12:17:19 ren last message repeated 3 times
Jul 18 12:17:30 ren kernel: usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
Jul 18 12:17:30 ren kernel: ugen0.2: <Unknown> at usbus0 (disconnected)
Jul 18 12:17:30 ren kernel: uhub_reattach_port: could not allocate new device
When I boot without keyboard and mouse the machine boots as quickly as it usually does and I see no obvious error messages.
I completed the upgrade process by calling "freebsd-update install" again to install the userspace stuff. Rebooted. Did another fetch and install to make sure I was up to date.
I searched online for the problem and found this thread:
and tried the suggested solution (tweak to /boot/loader.conf). It had no effect, so I removed it.
I have attached dmesg output of two boot cycles -- the first with the keyboard (and the errors), and the second without. In both cases, the XHCI and EHCI controllers appear to be recognized without error.
ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.1: <XHCI root HUB 0x8086> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen1.2: <product 0x8001 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
I want to emphasize that the keyboard and mouse are the same units as prior to the upgrade and were working with 10.2 without issue so this isn't strictly a hardware compatibility issue. Something changed in the 10.3 USB subsystem that breaks select (low speed in this case) USB device instantiation.
Note also that I am plugging the keyboard and mouse into the rear ports of the NUC, which I believe are USB2 only. The Superspeed ports are on the front. I tried plugging the keyboard into the superspeed ports and I have the same problem. The devices won't instantiate.
If you copy sys/dev/usb/controller/xhci*.[ch] from 10.2 to 10.3 and build a new kernel - does the problem go away?
Not sure I want to just blindly copy the entire 10.2 USB subsystem inside a 10.3 tree. Even if it works, it doesn't tell me much other than someone hosed the 10.3 USB subsystem....which is pretty much what I know already. This is not a hardware fault. Therefore it must be a software problem.
In any case, the original 10.2 tree was deleted during the upgrade so I'd have to seek out that source and build a custom 10.3 kernel with the USB subsystem replaced with 10.2 stuff. Not work I have time for at the moment, but I will put it on my list.
I'd rather play around with debug level and attach the relevant logs if you or someone else can provide guidance with respect to the debug level desired / required.
You might find the following two patches useful candidates for testing:
Ping - were you able to test the above mentioned patches?
(In reply to Hans Petter Selasky from comment #4)
No. Unfortunately my work schedule has simply not permitted evaluating them.
These patches have now been MFC'ed to 10-stable.
While playing with this again today I noticed something I didn't report earlier -- when the machine initially boots into the bootloader and the bootloader is counting down, my keyboard works and I can press return to accelerate the boot of the selected kernel. But once execution jumps to the kernel I get the problem I previously outlined. So basically whatever USB code is crammed into the bootloader works, while the USB code in 10.3-RELEASE generic kernel does not. This further highlights that this is a software bug rather than a hardware issue.
Point of reference: updated my system again, no patches received on 10.3-RELEASE since last update a couple weeks ago (as expected), USB problem still exists in 10.3-RELEASE-p7 at this time.
The bootloader is using the BIOS USB code. Try disabling USB legacy support in the BIOS.
BTW: The patches are in 10-stable not the release branches.
(In reply to Hans Petter Selasky from comment #8)
> Try disabling USB legacy support in the BIOS.
What will that do in this context? Not opposed to trying it. I just want to know what your aim is in suggesting it.
> BTW: The patches are in 10-stable not the release branches.
Yes, I know. Trying to figure out if I can use freebsd-upgrade to move to that branch. I'm more of a Linux guy, built my own custom distros from source, etc. but on FreeBSD I'm still a bit clueless. If I can switch to the 10 releng branch easily I'm willing to do that simply to validate the patches. I just don't have the time to deal with a custom kernel build at the moment.
Just upgraded to 11.0-RELEASE-P0 and USB is still broken. So I suppose while the patches were applied to 10.3-releng they were not pushed forward to 11 despite that being in a pre-release state at the time. Those patches need to go into 11 now. USB is utterly broken for Intel NUCs in 10.3 and 11.0.
Are you saying a kernel built from 11-stable does not exhibit any problems?
11.0 will not have the patches I've mentioned.
(In reply to Hans Petter Selasky from comment #11)
I haven't built the 11 kernel from source, mainly because I haven't had the time to babysit a kernel build or risk screwing this system up (very likely building from source, less likely installing via packages) as it's a production host.
So what I'm hearing is that the patches that apparently went into 10-stable are not in 11-release, but are in 11-stable and I need to build 11-stable from source to test them. Please correct me if I'm wrong and I'll try to allocate some time to build the 11-stable kernel from source.
Yes, that's correct.
@Doug, please don't hesitate re-open this issue if it is still reproducible in any currently supported version branches (stable/11, stable12, current)