Re: USB 3 strange behavior, lenovo x240
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/16/15 13:12, Sean Bruno wrote: On 01/16/15 11:48, Hans Petter Selasky wrote: On 01/16/15 19:00, Sean Bruno wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm seeing strange behavior when I enable USB 3 support on my laptop. Running head @r276878: Disabling USB 3 makes things behave better in that my wireless device will actually serve traffic and /dev/video0 will really exist when I switch over. Using USB 3 makes things behave erratically if at all. Devices don't appear after a reboot and I'm seeing issues using my USB 2 devices. Hi, Does setting: hw.usb.xhci.xhci_port_route=-1 In /boot/loader.conf Help? --HPS It does seem to help somewhat. Devices are available: % usbconfig ugen0.1: XHCI root HUB 0x8086 at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen1.1: EHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: product 0x8000 vendor 0x8087 at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.3: 802.11n NIC Realtek at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen1.4: Integrated Camera SunplusIT INC. at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) sean _ Hrm ... yeah. devices like my USB network adapter and USB camera (integrated) are definitely not working. The camera doesn't work in USB2 nor USB3 mode. The USB wireless device only works reliably if I disable USB3. sean -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUv9n0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5krCkH/2Cihq1EhBv52UZgTQ8L297W HG/fyMVKPZ7vFkijUEwDWuSIAb4N0G0gB6SIYSL5fmlVRxzsSFRQD24qxYfsr0p6 Tdx2C0YHM22bjYqcnjGN9U0aN1BzauQbImt6jDQbtP3uBcxlRavX+next16q5aV5 2+rbBIMUJSDM/kgM/8aSaHg4WYWvOP/vbK7uyyLmukNsbjO8VauJ4raVPsi0pBcQ pltJRkHYRIuJ9mWYu1mfthrcLYALSXEjbRIujQj2aymIc+zjKhzSDCSI1ic2k8NS rxr0/IOklgz1cGiiZZv0MLEf0jBQmDpz7mmSIRIqMm70Sa+gqLP8qnfJwrggPEw= =+DXZ -END PGP SIGNATURE- ___ 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: Lenovo x240 webcam not working with cheese/pwcview
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/12/15 08:12, Sean Bruno wrote: Unsure how to debug what's up here. webcamd seems to attach correctly and doesn't output any errors, but cheese is unable to access the webcam in /dev/video0 % ls -l /dev/video0 crw-rw 1 webcamd webcamd 0x6c Jan 12 07:54 /dev/video0 % groups sbruno sbruno wheel operator webcamd vboxusers pwcview seems to abort when attaching to my X11 session: % pwcview Webcam set to: 320x240 (sif) at 5 fps XDM authorization key matches an existing client!Failed to init sdl: Couldn't open X11 display The Lenovo X240 has one of these: ugen0.3: Integrated Camera SunplusIT INC. at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) webcamd and cuse4bsd seem happy with it: # /usr/local/sbin/webcamd -i 0 -d ugen0.3 -U webcamd -G webcamd -H Attached to ugen0.3[0] Waiting for HAL USB device. Creating /dev/video0 when trying to use cheese to test it out, I get some strangess like it can't seem to find a libvorbis package of something? (cheese:1283): cheese-WARNING **: Your GStreamer installation is missing a plug-in.: gstencodebin.c(1474): StreamGroup *_create_stream_group(GstEncodeBin *, GstEncodingProfile *, const gchar *, GstCaps *) (): /GstCameraBin:camerabin/GstEncodeBin:video-encodebin: Couldn't create encoder for format audio/x-vorbis However, I seem to have all the things required for this to work? % pkg info | grep -i vorbis gstreamer-plugins-vorbis-0.10.36_1,3 Gstreamer vorbis encoder/decoder plugin libvorbis-1.3.4_2,3Audio compression codec library -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUuUssXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kYoIH/RjqL80m3k2MU/DNMls+KbQy MJ2okoRt2zUM4fXG1KnqqvPaqIdfEm6FJjl7rpxk9ln5E/cBfPPSKMO0yJUgImhL GdGKfPdI+zD4BRWecz6de78vMcvWWkiyKv6IfaKsJObTDOIdIcz7O5av1Pvuji3m kXj3OOTjyGDeo9blc0cORWU/XLuSpgxStFALAnZvhxNp04KWkg0IqqhYFXYP0ckb V270z8Iz9tAXavJCho3Wq4sy708pPDCxZjnqOThg8v5Pb5IogRF+scTNxqF3cbbE YPB9Vu0VBiHSJ7Nb3pe4kRxlZOFFI1c4iIEZTk0bDScPEP0VMgHv+sFqQFbJ/xo= =znnR -END PGP SIGNATURE- ___ 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
USB 3 strange behavior, lenovo x240
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm seeing strange behavior when I enable USB 3 support on my laptop. Running head @r276878: Disabling USB 3 makes things behave better in that my wireless device will actually serve traffic and /dev/video0 will really exist when I switch over. Using USB 3 makes things behave erratically if at all. Devices don't appear after a reboot and I'm seeing issues using my USB 2 devices. % usbconfig ugen0.1: XHCI root HUB 0x8086 at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen1.1: EHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: 802.11n NIC Realtek at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen1.2: product 0x8000 vendor 0x8087 at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.3: Integrated Camera SunplusIT INC. at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) % pciconf -lv xhci0@pci0:0:20:0: class=0x0c0330 card=0x221417aa chip=0x9c318086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Lynx Point-LP USB xHCI HC' class = serial bus subclass = USB -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUuVGoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kxd8H/RW6GMr9herxrJEPmuGM3Wqv 3LCNubZFBLE/RS+d4d3PIW9IqSyN/9ttSJ1+PEQ3j+6Mj0lFRaDe4pOnkJkWQH0D hnOsQ3fX9h4KtV+A+exl5P50TCBc9ie9asumWC4b9fdMSatBmkjDH1k1RhGOXVyd qP8Lari6le1IFZrpWxkFMi20g2DuzoE9heCm9D0iDiclruXFUV9gPCYtftckvUzn cWUb5cDpGVmHhxr2Klr81YtMHJlDVQrPOaB6dfPsvMuvW5mu1Z0RYHOHe1+gfC1x CJfBm1iNt1dllzLjLTWxf722zVVguylJjXCyYqyWt5mJ3hORIaG6KNTjo2+05sU= =S41L -END PGP SIGNATURE- ___ 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: USB 3 strange behavior, lenovo x240
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/16/15 11:48, Hans Petter Selasky wrote: On 01/16/15 19:00, Sean Bruno wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm seeing strange behavior when I enable USB 3 support on my laptop. Running head @r276878: Disabling USB 3 makes things behave better in that my wireless device will actually serve traffic and /dev/video0 will really exist when I switch over. Using USB 3 makes things behave erratically if at all. Devices don't appear after a reboot and I'm seeing issues using my USB 2 devices. Hi, Does setting: hw.usb.xhci.xhci_port_route=-1 In /boot/loader.conf Help? --HPS It does seem to help somewhat. Devices are available: % usbconfig ugen0.1: XHCI root HUB 0x8086 at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen1.1: EHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: product 0x8000 vendor 0x8087 at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.3: 802.11n NIC Realtek at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen1.4: Integrated Camera SunplusIT INC. at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) sean -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUuX6fXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kO8sIAKSgrpDOHYHzZgI4ONxJGtEh pL5CnLqMJIIFOPemIb4JCE2fkgV1KFzE3ou4bs1hcrFxbhXeK4gi4jSw4jjqIuhu 8Gwu4+mz/Hbbm/weZjGujC0lxiiFecrZAC3lstq9Q+e2yVaQnrxZ8SsCvMueLsFy 0Z3lXGYOW01vt80osI/YTCc4XZ7C7GhB5ZaC/VPtrv7xtqmUxeb3LvrjXcEXmHjo jtzgFrmEpyViGnnkhl8UOkFCafWCY1iol2kLi++wvDjEBA4YeZxElA9RZhZWuLKy sOmiAFGsAQlBMbJrEXnAkQXGZIxRhcJKmKDKtDq7rW0xpoJUZHJ/5KmqawmFgEM= =jnJf -END PGP SIGNATURE- ___ 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
Lenovo x240 webcam not working with cheese/pwcview
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Unsure how to debug what's up here. webcamd seems to attach correctly and doesn't output any errors, but cheese is unable to access the webcam in /dev/video0 % ls -l /dev/video0 crw-rw 1 webcamd webcamd 0x6c Jan 12 07:54 /dev/video0 % groups sbruno sbruno wheel operator webcamd vboxusers pwcview seems to abort when attaching to my X11 session: % pwcview Webcam set to: 320x240 (sif) at 5 fps XDM authorization key matches an existing client!Failed to init sdl: Couldn't open X11 display -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUs/JYXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k35cH/Rj1zWroEIdZPj1tURl4HgfM 5tdnep/Njdc32C3ucw63tpzXPRJn3R/YR0rI38RL9JIQPjQU32lf9RhRqMWcVnvd ekjqGSepWqrTtStalcD6sG/pd8Fykz1lhgIw2rG5RIK9k/L5keiFZh8NjVZi85kX XJv5r9FssVZvmCmz6Kf+Hk2d9lC6v/lqwZAT6NnSpMxyLqnc4cTIMFhqioja/02E l3TKqIz/1DIOZ6gRVMhlsZ7MVpNZMWkfSQsHI+srnwplAdPqcVDqttaoqpK3Hjxj UgXJ7l7y0clpN03n3BmpfCun0G+pIyfAlEP0ZezfC3fonY/+U6n4uE8m/Wwu5f4= =0BDV -END PGP SIGNATURE- ___ 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
Lenovo x240 webcam not working with cheese/pwcview
Unsure how to debug what's up here. webcamd seems to attach correctly and doesn't output any errors, but cheese is unable to access the webcam in /dev/video0 % ls -l /dev/video0 crw-rw 1 webcamd webcamd 0x6c Jan 12 07:54 /dev/video0 % groups sbruno sbruno wheel operator webcamd vboxusers pwcview seems to abort when attaching to my X11 session: % pwcview Webcam set to: 320x240 (sif) at 5 fps XDM authorization key matches an existing client!Failed to init sdl: Couldn't open X11 display -- The information in this message may be confidential. It is intended solely for the addressee(s). If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. ___ 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: Random issues with xhci
On Thu, 2014-07-31 at 18:11 +0200, Hans Petter Selasky wrote: Best way to debug is to log all USB traffic: usbdump -i usbusX -s 65536 -w usblog.pcap Then try to see if there are any USB errors happening before the XHCI controller resets. Thank you! --HPS Hrm ... seems to most reliably happen on host startup and not really able to reproduce after multiuser. I see stuff like this: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ugen1.2: Belkin at usbus1 cd0 at ahcich4 bus 0 scbus4 target 0 lun 0 cd0: SONY DVD RW DRU-800A KY06 Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA4, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from zfs:zroot []... usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ugen1.3: Prolific Technology Inc. at usbus1 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ugen3.2: Unknown at usbus3 (disconnected) uhub_reattach_port: could not allocate new device ums0: Logitech USB Receiver, class 0/0, rev 2.00/24.00, addr 1 on usbus0 ums0: 16 buttons and [XYZT] coordinates ID=2 uhid0: Logitech USB Receiver, class 0/0, rev 2.00/24.00, addr 1 on usbus0 uaudio0: vendor 0x046d product 0x08c5, class 0/0, rev 2.00/0.05, addr 2 on usbus2 uaudio0: No playback. uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: No MIDI sequencer. pcm6: USB audio on uaudio0 uaudio0: No HID volume keys found. uhid1: Belkin Belkin UPS, class 0/0, rev 1.10/0.01, addr 2 on usbus1 ___ 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: Random issues with xhci
On Fri, 2014-08-01 at 10:03 -0700, Sean Bruno wrote: On Thu, 2014-07-31 at 18:11 +0200, Hans Petter Selasky wrote: Best way to debug is to log all USB traffic: usbdump -i usbusX -s 65536 -w usblog.pcap Then try to see if there are any USB errors happening before the XHCI controller resets. Thank you! --HPS Hrm ... seems to most reliably happen on host startup and not really able to reproduce after multiuser. I see stuff like this: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ugen1.2: Belkin at usbus1 cd0 at ahcich4 bus 0 scbus4 target 0 lun 0 cd0: SONY DVD RW DRU-800A KY06 Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA4, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from zfs:zroot []... usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ugen1.3: Prolific Technology Inc. at usbus1 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ugen3.2: Unknown at usbus3 (disconnected) uhub_reattach_port: could not allocate new device ums0: Logitech USB Receiver, class 0/0, rev 2.00/24.00, addr 1 on usbus0 ums0: 16 buttons and [XYZT] coordinates ID=2 uhid0: Logitech USB Receiver, class 0/0, rev 2.00/24.00, addr 1 on usbus0 uaudio0: vendor 0x046d product 0x08c5, class 0/0, rev 2.00/0.05, addr 2 on usbus2 uaudio0: No playback. uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: No MIDI sequencer. pcm6: USB audio on uaudio0 uaudio0: No HID volume keys found. uhid1: Belkin Belkin UPS, class 0/0, rev 1.10/0.01, addr 2 on usbus1 Hrm ... poking around the internet now. I'm seeing evidence of oddities from other users. http://ehc.ac/p/libusbx/mailman/message/29979450/ http://www.spinics.net/lists/linux-usb/msg67316.html ^^ something about a short packet bug is referenced here. sean ___ 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
Random issues with xhci
xhci0@pci0:2:0:0: class=0x0c0330 card=0x84881043 chip=0x10421b21 rev=0x00 hdr=0x00 vendor = 'ASMedia Technology Inc.' device = 'ASM1042 SuperSpeed USB Host Controller' class = serial bus subclass = USB I can't quite ping down a specific test case with this usb controller. I see that, sometimes, connecting devices to it or rebooting with devices connected to it will fail with a constant device timeout message. Any ideas on some better test cases with various bits of USB gear? sean ___ 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: Random issues with xhci
On Thu, 2014-07-31 at 18:09 +0200, Hans Petter Selasky wrote: On 07/31/14 17:54, Sean Bruno wrote: xhci0@pci0:2:0:0: class=0x0c0330 card=0x84881043 chip=0x10421b21 rev=0x00 hdr=0x00 vendor = 'ASMedia Technology Inc.' device = 'ASM1042 SuperSpeed USB Host Controller' class = serial bus subclass = USB I can't quite ping down a specific test case with this usb controller. I see that, sometimes, connecting devices to it or rebooting with devices connected to it will fail with a constant device timeout message. Any ideas on some better test cases with various bits of USB gear? Hi, Does this happen with recent -current and -stable branches? --HPS Yeah, I'm on: FreeBSD alice 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r268982: Tue Jul 22 09:31:08 PDT 2014 sbruno@alice:/usr/obj/usr/src/sys/ALICE amd64 My bus layout looks like this: ugen0.1: XHCI root HUB 0x1b21 at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen2.1: EHCI root HUB ATI at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: OHCI root HUB ATI at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen3.1: OHCI root HUB ATI at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen4.1: EHCI root HUB ATI at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen5.1: OHCI root HUB ATI at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen6.1: OHCI root HUB ATI at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen7.1: EHCI root HUB ATI at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) sean ___ 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
Logitech QuickCam Pro 5000
Jul 29 10:51:31 alice root: Unknown USB device: vendor 0x046d product 0x08c5 bus uhub7 I plug in my webcam and it seems that usbdevs doesn't know what this is. Seems odd, that its so old, but I guess it needs to be added somewhere? sean # usbconfig -u 7 -a 2 dump_curr_config_desc ugen7.2: product 0x08c5 vendor 0x046d at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x04f3 bNumInterfaces = 0x0004 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x0080 bMaxPower = 0x00fa Additional Descriptor bLength = 0x08 bDescriptorType = 0x0b bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x08, 0x0b, 0x00, 0x02, 0xff, 0x03, 0x00, 0x00 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x iInterface = 0x no string Additional Descriptor bLength = 0x0d bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x0d, 0x24, 0x01, 0x00, 0x01, 0x6a, 0x00, 0x00, 0x08 | 0x6c, 0xdc, 0x02, 0x01, 0x01 Additional Descriptor bLength = 0x12 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x12, 0x24, 0x02, 0x01, 0x01, 0x02, 0x00, 0x00, 0x08 | 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0e, 0x10 | 0x00, 0x00 Additional Descriptor bLength = 0x0b bDescriptorType = 0x24 bDescriptorSubType = 0x05 RAW dump: 0x00 | 0x0b, 0x24, 0x05, 0x02, 0x01, 0x00, 0x40, 0x02, 0x08 | 0x7b, 0x17, 0x00 Additional Descriptor bLength = 0x1c bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x1c, 0x24, 0x06, 0x03, 0x82, 0x06, 0x61, 0x63, 0x08 | 0x70, 0x50, 0xab, 0x49, 0xb8, 0xcc, 0xb3, 0x85, 0x10 | 0x5e, 0x8d, 0x22, 0x1d, 0x00, 0x01, 0x02, 0x03, 0x18 | 0xff, 0xff, 0x1f, 0x00 Additional Descriptor bLength = 0x1b bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x1b, 0x24, 0x06, 0x04, 0x82, 0x06, 0x61, 0x63, 0x08 | 0x70, 0x50, 0xab, 0x49, 0xb8, 0xcc, 0xb3, 0x85, 0x10 | 0x5e, 0x8d, 0x22, 0x1e, 0x00, 0x01, 0x03, 0x02, 0x18 | 0x7f, 0x01, 0x00 Additional Descriptor bLength = 0x09 bDescriptorType = 0x24 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x09, 0x24, 0x03, 0x05, 0x01, 0x01, 0x00, 0x04, 0x08 | 0x00 Additional Descriptor bLength = 0x20 bDescriptorType = 0x41 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x20, 0x41, 0x01, 0x08, 0x82, 0x06, 0x61, 0x63, 0x08 | 0x70, 0x50, 0xab, 0x49, 0xb8, 0xcc, 0xb3, 0x85, 0x10 | 0x5e, 0x8d, 0x22, 0x51, 0x03, 0x01, 0x04, 0x03, 0x18 | 0x19, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Additional Descriptor bLength = 0x20 bDescriptorType = 0x41 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x20, 0x41, 0x01, 0x0a, 0x82, 0x06, 0x61, 0x63, 0x08 | 0x70, 0x50, 0xab, 0x49, 0xb8, 0xcc, 0xb3, 0x85, 0x10 | 0x5e, 0x8d, 0x22, 0x52, 0x01, 0x01, 0x04, 0x03, 0x18 | 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0087 IN bmAttributes = 0x0003 INTERRUPT wMaxPacketSize = 0x0010 bInterval = 0x0008 bRefresh = 0x bSynchAddress = 0x Additional Descriptor bLength = 0x05 bDescriptorType = 0x25 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x05, 0x25, 0x03, 0x10, 0x00 Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x bInterfaceClass = 0x00ff bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x iInterface = 0x no string Additional Descriptor bLength = 0x10 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x10, 0x24, 0x01, 0x03, 0xa9, 0x02, 0x81, 0x00, 0x08 | 0x05, 0x02, 0x01, 0x00, 0x01, 0x04, 0x00, 0x04 Additional Descriptor bLength = 0x0b bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x0b, 0x24, 0x06, 0x01, 0x09, 0x01, 0x03, 0x00, 0x08 | 0x00, 0x00, 0x00 Additional Descriptor bLength = 0x32 bDescriptorType = 0x24 bDescriptorSubType = 0x07 RAW dump: 0x00 | 0x32, 0x24, 0x07, 0x01, 0x00, 0xa0, 0x00, 0x78, 0x08
Re: Lenovo T61, USB fails to power on after resume [solved?]
On Tue, 2014-06-03 at 22:21 +0200, Hans Petter Selasky wrote:
On 06/03/14 22:11, Sean Bruno wrote:
On Tue, 2014-06-03 at 21:59 +0200, Hans Petter Selasky wrote:
On 06/03/14 20:28, Sean Bruno wrote:
On Tue, 2014-06-03 at 18:58 +0200, Hans Petter Selasky wrote:
On 06/03/14 18:36, Sean Bruno wrote:
On Tue, 2014-06-03 at 17:54 +0200, Hans Petter Selasky wrote:
On 06/03/14 16:56, Sean Bruno wrote:
Noted that on resume, the USB ports on my T61 don't seem to be active.
How should I go about debugging this?
sean
Hi,
The USB stack performs the same EHCI/OHCI/UHCI/XHCI reset which is does
during power on, when it resumes. Ensure the ports are powered. +5V.
Might be a BIOS/PCI/ACPI issue.
--HPS
Is there something in the output of usbconfig that I can poke at to see
if the hardware *thinks* it is powered on?
sean
Yes, there is the port status.
struct usb_port_status {
uWord wPortStatus;
#define UPS_CURRENT_CONNECT_STATUS 0x0001
#define UPS_PORT_ENABLED0x0002
#define UPS_SUSPEND 0x0004
#define UPS_OVERCURRENT_INDICATOR 0x0008
#define UPS_RESET 0x0010
#define UPS_PORT_L1 0x0020 /* USB 2.0 only */
/* The link-state bits are valid for Super-Speed USB HUBs */
#define UPS_PORT_LINK_STATE_GET(x) (((x) 5) 0xF)
#define UPS_PORT_LINK_STATE_SET(x) (((x) 0xF) 5)
#define UPS_PORT_LS_U0 0x00
#define UPS_PORT_LS_U1 0x01
#define UPS_PORT_LS_U2 0x02
#define UPS_PORT_LS_U3 0x03
#define UPS_PORT_LS_SS_DIS 0x04
#define UPS_PORT_LS_RX_DET 0x05
#define UPS_PORT_LS_SS_INA 0x06
#define UPS_PORT_LS_POLL0x07
#define UPS_PORT_LS_RECOVER 0x08
#define UPS_PORT_LS_HOT_RST 0x09
#define UPS_PORT_LS_COMP_MODE 0x0A
#define UPS_PORT_LS_LOOPBACK0x0B
#define UPS_PORT_LS_RESUME 0x0F
#define UPS_PORT_POWER 0x0100
#define UPS_PORT_POWER_SS 0x0200 /* super-speed only */
#define UPS_LOW_SPEED 0x0200
#define UPS_HIGH_SPEED 0x0400
#define UPS_OTHER_SPEED 0x0600 /* currently FreeBSD
specific */
#define UPS_PORT_TEST 0x0800
#define UPS_PORT_INDICATOR 0x1000
#define UPS_PORT_MODE_DEVICE0x8000 /* currently FreeBSD
specific */
uWord wPortChange;
#define UPS_C_CONNECT_STATUS0x0001
#define UPS_C_PORT_ENABLED 0x0002
#define UPS_C_SUSPEND 0x0004
#define UPS_C_OVERCURRENT_INDICATOR 0x0008
#define UPS_C_PORT_RESET0x0010
#define UPS_C_PORT_L1 0x0020 /* USB 2.0 only */
#define UPS_C_BH_PORT_RESET 0x0020 /* USB 3.0 only */
#define UPS_C_PORT_LINK_STATE 0x0040
#define UPS_C_PORT_CONFIG_ERROR 0x0080
} __packed;
It is probed regularly by the UHUB driver and the port status is printed
in dmesg.
Turn on like this:
sysctl hw.usb.uhub.debug=16
By resetting the root HUB, you can write new power on bits:
usbconfig -d X.1 set_config 255
usbconfig -d X.1 set_config 0
--HPS
Well, that's problematic. The USB tree looks like this normally:
ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen2.1: EHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen3.1: UHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen4.1: UHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen5.1: UHCI root HUB Intel at usbus5, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen6.1: EHCI root HUB Intel at usbus6, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen0.2: Biometric Coprocessor STMicroelectronics at usbus0, cfg=0
md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
But, on resume ... sometimes ... ugen0.1 is just flatout gone (along
with the ugen0.2 device, obviously). This only seems to happen with
various USB device plugged in (tried about 4 different make/model usb
sticks and ext drives).
So, resetting doesn't work as the device is literally gone. Thoughts?
sean
Setting hw.usb.debug=15 should give you some hints. Are you sure the PCI
device is still there after resume?
--HPS
I did a pre/post resume pciconf -lv and I see no difference between the
two.
On initial resume, ugen0.1 appears to be there in usbconfig output, but
trying to set_config on it, causes it to dissapear and causes usbconfig
to hang:
root@bruno:/home/sbruno # usbconfig -d 0.1 set_config 255
load: 0.36 cmd: usbconfig 1540 [UGONE] 4.19r 0.00u 0.00s 0% 2064k
load: 0.36 cmd: usbconfig 1540 [UGONE] 5.00r 0.00u 0.00s 0% 2064k
Lenovo T61, USB fails to power on after resume
Noted that on resume, the USB ports on my T61 don't seem to be active. How should I go about debugging this? sean ___ 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: Lenovo T61, USB fails to power on after resume
On Tue, 2014-06-03 at 17:54 +0200, Hans Petter Selasky wrote: On 06/03/14 16:56, Sean Bruno wrote: Noted that on resume, the USB ports on my T61 don't seem to be active. How should I go about debugging this? sean Hi, The USB stack performs the same EHCI/OHCI/UHCI/XHCI reset which is does during power on, when it resumes. Ensure the ports are powered. +5V. Might be a BIOS/PCI/ACPI issue. --HPS Is there something in the output of usbconfig that I can poke at to see if the hardware *thinks* it is powered on? sean ___ 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: Lenovo T61, USB fails to power on after resume
On Tue, 2014-06-03 at 18:58 +0200, Hans Petter Selasky wrote:
On 06/03/14 18:36, Sean Bruno wrote:
On Tue, 2014-06-03 at 17:54 +0200, Hans Petter Selasky wrote:
On 06/03/14 16:56, Sean Bruno wrote:
Noted that on resume, the USB ports on my T61 don't seem to be active.
How should I go about debugging this?
sean
Hi,
The USB stack performs the same EHCI/OHCI/UHCI/XHCI reset which is does
during power on, when it resumes. Ensure the ports are powered. +5V.
Might be a BIOS/PCI/ACPI issue.
--HPS
Is there something in the output of usbconfig that I can poke at to see
if the hardware *thinks* it is powered on?
sean
Yes, there is the port status.
struct usb_port_status {
uWord wPortStatus;
#define UPS_CURRENT_CONNECT_STATUS 0x0001
#define UPS_PORT_ENABLED0x0002
#define UPS_SUSPEND 0x0004
#define UPS_OVERCURRENT_INDICATOR 0x0008
#define UPS_RESET 0x0010
#define UPS_PORT_L1 0x0020 /* USB 2.0 only */
/* The link-state bits are valid for Super-Speed USB HUBs */
#define UPS_PORT_LINK_STATE_GET(x) (((x) 5) 0xF)
#define UPS_PORT_LINK_STATE_SET(x) (((x) 0xF) 5)
#define UPS_PORT_LS_U0 0x00
#define UPS_PORT_LS_U1 0x01
#define UPS_PORT_LS_U2 0x02
#define UPS_PORT_LS_U3 0x03
#define UPS_PORT_LS_SS_DIS 0x04
#define UPS_PORT_LS_RX_DET 0x05
#define UPS_PORT_LS_SS_INA 0x06
#define UPS_PORT_LS_POLL0x07
#define UPS_PORT_LS_RECOVER 0x08
#define UPS_PORT_LS_HOT_RST 0x09
#define UPS_PORT_LS_COMP_MODE 0x0A
#define UPS_PORT_LS_LOOPBACK0x0B
#define UPS_PORT_LS_RESUME 0x0F
#define UPS_PORT_POWER 0x0100
#define UPS_PORT_POWER_SS 0x0200 /* super-speed only */
#define UPS_LOW_SPEED 0x0200
#define UPS_HIGH_SPEED 0x0400
#define UPS_OTHER_SPEED 0x0600 /* currently FreeBSD
specific */
#define UPS_PORT_TEST 0x0800
#define UPS_PORT_INDICATOR 0x1000
#define UPS_PORT_MODE_DEVICE0x8000 /* currently FreeBSD
specific */
uWord wPortChange;
#define UPS_C_CONNECT_STATUS0x0001
#define UPS_C_PORT_ENABLED 0x0002
#define UPS_C_SUSPEND 0x0004
#define UPS_C_OVERCURRENT_INDICATOR 0x0008
#define UPS_C_PORT_RESET0x0010
#define UPS_C_PORT_L1 0x0020 /* USB 2.0 only */
#define UPS_C_BH_PORT_RESET 0x0020 /* USB 3.0 only */
#define UPS_C_PORT_LINK_STATE 0x0040
#define UPS_C_PORT_CONFIG_ERROR 0x0080
} __packed;
It is probed regularly by the UHUB driver and the port status is printed
in dmesg.
Turn on like this:
sysctl hw.usb.uhub.debug=16
By resetting the root HUB, you can write new power on bits:
usbconfig -d X.1 set_config 255
usbconfig -d X.1 set_config 0
--HPS
Well, that's problematic. The USB tree looks like this normally:
ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen2.1: EHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen3.1: UHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen4.1: UHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen5.1: UHCI root HUB Intel at usbus5, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen6.1: EHCI root HUB Intel at usbus6, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen0.2: Biometric Coprocessor STMicroelectronics at usbus0, cfg=0
md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
But, on resume ... sometimes ... ugen0.1 is just flatout gone (along
with the ugen0.2 device, obviously). This only seems to happen with
various USB device plugged in (tried about 4 different make/model usb
sticks and ext drives).
So, resetting doesn't work as the device is literally gone. Thoughts?
sean
___
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: Lenovo T61, USB fails to power on after resume
On Tue, 2014-06-03 at 21:59 +0200, Hans Petter Selasky wrote:
On 06/03/14 20:28, Sean Bruno wrote:
On Tue, 2014-06-03 at 18:58 +0200, Hans Petter Selasky wrote:
On 06/03/14 18:36, Sean Bruno wrote:
On Tue, 2014-06-03 at 17:54 +0200, Hans Petter Selasky wrote:
On 06/03/14 16:56, Sean Bruno wrote:
Noted that on resume, the USB ports on my T61 don't seem to be active.
How should I go about debugging this?
sean
Hi,
The USB stack performs the same EHCI/OHCI/UHCI/XHCI reset which is does
during power on, when it resumes. Ensure the ports are powered. +5V.
Might be a BIOS/PCI/ACPI issue.
--HPS
Is there something in the output of usbconfig that I can poke at to see
if the hardware *thinks* it is powered on?
sean
Yes, there is the port status.
struct usb_port_status {
uWord wPortStatus;
#define UPS_CURRENT_CONNECT_STATUS 0x0001
#define UPS_PORT_ENABLED0x0002
#define UPS_SUSPEND 0x0004
#define UPS_OVERCURRENT_INDICATOR 0x0008
#define UPS_RESET 0x0010
#define UPS_PORT_L1 0x0020 /* USB 2.0 only */
/* The link-state bits are valid for Super-Speed USB HUBs */
#define UPS_PORT_LINK_STATE_GET(x) (((x) 5) 0xF)
#define UPS_PORT_LINK_STATE_SET(x) (((x) 0xF) 5)
#define UPS_PORT_LS_U0 0x00
#define UPS_PORT_LS_U1 0x01
#define UPS_PORT_LS_U2 0x02
#define UPS_PORT_LS_U3 0x03
#define UPS_PORT_LS_SS_DIS 0x04
#define UPS_PORT_LS_RX_DET 0x05
#define UPS_PORT_LS_SS_INA 0x06
#define UPS_PORT_LS_POLL0x07
#define UPS_PORT_LS_RECOVER 0x08
#define UPS_PORT_LS_HOT_RST 0x09
#define UPS_PORT_LS_COMP_MODE 0x0A
#define UPS_PORT_LS_LOOPBACK0x0B
#define UPS_PORT_LS_RESUME 0x0F
#define UPS_PORT_POWER 0x0100
#define UPS_PORT_POWER_SS 0x0200 /* super-speed only */
#define UPS_LOW_SPEED 0x0200
#define UPS_HIGH_SPEED 0x0400
#define UPS_OTHER_SPEED 0x0600 /* currently FreeBSD
specific */
#define UPS_PORT_TEST 0x0800
#define UPS_PORT_INDICATOR 0x1000
#define UPS_PORT_MODE_DEVICE0x8000 /* currently FreeBSD
specific */
uWord wPortChange;
#define UPS_C_CONNECT_STATUS0x0001
#define UPS_C_PORT_ENABLED 0x0002
#define UPS_C_SUSPEND 0x0004
#define UPS_C_OVERCURRENT_INDICATOR 0x0008
#define UPS_C_PORT_RESET0x0010
#define UPS_C_PORT_L1 0x0020 /* USB 2.0 only */
#define UPS_C_BH_PORT_RESET 0x0020 /* USB 3.0 only */
#define UPS_C_PORT_LINK_STATE 0x0040
#define UPS_C_PORT_CONFIG_ERROR 0x0080
} __packed;
It is probed regularly by the UHUB driver and the port status is printed
in dmesg.
Turn on like this:
sysctl hw.usb.uhub.debug=16
By resetting the root HUB, you can write new power on bits:
usbconfig -d X.1 set_config 255
usbconfig -d X.1 set_config 0
--HPS
Well, that's problematic. The USB tree looks like this normally:
ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen2.1: EHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen3.1: UHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen4.1: UHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen5.1: UHCI root HUB Intel at usbus5, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen6.1: EHCI root HUB Intel at usbus6, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen0.2: Biometric Coprocessor STMicroelectronics at usbus0, cfg=0
md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
But, on resume ... sometimes ... ugen0.1 is just flatout gone (along
with the ugen0.2 device, obviously). This only seems to happen with
various USB device plugged in (tried about 4 different make/model usb
sticks and ext drives).
So, resetting doesn't work as the device is literally gone. Thoughts?
sean
Setting hw.usb.debug=15 should give you some hints. Are you sure the PCI
device is still there after resume?
--HPS
I did a pre/post resume pciconf -lv and I see no difference between the
two.
On initial resume, ugen0.1 appears to be there in usbconfig output, but
trying to set_config on it, causes it to dissapear and causes usbconfig
to hang:
root@bruno:/home/sbruno # usbconfig -d 0.1 set_config 255
load: 0.36 cmd: usbconfig 1540 [UGONE] 4.19r 0.00u 0.00s 0% 2064k
load: 0.36 cmd: usbconfig 1540 [UGONE] 5.00r 0.00u 0.00s 0% 2064k
load: 0.36 cmd: usbconfig 1540 [UGONE] 5.16r 0.00u 0.00s 0% 2064k
load: 0.36 cmd: usbconfig 1540 [UGONE] 5.35r 0.00u 0.00s 0
Re: usb/184918: [ural] regression on WEP
The following reply was made to PR usb/184918; it has been noted by GNATS. From: Sean Bruno sbr...@ignoranthack.me To: bug-follo...@freebsd.org, takaw...@init-main.com Cc: Subject: Re: usb/184918: [ural] regression on WEP Date: Mon, 21 Apr 2014 05:45:24 -0700 --=-7AgUgKdCaOk69Nh0uQGa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable http://svnweb.freebsd.org/base?view=3Drevisionrevision=3D264390 This was found and fixed a few days ago in stable/10 ... try updating to stable/10. sean --=-7AgUgKdCaOk69Nh0uQGa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJTVRLkAAoJEBkJRdwI6BaH2LIH/ihUvTkHcpw4OZcj9ejA+OB+ f4E61ahhKxG524RdPHB4qZ1b9ZCFIWuMhCfNGHI1Eq9VneyJ6BrBz+gSwYlZVn7n DoQ2ZjO05/xRGYRfBlob6eW2OoZKbJMgW1yFsAMODKAoqPXTV8xv+REnOrVBbdmb wmz9pkC75DAtl0BQi3fH04RrqZL0R9HwpWVzpBAPPiny9MXjA15rg3Zfy1bXvKdV 6jA2NOmU7fTZ6I4WIW1/Mp0qlLcQQy5hYmSXNzKYZ8qdeRPx8x4JwMAfdno3Bq3/ rrpLeoXJHBia01ZO/I7HLxemdWuJyozQGL1q2n884E70lxB29AahJgOcSHUlmB8= =b7Jq -END PGP SIGNATURE- --=-7AgUgKdCaOk69Nh0uQGa-- ___ 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
Drive continues to spin down and spin back up
Was using this drive with -current today and noticed that it seems to spin down into power save and back up again a lot. When its not being used, it tried to go into power save, but since it is mounted, it keeps getting spun back up. Is there a quirk for this somewhere? ugen1.3: Iomega HDD Iomega HDD at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) repeats over and over (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 3 refs (pass3:umass-sim0:0:0:0): lost device (pass3:umass-sim0:0:0:0): removing device entry (da0:umass-sim0:0:0:0): removing device entry ugen1.3: Iomega HDD at usbus1 umass0: Interface0 on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:3:0:-1: Attached to scbus3 pass3 at umass-sim0 bus 0 scbus3 target 0 lun 0 pass3: External RAID 0 Fixed Direct Access SCSI-4 device pass3: Serial Number ABCDEF0123456847 pass3: 40.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: External RAID 0 Fixed Direct Access SCSI-4 device da0: Serial Number ABCDEF0123456847 da0: 40.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da0: quirks=0x2NO_6_BYTE da0: Delete methods: NONE(*) signature.asc Description: This is a digitally signed message part
Re: mouse/keyboard on suspend/resume stutter
On Wed, 2013-01-09 at 07:34 -0800, Warren Block wrote: On Tue, 8 Jan 2013, Sean Bruno wrote: I've noted that my stable/9-ish laptop seems to have issues with mouse/keyboard on suspend resume. The mouse behavior and keyboard seems laggy and sticks from time to time. If that's in X, that's sometimes seen with the misuse of AllowEmptyInput. That you don't see it normally might just mean something in the suspend/resume is triggering it. http://www.wonkity.com/~wblock/docs/html/aei.html Nope, not that. Still playing with it. I'm trying to do an entire week without rebooting my laptop. At this point, I can't make it an entire day without rebooting due to wireless things. Sean ___ 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
mouse/keyboard on suspend/resume stutter
I've noted that my stable/9-ish laptop seems to have issues with mouse/keyboard on suspend resume. The mouse behavior and keyboard seems laggy and sticks from time to time. What should I start poking at to diagnose this? Seems to happen on the T420/T520 series. Sean ugen0.1: EHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x idProduct = 0x bcdDevice = 0x0100 iManufacturer = 0x0001 Intel iProduct = 0x0002 EHCI root HUB iSerialNumber = 0x no string bNumConfigurations = 0x0001 ugen1.1: EHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x idProduct = 0x bcdDevice = 0x0100 iManufacturer = 0x0001 Intel iProduct = 0x0002 EHCI root HUB iSerialNumber = 0x no string bNumConfigurations = 0x0001 ugen1.2: product 0x0024 vendor 0x8087 at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x8087 idProduct = 0x0024 bcdDevice = 0x iManufacturer = 0x no string iProduct = 0x no string iSerialNumber = 0x no string bNumConfigurations = 0x0001 ugen0.2: product 0x0024 vendor 0x8087 at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x8087 idProduct = 0x0024 bcdDevice = 0x iManufacturer = 0x no string iProduct = 0x no string iSerialNumber = 0x no string bNumConfigurations = 0x0001 ugen0.3: product 0x100a vendor 0x17ef at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0002 bMaxPacketSize0 = 0x0040 idVendor = 0x17ef idProduct = 0x100a bcdDevice = 0x iManufacturer = 0x no string iProduct = 0x no string iSerialNumber = 0x no string bNumConfigurations = 0x0001 ugen0.4: HP Basic USB Keyboard CHICONY at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x03f0 idProduct = 0x0024 bcdDevice = 0x0300 iManufacturer = 0x0001 CHICONY iProduct = 0x0002 HP Basic USB Keyboard iSerialNumber = 0x no string bNumConfigurations = 0x0001 ugen0.5: USB-PS2 Optical Mouse Logitech at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x046d idProduct = 0xc050 bcdDevice = 0x2720 iManufacturer = 0x0001 Logitech iProduct = 0x0002 USB-PS/2 Optical Mouse iSerialNumber = 0x no string bNumConfigurations = 0x0001 ugen0.6: Integrated Camera Chicony Electronics Co., Ltd. at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ef bDeviceSubClass = 0x0002 bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x04f2 idProduct = 0xb217 bcdDevice = 0x0854 iManufacturer = 0x0001 Chicony Electronics Co., Ltd. iProduct = 0x0002 Integrated Camera iSerialNumber = 0x no string bNumConfigurations = 0x0001 ___ 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
qemu hw/usb/host-bsd.c
Trying to update the qemu port this weekend and I see there are a lot of legacy usb things going on inside of host-bsd.c that need to be updated. I've started with the qemu git tree at git://git.qemu.org/qemu.git Specifically, I'm staring at hw/usb/host-bsd.c The main issues seem to be wrapped around its handling and setup of SHORT_XFER and its abuse of the old udi_devnames[] data in the deviceinfo structs. I've started with the attached diff. I'm pretty sure this is wrong. Let start with the abuse of udi_devnames in this code. What's the best way for in usb-land to setup its emulated usb nonsense? http://people.freebsd.org/~sbruno/host-bsd.c.txt sean ___ 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
USB tethering, Motorola Droid
Was wondering if there is an expectation that the tethering capability of a Motorola Droid *should* work on FreeBSD at this point. The Linux folks seem to have it working just fine, and I was wondering what would need to be done to get it working for us? I assume from earlier posts about RNDIS that it doesn't work at all: [sbruno@powernoodle-l7 /usr/home/sbruno]$ usbconfig -u 1 -a 3 dump_curr_config_desc ugen1.3: Motorola A855 Motorola at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x00e0 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x00e0 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0003 iInterface = 0x0004 RNDIS Communications Control Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x05, 0x24, 0x01, 0x00, 0x01 Additional Descriptor bLength = 0x04 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x04, 0x24, 0x02, 0x00 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x00, 0x01 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 IN bmAttributes = 0x0003 INTERRUPT wMaxPacketSize = 0x0008 bInterval = 0x0009 bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x0005 RNDIS Ethernet Data Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x ___ 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
[stable 9] usbus entries in network namespace?
I note that on stable/9 the usbus seems to be inserting itself into the list of network links. What is this all about and how do I turn it off? -bash-4.2$ netstat -i NameMtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll bce0 1500 Link#1 00:25:64:f9:6d:b297002 0 0 33380 0 0 bce0 1500 10.73.149.0 x50 33623 - - 33322 - - bce0 1500 fe80::225:64f fe80::225:64ff:fe0 - - 0 - - bce1* 1500 Link#2 00:25:64:f9:6d:b40 0 0 0 0 0 bce2* 1500 Link#3 00:25:64:f9:6d:b60 0 0 0 0 0 bce3* 1500 Link#4 00:25:64:f9:6d:b80 0 0 0 0 0 usbus 0 Link#5 0 0 0 0 0 0 usbus 0 Link#6 0 0 0 0 0 0 usbus 0 Link#7 0 0 0 0 0 0 usbus 0 Link#8 0 0 0 0 0 0 usbus 0 Link#9 0 0 0 0 0 0 usbus 0 Link#10 0 0 0 0 0 0 lo0 16384 Link#11 0 0 0 0 0 0 lo0 16384 localhost ::1 0 - - 0 - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - lo0 16384 your-net localhost0 - - 0 - - ___ 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: [stable 9] usbus entries in network namespace?
On Tue, 2012-04-03 at 09:59 -0700, Hans Petter Selasky wrote: On Tuesday 03 April 2012 18:52:20 Sean Bruno wrote: I note that on stable/9 the usbus seems to be inserting itself into the list of network links. What is this all about and how do I turn it off? Hi, Try, sysctl hw.usb.no_pf=1 --HPS Muchas gracias. Sean ___ 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: 8.x grudges
5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. This is a commonly-reported problem, assuming at boot you mean while the kernel is starting. Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ Looking at this link, it doesn't match the described issue. Mikhail's machine would not boot *until* he disabled the firewire controller in the BIOS. The referenced issue on that Shuttle based machine talks about disabling the firewire controller and *then* it still being alive when the system powers on and crashing the system. I interpret this as a bug. Sean Also, I suck at reply-to. sean ___ 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: 8.x grudges
5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. This is a commonly-reported problem, assuming at boot you mean while the kernel is starting. Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ Looking at this link, it doesn't match the described issue. Mikhail's machine would not boot *until* he disabled the firewire controller in the BIOS. The referenced issue on that Shuttle based machine talks about disabling the firewire controller and *then* it still being alive when the system powers on and crashing the system. I interpret this as a bug. Sean ___ 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
