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
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
