strange errors when removing a second USB keyboard

2022-11-10 Thread Gary Jennejohn
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

2022-11-10 Thread Gary Jennejohn
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

2023-09-09 Thread Gary Jennejohn
; 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

2023-09-09 Thread Gary Jennejohn
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

2024-01-18 Thread Gary Jennejohn
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

2024-01-19 Thread Gary Jennejohn
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

2024-01-20 Thread Gary Jennejohn
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