Bug 218513 - USB fails to initialize
Summary: USB fails to initialize
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 11.0-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2017-04-09 21:10 UTC by rkoberman
Modified: 2017-12-12 05:31 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rkoberman 2017-04-09 21:10:19 UTC
11-Stable no longer works with my USB controllers. My old kernel, r314236, works fine, but my kernel of April 6 (r316552) does not see any USB devices.

Any recent changes to the USB software that might explain this? I will be trying to track it down by bisecting, but this will be slow die to lack of time. (Moving in two days.)

I see the following from the boot:
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xf252a000-0xf252a3ff irq 16 at device 26.0 on pci0
usbus0: EHCI version 1.0
usbus0 on ehci0
[...]
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xf2529000-0xf25293ff irq 23 at device 29.0 on pci0
sbus1: EHCI version 1.0
usbus1 on ehci1
[...]
usbus0: 480Mbps High Speed USB v2.0
usbus1: 480Mbps High Speed USB v2.0
ugen1.1: <Intel EHCI root HUB> at usbus1
uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
ugen0.1: <Intel EHCI root HUB> at usbus0
uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
uhub0: 3 ports with 3 removable, self powered
uhub1: 3 ports with 3 removable, self powered
usbus0: port reset timeout
usbus1: port reset timeout
uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1
uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1

usbconfig -d ugen1.1 reset produced:
Apr  9 09:15:11 rogue kernel: uhub1: at usbus0, port 1, addr 1 (disconnected)
Apr  9 09:15:11 rogue kernel: uhub1:
Apr  9 09:15:11 rogue kernel: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
Apr  9 09:15:12 rogue kernel: uhub1: 3 ports with 3 removable, self powered

From pcoconf -lv:
ehci0@pci0:0:26:0:	class=0x0c0320 card=0x21cf17aa chip=0x1c2d8086 rev=0x04 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller'
    class      = serial bus
    subclass   = USB

I have an almost GENERIC kernel with only:
nooptions         SCHED_ULE               # ULE scheduler
options           SCHED_4BSD              # 4BSD scheduler
options		IEEE80211_DEBUG

src.conf contains:
ogue# cat /etc/src.conf
PORTS_MODULES=emulators/virtualbox-ose-kmod sysutils/lsof
WITHOUT_ATM=true
WITHOUT_FLOPPY=true
WITHOUT_GPIB=YES
WITHOUT_I4B==YES
WITHOUT_IPFILTER=true
WITHOUT_LPR=true
WITHOUT_NCP=YES
WITHOUT_PF=YES
WITHOUT_PPP=true
WITHOUT_PROFILE=YES
WITHOUT_SENDMAIL=true
Comment 1 rkoberman 2017-04-10 03:29:54 UTC
The issue is the update to llvm-4.0. With r316422, USB works fine. llvm-4.0 was MFCed in r316423 and USB is not working with that kernel.  The commit did not touch and USB specific code. Should dim and/or emaste be involved? I can't think pulling the update is reasonable, but losing USB support i pretty serious, too.
Comment 2 Hans Petter Selasky freebsd_committer freebsd_triage 2017-04-10 13:50:12 UTC
Hi,

You might want to do "objdump -Dx /boot/kernel/kernel" and compare the output from the two different compilers.

--HPS
Comment 3 rkoberman 2017-04-10 17:35:26 UTC
(In reply to Hans Petter Selasky from comment #2)
The dumps are 441 MB and 438 MB and the kernels are significantly different. just the size differs by about 171 MB. They may be downloaded from http://ykoberman.dlinkddns.com/FreeBSD.

ATM I am in the process of moving. It was my intent to make a backup of my system prior to packing it that caused me to use a USB drive and that is how I discovered the issue. It also means that my server will be down for a couple of days starting (probably) in about 5 or 6 hours, though I may leave it up overnight as it takes little time to pack up and travels in a separate vehicle from most stuff (where the backup disks sit).

Would it be useful to have the kernels there?
Comment 4 david 2017-04-18 19:59:55 UTC
localhost(11.0-S)[5] uname -a
FreeBSD localhost 11.0-STABLE FreeBSD 11.0-STABLE #315  r317083M/317085:1100512: Tue Apr 18 05:32:22 PDT 2017     root@localhost:/common/S1/obj/usr/src/sys/CANARY  amd64
localhost(11.0-S)[6] tail -0F /var/log/messages
Apr 18 19:57:39 localhost kernel: ugen0.2: <JMicron USB Mass Storage Device> at usbus0
Apr 18 19:57:39 localhost kernel: umass0 on uhub0
Apr 18 19:57:39 localhost kernel: umass0: <MSC Bulk-Only Transfer> on usbus0
Apr 18 19:57:39 localhost kernel: umass0:  SCSI over Bulk-Only; quirks = 0x8100
Apr 18 19:57:39 localhost kernel: umass0:5:0: Attached to scbus5
Apr 18 19:57:39 localhost kernel: da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
Apr 18 19:57:39 localhost kernel: da0: <M4-CT512 M4SSD2 0103> Fixed Direct Access SPC-4 SCSI device
Apr 18 19:57:39 localhost kernel: da0: Serial Number DB9876543211161
Apr 18 19:57:39 localhost kernel: da0: 400.000MB/s transfers
Apr 18 19:57:39 localhost kernel: da0: 488386MB (1000215216 512 byte sectors)
Apr 18 19:57:39 localhost kernel: da0: quirks=0x2<NO_6_BYTE>

[That was the handiest USB device I happened to have....]
Comment 5 Hans Petter Selasky freebsd_committer freebsd_triage 2017-04-18 20:05:13 UTC
Hi,

Maybe you can repeat the dump for usb,ehci,uhci,ohci,xhci .ko only.

Do you feel certain the compiler was properly built?

--HPS
Comment 6 rkoberman 2017-04-19 22:37:40 UTC
Dumps of the usb, ehci, uhci, xhci and ohci modules are all now available at http://ykoberman.dlinkddns.com/FreeBSD/ and are labeled for 316422 (LLVM3.9) and 316423 (LLVM4.0). Note that this system has no xhci capability.

David Wolfskill has success with a newer Lynx Point based system. This may be limited to the Cougar Point chipset.

Are there good places I might insert printf statement in the code to further narrow this down? 

I plan to build a 316423 kernel without USB support so modules may be loaded to make testing and debugging easier. I realize there there is a possibility that this kernel may work.

The compiler built without any fatal error with a standard "make -j6 buildworld".
Comment 7 rkoberman 2017-04-24 01:56:03 UTC
This is really feeling like a race.

I built a kernel without any USB devices. I boot to single user and, when I load the USB device drivers, everything works. I can plug in a thumb drive and it works normally.

If I boot and load the USB drivers at the "ok" loader prompt and then boot, the USB fails. I can only guess that, with the 4.0 compiled kernel, ehci or usb load before something is ready and it fails to properly initialize.

Not sure where to go from here, but I will update my stable system to the latest and see how things work.
Comment 8 leeb 2017-12-11 22:22:07 UTC
Was any resolution to this issue found?  

I'm having problems installing onto a Dell R630 with 11-RELEASE/STABLE (kernel can't see USB boot media), 12-CURRENT (bootloader freezes) and 10.4-RELEASE (panic) as stock mini-memstick downloads.  For reference Xen 7.2 is working on the box, so I know the hardware is good and the keyboard works at the loader.

I'm was about to upgrade the BIOS before troubling the ML and saw this.
Comment 9 rkoberman 2017-12-12 05:31:01 UTC
(In reply to leeb from comment #8)
I should close this ticket. It was clearly a race and it vanished after a system update shortly after the discussion of this ticket. It was simply a failure to connect to the USB hub at boot time and even slight adjustments that affected timing eliminated the issue.

I'd suggest that you post a message about these problems you are seeing to the usb@freebsd.org list. Include details on exactly what you are seeing. hte more detailed, the better.

I do know that the current (12.0) boot is in a state of flux and has been a bit unstable, but 10 and 11 should be fine.

Sorry that I can't be of more help.