regression: if_rue device doesn't attach on HEAD
I have a USB nic which worked in 9.1 but regressed in HEAD and appears as an unrecognized device. I have not had time to properly bisect this issue. Any suggestions or pointers are appreciated: ugen2.3: USB 10100 LAN USBKR100 bLength = 0x0012 bDescriptorType = 0x0001 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x idVendor = 0x0bda idProduct = 0x8150 bcdDevice = 0x0100 iManufacturer = 0x0001 USBK100 LAN iProduct = 0x0002 USB 10/100 LAN iSerialNumber = 0x0003 8628 bNumConfigurations = 0x0001 -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: regression: if_rue device doesn't attach on HEAD
On 4 January 2013 03:21, Hans Petter Selasky hsela...@c2i.net wrote: Did you kldload if_rue? Did you enable devd? Default Default - it worked in 9.1 so I assumed it should work the same in HEAD. I'll try explicitly doing so when I get home. -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: regression: if_rue device doesn't attach on HEAD
On 4 January 2013 03:21, Hans Petter Selasky hsela...@c2i.net wrote: Did you kldload if_rue? Yes. This did nothing to help. Did you enable devd? Yes, this was already enabled. Use(full|less) debug info: I now see xhci_do_command: Command timeout! device init 2 failed USB_ERR_TIMEOUT which I did not see before in dmesg. -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: regression: if_rue device doesn't attach on HEAD
On 4 January 2013 16:41, Hans Petter Selasky hsela...@c2i.net wrote: This typically means set address failed, which in the XHCI is done in HW. I'll look into if I find some time. Not sure what we can do about it. As I mentioned - it works in 9.1 so *something* regressed. You can try set first set config 255 and the config 0 on the parent HUB of this device using usbconfig. I'm not sure what you mean here. What command should I run? -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: regression: if_rue device doesn't attach on HEAD
On 4 January 2013 17:01, Hans Petter Selasky hsela...@c2i.net wrote: On Friday 04 January 2013 22:50:38 Eitan Adler wrote: On 4 January 2013 16:41, Hans Petter Selasky hsela...@c2i.net wrote: This typically means set address failed, which in the XHCI is done in HW. I'll look into if I find some time. Not sure what we can do about it. Hi, As I mentioned - it works in 9.1 so *something* regressed. The only which I can think of which caused this is the recently added ETRON patches. You can look in the xhci.c revision history and revert from the top? There aren't that many patches made in that area. I tested in stable/9 and it is broken in stable too. This does not have the relevant patch applied I think. You can try set first set config 255 and the config 0 on the parent HUB of this device using usbconfig. I'm not sure what you mean here. What command should I run? usbconfig -d X.1 set_config 255 usbconfig -d X.1 set_config 0 done. It did not help. -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: regression: if_rue device doesn't attach on HEAD
On 6 January 2013 03:52, Hans Petter Selasky hsela...@c2i.net wrote: Could you do a diff between 9.1 and 9-stable sources and see what is changed? Might be some BIOS/ACPI stuff too. I havn't had a chance to go much beyond this but - 9.1-RELEASE is known to be working (this is r243808, right?) - r245084 is broken - r26 is broken - r244127 is broken - r243968 is broken -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: panic on removing urtw0
[moving to -usb where this seemingly belongs] On 10 February 2013 03:05, Hans Petter Selasky hsela...@c2i.net wrote: On Sunday 10 February 2013 03:17:03 Adrian Chadd wrote: Yes to both - i think some USB stack / memory buffer changes are responsible for your issue. :-) Hi, Can you send me the backtrace of the panic and I'll fix it. I fixed panic upon attach. [ textdump kernel available upon request ] Unread portion of the kernel message buffer: urtw0: failed to stop (USB_ERR_NOT_CONFIGURED) Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x368 fault code = supervisor read data, page not present instruction pointer = 0x20:0x808c4be7 stack pointer = 0x28:0xff8227152730 frame pointer = 0x28:0xff8227152780 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 15 (usbus2) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0x8090c7a6 at kdb_backtrace+0x66 #1 0x808d67be at panic+0x1ce #2 0x80bc4140 at trap_fatal+0x290 #3 0x80bc447d at trap_pfault+0x1ed #4 0x80bc4a9e at trap+0x3ce #5 0x80baf05f at calltrap+0x8 #6 0x809a541a at ieee80211_ageq_remove+0xea #7 0x809a54c9 at ieee80211_ageq_drain_node+0x9 #8 0x809c584a at node_cleanup+0x6a #9 0x809c5960 at node_free+0x30 #10 0x8077f97b at urtw_free_data_list+0x4b #11 0x80785a45 at urtw_detach+0xd5 #12 0x80905a84 at device_detach+0x74 #13 0x80750388 at usb_detach_device+0x58 #14 0x80750524 at usb_unconfigure+0x34 #15 0x807507c5 at usb_free_device+0x195 #16 0x80758dce at uhub_explore+0x1be #17 0x807590d4 at uhub_explore+0x4c4 -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: panic on removing urtw0
On 10 February 2013 08:27, Hans Petter Selasky hsela...@c2i.net wrote: On Sunday 10 February 2013 14:19:21 Eitan Adler wrote: [moving to -usb where this seemingly belongs] On 10 February 2013 03:05, Hans Petter Selasky hsela...@c2i.net wrote: On Sunday 10 February 2013 03:17:03 Adrian Chadd wrote: Yes to both - i think some USB stack / memory buffer changes are responsible for your issue. :-) Hi, Can you send me the backtrace of the panic and I'll fix it. I fixed panic upon attach. [ textdump kernel available upon request ] Unread portion of the kernel message buffer: urtw0: failed to stop (USB_ERR_NOT_CONFIGURED) Hi, Can you try this again with latest -current as of now. It happens because the nodes are freed after the IEEE802.11 adapter is gone. I can not test because the device does not attach at all on r246623. -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
randomly losing mouse
When I start my computer both my USB mouse and trackpad are capable of controlling the mouse via moused. At some point the USB mouse dies and when I try to re-plug it in I see: ugen0.3: LG Electronics Inc. at usbus0 (disconnected) umass0: at uhub2, port 4, addr 7 (disconnected) xhci_do_command: Command timeout! xhci_do_command: Command timeout! usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) in dmesg. [10017 eitan@gravity (98%) ~ ]%uname -a FreeBSD gravity.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r255215: Sat Sep 7 11:18:17 EDT 2013 eitan@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 How can I fix this? -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: randomly losing mouse
On Sat, Sep 28, 2013 at 8:24 AM, Hans Petter Selasky hans.petter.sela...@bitfrost.no wrote: Hi, Looks like a problem with the XHCI controller. Can you try SVN r255768 or newer? I did notice this commit but I have been running r255215 for a few weeks without issue. It might fix the problem. Else let me know. I just updated to r255924 and will let you know if I still see the problem -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Unable to attach USB mouse
The mouse driver fails to attach when plugging in my USB mouse. FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r257754: Thu Nov 7 12:12:51 EST 2013 root@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 From boot: [52341] ugen0.2: Logitech at usbus0 [52341] ums0: Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/27.20, addr 11 on usbus0 [52341] ums0: 8 buttons and [XYZT] coordinates ID=0 [54057] ugen0.2: Logitech at usbus0 (disconnected) [54057] ums0: at uhub0, port 1, addr 11 (disconnected) [54058] xhci_do_command: Command timeout! [54058] usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) [54058] xhci_do_command: Command timeout! [54058] xhci_do_command: Command timeout! [54058] xhci_do_command: Command timeout! [54059] xhci_do_command: Command timeout! [54059] xhci_do_command: Command timeout! [54059] xhci_do_command: Command timeout! [54059] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT [54060] xhci_do_command: Command timeout! [54060] xhci_do_command: Command timeout! [54060] usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) [54061] xhci_do_command: Command timeout! [54061] xhci_do_command: Command timeout! [54061] xhci_do_command: Command timeout! [54061] xhci_do_command: Command timeout! [54061] xhci_do_command: Command timeout! [54061] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT [54062] xhci_do_command: Command timeout! [54063] xhci_do_command: Command timeout! [54063] usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) [54064] xhci_do_command: Command timeout! [54064] xhci_do_command: Command timeout! [54064] xhci_do_command: Command timeout! [54064] xhci_do_command: Command timeout! [54064] xhci_do_command: Command timeout! [54064] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT [54065] xhci_do_command: Command timeout! [54065] xhci_do_command: Command timeout! [54066] usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) [54066] xhci_do_command: Command timeout! [54066] xhci_do_command: Command timeout! [54066] xhci_do_command: Command timeout! [54067] xhci_do_command: Command timeout! [54067] xhci_do_command: Command timeout! [54067] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT [54068] xhci_do_command: Command timeout! [54068] xhci_do_command: Command timeout! [54068] usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) [54069] xhci_do_command: Command timeout! [54069] xhci_do_command: Command timeout! [54069] xhci_do_command: Command timeout! [54070] xhci_do_command: Command timeout! [54070] xhci_do_command: Command timeout! [54070] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT [54070] ugen0.2: Unknown at usbus0 (disconnected) [54070] xhci_do_command: Command timeout! [54070] uhub_reattach_port: could not allocate new device [54070] xhci_interrupt: host controller halted [54070] xhci_interrupt: host system error [54080] xhci_do_command: Command timeout! [54080] usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) [54080] ugen0.2: Unknown at usbus0 (disconnected) [54080] uhub_reattach_port: could not allocate new device [56303] wlan0: link state changed to DOWN [56314] wlan0: link state changed to UP When plugging in the mouse: [136687] xhci_do_command: Command timeout! [136687] usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) [136687] ugen0.2: Unknown at usbus0 (disconnected) [136687] uhub_reattach_port: could not allocate new device -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Unable to attach USB mouse
On Thu, Nov 14, 2013 at 2:05 AM, Hans Petter Selasky h...@bitfrost.no wrote: On 11/14/13 05:08, Eitan Adler wrote: The mouse driver fails to attach when plugging in my USB mouse. FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r257754: Thu Nov 7 12:12:51 EST 2013 root@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 From boot: [52341] ugen0.2: Logitech at usbus0 [52341] ums0: Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/27.20, addr 11 on usbus0 [52341] ums0: 8 buttons and [XYZT] coordinates ID=0 [54057] ugen0.2: Logitech at usbus0 (disconnected) [54057] ums0: at uhub0, port 1, addr 11 (disconnected) [54058] xhci_do_command: Command timeout! [54058] usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) What USB controllers does this system have? --HPS [10005 root@gravity (100%) /home/eitan ]#usbconfig ugen0.1: XHCI root HUB 0x8086 at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen2.1: EHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: EHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.2: product 0x0024 vendor 0x8087 at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: product 0x0024 vendor 0x8087 at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.3: Lenovo EasyCamera Azurewave at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen1.4: BCM20702A0 Broadcom Corp at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) ugen1.3: Linksys AE1000 Linksys at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA) -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Unable to attach USB mouse
On Thu, Nov 14, 2013 at 10:24 AM, Hans Petter Selasky h...@bitfrost.no wrote: On 11/14/13 15:42, Eitan Adler wrote: On Thu, Nov 14, 2013 at 2:05 AM, Hans Petter Selasky h...@bitfrost.no wrote: On 11/14/13 05:08, Eitan Adler wrote: The mouse driver fails to attach when plugging in my USB mouse. FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r257754: Thu Nov 7 12:12:51 EST 2013 root@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 From boot: [52341] ugen0.2: Logitech at usbus0 [52341] ums0: Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/27.20, addr 11 on usbus0 [52341] ums0: 8 buttons and [XYZT] coordinates ID=0 [54057] ugen0.2: Logitech at usbus0 (disconnected) [54057] ums0: at uhub0, port 1, addr 11 (disconnected) [54058] xhci_do_command: Command timeout! [54058] usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) What USB controllers does this system have? --HPS [10005 root@gravity (100%) /home/eitan ]#usbconfig ugen0.1: XHCI root HUB 0x8086 at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen2.1: EHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: EHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.2: product 0x0024 vendor 0x8087 at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: product 0x0024 vendor 0x8087 at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.3: Lenovo EasyCamera Azurewave at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen1.4: BCM20702A0 Broadcom Corp at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) ugen1.3: Linksys AE1000 Linksys at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA) pciconf -lv xhci0@pci0:0:20:0: class=0x0c0330 card=0x397717aa chip=0x1e318086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '7 Series/C210 Series Chipset Family USB xHCI Host Controller' class = serial bus subclass = USB ehci0@pci0:0:26:0: class=0x0c0320 card=0x397717aa chip=0x1e2d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '7 Series/C210 Series Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB ehci1@pci0:0:29:0: class=0x0c0320 card=0x397717aa chip=0x1e268086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '7 Series/C210 Series Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB ahci0@pci0:0:31:2: class=0x010601 card=0x397717aa chip=0x1e038086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '7 Series Chipset Family 6-port SATA Controller [AHCI mode]' class = mass storage subclass = SATA sdhci_pci0@pci0:3:0:2: class=0x080501 card=0x397617aa chip=0x2391197b rev=0x30 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'Standard SD Host Controller' class = base peripheral subclass = SD host controller -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Unable to attach USB mouse
On Thu, Nov 14, 2013 at 11:16 AM, Eitan Adler li...@eitanadler.com wrote: On Thu, Nov 14, 2013 at 10:24 AM, Hans Petter Selasky h...@bitfrost.no wrote: On 11/14/13 15:42, Eitan Adler wrote: On Thu, Nov 14, 2013 at 2:05 AM, Hans Petter Selasky h...@bitfrost.no wrote: On 11/14/13 05:08, Eitan Adler wrote: The mouse driver fails to attach when plugging in my USB mouse. FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r257754: Thu Nov 7 12:12:51 EST 2013 root@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 From boot: [52341] ugen0.2: Logitech at usbus0 [52341] ums0: Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/27.20, addr 11 on usbus0 [52341] ums0: 8 buttons and [XYZT] coordinates ID=0 [54057] ugen0.2: Logitech at usbus0 (disconnected) [54057] ums0: at uhub0, port 1, addr 11 (disconnected) [54058] xhci_do_command: Command timeout! [54058] usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) ... I'm still getting errors like these. Sometimes it happens at boot. Other times it happens as the machine runs. -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Unable to attach USB mouse
On Tue, Dec 10, 2013 at 3:44 PM, Hans Petter Selasky h...@bitfrost.no wrote: On 12/10/13 21:23, Hans Petter Selasky wrote: On 12/10/13 21:16, Eitan Adler wrote: On Tue, Dec 10, 2013 at 2:16 PM, Hans Petter Selasky h...@bitfrost.no wrote: On 12/10/13 19:47, Eitan Adler wrote: [ moving back to the mailing list ] Looks like you traced the wrong endpoint. Should be endpoint 0x83. Could you check the other USB's ? Sorry, it was the right endpoint after all, but I don't see any transfer errors, so your device is working I assume. [ revision: FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r259023: Mon Dec 9 22:22:57 EST 2013 eitan@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 ] So far, yes, everything is working. However, I've seen the errors above on this revision. I'm not sure what is the exact reason for when I see them and when I don't. -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Unable to attach USB mouse
On Tue, Dec 10, 2013 at 4:02 PM, Eitan Adler li...@eitanadler.com wrote: On Tue, Dec 10, 2013 at 3:44 PM, Hans Petter Selasky h...@bitfrost.no wrote: On 12/10/13 21:23, Hans Petter Selasky wrote: On 12/10/13 21:16, Eitan Adler wrote: On Tue, Dec 10, 2013 at 2:16 PM, Hans Petter Selasky h...@bitfrost.no wrote: On 12/10/13 19:47, Eitan Adler wrote: [ moving back to the mailing list ] Looks like you traced the wrong endpoint. Should be endpoint 0x83. Could you check the other USB's ? Sorry, it was the right endpoint after all, but I don't see any transfer errors, so your device is working I assume. [ revision: FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r259023: Mon Dec 9 22:22:57 EST 2013 eitan@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 ] So far, yes, everything is working. However, I've seen the errors above on this revision. I'm not sure what is the exact reason for when I see them and when I don't. After leaving the system running for a while I see: [90548] uhub_reattach_port: could not allocate new device [90549] usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) [90549] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR [90549] usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) [90549] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR [90550] usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) [90550] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR [90550] usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) [90550] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR [90552] usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) [90552] usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR [90552] ugen0.2: Unknown at usbus0 (disconnected) [90552] uhub_reattach_port: could not allocate new device I feel like there is something leaking but I'm not sure what. -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: RE: Entering password at GELI prompt using USB keyboard
[ Andriy, see quoted paragraph below ] On Sat, Feb 8, 2014 at 9:12 AM, pe...@freenet.de wrote: Hello again, finally I was able to solve my problem. The culprit was - as suspected - that GELI uses cngets() instead of gets() since 9.1. I used the old gets() as well as the related cngetc() and cncheckc() implementations from 9.0 and changed the call in GELI from cngets() to gets_old(). As a result of this, I can now enter the password at the GELI prompt again. Now, I am not sure what really causes my problem as cngets() is not that different from gets() except for the new cngrab() and cnungrab() calls as well as the the cpu_spinwait() in cngetc() that wasn't present before. Perhaps cpu_spinwait() is buggy on my system? Or the grab/ungrab things don't work correctly? If I see it correctly, Andriy Gapon is responsible for these last changes so I suppose it would be best to contact him directly and work out a solution? Just add him on CC (done) and work out the solution on a public list: this way it helps more than just you and people could learn from how the debugging is done too. :-) -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
weird mouse: acts as keyboard and mouse
Hey Hans, I have a Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 which is reporting itself as both a mouse and a keyboard. I know that the mouse has the ability to remap itself as it used to not do this (I was able to configure this on a mac). The annoying effect is that the back and forward keys now report themselves as [ and ] keys. [1645919] ugen0.2: Logitech at usbus0 [1645919] ums0: Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 on usbus0 [1645919] ums0: 16 buttons and [XYZT] coordinates ID=0 [1645919] ukbd0: Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 on usbus0 [1645919] kbd2 at ukbd0 I think it would be a good idea to write a utility to configure this stuff on FreeBSD. What information do I need to obtain / how should I obtain it? I'm guessing its possible to talk to the mouse over USB but I'm not sure how. -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: weird mouse: acts as keyboard and mouse
On 15 June 2014 23:49, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:39, Eitan Adler wrote: On 15 June 2014 23:33, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:30, Eitan Adler wrote: On 15 June 2014 23:26, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:21, Eitan Adler wrote: On 15 June 2014 23:18, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:09, Eitan Adler wrote: Hey Hans, I have a Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 which is reporting itself as both a mouse and a keyboard. I know that the mouse has the ability to remap itself as it used to not do this (I was able to configure this on a mac). The annoying effect is that the back and forward keys now report themselves as [ and ] keys. [1645919] ugen0.2: Logitech at usbus0 [1645919] ums0: Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 on usbus0 [1645919] ums0: 16 buttons and [XYZT] coordinates ID=0 [1645919] ukbd0: Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 on usbus0 [1645919] kbd2 at ukbd0 I think it would be a good idea to write a utility to configure this stuff on FreeBSD. What information do I need to obtain / how should I obtain it? I'm guessing its possible to talk to the mouse over USB but I'm not sure how. Hi, Can you check the configuration descriptor first? usbconfig -d X.Y dump_device_desc dump_curr_config_desc Possibly you need to issue some HID command (set report descriptor) to make the device change behaviour. --HPS Hi, USB descriptors look sane. Add: usbconfig -d X.Y add_quirk UQ_KBD_IGNORE usbconfig -d X.Y add_quirk UQ_UMS_IGNORE Then re-plug the device. Now you should have /dev/uhidX Run: usbhidctl -f /dev/uhidX -rvx For both uhid devices. Thank you! --HPS [10054 root@gravity .../eitan/svn/fbsd/ports !2!]#usbhidctl -f /dev/uhid0 -rvx (svn:ports)-[head:357806] Report descriptor: Collection type=Application page=Generic_Desktop usage=Mouse Collection type=Physical page=Generic_Desktop usage=Pointer Input rid=0 size=1 count=1 page=Button usage=Button_1, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_2, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_3, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_4, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_5, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_6, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_7, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_8, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_9, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_10, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_11, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_12, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_13, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_14, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_15, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_16, logical range 0..1 Input rid=0 size=16 count=1 page=Generic_Desktop usage=X, logical range -32767..32767 Input rid=0 size=16 count=1 page=Generic_Desktop usage=Y, logical range -32767..32767 Input rid=0 size=8 count=1 page=Generic_Desktop usage=Wheel, logical range -127..127 Input rid=0 size=8 count=1 page=Consumer usage=AC_Pan, logical range -127..127 End collection End collection Total input size 8 bytes Total output size 0 bytes Total feature size 0 bytes [10055 root@gravity /home/eitan/svn/fbsd/ports ]#usbhidctl -f /dev/uhid1 -rvx 41s (svn:ports)-[head:357806] Report descriptor: Collection type=Application page=Generic_Desktop usage=Keyboard Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftControl, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftShift, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftAlt, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_Left_GUI, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_RightControl, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_RightShift, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_RightAlt, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_Right_GUI, logical range 0..1 Input rid=1 size=8 count=5 page=Keyboard usage=Reserved_(no_event_indicated) Array, logical range 0..164 End collection Collection type=Application page
Re: weird mouse: acts as keyboard and mouse
On 16 June 2014 08:32, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 17:15, Eitan Adler wrote: On 15 June 2014 23:49, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:39, Eitan Adler wrote: On 15 June 2014 23:33, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:30, Eitan Adler wrote: On 15 June 2014 23:26, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:21, Eitan Adler wrote: On 15 June 2014 23:18, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:09, Eitan Adler wrote: Hey Hans, I have a Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 which is reporting itself as both a mouse and a keyboard. I know that the mouse has the ability to remap itself as it used to not do this (I was able to configure this on a mac). The annoying effect is that the back and forward keys now report themselves as [ and ] keys. [1645919] ugen0.2: Logitech at usbus0 [1645919] ums0: Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 on usbus0 [1645919] ums0: 16 buttons and [XYZT] coordinates ID=0 [1645919] ukbd0: Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 on usbus0 [1645919] kbd2 at ukbd0 I think it would be a good idea to write a utility to configure this stuff on FreeBSD. What information do I need to obtain / how should I obtain it? I'm guessing its possible to talk to the mouse over USB but I'm not sure how. Hi, Can you check the configuration descriptor first? usbconfig -d X.Y dump_device_desc dump_curr_config_desc Possibly you need to issue some HID command (set report descriptor) to make the device change behaviour. --HPS Hi, USB descriptors look sane. Add: usbconfig -d X.Y add_quirk UQ_KBD_IGNORE usbconfig -d X.Y add_quirk UQ_UMS_IGNORE Then re-plug the device. Now you should have /dev/uhidX Run: usbhidctl -f /dev/uhidX -rvx For both uhid devices. Thank you! --HPS [10054 root@gravity .../eitan/svn/fbsd/ports !2!]#usbhidctl -f /dev/uhid0 -rvx (svn:ports)-[head:357806] Report descriptor: Collection type=Application page=Generic_Desktop usage=Mouse Collection type=Physical page=Generic_Desktop usage=Pointer Input rid=0 size=1 count=1 page=Button usage=Button_1, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_2, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_3, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_4, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_5, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_6, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_7, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_8, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_9, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_10, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_11, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_12, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_13, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_14, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_15, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_16, logical range 0..1 Input rid=0 size=16 count=1 page=Generic_Desktop usage=X, logical range -32767..32767 Input rid=0 size=16 count=1 page=Generic_Desktop usage=Y, logical range -32767..32767 Input rid=0 size=8 count=1 page=Generic_Desktop usage=Wheel, logical range -127..127 Input rid=0 size=8 count=1 page=Consumer usage=AC_Pan, logical range -127..127 End collection End collection Total input size 8 bytes Total output size 0 bytes Total feature size 0 bytes [10055 root@gravity /home/eitan/svn/fbsd/ports ]#usbhidctl -f /dev/uhid1 -rvx 41s (svn:ports)-[head:357806] Report descriptor: Collection type=Application page=Generic_Desktop usage=Keyboard Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftControl, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftShift, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftAlt, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_Left_GUI, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_RightControl, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_RightShift, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_RightAlt, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_Right_GUI, logical range 0..1 Input rid=1 size=8 count=5
Re: weird mouse: acts as keyboard and mouse
On 16 June 2014 17:59, Eitan Adler li...@eitanadler.com wrote: On 16 June 2014 08:32, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 17:15, Eitan Adler wrote: On 15 June 2014 23:49, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:39, Eitan Adler wrote: On 15 June 2014 23:33, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:30, Eitan Adler wrote: On 15 June 2014 23:26, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:21, Eitan Adler wrote: On 15 June 2014 23:18, Hans Petter Selasky h...@selasky.org wrote: On 06/16/14 08:09, Eitan Adler wrote: Hey Hans, I have a Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 which is reporting itself as both a mouse and a keyboard. I know that the mouse has the ability to remap itself as it used to not do this (I was able to configure this on a mac). The annoying effect is that the back and forward keys now report themselves as [ and ] keys. [1645919] ugen0.2: Logitech at usbus0 [1645919] ums0: Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 on usbus0 [1645919] ums0: 16 buttons and [XYZT] coordinates ID=0 [1645919] ukbd0: Logitech G500s Laser Gaming Mouse, class 0/0, rev 2.00/84.01, addr 12 on usbus0 [1645919] kbd2 at ukbd0 I think it would be a good idea to write a utility to configure this stuff on FreeBSD. What information do I need to obtain / how should I obtain it? I'm guessing its possible to talk to the mouse over USB but I'm not sure how. Hi, Can you check the configuration descriptor first? usbconfig -d X.Y dump_device_desc dump_curr_config_desc Possibly you need to issue some HID command (set report descriptor) to make the device change behaviour. --HPS Hi, USB descriptors look sane. Add: usbconfig -d X.Y add_quirk UQ_KBD_IGNORE usbconfig -d X.Y add_quirk UQ_UMS_IGNORE Then re-plug the device. Now you should have /dev/uhidX Run: usbhidctl -f /dev/uhidX -rvx For both uhid devices. Thank you! --HPS [10054 root@gravity .../eitan/svn/fbsd/ports !2!]#usbhidctl -f /dev/uhid0 -rvx (svn:ports)-[head:357806] Report descriptor: Collection type=Application page=Generic_Desktop usage=Mouse Collection type=Physical page=Generic_Desktop usage=Pointer Input rid=0 size=1 count=1 page=Button usage=Button_1, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_2, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_3, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_4, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_5, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_6, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_7, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_8, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_9, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_10, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_11, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_12, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_13, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_14, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_15, logical range 0..1 Input rid=0 size=1 count=1 page=Button usage=Button_16, logical range 0..1 Input rid=0 size=16 count=1 page=Generic_Desktop usage=X, logical range -32767..32767 Input rid=0 size=16 count=1 page=Generic_Desktop usage=Y, logical range -32767..32767 Input rid=0 size=8 count=1 page=Generic_Desktop usage=Wheel, logical range -127..127 Input rid=0 size=8 count=1 page=Consumer usage=AC_Pan, logical range -127..127 End collection End collection Total input size 8 bytes Total output size 0 bytes Total feature size 0 bytes [10055 root@gravity /home/eitan/svn/fbsd/ports ]#usbhidctl -f /dev/uhid1 -rvx 41s (svn:ports)-[head:357806] Report descriptor: Collection type=Application page=Generic_Desktop usage=Keyboard Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftControl, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftShift, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftAlt, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_Left_GUI, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_RightControl, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_RightShift, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage=Keyboard_RightAlt, logical range 0..1 Input rid=1 size=1 count=1 page=Keyboard usage
Re: IRQ storm on xhci0
On 1 May 2018 at 20:53, Eitan Adler <li...@eitanadler.com> wrote: > Hi all, > > I am noticing consistently high IRQ rates on xhci0 > > example from vmstat -i right now: > irq259: xhci0153 1876 > > and this is not the highest I've seen. > > My understanding is that a rate of 1876/s is insane for USB devices. > Any suggestions of what I can do to debug? > > Things I've tried: > - disabling MSI interrupts > - disabling MSI-X interrupts > - powering off all usb devices using usbconfig > - unplugging all USB devices > > One thing of note: > My mobo has a broken USB connector resulting in one of the two front > USB-3 ports not working. I'm guessing this is related but I'd like > some confirmation and/or a way to bypass the issue in software. with insane debugging enabled: ... [3542] xhci_check_transfer: slot=1 epno=6 stream=256 remainder=0 status=1 [3542] xhci_check_transfer: stream_id=0 [3542] xhci_check_transfer: Checking if 0x99c01480 == (0x5df39980 .. 0x5df39aa0) [3542] xhci_check_transfer: Checking if 0x99c01480 == (0x99c01480 .. 0x99c015a0) [3542] xhci_check_transfer: New remainder: 0 [3542] xhci_check_transfer: Following next TD [3542] xhci_interrupt_poll: event[103] = 32 (0x0001167f8790 0x0100 0x01078001) [3542] xhci_check_transfer: slot=1 epno=7 stream=256 remainder=0 status=1 [3542] xhci_check_transfer: stream_id=0 [3542] xhci_check_transfer: Checking if 0x0001167f8790 == (0x5df7b980 .. 0x5df7baa0) [3542] xhci_check_transfer: Checking if 0x0001167f8790 == (0x0001167f8600 .. 0x0001167f8720) [3542] xhci_interrupt_poll: event[104] = 32 (0x0001167f8600 0x0d31 0x01078001) [3542] xhci_check_transfer: slot=1 epno=7 stream=3328 remainder=49 status=13 [3542] xhci_check_transfer: stream_id=0 [3542] xhci_check_transfer: Checking if 0x0001167f8600 == (0x5df7b980 .. 0x5df7baa0) [3542] xhci_check_transfer: Checking if 0x0001167f8600 == (0x0001167f8600 .. 0x0001167f8720) [3542] xhci_check_transfer: New remainder: 49 [3542] xhci_check_transfer: TD has short pkt [3542] xhci_interrupt: real interrupt (status=0x0008) [3542] xhci_interrupt_poll: event[105] = 32 (0x99c01490 0x0100 0x01068001) [3542] xhci_check_transfer: slot=1 epno=6 stream=256 remainder=0 status=1 [3542] xhci_check_transfer: stream_id=0 [3542] xhci_check_transfer: Checking if 0x99c01490 == (0x5df39980 .. 0x5df39aa0) [3542] xhci_check_transfer: Checking if 0x99c01490 == (0x99c01300 .. 0x99c01420) [3542] xhci_interrupt_poll: event[106] = 32 (0x99c01300 0x0100 0x01068001) [3542] xhci_check_transfer: slot=1 epno=6 stream=256 remainder=0 status=1 [3542] xhci_check_transfer: stream_id=0 [3542] xhci_check_transfer: Checking if 0x99c01300 == (0x5df39980 .. 0x5df39aa0) [3542] xhci_check_transfer: Checking if 0x99c01300 == (0x99c01300 .. 0x99c01420) [3542] xhci_check_transfer: New remainder: 0 [3542] xhci_check_transfer: Following next TD [3542] xhci_interrupt_poll: event[107] = 32 (0x0001167f8610 0x0100 0x01078001) [3542] xhci_check_transfer: slot=1 epno=7 stream=256 remainder=0 status=1 [3542] xhci_check_transfer: stream_id=0 [3542] xhci_check_transfer: Checking if 0x0001167f8610 == (0x5df7b980 .. 0x5df7baa0) [3542] xhci_check_transfer: Checking if 0x0001167f8610 == (0x0001167f8480 .. 0x0001167f85a0) [3542] xhci_interrupt_poll: event[108] = 32 (0x0001167f8480 0x0d31 0x01078001) [3542] xhci_check_transfer: slot=1 epno=7 stream=3328 remainder=49 status=13 [3542] xhci_check_transfer: stream_id=0 [3542] xhci_check_transfer: Checking if 0x0001167f8480 == (0x5df7b980 .. 0x5df7baa0) [3542] xhci_check_transfer: Checking if 0x0001167f8480 == (0x0001167f8480 .. 0x0001167f85a0) [3542] xhci_check_transfer: New remainder: 49 [3542] xhci_check_transfer: TD has short pkt -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
IRQ storm on xhci0
Hi all, I am noticing consistently high IRQ rates on xhci0 example from vmstat -i right now: irq259: xhci0153 1876 and this is not the highest I've seen. My understanding is that a rate of 1876/s is insane for USB devices. Any suggestions of what I can do to debug? Things I've tried: - disabling MSI interrupts - disabling MSI-X interrupts - powering off all usb devices using usbconfig - unplugging all USB devices One thing of note: My mobo has a broken USB connector resulting in one of the two front USB-3 ports not working. I'm guessing this is related but I'd like some confirmation and/or a way to bypass the issue in software. -- Eitan Adler ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
