Hi, guys:
My collegues from HP asked me to incorporate the following patch, which
adds a quirk bit to the unusual_devs.h and sets NO_FSBR.
diff -urp -X dontdiff linux-2.6.14/drivers/usb/storage/transport.c
linux-2.6.14-ilo/drivers/usb/storage/transport.c
--- linux-2.6.14/drivers/usb/storage/transport.c 2005-10-28
19:12:04.000000000 -0700
+++ linux-2.6.14-ilo/drivers/usb/storage/transport.c 2005-11-10
01:32:12.000000000 -0800
@@ -159,6 +159,8 @@ static int usb_stor_msg_common(struct us
* easier than always having the caller tell us whether the
* transfer buffer has already been mapped. */
us->current_urb->transfer_flags = URB_NO_SETUP_DMA_MAP;
+ if (us->flags & US_FL_NO_FSBR)
+ us->current_urb->transfer_flags |= URB_NO_FSBR;
if (us->current_urb->transfer_buffer == us->iobuf)
us->current_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
us->current_urb->transfer_dma = us->iobuf_dma;
diff -urp -X dontdiff linux-2.6.14/drivers/usb/storage/unusual_devs.h
linux-2.6.14-ilo/drivers/usb/storage/unusual_devs.h
--- linux-2.6.14/drivers/usb/storage/unusual_devs.h 2005-10-28
19:12:04.000000000 -0700
+++ linux-2.6.14-ilo/drivers/usb/storage/unusual_devs.h 2005-11-10
10:52:00.000000000 -0800
@@ -166,6 +166,41 @@ UNUSUAL_DEV( 0x0482, 0x0105, 0x0100, 0x
US_SC_SCSI, US_PR_BULK, NULL,
US_FL_FIX_INQUIRY),
+/*
+ * Pete Zaitcev <[EMAIL PROTECTED]>
+ * bz#168506: HP iLO is slow replying, which causes "FSBR timeout".
+ */
+UNUSUAL_DEV( 0x049f, 0x0041, 0x0000, 0xFFFF,
+ "HP",
+ "Virtual Floppy",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_NO_FSBR ),
+UNUSUAL_DEV( 0x049f, 0x0042, 0x0000, 0xFFFF,
+ "HP",
+ "Virtual CD-ROM",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_NO_FSBR ),
+UNUSUAL_DEV( 0x049f, 0x0043, 0x0000, 0xFFFF,
+ "HP",
+ "Virtual Floppy/CD-ROM",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_NO_FSBR ),
+UNUSUAL_DEV( 0x049f, 0x0049, 0x0000, 0xFFFF,
+ "HP",
+ "Virtual Floppy",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_NO_FSBR ),
+UNUSUAL_DEV( 0x049f, 0x004a, 0x0000, 0xFFFF,
+ "HP",
+ "Virtual CD-ROM",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_NO_FSBR ),
+UNUSUAL_DEV( 0x049f, 0x004b, 0x0000, 0xFFFF,
+ "HP",
+ "Virtual Floppy/CD-ROM",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_NO_FSBR ),
+
/* Reported by Paul Stewart <[EMAIL PROTECTED]>
* This entry is needed because the device reports Sub=ff */
UNUSUAL_DEV( 0x04a4, 0x0004, 0x0001, 0x0001,
@@ -1093,3 +1128,4 @@ UNUSUAL_DEV( 0x55aa, 0xa103, 0x0000, 0x
US_SC_SCSI, US_PR_SDDR55, NULL,
US_FL_SINGLE_LUN),
#endif
+
diff -urp -X dontdiff linux-2.6.14/drivers/usb/storage/usb.h
linux-2.6.14-ilo/drivers/usb/storage/usb.h
--- linux-2.6.14/drivers/usb/storage/usb.h 2005-10-28 19:12:04.000000000
-0700
+++ linux-2.6.14-ilo/drivers/usb/storage/usb.h 2005-11-10 10:48:55.000000000
-0800
@@ -91,6 +91,8 @@ struct us_unusual_dev {
/* Need delay after Command phase */ \
US_FLAG(NO_WP_DETECT, 0x00000200) \
/* Don't check for write-protect */ \
+ US_FLAG(NO_FSBR, 0x00000400) \
+ /* Set URB_NO_FSBR */ \
#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
Here's the explanation (from Chris):
-------------------------------
I think under normal conditions, uhci_inc_fsbr() gets called, which
causes the terminating QH to be linked back to the control QH. This
linking will cause the host controller to re-run all pending full-speed
control and bulk transactions (e.g. it puts a cycle in the HC work-to-do
list).
If a "fsbr timeout" occurs (e.g. it takes longer than 50ms to complete a
TD), then it appears to me that the driver deems FSBR to be a waste of
time for that transfer and it does not link the terminating QH back to
the control QH. When the host controller lists are in this state (no
cycle in the list), I think the HC will idle-out the remaining frame
time when it hits the terminate bit.
It appears that the stall callback is the thing that turns off FSBR if
there has been an fsbr timeout. If an URB requests NO_FSBR, then the
stall_callback can't turn off FSBR, so the host controller queues remain
linked in a cycle, and the controller continuously retries transfers
regarless of how long they're taking. It also appears (from
uhci_inc_fsbr) that FSBR isn't turned on for URBs that request NO_FSBR,
but if some other URB turns on FSBR, urbs that didn't request it seem to
benefit from it. I'm not sure if this is the behavior the developer had
in mind (not enough comments to read programmer intent), but it looks
like that's how it works.
In any case, by requesting NO_FSBR in the urbs from the storage driver,
it appears that we prevent stall_callback from breaking the cycle in the
work-to-do list, thus keeping the controller busy with our
slow-to-respond transfers from iLO. If the uhci driver does break the
cycle in the work-to-do list, then our slow-to-respond transfers suffer
their normal slowness plus the additional end-of-frame idle time (e.g.
the UHCI controller hits the terminate bit and idles out the rest of the
frame).
-------------------------------
The patch appears safe from regressions, but I was unable to find
a box to test it, so I'm taking HP word that it actually cures
the symptoms. I would like to have it accepted.
But also, I am curious if we have some performance anomalies in
uhci-hcd. They claim that "2.4 worked". What actually worked was
probably usb-uhci, because that was default in RHL & RHEL.
-- Pete
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
