Re: HEADSUP usb2/usb4bsd to become default in GENERIC

From: Hans Petter Selasky <hselasky_at_c2i.net>
Date: Sat, 14 Feb 2009 14:48:54 +0100
On Saturday 14 February 2009, Rodion Turlac wrote:
>  Hello.
>
> I have tried to test USB2 stack with usb flash on FreeBSD-CURRENT
> under VMWare Server, but I have got dmesg output like this.
>
> uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0x1060-0x107f irq 9
> at device 7.2 on pci0
> uhci0: [ITHREAD]
> uhci0: LegSup = 0x003b
> usbus0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
> usbus0: 12Mbps Full Speed USB v1.0
> ugen0.1: <Intel> at usbus0
> ushub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
> ushub0: 2 ports with 2 removable, self powered
> usb2_alloc_device:1401: set address 2 failed (ignored)
> usb2_alloc_device:1437: getting device descriptor at addr 2 failed!
> usb2_req_re_enumerate:1409: addr=2, set address failed! (ignored)
> usb2_req_re_enumerate:1422: getting device descriptor at addr 2 failed!
> usb2_req_re_enumerate:1409: addr=2, set address failed! (ignored)
> usb2_req_re_enumerate:1422: getting device descriptor at addr 2 failed!
> ugen0.2: <> at usbus0 (disconnected)
> uhub_reattach_port:414: could not allocate new device!
> usb2_alloc_device:1401: set address 2 failed (ignored)
> usb2_alloc_device:1437: getting device descriptor at addr 2 failed!
> usb2_req_re_enumerate:1409: addr=2, set address failed! (ignored)
> usb2_req_re_enumerate:1422: getting device descriptor at addr 2 failed!
> usb2_req_re_enumerate:1409: addr=2, set address failed! (ignored)
> usb2_req_re_enumerate:1422: getting device descriptor at addr 2 failed!
> ugen0.2: <> at usbus0 (disconnected)
> uhub_reattach_port:414: could not allocate new device!
>
> With old USB stack all works fine. There is dmesg output.
>
> uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0x1060-0x107f irq 9
> at device 7.2 on pci0
> uhci0: [GIANT-LOCKED]
> uhci0: [ITHREAD]
> usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
> usb0: USB revision 1.0
> uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> uhub0: 2 ports with 2 removable, self powered
> umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/1.41, addr 2> on
> uhub0
> umass0: Get Max Lun not supported (STALLED)
> (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
> (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition
> (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
> (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have
> changed
> (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <JetFlash TS1GJFV33 8.07> Removable Direct Access SCSI-2 device
> da0: 1.000MB/s transfers
> da0: 977MB (2002942 512 byte sectors: 64H 32S/T 977C)
> GEOM: da0: partition 1 does not start on a track boundary.
> GEOM: da0: partition 1 does not end on a track boundary.
>
>
> uname -a
> FreeBSD rad-home-60.rad.home 8.0-CURRENT FreeBSD 8.0-CURRENT #4:
>  Sat Feb 14 13:36:12 EET 2009
> root_at_rad-home-60.rad.home:/usr/obj/usr/src/sys/KERNEL  i386
>
> How could I track down this problem of USB2 stack?

There are debugging sysctls you can turn on:

See:

sysctl hw.usb2

Else I would contact the VMWare people about this. Seems like there is a 
dependancy inside the VMWare emulator to a certain way of operation.

--HPS
Received on Sat Feb 14 2009 - 12:46:31 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:42 UTC