Messages in this thread |  | | Subject | Re: Test Patch: 2.5.69 Interrupt Latency | From | Paul Fulghum <> | Date | 15 May 2003 08:45:38 -0500 |
| |
On Wed, 2003-05-14 at 15:52, Alan Stern wrote: > Below is a patch that addresses both of the issues raised in this thread. > The delay time is moved out of the interrupt handler, and the > wakeup/suspend transitions are de-bounced. To do this, I needed to add a > mildly elaborate state mechanism. State transitions are polled during the > stall-timer callback. > > There is no protection against simultaneous access from multiple threads, > such as a PCI suspend occurring at the same time as a normal suspend or > resume. The original driver didn't have any either; it's probably not > worth worrying too much about. The patch works okay on my system. Try it > and see how it works on yours. > > Johannes, please look over this code and verify that I haven't screwed > anything up. > > Alan Stern
I tested the patch, and it solves the IRQ latency problems by moving the delay outside of the ISR. The debouncing period reduces the rate of thrashing back and forth between wake and suspend, but the cycle does continue forever:
May 15 08:27:27 diemos kernel: suspend_hc():UHCI_RUNNING_GRACE May 15 08:27:27 diemos kernel: suspend_hc():UHCI_RUNNING May 15 08:27:28 diemos kernel: suspend_hc():UHCI_SUSPENDING_GRACE May 15 08:27:28 diemos kernel: wakeup_hc():UHCI_SUSPENDED May 15 08:27:28 diemos kernel: wakeup_hc():UHCI_RESUMING_1 May 15 08:27:28 diemos kernel: suspend_hc():UHCI_RESUMING_2 May 15 08:27:29 diemos kernel: suspend_hc():UHCI_RUNNING_GRACE May 15 08:27:29 diemos kernel: suspend_hc():UHCI_RUNNING May 15 08:27:30 diemos kernel: suspend_hc():UHCI_SUSPENDING_GRACE May 15 08:27:30 diemos kernel: wakeup_hc():UHCI_SUSPENDED May 15 08:27:30 diemos kernel: wakeup_hc():UHCI_RESUMING_1 May 15 08:27:30 diemos kernel: suspend_hc():UHCI_RESUMING_2 May 15 08:27:31 diemos kernel: suspend_hc():UHCI_RUNNING_GRACE
This patch removes my complaint, but I do wonder why this unused controller continually generates the USBSTS_RD indications. I would hope HP used pull-ups/downs on unused input signals of the PIIX3 chipset, but maybe not.
I also can't vouch for the correct operation of this patch for fully functional USB implementations.
If you have other tests you want me to do to try and figure out a sane way of dealing with such unused controllers, just ask.
Thanks, Paul
-- Paul Fulghum, paulkf@microgate.com Microgate Corporation, http://www.microgate.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |