As per Title, FreeBSD14.0 on startup enters a usb connect / disconnect loop. usb_alloc_device: Failure selecting configuration index 0:USB_ERR_IOERROR, port 14, address 7 (ignored) This will continue, cycling through the address range. The error appears to go away after starting xorg / Mate Desktop. Bear with me, this is the first time I've used bugzilla, apologies if I have done it correctly.
this is likely highly Hardware specific, so we would need some information about the hardware to be able to triage this. Let's start with the output of pciconf -l and relevant parts of your dmesg output if your problem relates to a specific piece of hardware. You can find more tips here, https://docs.freebsd.org/en/articles/problem-reports/
(In reply to Mina Galić from comment #2) On starting this pc today, there were no errors, unable to replicate. It was on for over 2 hours with no disconnect errors at all. I did notice on dmesg that previously it stalled on waiting for USBUS1, about 8 times, then the error occurred. Today it went through USBUS1 USBUS2 and USBUS3 then booted cleanly. Nothing was changed, same keyboard / mouse combination.
Ok, this is still happening on FreeBSD 14.0-BETA3 It seems to be random, sometines system boots normally, on next boot, the usb errors return. Dmesg: uhub0: 6 ports with 6 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 21 ports with 21 removable, self powered ugen3.2: <vendor 0x8087 product 0x8001> at usbus3 uhub4 on uhub1 uhub4: <vendor 0x8087 product 0x8001, class 9/0, rev 2.00/0.00, addr 2> on usbus3 ugen1.2: <PixArt USB Optical Mouse> at usbus1 Root mount waiting for: usbus1 usbus2 usbus3 ugen2.2: <vendor 0x8087 product 0x8009> at usbus2 uhub5 on uhub2 uhub5: <vendor 0x8087 product 0x8009, class 9/0, rev 2.00/0.00, addr 2> on usbus2 uhub5: 6 ports with 6 removable, self powered uhub4: 8 ports with 8 removable, self powered Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 usb_alloc_device: Failure selecting configuration index 0:USB_ERR_TIMEOUT, port 14, addr 2 (ignored) ugen1.3: <Logitech USB Keyboard> at usbus1 ugen1.3: <Logitech USB Keyboard> at usbus1 (disconnected) ugen1.3: <Logitech USB Keyboard> at usbus1 ukbd0 on uhub3 ukbd0: <USB Keyboard> on usbus1 kbd2 at ukbd0 nvidia0: <NVIDIA GeForce RTX 2060> on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 535.104.05 Sat Aug 19 00:40:44 UTC 2023 ichsmb0: <Intel Wildcat Point SMBus controller> port 0xf040-0xf05f mem 0xef838000-0xef8380ff irq 18 at device 31.3 on pci0 smbus0: <System Management Bus> on ichsmb0 em0: link state changed to UP lo0: link state changed to UP em0: link state changed to DOWN em0: link state changed to UP ums0 on uhub3 ums0: <PixArt USB Optical Mouse, class 0/0, rev 1.10/1.00, addr 1> on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 uhid0 on uhub3 uhid0: <USB Keyboard> on usbus1 Security policy loaded: MAC/ntpd (mac_ntpd) pciconf -l: hostb0@pci0:0:0:0: class=0x060000 rev=0x06 hdr=0x00 vendor=0x8086 device=0x0c00 subvendor=0x1849 subdevice=0x0c00 pcib1@pci0:0:1:0: class=0x060400 rev=0x06 hdr=0x01 vendor=0x8086 device=0x0c01 subvendor=0x1849 subdevice=0x0c01 vgapci1@pci0:0:2:0: class=0x038000 rev=0x06 hdr=0x00 vendor=0x8086 device=0x0412 subvendor=0x1849 subdevice=0x0412 hdac1@pci0:0:3:0: class=0x040300 rev=0x06 hdr=0x00 vendor=0x8086 device=0x0c0c subvendor=0x1849 subdevice=0x0c0c xhci1@pci0:0:20:0: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x8086 device=0x8cb1 subvendor=0x1849 subdevice=0x8cb1 none0@pci0:0:22:0: class=0x078000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x8cba subvendor=0x1849 subdevice=0x8cba em0@pci0:0:25:0: class=0x020000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x15a1 subvendor=0x1849 subdevice=0x15a1 ehci0@pci0:0:26:0: class=0x0c0320 rev=0x00 hdr=0x00 vendor=0x8086 device=0x8cad subvendor=0x1849 subdevice=0x8cad hdac2@pci0:0:27:0: class=0x040300 rev=0x00 hdr=0x00 vendor=0x8086 device=0x8ca0 subvendor=0x1849 subdevice=0x1151 pcib2@pci0:0:28:0: class=0x060400 rev=0xd0 hdr=0x01 vendor=0x8086 device=0x8c90 subvendor=0x1849 subdevice=0x8c90 pcib3@pci0:0:28:2: class=0x060401 rev=0xd0 hdr=0x01 vendor=0x8086 device=0x244e subvendor=0x1849 subdevice=0x244e ehci1@pci0:0:29:0: class=0x0c0320 rev=0x00 hdr=0x00 vendor=0x8086 device=0x8ca6 subvendor=0x1849 subdevice=0x8ca6 isab0@pci0:0:31:0: class=0x060100 rev=0x00 hdr=0x00 vendor=0x8086 device=0x8cc6 subvendor=0x1849 subdevice=0x8cc6 ahci0@pci0:0:31:2: class=0x010601 rev=0x00 hdr=0x00 vendor=0x8086 device=0x8c82 subvendor=0x1849 subdevice=0x8c82 ichsmb0@pci0:0:31:3: class=0x0c0500 rev=0x00 hdr=0x00 vendor=0x8086 device=0x8ca2 subvendor=0x1849 subdevice=0x8ca2 vgapci0@pci0:1:0:0: class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1e89 subvendor=0x1043 subdevice=0x8798 hdac0@pci0:1:0:1: class=0x040300 rev=0xa1 hdr=0x00 vendor=0x10de device=0x10f8 subvendor=0x1043 subdevice=0x8798 xhci0@pci0:1:0:2: class=0x0c0330 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1ad8 subvendor=0x1043 subdevice=0x8798 none1@pci0:1:0:3: class=0x0c8000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1ad9 subvendor=0x1043 subdevice=0x8798 pcib4@pci0:3:0:0: class=0x060401 rev=0x03 hdr=0x01 vendor=0x1b21 device=0x1080 subvendor=0x1849 subdevice=0x1080
Can you add the output of usbconfig -v list ?
What type of board is it ? Is the keyboard directly attached or via some usb hub ?
(In reply to William Wallis from comment #4) Also, can you put the output of pciconf -lBbcevV somewhere on a website ? It's probably a bit verbose, so...
(In reply to Kurt Jaeger from comment #6) New keyboard directly attached to from USB2 port on the front of the server. No USB hub used at all.
(In reply to Kurt Jaeger from comment #5) https://pastebin.com/SJ87FyUK USBconfig -v list
(In reply to Kurt Jaeger from comment #7) https://pastebin.com/JnaC4A2y pciconf -v list The keyboard was attached to the server when these commands were followed. As of today (Australian time) there were no further disconnects.