Pete,
Which kernel is running?
A while back, Alan Stern and I worked out a patch for an issue that
sounds just like this one. The UHCI controller in iLO cannot meet the
timing requirements of the hub code in kernels >= 2.6.12 (I think). The
patch added some extra delay if it detected that it was our usb
controller.
The last time I checked, this patch (named as657 by Alan) hadn't yet
been applied to the vanilla sources.
--Chris
Index: usb-2.6/drivers/usb/host/uhci-hub.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/uhci-hub.c
+++ usb-2.6/drivers/usb/host/uhci-hub.c
@@ -99,6 +99,21 @@ static void uhci_finish_suspend(struct u
}
}
+/* Wait for the UHCI controller in HP's iLO2 server management chip.
+ * It can take up to 250 us to finish a reset and set the CSC bit. */
+static void wait_for_HP(unsigned long port_addr)
+{
+ int i;
+
+ for (i = 10; i < 250; i += 10) {
+ if (inw(port_addr) & USBPORTSC_CSC)
+ return;
+ udelay(10);
+ }
+ /* Log a warning? */
+}
+
static void uhci_check_ports(struct uhci_hcd *uhci)
{
unsigned int port;
@@ -113,6 +128,12 @@ static void uhci_check_ports(struct uhci
CLR_RH_PORTSTAT(USBPORTSC_PR);
udelay(10);
+ /* HP's server management chip requires
+ * a longer delay. */
+ if (to_pci_dev(uhci_dev(uhci))->vendor
==
+ PCI_VENDOR_ID_HP)
+ wait_for_HP(port_addr);
+
/* If the port was enabled before,
turning
* reset on caused a port enable change.
* Turning reset off causes a port
connect
-----Original Message-----
From: Pete Zaitcev [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 11, 2006 8:48 PM
To: Dario Lesca
Cc: [EMAIL PROTECTED]; [email protected]; Frantz,
Chris
Subject: Re: fc5: udev: usb: hp virtual keyboard
On Wed, 21 Jun 2006 15:01:45 +0200, Dario Lesca <[EMAIL PROTECTED]>
wrote:
> > > The problem is caused from the continuous loading of the "HP
> > > Virtual Keyboard" USB subsystem.
> > I'll tell you what, why don't you do this:
> > mount -t debugfs none /sys/kernel/debug
> > cat /sys/kernel/debug/usbmon/5t > /tmp/00.5t.mon &
> Done, see the follow log.
I decoded the log and it seems to be an enumeration issue. It looks like
this.
First, khubd sets up at a device normally (I start at an arbitrary point
in the cycle; in this case we're setting port 2 and address 19).
> f6cef0c0 3806580334 C Ii:001:01 0 1 = 06
> f6cef0c0 3806580338 S Ii:001:01 -115 2 <
> f6cef6c0 3806636328 S Ci:001:00 s a3 00 0000 0002 0004 4 < f6cef6c0
> 3806636380 C Ci:001:00 0 4 = 03010000 f6cef6c0 3806692330 S Co:001:00
> s 23 01 0014 0002 0000 0 f6cef6c0 3806692334 C Co:001:00 0 0
> f6cef6c0 3806692338 S Co:000:00 s 00 05 0013 0000 0000 0
type = 0x00 = USB_TYPE_STANDARD
request = 0x05 = USB_REQ_SET_ADDRESS
value = 0x13 = 19
> f6cef6c0 3806693900 C Co:000:00 0 0
> f6cef6c0 3806708331 S Ci:019:00 s 80 06 0100 0000 0012 18 < f6cef6c0
> 3806711184 C Ci:019:00 0 18 = 12011001 09000040 f0032713 01000102 0001
So far so good, we get the strings and HID gets its reports, sets idle,
etc. It also submits interrupt URB(s).
> f6cef0c0 3806832359 C Ii:001:01 0 1 = 06
> f6cef0c0 3806832362 S Ii:001:01 -115 2 <
> f6cef6c0 3806844352 S Ii:019:01 -115 8 <
> f6cefe40 3806844374 S Ci:019:00 s 80 06 0310 0409 00ff 255 < f6cefe40
> 3806847307 C Ci:019:00 0 24 = 18035600 69007200 74007500 61006c00
> 20004800 75006200
At this point, port 2 is settled completely, so khubd turns its
attention to port 1, and does exactly the same thing.
> f6cefe40 3807204395 C Co:001:00 0 0
> f6cefe40 3807204400 S Co:000:00 s 00 05 0014 0000 0000 0
type = 0x00 = USB_TYPE_STANDARD
request = 0x05 = USB_REQ_SET_ADDRESS
value = 0x14 = 20
....
> f502c4c0 3807263223 S Ii:020:02 -115 3 <
> f502cf40 3807263295 S Ci:020:00 s 80 06 0320 0409 00ff 255 < f502cf40
> 3807266359 C Ci:020:00 0 28 = 1c035600 69007200 74007500 61006c00
> 20004d00 6f007500 73006500
All is done, we return to port #2:
> f502cf40 3807266405 S Ci:001:00 s a3 00 0000 0002 0004 4 <
type = 0xa3 = USB_DIR_IN|USB_RT_PORT
request = USB_REQ_GET_STATUS
value = 0
index = 2
But the iLO (well, root hub of UHCI) returns a change of status!
> f502cf40 3807266412 C Ci:001:00 0 4 = 03010100
wPortStatus = 0103
wPortChange = 0001 { USB_PORT_STAT_C_CONNECTION }
Since there was a change, we clear the change:
> f502cf40 3807266417 S Co:001:00 s 23 01 0010 0002 0000 0
type = 0x23 = USB_TYPE_CLASS|USB_RECIP_OTHER = USB_RT_PORT request =
0x01 = USB_CLEAR_FEATURE value = 0x10 = 16 = USB_PORT_FEAT_C_CONNECTION
index = 2 = port#2
> f502cf40 3807266422 C Co:001:00 0 0
The device #19 on the port #2 collapses immediately:
> f6cef6c0 3807267424 C Ii:019:01 -108 0
Then we set it again, and the cycle continues indefinitely.
The responsible code is very simple and was with us for a long time:
static void hub_events(void)
{
u16 portstatus;
u16 portchange;
hub_port_status(hub, i, &portstatus, &portchange);
if (portchange & USB_PORT_STAT_C_CONNECTION) {
clear_port_feature(hdev, i, USB_PORT_FEAT_C_CONNECTION);
connect_change = 1;
}
}
We cannot ignore the connection change (Although... Alan, any
opinions?). So, there's not much we can do about it. I think it's
something which HP people need to look into.
I have no idea what this phantom change is. AFAIK, the root hub
circuitry is not a part of iLO. So, the only chance why this would
happen is for iLO chip actually to blip the D+/D- lines in such a way
that UHCI's hub detects a connection change. Right, Chris?
Dario, did you try to run Windows on that box? And yes, I mean that very
box, not some other system. It's very possible that something is not
good with your power supply or the motherboard.
-- Pete
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
