usb: use IRQ watching
in [Kernel]
|
Prev: [PATCH 19/30] workqueue: make single thread workqueue shared worker pool friendly
Next: [PATCH 13/30] workqueue: reimplement work flushing using linked works
From: Greg KH on 14 Jun 2010 17:50 On Sun, Jun 13, 2010 at 05:31:38PM +0200, Tejun Heo wrote: > Ask IRQ subsystem to watch HCD IRQ line after initialization. This at > least keeps USB ports which are occupied on initialization working and > eases bug reporting and debugging. > > Signed-off-by: Tejun Heo <tj(a)kernel.org> > --- > drivers/usb/core/hcd.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > index 12742f1..383875f 100644 > --- a/drivers/usb/core/hcd.c > +++ b/drivers/usb/core/hcd.c > @@ -2270,6 +2270,7 @@ int usb_add_hcd(struct usb_hcd *hcd, > "request interrupt %d failed\n", irqnum); > goto err_request_irq; > } > + watch_irq(irqnum, hcd); So if there's a routing problem, it turns into a polled interrupt? Do we really want that? I wonder how long people will run without realizing that there are problems with their system if their devices still work. Other than that minor comment, it all looks good to me. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 14 Jun 2010 18:00 Hello, On 06/14/2010 11:41 PM, Greg KH wrote: > So if there's a routing problem, it turns into a polled interrupt? Do > we really want that? Oh yeah, I really want that for libata. Routing is only part of the problem and flaky IRQ is something we have to learn to cope with. > I wonder how long people will run without realizing that there are > problems with their system if their devices still work. I think things would be better this way. If the drives (both cd and hard) / input devices are not accessible, most people would simply give up rather than reporting, and many cases are transient problems which happen only once in the blue moon. It would be great if some kind of automatic reporting can be used (similar to kerneloops?). Hmm... maybe make the warnings scarier? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 14 Jun 2010 18:20 On Mon, Jun 14, 2010 at 11:52:10PM +0200, Tejun Heo wrote: > Hello, > > On 06/14/2010 11:41 PM, Greg KH wrote: > > So if there's a routing problem, it turns into a polled interrupt? Do > > we really want that? > > Oh yeah, I really want that for libata. Routing is only part of the > problem and flaky IRQ is something we have to learn to cope with. > > > I wonder how long people will run without realizing that there are > > problems with their system if their devices still work. > > I think things would be better this way. If the drives (both cd and > hard) / input devices are not accessible, most people would simply > give up rather than reporting, and many cases are transient problems > which happen only once in the blue moon. > > It would be great if some kind of automatic reporting can be used > (similar to kerneloops?). Hmm... maybe make the warnings scarier? If you throw a WARN(), then kerneloops will pick it up, so you should be fine there. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 14 Jun 2010 18:30 cc'ing Kay, hi. On 06/14/2010 11:52 PM, Tejun Heo wrote: > Hello, > > On 06/14/2010 11:41 PM, Greg KH wrote: >> So if there's a routing problem, it turns into a polled interrupt? Do >> we really want that? > > Oh yeah, I really want that for libata. Routing is only part of the > problem and flaky IRQ is something we have to learn to cope with. > >> I wonder how long people will run without realizing that there are >> problems with their system if their devices still work. > > I think things would be better this way. If the drives (both cd and > hard) / input devices are not accessible, most people would simply > give up rather than reporting, and many cases are transient problems > which happen only once in the blue moon. > > It would be great if some kind of automatic reporting can be used > (similar to kerneloops?). Hmm... maybe make the warnings scarier? Hmm... maybe what we can do is generating an uevent when an IRQ is confirmed to be bad and then let udev notify the user. That way we'll probably have better chance of getting bug reports and users have whiny but working system. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 15 Jun 2010 06:40
On Tue, Jun 15, 2010 at 00:19, Tejun Heo <tj(a)kernel.org> wrote: > On 06/14/2010 11:52 PM, Tejun Heo wrote: >> On 06/14/2010 11:41 PM, Greg KH wrote: >>> So if there's a routing problem, it turns into a polled interrupt? Do >>> we really want that? >> >> Oh yeah, I really want that for libata. Routing is only part of the >> problem and flaky IRQ is something we have to learn to cope with. >> >>> I wonder how long people will run without realizing that there are >>> problems with their system if their devices still work. >> >> I think things would be better this way. If the drives (both cd and >> hard) / input devices are not accessible, most people would simply >> give up rather than reporting, and many cases are transient problems >> which happen only once in the blue moon. >> >> It would be great if some kind of automatic reporting can be used >> (similar to kerneloops?). Hmm... maybe make the warnings scarier? > > Hmm... maybe what we can do is generating an uevent when an IRQ is > confirmed to be bad and then let udev notify the user. That way we'll > probably have better chance of getting bug reports and users have > whiny but working system. Not really, uevents are not picked up by anything that could report an error to userspace, they are just seen by udev. Also uevents are usually not the proper passing method. They are not meant to ever transport higher frequency events, or structured data. They cause to run the entire udev rule matching machine, and update symlinks and permissions with every event. We will need some better error reporting facility. On Linux you don't even get notified when the kernel mounts your filesystem read-only because of an error. It will only end up in 'dmesg' as a pretty much undefined bunch of words. :) We will need some generic error reporting facility, with structured data exported, and where userspace stuff can subscribe to. Uevents/udev can not really properly provide such infrastructure. Maybe that can be extended somehow, but using kobject_uevent() and trigger the usual udev rule engine is not what we are looking for, for sane error reporting. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |