strange errors when removing a second USB keyboard
rnst kernel: uhub1: 22 ports with 22 removable, self powered Nov 10 15:02:08 ernst kernel: xhci0: Resetting controller Nov 10 15:02:08 ernst kernel: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) Nov 10 15:02:17 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Nov 10 15:02:17 ernst kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) Nov 10 15:02:20 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Nov 10 15:02:21 ernst kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) Nov 10 15:02:23 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Nov 10 15:02:23 ernst kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) Nov 10 15:02:26 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Nov 10 15:02:27 ernst kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) Nov 10 15:02:29 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Nov 10 15:02:29 ernst kernel: ugen0.2: at usbus0 (disconnected) Nov 10 15:02:29 ernst kernel: uhub_reattach_port: could not allocate new device Nov 10 15:02:29 ernst kernel: uhub1: at usbus0, port 1, addr 1 (disconnected) Nov 10 15:02:29 ernst kernel: uhub1: detached Nov 10 15:02:29 ernst kernel: uhub1 on usbus0 Nov 10 15:02:29 ernst kernel: uhub1: on usbus0 Nov 10 15:02:32 ernst kernel: uhub1: 22 ports with 22 removable, self powered Nov 10 15:02:32 ernst kernel: xhci0: Resetting controller Nov 10 15:02:32 ernst kernel: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) Nov 10 15:02:48 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Nov 10 15:02:49 ernst kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Nov 10 15:02:57 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Nov 10 15:02:57 ernst kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) Nov 10 15:03:00 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Nov 10 15:03:00 ernst kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) Nov 10 15:03:03 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Nov 10 15:03:03 ernst kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) Nov 10 15:03:06 ernst kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Nov 10 15:03:06 ernst kernel: ugen0.2: at usbus0 (disconnected) Nov 10 15:03:06 ernst kernel: uhub_reattach_port: could not allocate new device Nov 10 15:03:06 ernst kernel: uhub1: at usbus0, port 1, addr 1 (disconnected) Nov 10 15:03:06 ernst kernel: uhub1: detached Nov 10 15:03:06 ernst kernel: uhub1 on usbus0 Nov 10 15:03:06 ernst kernel: uhub1: on usbus0 Nov 10 15:03:08 ernst kernel: uhub1: 22 ports with 22 removable, self powered It looks like the removal of the second keyboard was not handled correctly. Nov 10 15:03:08 ernst kernel: ugen2.5: at usbus2 Nov 10 15:03:08 ernst kernel: uhub4 on uhub3 Nov 10 15:03:08 ernst kernel: uhub4: on usbus2 Nov 10 15:03:09 ernst kernel: uhub4: 3 ports with 2 removable, bus powered Nov 10 15:03:09 ernst kernel: ugen2.6: at usbus2 Nov 10 15:03:09 ernst kernel: ukbd0 on uhub4 Nov 10 15:03:09 ernst kernel: ukbd0: on usbus2 Nov 10 15:03:09 ernst kernel: kbd2 at ukbd0 Nov 10 15:03:10 ernst kernel: ugen2.7: at usbus2 Nov 10 15:03:10 ernst kernel: ums0 on uhub4 Nov 10 15:03:10 ernst kernel: ums0: on usbus2 Nov 10 15:03:10 ernst kernel: ums0: 3 buttons and [XYZ] coordinates ID=0 I only got the keyboard and mouse back after plugging the keyboard into a USB3 hub. Interestingly, I could then plug a USB thumb drive into one of the USB2 ports and it was recognized, but trying to plug the keyboard into the adjacent USB2 port resulted in lots of errors and I had to plug it back into the USB3 hub. So, it almost appears that having two USB keyboards plugged into USB2 ports, and then removiing one, resulted in the errors. -- Gary Jennejohn
Re: strange errors when removing a second USB keyboard
On Thu, 10 Nov 2022 20:33:39 +0100 Hans Petter Selasky wrote: > On 11/10/22 15:36, Gary Jennejohn wrote: > > Nov 10 15:02:08 ernst kernel: xhci0: Resetting controller > > Hi Gary, > > To me it looks like the XHCI hardware hit an assert and crashed and a reset > was needed! > > It is very difficult to figure out such things without the help of the > manufacturer. > > Maybe XHCI debug prints will help shed some more light into what is going on > there. > OK, but why does the XHCI controller recognize the USB thumbdrive _after_ the reset, but not the keyboard? Seems like the thumbdrive should also fail to work in this case. -- Gary Jennejohn
Re: udl(4) patch for SIIG USB 2.0 DVI/VGA Pro support
; 800x600 @ 75Hz (49500 816 896 1056 601 604 625 +H +V) > > 1024x768 @ 60Hz (65000 1048 1184 1344 771 777 806 -H -V) > > 1024x768 @ 75Hz (78750 1040 1136 1312 769 772 800 +H +V) > > 1280x1024 @ 75Hz (135000 1296 1440 1688 1025 1028 1066 +H +V) > > 1366x768 @ 60Hz (85500 1436 1579 1792 771 774 798 +H +V) > > Preferred mode: 1366x768 @ 60Hz > > Number of extension blocks: 0 > > udl0: Mode selected 1280x1024 @ 75Hz > > fbd0 on udl0 > > > > root@fbsd14a4:~ # usbconfig -d ugen0.2 dump_device_desc > > ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) > > pwr=ON (500mA) > > > > bLength = 0x0012 > > bDescriptorType = 0x0001 > > bcdUSB = 0x0110 > > bDeviceClass = 0x > > bDeviceSubClass = 0x > > bDeviceProtocol = 0x > > bMaxPacketSize0 = 0x0040 > > idVendor = 0x17e9 > > idProduct = 0x028f > > bcdDevice = 0x0001 > > iManufacturer = 0x0001 > > iProduct = 0x0002 > > iSerialNumber = 0x0003 <111018> > > bNumConfigurations = 0x0001 > > > > root@fbsd14a4:~ # sysctl -a | grep udl > > udl0 on uhub0 > > udl0: on usbus0 > > udl0: Mode selected 1280x1024 @ 75Hz > > fbd0 on udl0 > > device udl > > hw.usb.udl.fps: 25 > > hw.usb.udl.debug: 0 > > dev.fbd.0.%parent: udl0 > > dev.udl.0.mode: 17 > > dev.udl.0.mode_force: -1 > > dev.udl.0.chipid: 4 > > dev.udl.0.chipid_force: -1 > > dev.udl.0.%parent: uhub0 > > dev.udl.0.%pnpinfo: vendor=0x17e9 product=0x028f devclass=0x00 > > devsubclass=0x00 devproto=0x00 sernum="111018" release=0x0001 mode=host > > intclass=0xff intsubclass=0x00 intprotocol=0x00 > > dev.udl.0.%location: bus=0 hubaddr=1 port=1 devaddr=2 interface=0 > > ugen=ugen0.2 > > dev.udl.0.%driver: udl > > dev.udl.0.%desc: DisplayLink AN2440D3, class 0/0, rev 1.10/0.01, addr 2 > > dev.udl.%parent: > > > > Lastly, I would also submit a patch for the udl(4) manual for update. > > First, there's a need to include DL-195 in the description since this model > > is the chipset of SIIG USB 2.0 DVI/VGA Pro which is working as tested. > > Second, the udl(4) driver must be accompanied with the videomode driver > > otherwise kernel compilation will fail and third, adding the SIIG USB 2.0 > > DVI/VGA Pro device in the list. > > > > root@fbsd14a4:~ # diff -Nur udl-manual.orig udl-manual > > --- udl-manual.orig 2023-08-18 00:13:25.583021000 + > > +++ udl-manual 2023-08-18 15:06:41.896163000 + > > @@ -1,13 +1,14 @@ > > UDL(4) FreeBSD Kernel Interfaces Manual > > UDL(4) > > > > NAME > > - udl ? DisplayLink DL-120 / DL-160 USB display devices > > + udl ? DisplayLink DL-120 / DL-160 / DL-195 USB display devices > > > > SYNOPSIS > > - To compile this driver into the kernel, place the following line in > > your > > + To compile this driver into the kernel, place the following lines in > > your > > kernel configuration file: > > > > device udl > > + device videomode > > > > Alternatively, to load the driver as a module at boot time, place the > > following line in loader.conf(5): > > @@ -16,7 +17,7 @@ > > > > DESCRIPTION > > The udl driver supports USB display devices based on the DisplayLink > > - DL-120 / DL-160 graphic chip. > > + DL-120 / DL-160 / DL-195 graphic chip. > > > > HARDWARE > > The following devices should work: > > @@ -40,6 +41,7 @@ > > Unitek Y-2240 USB to DVI > > VideoHome NBdock1920 > > i-tec USB 2.0 Docking Station (USBDVIDOCK) > > + SIIG USB 2.0 DVI/VGA Pro > > > > Thanks, > > Archimedes > > > > Hi, > > By the way, should I post this patch to the Phabricator > https://reviews.freebsd.org for review? The other patch is related to the > manual, where to post it as well? > Posting the patches to Phabricator would be a good idea. It might get more attention that way. Since the manpage is also relevant to the driver I would recommend putting it in the Phabricator entry along with the USB driver patches. Once you've created the Phabricator entry you should post its number. -- Gary Jennejohn
Re: udl(4) patch for SIIG USB 2.0 DVI/VGA Pro support
On Sat, 9 Sep 2023 22:07:46 +0800 Archimedes Gaviola wrote: > On Sat, Sep 9, 2023 at 6:23?PM Archimedes Gaviola < > archimedes.gavi...@gmail.com> wrote: > [big SNIP] > Hi Gary, > > I already posted the patch here https://reviews.freebsd.org/D41798 however, > submission requires reviewers. Any idea who should be the designated > reviewers for this? > Unfortunately, the original USB maintainer. Hans Petter Selasky, died recently. But I see that ste...@freebsd.org did a few USB commits in August, so he may be a candidate. -- Gary Jennejohn
Re: USB key is 2.0 or 3.0
On Thu, 18 Jan 2024 14:08:09 +0100 Matthias Apitz wrote: > Hello, > > I will move this topic to freebsd-usb@ > > I bought a new USB 3.0 key with very poor write performan and the > question is if the key is really USB 3.0: > > - Forwarded message from Matthias Apitz - > > El día jueves, enero 18, 2024 a las 02:43:23 +1100, Ian Smith escribió: > > > From your first post: > > > > > Jan 16 17:50:52 c720-1400094 kernel: da0: 40.000MB/s transfers > > > Jan 16 17:50:52 c720-1400094 kernel: da0: 12MB (24576 512 byte > > sectors) > > I checked older /var/log/messages and other external USB disks have > 400.000MB/s. So it is not the port of the laptop. > > I run on my Linux phone a lsusb command which shows: > > $ lsusb -v -d 058f:6387 > Bus 003 Device 002: ID 058f:6387 Alcor Micro Corp. Flash Drive > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.10 > bDeviceClass0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > idVendor 0x058f Alcor Micro Corp. > idProduct 0x6387 Flash Drive > bcdDevice0.02 > iManufacturer 1 Generic > iProduct2 Mass Storage > iSerial 3 A430786F > ... > > I interpret 'bcdUSB 2.10' as an indicator of USB 2.10. The key is new > and its wrapping says USB 3.0. > I plugged a Intenso USB3 stick into a USB3 port and got this: bcdUSB = 0x0320 I then plugged it into a USB2 port and got this: bcdUSB = 0x0210 Note that I executed usbconfig -v -d ugenX.Y in both cases. So, I suspect that your Linux phone might only support USB2. -- Gary Jennejohn
Re: USB key is 2.0 or 3.0
On Thu, 18 Jan 2024 18:30:34 +0100 Matthias Apitz wrote: > I've two new USB keys, both claiming on its wrapping USB 3.0: > > usbconfig -v reads from them: > > ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) > pwr=ON (200mA) > ugen0.4.0: umass0: > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0210 > bDeviceClass = 0x > bDeviceSubClass = 0x > bDeviceProtocol = 0x > bMaxPacketSize0 = 0x0040 > idVendor = 0x058f > idProduct = 0x6387 > bcdDevice = 0x0002 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 > bNumConfigurations = 0x0001 > > > ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) > pwr=ON (224mA) > ugen0.4.0: umass0: > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0210 > bDeviceClass = 0x > bDeviceSubClass = 0x > bDeviceProtocol = 0x > bMaxPacketSize0 = 0x0040 > idVendor = 0x0781 > idProduct = 0x55ab > bcdDevice = 0x0100 > > Both say on plugin "da0: 40.000MB/s transfers"; the USB port itself says > on plugin of an external disks "da0: 400.000MB/s transfers", what is > expected for USB 3.0; > > Why both USB keys only reach da0: 40.000MB/s? > You could try running usbdump(8). Be aware that you need device bpf and perhaps options DEV_BPF in your kernel config file if you aren't running a GENERIC kernel. usbdump has to be run as root. I tried it with a USB3 and a USB2 thumb drive, plugging both into a USB3 port. I used this command line: usbdump -d ugenX.Y -s 256 -w /tmp/USB{2,3} to save the output and then usbdump -r /tmp/USB{2,3} to get the user readable text. You'll probably want to use different names for the -w file names. I simply plugged in and unplugged each thumb drive and then stopped usbdump. The USB3 thumb drive always showed SPD=SUPER and the USB2 thumb drive always showed SPD=HIGH in the user readable text. So, if your disk shows SPD=SUPER and the thumb drives show SPD=HIGH then the thumb drives are NOT USB3. -- Gary Jennejohn
Re: USB key is 2.0 or 3.0
On Sat, 20 Jan 2024 08:53:58 +0100 Matthias Apitz wrote: > El día viernes, enero 19, 2024 a las 02:24:19p. m. +0000, Gary Jennejohn > escribió: > > > You could try running usbdump(8). Be aware that you need device bpf and > > perhaps options DEV_BPF in your kernel config file if you aren't running a > > GENERIC kernel. > > [SNIP] > > So, if your disk shows SPD=SUPER and the thumb drives show SPD=HIGH > > then the thumb drives are NOT USB3. > > I did the above tests with the 'hama' USB key; it shows: > > $ tail -5 hama.dmp.txt > 08:15:12.873247 usbus0.4 > DONE-BULK-EP=0002,SPD=HIGH,NFR=1,SLEN=0,IVAL=0,ERR=0 > 08:15:12.873254 usbus0.4 SUBM-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=0,IVAL=0 > 08:15:12.874636 usbus0.4 > DONE-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=36,IVAL=0,ERR=0 > 08:15:12.874642 usbus0.4 SUBM-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=0,IVAL=0 > 08:15:12.874884 usbus0.4 > DONE-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=16,IVAL=0,ERR=0 > > Then I used an extrernal Western Digital USB disk, which presents itself > in /var/log/messages as: > > Jan 20 08:36:07 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN > set for USB mass storage device Western Digital Elements 2621 (0x1058:0x2621) > Jan 20 08:36:07 c720-1400094 kernel: usb_msc_auto_quirk: > UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage device Western Digital > Elements 2621 (0x1058:0x2621) > Jan 20 08:36:09 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_SYNC_CACHE > set for USB mass storage device Western Digital Elements 2621 (0x1058:0x2621) > Jan 20 08:36:09 c720-1400094 kernel: usb_msc_auto_quirk: > UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device Western Digital > Elements 2621 (0x1058:0x2621) > Jan 20 08:36:09 c720-1400094 kernel: usb_msc_auto_quirk: > UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage device Western Digital > Elements 2621 (0x1058:0x2621) > Jan 20 08:36:09 c720-1400094 kernel: usb_msc_auto_quirk: UQ_MSC_NO_START_STOP > set for USB mass storage device Western Digital Elements 2621 (0x1058:0x2621) > Jan 20 08:36:09 c720-1400094 kernel: ugen0.4: > at usbus0 > Jan 20 08:36:09 c720-1400094 kernel: umass0 on uhub0 > Jan 20 08:36:09 c720-1400094 kernel: umass0: class 0/0, rev 3.10/10.26, addr 4> on usbus0 > Jan 20 08:36:09 c720-1400094 kernel: umass0: SCSI over Bulk-Only; quirks = > 0xc105 > Jan 20 08:36:09 c720-1400094 kernel: umass0:1:0: Attached to scbus1 > Jan 20 08:36:10 c720-1400094 kernel: da0 at umass-sim0 bus 0 scbus1 target 0 > lun 0 > Jan 20 08:36:10 c720-1400094 kernel: da0: Fixed > Direct Access SPC-4 SCSI device > Jan 20 08:36:10 c720-1400094 kernel: da0: Serial Number > 57584B314132394152334B33 > Jan 20 08:36:10 c720-1400094 kernel: da0: 400.000MB/s transfers > Jan 20 08:36:10 c720-1400094 kernel: da0: 1907697MB (3906963456 512 byte > sectors) > Jan 20 08:36:10 c720-1400094 kernel: da0: quirks=0x2 > Jan 20 08:36:17 c720-1400094 kernel: ugen0.4: > at usbus0 (disconnected) > > and the usbdump shows: > > $ tail -5 WD.dmp.txt > 08:36:10.663903 usbus0.4 > DONE-BULK-EP=0002,SPD=SUPER,NFR=1,SLEN=0,IVAL=0,ERR=0 > 08:36:10.663906 usbus0.4 SUBM-BULK-EP=0081,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 > 08:36:10.664158 usbus0.4 > DONE-BULK-EP=0081,SPD=SUPER,NFR=1,SLEN=512,IVAL=0,ERR=0 > 08:36:10.664161 usbus0.4 SUBM-BULK-EP=0081,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 > 08:36:10.664411 usbus0.4 > DONE-BULK-EP=0081,SPD=SUPER,NFR=1,SLEN=16,IVAL=0,ERR=0 > > Thanks in advance for further comments > It shouldn't be a power problem since the HDD needs more power than a thumb drive and from what I can find in a search the Western Digital Elements 2621 doesn't have a separate power supply. Can you send them back to wherever you bought them and demand replacements? A reputable seller shouldn't have a problem with that. I have a number of Intenso 128GB USB3.2 thumb drives and I've never had a problem with them. Unfortunately, there are lots of counterfeit thumb drives in the wild and you might be a victim. -- Gary Jennejohn