On 11 Feb 2004, Paul Fulghum wrote: > > Does an irq arrive when you plug in a device? > > On this machine the physical ports are not implemented > so there is nothing to plug devices into.
So both ports have their overcurrent inputs wired and you can't use any USB devices at all? Hmm... I thought I remembered a situation where one port was usable and the other was not. Guess I was thinking of someone else's computer, probably another HP. So your test is a rather theoretical one. Given that there aren't any USB ports available, you wouldn't normally load the uhci-hcd module in the first place, right? > > Is the RESUME DETECT flag in the USBSTS status register set correctly? > > It seems to be set once after loading the host module. > If I remember correctly the chip bug meant that the RD > bit was unreliable when OC is present (which is the > case for both ports of this machine). What happens is that OC present causes the controller to report RD. > Here is the syslog output when loading the module: > > Feb 10 13:19:00 deimos kernel: drivers/usb/host/uhci-hcd.c: USB Universal Host > Controller Interface driver v2.1 > Feb 10 13:19:00 deimos kernel: uhci_hcd 0000:00:04.2: UHCI Host Controller > Feb 10 13:19:00 deimos kernel: uhci_hcd 0000:00:04.2: irq 19, io base 0000fce0 > Feb 10 13:19:00 deimos kernel: uhci_hcd 0000:00:04.2: new USB bus registered, > assigned bus number 1 > Feb 10 13:19:00 deimos kernel: hub 1-0:1.0: USB hub found > Feb 10 13:19:00 deimos kernel: hub 1-0:1.0: 2 ports detected > Feb 10 13:19:02 deimos kernel: fce0: irq status 0x24 > Feb 10 13:19:02 deimos kernel: fce0: irq status 0x20 > Feb 10 13:19:02 deimos last message repeated 5 times > Feb 10 13:19:02 deimos kernel: fce0: port 0 resume status: 0xc80 > Feb 10 13:19:02 deimos kernel: fce0: port 1 resume status: 0xc80 > Feb 10 13:19:02 deimos kernel: fce0: irq status 0x20 > Feb 10 13:19:13 deimos last message repeated 18 times > > After the initial irq status of 0x24 (HCH and RD) the irq status > 0x20 (HCH only) repeats forever. Why do you think you get all those "irq status" messages? The controller should have sent only one interrupt request. Is there another device on the system sharing the same IRQ line? Also, why isn't there a log message showing the controller being suspended? The patch should have caused that to happen after 1 second. In fact it _must_ have happened, otherwise there wouldn't be any "resume status" messages. > The resume status shows OC on both ports (expected), but never > a connection status change (CCS) or current connect status (CCS). > > It's been a while, but wasn't the previous verdict that the buggy > controller did weird stuff when suspended with OC, with the solution > being not to put such a controller into suspend mode? Yes. The weird stuff was to signal Resume Detect because of the OC condition. That would cause the driver to wake up the controller, then put it back to sleep because nothing was actually connected, and so on... At the time we decided not to suspend the controller if any ports are OC. Now I'm thinking it would be better to go ahead and suspend, and then avoid resuming when no ports are connected. The potential problem is that if only one port is hardwired OC then we risk missing a RD from a device being plugged in to the other port. That's what I really wanted to test, but your machine can't do it. Alan Stern ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
