Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Aug 2004 23:59:39 +0200 (CEST)
From:      Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk>
To:        freebsd-current@freebsd.org
Subject:   Re: Unloading USB driver while device is attached. 
Message-ID:  <200408142159.i7ELxdH00871@Mail.NOSPAM.DynDNS.dK>
References:  <200407200045.aa99979@salmon.maths.tcd.ie> <200407271843.aa10377@salmon.maths.tcd.ie> <200408102244.i7AMid614188@Mail.NOSPAM.DynDNS.dK>

next in thread | previous in thread | raw e-mail | index | archive | help
[keep replies to the list and I'll catch up later, thanks]

Talking to myself, I figured a followup (in current@) might be appropriate.

> I no longer see the need_toggle_updates that froze my disk, from
> my previous attempt to merge in -current code, and I've got that
> disk attached now via a USB2 hub.

Actually, on another machine with a different card, and the same
code, I still see the problem (accompanied by panic soon after),
and furthermore, the USB2 hub (although one rev number different)
gets held onto by USB1.

This machine is where I do most of my work (offline); the other
machine where it worked great I normally don't use that much.
So it could well be that the previous code would also work, if
I had tried it on the machine that I use on occasion when going
online.

As far as I've seen, NetBSD on the machine where I had this
panic works fine accessing the disk over EHCI (and it's the
system disk too).

For comparison, here's how the problem machine looks -- extracts
from a boot dmesg, followed by usbdevs to show how the USB2 hub
appears.  Following it, I give the same for the machine which
seemed to work.

Not only are the cards different between the two machines, but
even when I use card from the working machine in the problem
machine, I see problems -- I had to hack pcib into -stable, and
both with and without it, data retrieved both over OHCI and via
firewire seems to be corrupt.  With the UHCI card, the data
appears perfectly fine.  In other words, there could be something
else going on resulting in the data_toggle problem.  Like, my
machine could be wacky.  Which I know has some truth.



uhci0: <VIA 83C572 USB controller> port 0x6300-0x631f irq 12 at device 11.0 on pci0
usb0: <VIA 83C572 USB controller> on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: <VIA 83C572 USB controller> port 0x6400-0x641f irq 11 at device 11.1 on pci0
usb1: <VIA 83C572 USB controller> on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ehci0: <VIA VT6202 USB 2.0 controller> mem 0xe1002000-0xe10020ff irq 10 at device 11.2 on pci0
	using shared irq10.
ehci_pci_attach: companion usb0
ehci_pci_attach: companion usb1
usb2: EHCI version 0.95
usb2: companion controllers, 2 ports each: usb0 usb1
usb2: <VIA VT6202 USB 2.0 controller> on ehci0
usb2: USB revision 2.0
uhub2: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2: 4 ports with 4 removable, self powered
 [ ... ]
umass0: Maxtor 5000XT v01.00.00, rev 2.00/1.00, addr 2
ehci_idone: need toggle update status=80018d40 nstatus=80008c80
ehci_idone: need toggle update status=80028d40 nstatus=80008c80
umass0: Get Max Lun not supported (STALLED)
umass0:2:0:-1: Attached to scbus2
uhub3: Cypress Semiconductor Slim Hub, class 9/0, rev 2.00/0.07, addr 2
uhub3: 4 ports with 4 removable, self powered
ums0: vendor 0x062a product 0x0000, rev 1.10/0.00, addr 3, iclass 3/1
ums0: 5 buttons and Z dir.


Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1.00
 port 1 powered
 port 2 addr 2: full speed, self powered, config 1, Slim Hub(0x6560), Cypress Semiconductor(0x04b4), rev 0.07
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 addr 3: low speed, power 100 mA, config 1, product 0x0000(0x0000), vendor 0x062a(0x062a), rev 0.00
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1.00
 port 1 powered
 port 2 powered
Controller /dev/usb2:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), VIA(0x0000), rev 1.00
 port 1 addr 2: high speed, self powered, config 1, 5000XT v01.00.00(0x5000), Maxtor(0x0d49), rev 1.00
 port 2 powered
 port 3 powered
 port 4 powered


Note that the hub remains on usb0...
Now, the same from the machine where it works as expected:


ohci0: <NEC uPD 9210 USB controller> mem 0xfdfff000-0xfdffffff irq 9 at device 8.0 on pci1
pcib1: device ohci0 requested decoded memory range 0xfdfff000-0xfdffffff
usb0: OHCI version 1.0
usb0: <NEC uPD 9210 USB controller> on ohci0
usb0: USB revision 1.0
uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1: <NEC uPD 9210 USB controller> mem 0xfdffe000-0xfdffefff irq 11 at device 8.1 on pci1
pcib1: device ohci1 requested decoded memory range 0xfdffe000-0xfdffefff
usb1: OHCI version 1.0
usb1: <NEC uPD 9210 USB controller> on ohci1
usb1: USB revision 1.0
uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ehci0: <NEC uPD 720100 USB 2.0 controller> mem 0xfdffdc00-0xfdffdcff irq 10 at device 8.2 on pci1
pcib1: device ehci0 requested decoded memory range 0xfdffdc00-0xfdffdcff
ehci_pci_attach: companion usb0
ehci_pci_attach: companion usb1
usb2: EHCI version 0.95
usb2: companion controllers, 3 ports each: usb0 usb1
usb2: <NEC uPD 720100 USB 2.0 controller> on ehci0
usb2: USB revision 2.0
uhub2: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2: 5 ports with 5 removable, self powered
 [ ... ]
uhub3: Cypress Semiconductor Slim Hub, class 9/0, rev 2.00/0.08, addr 2
uhub3: 4 ports with 4 removable, self powered
umass0: Maxtor 5000XT v01.00.00, rev 2.00/1.00, addr 3
ehci_idone: need toggle update status=80018d40 nstatus=80008c80
ehci_idone: need toggle update status=80028d40 nstatus=80008c80
umass0: Get Max Lun not supported (STALLED)
umass0:3:0:-1: Attached to scbus3
 [ snip bunch of x-in-1 cardreader attaches ]
ums0: vendor 0x062a product 0x0000, rev 1.10/0.00, addr 2, iclass 3/1
ums0: 5 buttons and Z dir.


After this boot, `usbdevs' looks like this:

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), NEC(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), NEC(0x0000), rev 1.00
 port 1 addr 2: low speed, power 100 mA, config 1, product 0x0000(0x0000), vendor 0x062a(0x062a), rev 0.00
 port 2 powered
Controller /dev/usb2:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), NEC(0x0000), rev 1.00
 port 1 addr 2: high speed, self powered, config 1, Slim Hub(0x6560), Cypress Semiconductor(0x04b4), rev 0.08
  port 1 addr 3: high speed, self powered, config 1, 5000XT v01.00.00(0x5000), Maxtor(0x0d49), rev 1.00
  port 2 powered
  port 3 addr 4: high speed, power 96 mA, config 1, 223 USB97C223(0x223a), SMSC(0x0424), rev 1.95
  port 4 addr 5: high speed, power 500 mA, config 1, USB 7-in-1 Card Reader(0x2126), OTi(0x0ea0), rev 2.00
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered



There may well be important clues in the parts of the `dmesg' that
I snipped for sake of brevity, with my luck.

On the other hand, there may well be known problems with this
particular chipset.  I haven't done a thorough juggling of cards
and machines.

Note that in the non-working case, I have the disk connected
directly to the card, while in the working case, it goes through
an external hub.  The latter is due to wanting a USB1-only mouse
to work.  (As is the former, where the hub is attached as USB1
and the mouse functions.)


Also, the Get Max Lun with the latest code returns much faster
than the default code in -current; as a workaround a while back
I had added a quirk to bypass this step for my particular drive,
which, as the boot doesn't hang for innumerable seconds (my fingers
don't go above ten or so), no longer seems to be a show-stopper-
avoider.


thanks
barry bouwsma



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408142159.i7ELxdH00871>