On Mon, 6 Jun 2005, Alan Stern wrote:
> On Mon, 6 Jun 2005, Jamie Guinan wrote:
>
> > Hi,
> >
> > I'm running linux 2.6.11 (vanilla) on a custom board, with a
> > Sharp LH7A404.
> >
> > .config:
> > CONFIG_ARCH_LH7A40X=y
> > CONFIG_ARCH_LH7A404=y
> >
> > I've been having problems with a USB storage chip connected to the
> > USB host interface (ST72F65, soldered on to the board).
> >
> > To detect media presence, I have a program that polls /dev/sd[abcde]
> > once every 2 seconds or so, and reads a sector's worth of data, roughly
> > equivalent to,
> >
> > $ dd if=/dev/sdc of=/dev/null bs=512 count=1 \
> > && echo 'Media present' || echo 'No media'
> >
> > Way down, this calls, from drivers/usb/host/ohci.h:
> >
> > static u32 roothub_portstatus (struct ohci_hcd *hc, int i)
> > { return read_roothub (hc, portstatus [i], 0xffe0fce0); }
> >
> > and typically this returns 0x103,
> >
> > 00000100=RH_PS_PPS (port power status)
> > 00000002=RH_PS_PES (port enable status)
> > 00000001=RH_PS_CCS (current connect status)
>
> That's odd. While I'm not familiar with the details of OHCI or the
> LH7A404 driver, normally a host controller driver does not check the port
> status when communicating with a device. Port status is checked
> asynchronously by the hub driver. Of course, there could be something
> going on here that I'm unaware of...
Well, it may not be as a direct result of the scsi read(). From my logs
it looks like the call stack leading up to this point was,
rh_report_status()
ohci_hub_status_data()
roothub_portstatus()
The only reference to rh_report_status I can find is,
static int rh_status_urb (struct usb_hcd *hcd, struct urb *urb)
...
hcd->rh_timer.function = rh_report_status;
I don't want to speculate on the call stack before that, as I didn't
keep track of thread context while logging.
> > but after a minute or two of polling (once a second or so), I get 0x30101,
> >
> > 00020000=RH_PS_PESC (port enable status change)
> > 00010000=RH_PS_CSC (connect status change)
> > 00000100=RH_PS_PPS (port power status)
> > 00000001=RH_PS_CCS (current connect status)
> >
> > which bubbles up through the calling code in the usb layer and triggers
> > a disconnect cycle due to PESC and CSC,
> >
> > ohci_hub_status_data (struct usb_hcd *hcd, char *buf)
> > {
> > ...
> >
> > for (i = 0; i < ports; i++) {
> > u32 status = roothub_portstatus (ohci, i);
> > if (status & (RH_PS_CSC | RH_PS_PESC | RH_PS_PSSC
> > | RH_PS_OCIC | RH_PS_PRSC)) {
> > changed = 1;
> >
> >
> > Now my questions:
> >
> > 1) Is there a better way to poll for media presence than reading
> > /dev/sd[a..e] ?
>
> You can use the sg interface to send a TEST UNIT READY command. Since
> this doesn't actually read any data it will be more efficient.
Great - just what I was looking for.
> > 2) Does the 0x30101 look like a sane response? I'm seeing 0x30100
> > when I remove an IOGEAR media reader connected through via a
> > standard USB TypeA port.
>
> It means that for some reason the host controller thought the device
> disconnected momentarily and then reconnected. In the IOGEAR case you
> didn't reconnect; hence the different code.
Ok, I'll test the IOGEAR with a quick {dis,re}-connect.
> > Any other insights/tips are welcome.
> >
> > This might come down to a board-layout or electrical problem, I know.
>
> Quite likely.
>
> > Thanks,
> > -Jamie
> >
> > p.s. I got the 0x30101/etc numbers by saving the result of
> > roothub_portstatus() in a huge buffer in the kernel, then downloading
> > the buffer through a /proc file. Its an embarassingly ugly hack, but
> > it was the only way I could avoid messing with USB timing.
>
> Nothing wrong with doing it that way, except that you might prefer to use
> the debugfs filesystem instead of procfs. That's what it's intended for.
Ok, I'll try that.
Thanks for your very helpful reply.
-Jamie
> Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
