Summary: | USB_ERR_TIMEOUT errors after upgrade from 10.2 to 10.3 | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Doug <dwvcfii> | ||||
Component: | usb | Assignee: | Kubilay Kocak <koobs> | ||||
Status: | Closed Feedback Timeout | ||||||
Severity: | Affects Only Me | CC: | hselasky, usb | ||||
Priority: | --- | Keywords: | needs-qa, regression | ||||
Version: | 10.3-RELEASE | ||||||
Hardware: | amd64 | ||||||
OS: | Any | ||||||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212021 | ||||||
Attachments: |
|
Description
Doug
2016-07-18 16:40:37 UTC
Hi, 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? --HPS 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. Hi, You might find the following two patches useful candidates for testing: https://svnweb.freebsd.org/changeset/base/304597 https://svnweb.freebsd.org/changeset/base/304629 --HPS 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. Hi, These patches have now been MFC'ed to 10-stable. --HPS 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. --HPS (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. Hi Doug, Are you saying a kernel built from 11-stable does not exhibit any problems? 11.0 will not have the patches I've mentioned. --HPS (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. --HPS @Doug, please don't hesitate re-open this issue if it is still reproducible in any currently supported version branches (stable/11, stable12, current) |