[Bug 237666] repeated messages of "uhub_reattach_port: giving up port reset - device vanished"

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666

--- Comment #41 from John Baldwin <jhb at FreeBSD.org> ---
If PCI messed up you would get -1 constantly, not sporadically.  FWIW, I have
the exact same problem on my desktop since I upgraded it to 12.0.  I also use
apcupsd and usually get a couple of e-mails a day due to "losing
communications", but apcupsd is able to reattach when the device comes back so
it still works overall aside from sending spammy e-mails.

Mine is also not a laptop, it's an Ivy Bridge desktop motherboard:

smbios.planar.maker="MSI"
smbios.planar.product="Z77A-G45 (MS-7752)"

xhci0: <Intel Panther Point USB 3.0 controller> mem 0xf7100000-0xf710ffff irq
16 at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
usbus0: waiting for BIOS to give up control
xhci0: Port routing mask set to 0xffffffff
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
ehci0: <Intel Panther Point USB 2.0 controller> mem 0xf7118000-0xf71183ff irq
16 at device 26.0 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
usbus1: 480Mbps High Speed USB v2.0
...
ehci1: <Intel Panther Point USB 2.0 controller> mem 0xf7117000-0xf71173ff irq
23 at device 29.0 on pci0
usbus2: EHCI version 1.0
usbus2 on ehci1
usbus2: 480Mbps High Speed USB v2.0
...
ugen1.1: <Intel EHCI root HUB> at usbus1
ugen2.1: <Intel EHCI root HUB> at usbus2
ugen0.1: <0x8086 XHCI root HUB> at usbus0
...
uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
uhub2: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub2: 8 ports with 8 removable, self powered
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
ugen1.2: <vendor 0x8087 product 0x0024> at usbus1
uhub3 on uhub0
uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on
usbus1
ugen2.2: <vendor 0x8087 product 0x0024> at usbus2
uhub4 on uhub1
uhub4: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on
usbus2
uhub3: 6 ports with 6 removable, self powered
uhub4: 8 ports with 8 removable, self powered
ugen1.3: <American Power Conversion Back-UPS RS 1000G FW:868.L3 .D USB FW:L3>
at usbus1
ugen1.4: <vendor 0x0451 product 0x8043> at usbus1
uhub5 on uhub3
uhub5: <vendor 0x0451 product 0x8043, class 9/0, rev 2.10/1.00, addr 4> on
usbus1
uhub5: MTT enabled
uhub5: 4 ports with 4 removable, self powered
ugen1.5: <Logitech Trackball> at usbus1
ums0 on uhub5
ums0: <Logitech Trackball, class 0/0, rev 1.10/2.20, addr 5> on usbus1
ums0: 3 buttons and [XYZ] coordinates ID=0
ugen1.6: <LITE-ON Technology USB NetVista Full Width Keyboard.> at usbus1
ukbd0 on uhub5
ukbd0: <EP1 Interrupt> on usbus1
kbd2 at ukbd0

This is a typical set of logs from /var/log/messages when the UPS bounces:

Aug  9 17:35:01 ralph kernel: ugen1.3: <American Power Conversion Back-UPS RS
10
00G FW:868.L3 .D USB FW:L3> at usbus1 (disconnected)
Aug  9 17:35:01 ralph kernel: ugen1.3: <American Power Conversion Back-UPS RS
10
00G FW:868.L3 .D USB FW:L3> at usbus1
Aug  9 17:35:01 ralph kernel: interface uhid.1 already present in the KLD
'kerne
l'!
Aug  9 17:35:01 ralph kernel: linker_load_file: /boot/kernel/uhid.ko -
unsupport
ed file type
Aug  9 17:35:07 ralph apcupsd[1967]: Communications with UPS restored.

-- 
You are receiving this mail because:
You are the assignee for the bug.