Re: 3.4.4: disabling irq
On Thu, 29 Aug 2013, Udo van den Heuvel wrote:
> On 2013-08-28 21:37, Alan Stern wrote:
> >>> No, if you unload the ohci-hcd driver then the webcam won't be used.
> >>> Are you certain that merely stopping the daemon program will prevent
> >>> the problem?
> >>
> >> Quite certain but retesting can confirm that.
> >
> > Maybe without activity, the OHCI controller goes into suspend. You can
> > prevent it by doing:
> >
> > echo on >/sys/bus/pci/devices/:00:13.1/usb?/power/control
>
> /sys/bus/pci/devices/:00:13.0 has a file irq containing 18.
> subdirectory usb8 under there has no power/control subdir/file.
> Is this a configuration issue or kernel version difference?
It could be a config issue. The file will be present only if
CONFIG_PM_RUNTIME is enabled.
> > By the way, since you switched to the new computer, are there any
> > devices attached to this USB bus other than the webcam?
>
> The wired mouse (logitech M-BD58) is connected via usb.
Is it connected to the :00:13.1 controller or to the :00:13.0
controller?
> > Also, at one point you had a second webcam attached to a different OHCI
> > controller, as well as a Bluetooth device and a USB-serial device.
> > Are they still present?
>
> Nope. Presently not connected.
>
> I'll have some hubs this weekend to play with.
In the meantime, here is a diagnostic patch you can try out.
Alan Stern
Index: usb-3.11/drivers/usb/host/ohci-hcd.c
===
--- usb-3.11.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.11/drivers/usb/host/ohci-hcd.c
@@ -592,7 +592,10 @@ static int ohci_run (struct ohci_hcd *oh
u32 mask, val;
int first = ohci->fminterval == 0;
struct usb_hcd *hcd = ohci_to_hcd(ohci);
+ static int alan_id;
+ ohci->alan_time = jiffies;
+ ohci->alan_limit = (++alan_id) * 1000;
ohci->rh_state = OHCI_RH_HALTED;
/* boot firmware should have set this up (5.1.1.3.1) */
@@ -810,6 +813,20 @@ static irqreturn_t ohci_irq (struct usb_
return IRQ_HANDLED;
}
+ if (ohci->alan_count < 0)
+ return IRQ_NOTMINE;
+ else if (time_after(jiffies, ohci->alan_time)) {
+ ohci->alan_time = jiffies + HZ/10;
+ ohci->alan_count = 0;
+ } else if (++ohci->alan_count > ohci->alan_limit) {
+ ohci_info(ohci, "Too many interrupts %d, disabling\n",
+ ohci->alan_limit);
+ ohci->alan_count = -1;
+ ohci_writel(ohci, ~0, ®s->intrdisable);
+ ohci_writel(ohci, ~0, ®s->intrstatus);
+ return IRQ_NOTMINE;
+ }
+
/* We only care about interrupts that are enabled */
ints &= ohci_readl(ohci, ®s->intrenable);
Index: usb-3.11/drivers/usb/host/ohci-hub.c
===
--- usb-3.11.orig/drivers/usb/host/ohci-hub.c
+++ usb-3.11/drivers/usb/host/ohci-hub.c
@@ -218,7 +218,8 @@ __acquires(ohci->lock)
skip_resume:
/* interrupts might have been disabled */
- ohci_writel (ohci, OHCI_INTR_INIT, &ohci->regs->intrenable);
+ if (ohci->alan_count >= 0)
+ ohci_writel (ohci, OHCI_INTR_INIT, &ohci->regs->intrenable);
if (ohci->ed_rm_list)
ohci_writel (ohci, OHCI_INTR_SF, &ohci->regs->intrenable);
Index: usb-3.11/drivers/usb/host/ohci.h
===
--- usb-3.11.orig/drivers/usb/host/ohci.h
+++ usb-3.11/drivers/usb/host/ohci.h
@@ -415,6 +415,10 @@ struct ohci_hcd {
struct ed *ed_to_check;
unsignedzf_delay;
+ unsigned long alan_time;
+ int alan_count;
+ int alan_limit;
+
#ifdef DEBUG
struct dentry *debug_dir;
struct dentry *debug_async;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2013-08-28 21:37, Alan Stern wrote: >>> No, if you unload the ohci-hcd driver then the webcam won't be used. >>> Are you certain that merely stopping the daemon program will prevent >>> the problem? >> >> Quite certain but retesting can confirm that. > > Maybe without activity, the OHCI controller goes into suspend. You can > prevent it by doing: > > echo on >/sys/bus/pci/devices/:00:13.1/usb?/power/control /sys/bus/pci/devices/:00:13.0 has a file irq containing 18. subdirectory usb8 under there has no power/control subdir/file. Is this a configuration issue or kernel version difference? > By the way, since you switched to the new computer, are there any > devices attached to this USB bus other than the webcam? The wired mouse (logitech M-BD58) is connected via usb. > Also, at one point you had a second webcam attached to a different OHCI > controller, as well as a Bluetooth device and a USB-serial device. > Are they still present? Nope. Presently not connected. I'll have some hubs this weekend to play with. Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Wed, 28 Aug 2013, Udo van den Heuvel wrote: > On 2013-08-27 19:43, Alan Stern wrote: > >>> rmmod ohci-pci > >>> modprobe dummy-irq irq=18 > >>> > >>> and see if the IRQ line gets disabled after that. > >> > >> Can I actually use that irq/ports that way? (as with no usage the > >> problem does not occur) > > > > No, if you unload the ohci-hcd driver then the webcam won't be used. > > Are you certain that merely stopping the daemon program will prevent > > the problem? > > Quite certain but retesting can confirm that. Maybe without activity, the OHCI controller goes into suspend. You can prevent it by doing: echo on >/sys/bus/pci/devices/:00:13.1/usb?/power/control If you do this and stop using the webcam, but leave ohci-hcd bound to the controller, does the problem occur? > >> No ohci_pci, is that a problem? > > > > Sorry, for 3.10 it should be ohci_hcd. In 3.11 it changed to ohci_pci. > > 3.10.9 is the latest here. > > > Have you tried getting a USB-2 hub and plugging the webcam into it? > > That will make a good test: You'll be able to use the webcam without > > it affecting the ohci-hcd driver. > > Not yet but I'll have hubs to test with soon. > > > As a second test, you can try plugging everything _except_ the webcam > > into the hub. > > To see if the webcam itself is a factor. I see. By the way, since you switched to the new computer, are there any devices attached to this USB bus other than the webcam? Also, at one point you had a second webcam attached to a different OHCI controller, as well as a Bluetooth device and a USB-serial device. Are they still present? > This afternoon I found a 3.8.10 kernel with the disabled irq 18 and some > ^@^@^@ characters on teh console. > After I did: > > service motion stop > rmmod pwc > echo :00:13.0 >/sys/bus/pci/drivers/ohci_hcd/unbind > echo :00:13.0 >/sys/bus/pci/drivers/ohci_hcd/bind > modprobe pwc > service motion start > > the ^@^@^@ appeared to stop. > I'll try to watch /proc/interrupts to see if the ^@^@ correlate with > i8042 interrupts. Maybe they are related somehow, but I have no idea how. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2013-08-27 19:43, Alan Stern wrote: >>> rmmod ohci-pci >>> modprobe dummy-irq irq=18 >>> >>> and see if the IRQ line gets disabled after that. >> >> Can I actually use that irq/ports that way? (as with no usage the >> problem does not occur) > > No, if you unload the ohci-hcd driver then the webcam won't be used. > Are you certain that merely stopping the daemon program will prevent > the problem? Quite certain but retesting can confirm that. >> No ohci_pci, is that a problem? > > Sorry, for 3.10 it should be ohci_hcd. In 3.11 it changed to ohci_pci. 3.10.9 is the latest here. > Have you tried getting a USB-2 hub and plugging the webcam into it? > That will make a good test: You'll be able to use the webcam without > it affecting the ohci-hcd driver. Not yet but I'll have hubs to test with soon. > As a second test, you can try plugging everything _except_ the webcam > into the hub. To see if the webcam itself is a factor. I see. >> FWIW: on these boards (same type, BIOS, etc) I also see the issue >> described at http://marc.info/?l=linux-kernel&m=137749729105329&w=2. >> Any correlation? > > Not that I can see. This afternoon I found a 3.8.10 kernel with the disabled irq 18 and some ^@^@^@ characters on teh console. After I did: service motion stop rmmod pwc echo :00:13.0 >/sys/bus/pci/drivers/ohci_hcd/unbind echo :00:13.0 >/sys/bus/pci/drivers/ohci_hcd/bind modprobe pwc service motion start the ^@^@^@ appeared to stop. I'll try to watch /proc/interrupts to see if the ^@^@ correlate with i8042 interrupts. Kind regards, Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Tue, 27 Aug 2013, Udo van den Heuvel wrote: > Hello Alan, > > On 2013-08-23 21:33, Alan Stern wrote: > >> Well, I replaced the motherboard by one of the same type and same BIOS > >> version. > >> And the problem is still here. > >> > >>> kernel:[ 3013.199945] Disabling IRQ #18 > >> > >> So what can we conclude? > >> Kernel bug? > >> Hardware bug? > >> Something else? > > > > Any of the above. On the new hardware, is it still true that > > /proc/interrupts shows IRQ 18 being used by ohci_hcd:usb1, 2, 3, and > > nothing else? > > $ cat /proc/interrupts |grep 18: > 104556 35248 IR-IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb8, > ohci_hcd:usb9 Different bus numbers, but probably the same controllers. All right. > > Suppose you don't use the webcam, or better yet, unplug it (so that it > > can't possibly be used without your knowledge). If you do, does the > > IRQ still get disabled? > > If I simply stop the `motion` daemon I did not see the errors in the past. > Replacing the pwc webcam did not help. > > rmmod ohci-pci > > modprobe dummy-irq irq=18 > > > > and see if the IRQ line gets disabled after that. > > Can I actually use that irq/ports that way? (as with no usage the > problem does not occur) No, if you unload the ohci-hcd driver then the webcam won't be used. Are you certain that merely stopping the daemon program will prevent the problem? > Also: > > $ lsmod|grep pci > ehci_pci 12432 0 > ehci_hcd 56916 1 ehci_pci > > No ohci_pci, is that a problem? Sorry, for 3.10 it should be ohci_hcd. In 3.11 it changed to ohci_pci. Have you tried getting a USB-2 hub and plugging the webcam into it? That will make a good test: You'll be able to use the webcam without it affecting the ohci-hcd driver. As a second test, you can try plugging everything _except_ the webcam into the hub. > FWIW: on these boards (same type, BIOS, etc) I also see the issue > described at http://marc.info/?l=linux-kernel&m=137749729105329&w=2. > Any correlation? Not that I can see. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
Hello Alan, On 2013-08-23 21:33, Alan Stern wrote: >> Well, I replaced the motherboard by one of the same type and same BIOS >> version. >> And the problem is still here. >> >>> kernel:[ 3013.199945] Disabling IRQ #18 >> >> So what can we conclude? >> Kernel bug? >> Hardware bug? >> Something else? > > Any of the above. On the new hardware, is it still true that > /proc/interrupts shows IRQ 18 being used by ohci_hcd:usb1, 2, 3, and > nothing else? $ cat /proc/interrupts |grep 18: 104556 35248 IR-IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb8, ohci_hcd:usb9 > Suppose you don't use the webcam, or better yet, unplug it (so that it > can't possibly be used without your knowledge). If you do, does the > IRQ still get disabled? If I simply stop the `motion` daemon I did not see the errors in the past. Replacing the pwc webcam did not help. > By the way, you aren't still running a 3.4 kernel are you? We move up with the releases so yes we have 3.10 kernels. > Assuming > you are using 3.10 or later, here's something else you can do. Turn on > CONFIG_DUMMY_IRQ in the kernel config. Then do > > rmmod ohci-pci > modprobe dummy-irq irq=18 > > and see if the IRQ line gets disabled after that. Can I actually use that irq/ports that way? (as with no usage the problem does not occur) Also: $ lsmod|grep pci ehci_pci 12432 0 ehci_hcd 56916 1 ehci_pci No ohci_pci, is that a problem? FWIW: on these boards (same type, BIOS, etc) I also see the issue described at http://marc.info/?l=linux-kernel&m=137749729105329&w=2. Any correlation? Kind regards, Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Fri, 23 Aug 2013, Udo van den Heuvel wrote: > On 2013-01-26 19:48, Alan Stern wrote: > >> Please explain. > > > > I can't. I don't know what's going on with your systems. But nobody > > else seems to be experiencing this problem. > > Well, I replaced the motherboard by one of the same type and same BIOS > version. > And the problem is still here. > > > kernel:[ 3013.199945] Disabling IRQ #18 > > So what can we conclude? > Kernel bug? > Hardware bug? > Something else? Any of the above. On the new hardware, is it still true that /proc/interrupts shows IRQ 18 being used by ohci_hcd:usb1, 2, 3, and nothing else? Suppose you don't use the webcam, or better yet, unplug it (so that it can't possibly be used without your knowledge). If you do, does the IRQ still get disabled? By the way, you aren't still running a 3.4 kernel are you? Assuming you are using 3.10 or later, here's something else you can do. Turn on CONFIG_DUMMY_IRQ in the kernel config. Then do rmmod ohci-pci modprobe dummy-irq irq=18 and see if the IRQ line gets disabled after that. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2013-01-26 19:48, Alan Stern wrote: >> Please explain. > > I can't. I don't know what's going on with your systems. But nobody > else seems to be experiencing this problem. Well, I replaced the motherboard by one of the same type and same BIOS version. And the problem is still here. > kernel:[ 3013.199945] Disabling IRQ #18 So what can we conclude? Kernel bug? Hardware bug? Something else? Kind regards, Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Sat, 26 Jan 2013, Udo van den Heuvel wrote: > On 2013-01-26 15:56, Alan Stern wrote: > > That SF bit in the intrstatus register is the one causing the problem, > > I think. It is not set in the intrenable register, so the controller > > shouldn't issue any IRQs. But it does, nonetheless. Turning off SF > > apparently doesn't help -- the controller turns it on again a > > millisecond later anyway. > > > > So it looks like there's nothing we can do about this. It's just bad > > hardware. Sorry. > > So why was this problem introduced on my old hardware after running for > years without this issue? > This new hardware is just 2-3 months old or so should not have grown > extra 'features'. > Please explain. I can't. I don't know what's going on with your systems. But nobody else seems to be experiencing this problem. You can always try installing an earlier version of the kernel to see if that makes the problem go away. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2013-01-26 15:56, Alan Stern wrote: > That SF bit in the intrstatus register is the one causing the problem, > I think. It is not set in the intrenable register, so the controller > shouldn't issue any IRQs. But it does, nonetheless. Turning off SF > apparently doesn't help -- the controller turns it on again a > millisecond later anyway. > > So it looks like there's nothing we can do about this. It's just bad > hardware. Sorry. So why was this problem introduced on my old hardware after running for years without this issue? This new hardware is just 2-3 months old or so should not have grown extra 'features'. Please explain. Kind regards, Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Sat, 26 Jan 2013, Udo van den Heuvel wrote: > On 2013-01-25 19:06, Alan Stern wrote: > > On Fri, 25 Jan 2013, Alan Stern wrote: > > > >> This isn't a software problem. I don't know of any way to fix it or > >> work around it in the driver. The only thing to do is stop using that > >> controller. > > > > Spoke too soon. Try this patch; maybe it will help. (You'll have to > > remove the debugging patch first.) > > Did so. > Reloaded the ohci module, problem did not go away. > In the dmesg below you can see messages of reloading ohci modules, the > issue, then some pwc frame errors and then the restarting of the stuff. > [244322.416040] usb usb2: unregistering interface 2-0:1.0 > [244322.416054] ohci_hcd :00:13.0: shutdown urb 88019f5e2900 > ep1in-intr > [244322.416095] usb usb2: usb_disable_device nuking all URBs > [244322.416170] ohci_hcd :00:13.0: OHCI controller state > [244322.416173] ohci_hcd :00:13.0: OHCI 1.0, NO legacy support > registers, rh state running > [244322.416176] ohci_hcd :00:13.0: control 0x083 HCFS=operational CBSR=3 > [244322.416179] ohci_hcd :00:13.0: cmdstatus 0x0 SOC=0 > [244322.416182] ohci_hcd :00:13.0: intrstatus 0x0004 SF > [244322.416185] ohci_hcd :00:13.0: intrenable 0x805a MIE RHSC UE > RD WDH That SF bit in the intrstatus register is the one causing the problem, I think. It is not set in the intrenable register, so the controller shouldn't issue any IRQs. But it does, nonetheless. Turning off SF apparently doesn't help -- the controller turns it on again a millisecond later anyway. So it looks like there's nothing we can do about this. It's just bad hardware. Sorry. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2013-01-25 19:06, Alan Stern wrote: > On Fri, 25 Jan 2013, Alan Stern wrote: > >> This isn't a software problem. I don't know of any way to fix it or >> work around it in the driver. The only thing to do is stop using that >> controller. > > Spoke too soon. Try this patch; maybe it will help. (You'll have to > remove the debugging patch first.) Did so. Reloaded the ohci module, problem did not go away. In the dmesg below you can see messages of reloading ohci modules, the issue, then some pwc frame errors and then the restarting of the stuff. [236793.480518] ohci_hcd :00:12.0: GetStatus roothub.portstatus [1] = 0x00010301 CSC LSDA PPS CCS [236793.480527] hub 1-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s [236793.608085] hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301 [236793.679770] ohci_hcd :00:12.0: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS [236793.735595] usb 1-2: new low-speed USB device number 2 using ohci_hcd [236793.807504] ohci_hcd :00:12.0: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS [236793.891176] usb 1-2: skipped 1 descriptor after interface [236793.893035] usb 1-2: default language 0x0409 [236793.899048] usb 1-2: udev 2, busnum 1, minor = 1 [236793.899058] usb 1-2: New USB device found, idVendor=046d, idProduct=c00c [236793.899064] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [236793.899069] usb 1-2: Product: USB Mouse [236793.899073] usb 1-2: Manufacturer: Logitech [236793.902798] usb 1-2: usb_probe_device [236793.902806] usb 1-2: configuration #1 chosen from 1 choice [236793.904007] usb 1-2: adding 1-2:1.0 (config #1, interface 0) [236793.906553] usbhid 1-2:1.0: usb_probe_interface [236793.906558] usbhid 1-2:1.0: usb_probe_interface - got id [236793.922957] input: Logitech USB Mouse as /devices/pci:00/:00:12.0/usb1/1-2/1-2:1.0/input/input8 [236793.930894] hid-generic 0003:046D:C00C.0002: input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-:00:12.0-2/input0 [236793.930946] hub 5-0:1.0: state 7 ports 2 chg evt [236793.930953] hub 2-0:1.0: state 7 ports 5 chg evt 0010 [236793.930966] ohci_hcd :00:13.0: GetStatus roothub.portstatus [3] = 0x00010101 CSC PPS CCS [236793.930975] hub 2-0:1.0: port 4, status 0101, change 0001, 12 Mb/s [236794.058797] hub 2-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x101 [236794.130186] ohci_hcd :00:13.0: GetStatus roothub.portstatus [3] = 0x00100103 PRSC PPS PES CCS [236794.186027] usb 2-4: new full-speed USB device number 2 using ohci_hcd [236794.257768] ohci_hcd :00:13.0: GetStatus roothub.portstatus [3] = 0x00100103 PRSC PPS PES CCS [236794.333430] usb 2-4: ep0 maxpacket = 8 [236794.432125] usb 2-4: skipped 4 descriptors after interface [236794.432134] usb 2-4: skipped 2 descriptors after interface [236794.432140] usb 2-4: skipped 1 descriptor after endpoint [236794.432146] usb 2-4: skipped 2 descriptors after interface [236794.432150] usb 2-4: skipped 1 descriptor after endpoint [236794.432155] usb 2-4: skipped 2 descriptors after interface [236794.432160] usb 2-4: skipped 1 descriptor after endpoint [236794.432165] usb 2-4: skipped 2 descriptors after interface [236794.432170] usb 2-4: skipped 1 descriptor after endpoint [236794.435090] usb 2-4: default language 0x0409 [236794.457034] usb 2-4: udev 2, busnum 2, minor = 129 [236794.457045] usb 2-4: New USB device found, idVendor=0471, idProduct=0311 [236794.457050] usb 2-4: New USB device strings: Mfr=0, Product=0, SerialNumber=1 [236794.457056] usb 2-4: SerialNumber: 0169A500 [236794.457314] usb 2-4: usb_probe_device [236794.457321] usb 2-4: configuration #1 chosen from 1 choice [236794.459031] usb 2-4: adding 2-4:1.0 (config #1, interface 0) [236794.459723] Philips webcam 2-4:1.0: usb_probe_interface [236794.459730] Philips webcam 2-4:1.0: usb_probe_interface - got id [236794.459735] pwc: Philips PCVC740K (ToUCam Pro)/PCVC840 (ToUCam II) USB webcam detected. [236795.067186] pwc: Registered as video0. [236795.067353] input: PWC snapshot button as /devices/pci:00/:00:13.0/usb2/2-4/input/input9 [236795.067510] usb 2-4: adding 2-4:1.1 (config #1, interface 1) [236795.067645] snd-usb-audio 2-4:1.1: usb_probe_interface [236795.067656] snd-usb-audio 2-4:1.1: usb_probe_interface - got id [236795.130472] usb 2-4: adding 2-4:1.2 (config #1, interface 2) [236795.130732] hub 4-0:1.0: state 7 ports 5 chg evt 0010 [236795.130747] ehci_hcd :00:13.2: GetStatus port:4 status 003002 0 ACK POWER OWNER sig=se0 CSC [236795.130758] hub 4-0:1.0: port 4, status 0100, change 0001, 12 Mb/s [236795.258571] hub 4-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x100 [236795.258584] hub 1-0:1.0: state 7 ports 5 chg evt 0004 [236795.258601] hub 2-0:1.0: state 7 ports 5 chg evt 0010 [244306.358532] irq 18: nobody cared (try booting with the "irqpoll" option) [244306.358536] Pid: 27585, comm: irq/18-ohci_hcd Not tainted 3.6
Re: 3.4.4: disabling irq
On Fri, 25 Jan 2013, Alan Stern wrote:
> This isn't a software problem. I don't know of any way to fix it or
> work around it in the driver. The only thing to do is stop using that
> controller.
Spoke too soon. Try this patch; maybe it will help. (You'll have to
remove the debugging patch first.)
Alan Stern
Index: usb-3.8/drivers/usb/host/ohci-hcd.c
===
--- usb-3.8.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.8/drivers/usb/host/ohci-hcd.c
@@ -794,6 +794,9 @@ static irqreturn_t ohci_irq (struct usb_
return IRQ_HANDLED;
}
+ /* Clear the pending status bits */
+ ohci_writel(ohci, ints, ®s->intrstatus);
+
/* We only care about interrupts that are enabled */
ints &= ohci_readl(ohci, ®s->intrenable);
@@ -846,7 +849,6 @@ static irqreturn_t ohci_irq (struct usb_
*/
else if (ints & OHCI_INTR_RD) {
ohci_vdbg(ohci, "resume detect\n");
- ohci_writel(ohci, OHCI_INTR_RD, ®s->intrstatus);
set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
if (ohci->autostop) {
spin_lock (&ohci->lock);
@@ -903,9 +905,8 @@ static irqreturn_t ohci_irq (struct usb_
spin_unlock (&ohci->lock);
if (ohci->rh_state == OHCI_RH_RUNNING) {
- ohci_writel (ohci, ints, ®s->intrstatus);
ohci_writel (ohci, OHCI_INTR_MIE, ®s->intrenable);
- // flush those writes
+ // flush the write
(void) ohci_readl (ohci, &ohci->regs->control);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Fri, 25 Jan 2013, Udo van den Heuvel wrote: > On 2013-01-02 17:46, Alan Stern wrote: > > Or else leave those devices unplugged entirely -- use a network login > > instead of the USB keyboard and mouse. > > When the motion service is off, i.e. the USB webcam isnt used, the > issue does not happen. > > On the other hand: > > If it is on, within a few days I see stuff like: > > Jan 25 03:08:26 s kernel: [128427.542235] irq 18: nobody cared (try > booting with the "irqpoll" option) > And when I restart everything: > [133977.918683] ohci_hcd :00:13.0: IRQ: 4 805a > [133985.698868] ohci_hcd :00:13.0: last IRQ repeated 100 times > [134003.770072] ohci_hcd :00:13.0: IRQ: 24 805a > [134006.297099] ohci_hcd :00:13.0: last IRQ repeated 100 times This seems pretty clear. The hardware in that OHCI controller is broken. It is issuing interrupt requests when it shouldn't. This isn't a software problem. I don't know of any way to fix it or work around it in the driver. The only thing to do is stop using that controller. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2013-01-02 17:46, Alan Stern wrote: > Or else leave those devices unplugged entirely -- use a network login > instead of the USB keyboard and mouse. When the motion service is off, i.e. the USB webcam isnt used, the issue does not happen. On the other hand: If it is on, within a few days I see stuff like: Jan 25 03:08:26 s kernel: [128427.542235] irq 18: nobody cared (try booting with the "irqpoll" option) Jan 25 03:08:26 s kernel: [128427.542239] Pid: 1279, comm: irq/18-ohci_hcd Not tainted 3.6.11 #22 Jan 25 03:08:26 s kernel: [128427.542240] Call Trace: Jan 25 03:08:26 s kernel: [128427.542246] [] ? __report_bad_irq+0x36/0xd0 Jan 25 03:08:26 s kernel: [128427.542248] [] ? note_interrupt+0x1c9/0x220 Jan 25 03:08:26 s kernel: [128427.542250] [] ? irq_thread_fn+0x40/0x40 Jan 25 03:08:26 s kernel: [128427.542252] [] ? irq_thread+0x145/0x180 Jan 25 03:08:26 s kernel: [128427.542255] [] ? __wake_up_common+0x4c/0x80 Jan 25 03:08:26 s kernel: [128427.542257] [] ? irq_finalize_oneshot+0x100/0x100 Jan 25 03:08:26 s kernel: [128427.542259] [] ? wake_threads_waitq+0x50/0x50 Jan 25 03:08:26 s kernel: [128427.542261] [] ? kthread+0x85/0x90 Jan 25 03:08:26 s kernel: [128427.542265] [] ? kernel_thread_helper+0x4/0x10 Jan 25 03:08:26 s kernel: [128427.542267] [] ? kthread_freezable_should_stop+0x50/0x50 Jan 25 03:08:26 s kernel: [128427.542275] [] ? gs_change+0xb/0xb Jan 25 03:08:26 s kernel: [128427.542276] handlers: Jan 25 03:08:26 s kernel: [128427.542278] [] irq_default_primary_handler threaded [] usb_hcd_irq Jan 25 03:08:26 s kernel: [128427.542283] [] irq_default_primary_handler threaded [] usb_hcd_irq Jan 25 03:08:26 s kernel: [128427.542286] [] irq_default_primary_handler threaded [] usb_hcd_irq Jan 25 03:08:26 s kernel: [128427.542288] Disabling IRQ #18 [133970.593390] pwc: Iso frame 4 has error -18 [133970.593392] pwc: Iso frame 5 has error -18 [133970.593394] pwc: Iso frame 6 has error -18 [133970.593396] pwc: Iso frame 7 has error -114 [133970.593398] pwc: Iso frame 8 has error -18 [133970.593399] pwc: Iso frame 9 has error -18 And when I restart everything: [133971.011352] usbcore: deregistering interface driver Philips webcam [133971.056287] ohci_hcd :00:13.0: remove, state 1 [133971.056296] ohci_hcd :00:13.0: roothub graceful disconnect [133971.056303] usb usb2: USB disconnect, device number 1 [133971.056307] usb 2-4: USB disconnect, device number 2 [133971.056310] usb 2-4: unregistering device [133971.056314] usb 2-4: unregistering interface 2-4:1.0 [133971.056480] usb 2-4: unregistering interface 2-4:1.1 [133971.056951] usb 2-4: unregistering interface 2-4:1.2 [133971.057053] usb 2-4: usb_disable_device nuking all URBs [133971.058693] usb usb2: unregistering device [133971.058702] usb usb2: unregistering interface 2-0:1.0 [133971.058744] ohci_hcd :00:13.0: shutdown urb 8802342b7e00 ep1in-intr [133971.060699] usb usb2: usb_disable_device nuking all URBs [133971.061051] ohci_hcd :00:13.0: OHCI controller state [133971.061059] ohci_hcd :00:13.0: OHCI 1.0, NO legacy support registers, rh state running [133971.061066] ohci_hcd :00:13.0: control 0x083 HCFS=operational CBSR=3 [133971.061071] ohci_hcd :00:13.0: cmdstatus 0x0 SOC=0 [133971.061077] ohci_hcd :00:13.0: intrstatus 0x0024 FNO SF [133971.061082] ohci_hcd :00:13.0: intrenable 0x805a MIE RHSC UE RD WDH [133971.061088] ohci_hcd :00:13.0: ed_controlhead 4000 [133971.061095] ohci_hcd :00:13.0: hcca frame #86d9 [133971.061101] ohci_hcd :00:13.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5) [133971.061106] ohci_hcd :00:13.0: roothub.b PPCM= DR= [133971.06] ohci_hcd :00:13.0: roothub.status 8000 DRWE [133971.061116] ohci_hcd :00:13.0: roothub.portstatus [0] 0x0100 PPS [133971.061121] ohci_hcd :00:13.0: roothub.portstatus [1] 0x0100 PPS [133971.061126] ohci_hcd :00:13.0: roothub.portstatus [2] 0x0100 PPS [133971.061131] ohci_hcd :00:13.0: roothub.portstatus [3] 0x0103 PPS PES CCS [133971.061136] ohci_hcd :00:13.0: roothub.portstatus [4] 0x0100 PPS [133971.061188] ohci_hcd :00:13.0: USB bus 2 deregistered [133971.061449] ohci_hcd :00:13.0: OHCI Host Controller [133971.061459] ohci_hcd :00:13.0: new USB bus registered, assigned bus number 2 [133971.061490] ohci_hcd :00:13.0: created debug files [133971.061494] ohci_hcd :00:13.0: supports USB remote wakeup [133971.061549] ohci_hcd :00:13.0: irq 18, io mem 0xfeb4e000 [133971.115480] hub 4-0:1.0: state 7 ports 5 chg evt 0010 [133971.115500] ehci_hcd :00:13.2: GetStatus port:4 status 001803 0 ACK POWER sig=j CSC CONNECT [133971.115514] hub 4-0:1.0: port 4, status 0501, change 0001, 480 Mb/s [133971.119435] ohci_hcd :00:13.0: OHCI controller state [133971.119442] ohci_hcd :00:13.0: OHCI 1.0, NO legacy support registers, rh state running [133971.119449] ohci_hcd :00:13.0: control 0x083 HCFS=operational CBSR=3 [
Re: 3.4.4: disabling irq
On 2013-01-02 17:46, Alan Stern wrote: >> Can it be the webcam? >> I can interchange it with another one of same type. > > If it's a USB webcam then it can't created unwanted IRQs. But you > certainly should try removing it to see if that makes any difference. Stopping the motion service helps in not generating activity from the webcam. (motion uses the webcam to see if stuff happens in the camera's view) >> I'll see if I can find a hub. > > Or else leave those devices unplugged entirely -- use a network login > instead of the USB keyboard and mouse. Mouse is usb. Keyboard is PS/2. This is my main workstation, will have to use the console. Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Wed, 2 Jan 2013, Udo van den Heuvel wrote: > > In the end, this comes down to two possibilities. Either the OHCI > > controller is malfunctioning > > Seen on two mainboards. This one is quite new. > > > or else some other piece of > > hardware/software is. > > Can it be the webcam? > I can interchange it with another one of same type. If it's a USB webcam then it can't created unwanted IRQs. But you certainly should try removing it to see if that makes any difference. > > I suppose you could try unplugging all your low-speed and full-speed > > devices from the OHCI controller. (Get a high-speed hub and plug them > > into it instead.) Then the controller hardware should be totally > > quiescent. If the unwanted IRQs still occur then it seems likely that > > the controller is not the cause -- although this isn't an airtight > > proof. > > I'll see if I can find a hub. Or else leave those devices unplugged entirely -- use a network login instead of the USB keyboard and mouse. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2013-01-02 16:55, Alan Stern wrote: > I don't understand. How can there be nothing more? Above you showed > an "irq 18: nobody cared" message that appeared at 8:51 on Jan 1. It > certainly ought to be in the dmesg log as of 9:00. dmesg can only hold a certain amount of data. The pwc errors take a lot of space per second. > Also, I asked you to turn on CONFIG_PRINTK_TIME. Without that, there's > no way for me to tell when those IRQ: messages appear in relation to > the "nobody cared". I did not reboot yet but I'll see if I can add the PRINTK option. > In the end, this comes down to two possibilities. Either the OHCI > controller is malfunctioning Seen on two mainboards. This one is quite new. > or else some other piece of > hardware/software is. Can it be the webcam? I can interchange it with another one of same type. > I suppose you could try unplugging all your low-speed and full-speed > devices from the OHCI controller. (Get a high-speed hub and plug them > into it instead.) Then the controller hardware should be totally > quiescent. If the unwanted IRQs still occur then it seems likely that > the controller is not the cause -- although this isn't an airtight > proof. I'll see if I can find a hub. Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Tue, 1 Jan 2013, Udo van den Heuvel wrote: > On 2012-12-31 18:24, Alan Stern wrote: > > Can you provide the entire output? Two lines isn't enough. > > It just happened again. Messages in edited form: > > Jan 1 07:23:46 bobo dbus[3106]: [system] Rejected send message, 2 > matched rules; type="method_return", sender=":1.1" (uid=0 pid=3076 > comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" > member="(unset)" error name="(unset)" requested_reply="0" > destination=":1.34" (uid=500 pid=4183 comm="gnome-session ") > Jan 1 08:51:21 bobo kernel: irq 18: nobody cared (try booting with the > "irqpoll" option) > Jan 1 08:51:21 bobo kernel: Pid: 22652, comm: irq/18-ohci_hcd Not > tainted 3.6.11 #19 > dmesg startingsunday afternoon, edited: ... > hub 2-0:1.0: state 7 ports 5 chg evt 0010 > ohci_hcd :00:13.0: IRQ: 4 805a > ohci_hcd :00:13.0: last IRQ repeated 100 times > ohci_hcd :00:13.0: IRQ: 24 805a > ohci_hcd :00:13.0: last IRQ repeated 100 times > > (and nothing more in dmesg as of Tue Jan 1 09:06:45 CET 2013) I don't understand. How can there be nothing more? Above you showed an "irq 18: nobody cared" message that appeared at 8:51 on Jan 1. It certainly ought to be in the dmesg log as of 9:00. Also, I asked you to turn on CONFIG_PRINTK_TIME. Without that, there's no way for me to tell when those IRQ: messages appear in relation to the "nobody cared". In the end, this comes down to two possibilities. Either the OHCI controller is malfunctioning or else some other piece of hardware/software is. Either the unwanted interrupt requests are generated by the OHCI controller or else they are generated by something else. The messages above indicate that lots of IRQs occur at times when the controller has no reason to issue one. Unfortunately, I don't know of any way to tell whether or not the controller actually issued the interrupt requests. If the controller is working correctly and didn't issue those requests then something else did -- and there's no way to tell what. I suppose you could try unplugging all your low-speed and full-speed devices from the OHCI controller. (Get a high-speed hub and plug them into it instead.) Then the controller hardware should be totally quiescent. If the unwanted IRQs still occur then it seems likely that the controller is not the cause -- although this isn't an airtight proof. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-12-31 18:24, Alan Stern wrote: > Can you provide the entire output? Two lines isn't enough. It just happened again. Messages in edited form: Jan 1 07:23:46 bobo dbus[3106]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.1" (uid=0 pid=3076 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.34" (uid=500 pid=4183 comm="gnome-session ") Jan 1 08:51:21 bobo kernel: irq 18: nobody cared (try booting with the "irqpoll" option) Jan 1 08:51:21 bobo kernel: Pid: 22652, comm: irq/18-ohci_hcd Not tainted 3.6.11 #19 Jan 1 08:51:21 bobo kernel: Call Trace: Jan 1 08:51:21 bobo kernel: [] ? __report_bad_irq+0x36/0xd0 Jan 1 08:51:21 bobo kernel: [] ? note_interrupt+0x1c9/0x220 Jan 1 08:51:21 bobo kernel: [] ? irq_thread_fn+0x40/0x40 Jan 1 08:51:21 bobo kernel: [] ? irq_thread+0x145/0x180 Jan 1 08:51:21 bobo kernel: [] ? __wake_up_common+0x4c/0x80 Jan 1 08:51:21 bobo kernel: [] ? irq_finalize_oneshot+0x100/0x100 Jan 1 08:51:21 bobo kernel: [] ? wake_threads_waitq+0x50/0x50 Jan 1 08:51:21 bobo kernel: [] ? kthread+0x85/0x90 Jan 1 08:51:21 bobo kernel: [] ? kernel_thread_helper+0x4/0x10 Jan 1 08:51:21 bobo kernel: [] ? kthread_freezable_should_stop+0x50/0x50 Jan 1 08:51:21 bobo kernel: [] ? gs_change+0xb/0xb Jan 1 08:51:21 bobo kernel: handlers: Jan 1 08:51:21 bobo kernel: [] irq_default_primary_handler threaded [] usb_hcd_irq Jan 1 08:51:21 bobo kernel: [] irq_default_primary_handler threaded [] usb_hcd_irq Jan 1 08:51:21 bobo kernel: [] irq_default_primary_handler threaded [] usb_hcd_irq Jan 1 08:51:21 bobo kernel: Disabling IRQ #18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 0 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 1 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 2 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 3 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 4 has error -114 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 5 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 6 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 7 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 8 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 9 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 0 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 1 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 2 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 3 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 4 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 5 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 6 has error -114 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 7 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 8 has error -18 Jan 1 08:51:22 bobo kernel: pwc: Iso frame 9 has error -18 () Jan 1 08:51:33 bobo kernel: pwc: Iso frame 5 has error -18 Jan 1 08:51:33 bobo kernel: pwc: Iso frame 6 has error -18 Jan 1 08:51:33 bobo kernel: pwc: Iso frame 7 has error -18 Jan 1 08:51:33 bobo kernel: pwc: Iso frame 8 has error -18 Jan 1 08:51:33 bobo kernel: pwc: Iso frame 9 has error -18 Jan 1 08:51:34 bobo systemd[1]: motion.service: main process exited, code=killed, status=9 Jan 1 08:51:34 bobo systemd[1]: Unit motion.service entered failed state. Jan 1 08:51:34 bobo kernel: usbcore: deregistering interface driver Philips webcam Jan 1 08:51:34 bobo kernel: ohci_hcd :00:13.0: remove, state 1 Jan 1 08:51:34 bobo kernel: usb usb2: USB disconnect, device number 1 Jan 1 08:51:34 bobo kernel: usb 2-4: USB disconnect, device number 2 Jan 1 08:51:34 bobo kernel: ohci_hcd :00:13.0: USB bus 2 deregistered Jan 1 08:51:34 bobo kernel: ohci_hcd :00:13.0: OHCI Host Controller Jan 1 08:51:34 bobo kernel: ohci_hcd :00:13.0: new USB bus registered, assigned bus number 2 Jan 1 08:51:34 bobo kernel: ohci_hcd :00:13.0: irq 18, io mem 0xfeb4e000 Jan 1 08:51:34 bobo kernel: usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 Jan 1 08:51:34 bobo kernel: usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Jan 1 08:51:34 bobo kernel: usb usb2: Product: OHCI Host Controller Jan 1 08:51:34 bobo kernel: usb usb2: Manufacturer: Linux 3.6.11 ohci_hcd Jan 1 08:51:34 bobo kernel: usb usb2: SerialNumber: :00:13.0 Jan 1 08:51:34 bobo kernel: hub 2-0:1.0: USB hub found Jan 1 08:51:34 bobo kernel: hub 2-0:1.0: 5 ports detected Jan 1 08:51:34 bobo udevd[1580]: RUN+="socket:..." support will be removed from a future udev release. Please remove it from: /etc/udev/rules.d/90-hal.rules:2 and use libudev to subscribe to events. Jan 1 08:51:34 bobo kernel: usbcore: registered new interface driver Philips webcam Jan 1 08:51:34 bobo motion: [0] [NTC] [ALL] conf_load: Processing thread 0 - config file /etc/motion/motion.conf Jan 1 08:51:34 bobo motion: [0] [NTC] [ALL] motion_startup: Motion 3.3.0 Started Jan 1 08:51:34 bobo m
Re: 3.4.4: disabling irq
Hello Alan, On 2012-12-31 18:24, Alan Stern wrote: >> The patch works OK for the first few times: >> >> ohci_hcd :00:13.0: last IRQ repeated 22 times >> ohci_hcd :00:13.0: IRQ: 24 805a > > Can you provide the entire output? Two lines isn't enough. It's just the normal bootup, then the two usb lines, and then nothing more related until the irq problem occurs. Then there's loads of pwc frame errors until I find out and correct the situation a bit. >> The irq issue still occurs. How can we fix this? > Does the IRQ problem occur immediately after the last line from the > patch? Nope. The lines are printed after bootup and then it can take hours. Kind regards, Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Sat, 29 Dec 2012, Udo van den Heuvel wrote: > Hello Alan, > > On 2012-12-02 18:38, Alan Stern wrote: > > Try this patch instead. > > The patch works OK for the first few times: > > ohci_hcd :00:13.0: last IRQ repeated 22 times > ohci_hcd :00:13.0: IRQ: 24 805a Can you provide the entire output? Two lines isn't enough. > After that it never prints anything anymore. > > The irq issue still occurs. How can we fix this? Does the IRQ problem occur immediately after the last line from the patch? I really need to see the entire log to tell what's happening. Also, you should turn on CONFIG_PRINTK_TIME so that the log entries will have timestamps. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Sat, 1 Dec 2012, Udo van den Heuvel wrote: > > Secondly, try building a kernel with the patch below and > > CONFIG_USB_DEBUG enabled. Let's see what the dmesg log says when the > > problem occurs. > [root@a mesa]# dmesg|sort|uniq The sort messes up the order of the messages. uniq by itself would be okay, though. It would help if you also turn on CONFIG_PRINTK_TIME. These lines looks significant: > ohci_hcd :00:13.0: IRQ: 44 801a > ohci_hcd :00:13.0: IRQ: 4 801a > ohci_hcd :00:13.0: IRQ: 4 805a > ohci_hcd :00:13.0: IRQ: 64 5a The last one is strange. I wouldn't expect it to appear, because 0x64 & 0x5a = 0x40 is nonzero. But it's had to say much without knowing where this message belongs in the log. > I had to hurry as the debug patch overflows dmesg very quickly. > That is the reason why the dmesg is sorted and uniq'd etc. > I do hope there is enough info to further this issue. No, not really. The patch could be modified to reduce the amount of output, if you think that would help. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-11-19 17:41, Alan Stern wrote: > On Sat, 17 Nov 2012, Udo van den Heuvel wrote: >> How to proceed next? > > Firstly, what does /proc/interrupts say? > > Secondly, try building a kernel with the patch below and > CONFIG_USB_DEBUG enabled. Let's see what the dmesg log says when the > problem occurs. Message from syslogd@a at Dec 1 09:46:01 ... kernel:Disabling IRQ #18 ^C [root@a mesa]# cat /sys/kernel/debug/usb/ohci/*/registers bus pci, device :00:12.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x08f HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead 4000 hcca frame 0xa078 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001c56 FRT FR=0x1c56 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0303 LSDA PPS PES CCS roothub.portstatus [2] 0x0100 PPS roothub.portstatus [3] 0x0100 PPS roothub.portstatus [4] 0x0100 PPS bus pci, device :00:13.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x08f HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0026 FNO SF WDH intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead 00092000 hcca frame 0xa2ab fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x8000184a FRT FR=0x184a periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS roothub.portstatus [2] 0x0100 PPS roothub.portstatus [3] 0x0103 PPS PES CCS roothub.portstatus [4] 0x0100 PPS bus pci, device :00:14.5 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x083 HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH hcca frame 0xa000 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x800014da FRT FR=0x14da periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS [root@a mesa]# cat /sys/kernel/debug/usb/devices T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 5 B: Alloc=757/900 us (84%), #Int= 0, #Iso= 3 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.06 S: Manufacturer=Linux 3.6.7 ohci_hcd S: Product=OHCI Host Controller S: SerialNumber=:00:13.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0471 ProdID=0311 Rev= 0.03 S: SerialNumber=0169A500 C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 0 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 196 Ivl=1ms I: If#= 0 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 292 Ivl=1ms I: If#= 0 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 448 Ivl=1ms I: If#= 0 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 592 Ivl=1ms I: If#= 0 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 704 Ivl=1ms I: If#= 0 Alt= 6 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 776 Ivl=1ms I: If#= 0 Alt= 7 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 840 Ivl=1ms I: If#= 0 Alt= 8 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 896 Ivl=1ms I:* If#= 0 Alt= 9 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=Philips webcam E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms E: Ad=85(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms I: If#= 0 Alt=10 #EPs= 2 Cls=ff(vend.) Sub=00
Re: 3.4.4: disabling irq
On Tue, 20 Nov 2012, Udo van den Heuvel wrote: > > Secondly, try building a kernel with the patch below and > > CONFIG_USB_DEBUG enabled. Let's see what the dmesg log says when the > > problem occurs. > > I just booted into 3.6.7 with the patch: > > # dmesg|sort|uniq > ohci_hcd :00:12.0: IRQ: 24 805a > ohci_hcd :00:14.5: IRQ: 24 805a > # > > So what does this mean? > I did not get the `disabling irq` yet. It means your system was working normally. Which you already knew, because the IRQ didn't get disabled. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-11-19 17:41, Alan Stern wrote: > Firstly, what does /proc/interrupts say? # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 40 0 0 0 IO-APIC-edge timer 1:631640677734 IO-APIC-edge i8042 4: 1026976961 1098 IO-APIC-edge serial 9: 0 0 0 0 IO-APIC-fasteoi acpi 16:409403406414 IO-APIC-fasteoi snd_hda_intel 17: 1 1 0 2 IO-APIC-fasteoi ehci_hcd:usb4, ehci_hcd:usb5 18: 62356 62649 64102 67369 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3 20: 5774 5762 5902 6405 IO-APIC-fasteoi serial 40: 0 0 0 0 PCI-MSI-edge AMD-Vi 43: 19483 19239 19938 20909 PCI-MSI-edge ahci 44: 51837 52223 53122 55971 PCI-MSI-edge eth0 45: 0 0 0 0 PCI-MSI-edge xhci_hcd 46: 0 0 0 0 PCI-MSI-edge xhci_hcd 47: 0 0 0 0 PCI-MSI-edge xhci_hcd 48: 0 0 0 0 PCI-MSI-edge xhci_hcd 49: 0 0 0 0 PCI-MSI-edge xhci_hcd 50: 0 0 0 0 PCI-MSI-edge xhci_hcd 51: 0 0 0 0 PCI-MSI-edge xhci_hcd 52: 0 0 0 0 PCI-MSI-edge xhci_hcd 53: 0 0 0 0 PCI-MSI-edge xhci_hcd 54: 0 0 0 0 PCI-MSI-edge xhci_hcd 55: 0 0 0 0 PCI-MSI-edge xhci_hcd 56: 26 24 42 31 PCI-MSI-edge snd_hda_intel 57: 28748 28431 29792 32594 PCI-MSI-edge radeon NMI: 0 0 0 0 Non-maskable interrupts LOC: 271724 235396 273222 256476 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 534762 574540 368898 508436 Rescheduling interrupts CAL: 30439 42897 30212 31668 Function call interrupts TLB: 0 0 0 0 TLB shootdowns THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 4 4 4 4 Machine check polls ERR: 8 MIS: 0 > Secondly, try building a kernel with the patch below and > CONFIG_USB_DEBUG enabled. Let's see what the dmesg log says when the > problem occurs. I just booted into 3.6.7 with the patch: # dmesg|sort|uniq ohci_hcd :00:12.0: IRQ: 24 805a ohci_hcd :00:14.5: IRQ: 24 805a # So what does this mean? I did not get the `disabling irq` yet. Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-11-19 17:41, Alan Stern wrote: >> How to proceed next? > > Firstly, what does /proc/interrupts say? # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 39 0 0 0 IO-APIC-edge timer 1:716721730687 IO-APIC-edge i8042 4: 1631 1603 1713 1914 IO-APIC-edge serial 9: 0 0 0 0 IO-APIC-fasteoi acpi 16:427437443447 IO-APIC-fasteoi snd_hda_intel 17: 0 0 3 1 IO-APIC-fasteoi ehci_hcd:usb4, ehci_hcd:usb5 18: 100443 100710 103881 116011 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3 20: 8049 8235 8456 9657 IO-APIC-fasteoi serial 40: 0 0 0 0 PCI-MSI-edge AMD-Vi 43: 47534 47847 49501 52187 PCI-MSI-edge ahci 44: 118811 119571 123111 134412 PCI-MSI-edge eth0 45: 0 0 0 0 PCI-MSI-edge xhci_hcd 46: 0 0 0 0 PCI-MSI-edge xhci_hcd 47: 0 0 0 0 PCI-MSI-edge xhci_hcd 48: 0 0 0 0 PCI-MSI-edge xhci_hcd 49: 0 0 0 0 PCI-MSI-edge xhci_hcd 50: 0 0 0 0 PCI-MSI-edge xhci_hcd 51: 0 0 0 0 PCI-MSI-edge xhci_hcd 52: 0 0 0 0 PCI-MSI-edge xhci_hcd 53: 0 0 0 0 PCI-MSI-edge xhci_hcd 54: 0 0 0 0 PCI-MSI-edge xhci_hcd 55: 0 0 0 0 PCI-MSI-edge xhci_hcd 56: 33 28 36 28 PCI-MSI-edge snd_hda_intel 57: 52846 53825 5 64450 PCI-MSI-edge radeon NMI: 0 0 0 0 Non-maskable interrupts LOC: 381988 405614 348070 323872 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES:1166893118478110890481016935 Rescheduling interrupts CAL: 34472 32009 62610 50241 Function call interrupts TLB: 0 0 0 0 TLB shootdowns THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 8 8 8 8 Machine check polls ERR: 4 MIS: 0 > Secondly, try building a kernel with the patch below and > CONFIG_USB_DEBUG enabled. Let's see what the dmesg log says when the > problem occurs. Will do! Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Sat, 17 Nov 2012, Udo van den Heuvel wrote:
> The problem still happens. irq 18 is dsiabled every now and then.
> This time on different, new hardware.
> The motherboard is now a Gigabyte F2A85X-UP4.
> Camera is the same pwc cam.
>
> Recently I removed the USB printer that was attached to the same USB
> controller.
> So probably it is not a hardware issue related to board or printer.
>
> How to proceed next?
Firstly, what does /proc/interrupts say?
Secondly, try building a kernel with the patch below and
CONFIG_USB_DEBUG enabled. Let's see what the dmesg log says when the
problem occurs.
Alan Stern
Index: usb-3.7/drivers/usb/host/ohci-hcd.c
===
--- usb-3.7.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.7/drivers/usb/host/ohci-hcd.c
@@ -777,6 +777,7 @@ static irqreturn_t ohci_irq (struct usb_
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
struct ohci_regs __iomem *regs = ohci->regs;
int ints;
+ int i, j;
/* Read interrupt status (and flush pending writes). We ignore the
* optimization of checking the LSB of hcca->done_head; it doesn't
@@ -795,11 +796,15 @@ static irqreturn_t ohci_irq (struct usb_
}
/* We only care about interrupts that are enabled */
- ints &= ohci_readl(ohci, ®s->intrenable);
+ i = ints;
+ j = ohci_readl(ohci, ®s->intrenable);
+ ints &= j;
/* interrupt for some other device? */
- if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED))
+ if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED)) {
+ ohci_dbg(ohci, "IRQ: %x %x\n", i, j);
return IRQ_NOTMINE;
+ }
if (ints & OHCI_INTR_UE) {
// e.g. due to PCI Master/Target Abort
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-07-15 20:28, Alan Stern wrote: > Um, I think you missed the point. The whole idea of the test is to see > what happens while the controller is unbound from the driver. Binding > it again defeats the purpose. The problem still happens. irq 18 is dsiabled every now and then. This time on different, new hardware. The motherboard is now a Gigabyte F2A85X-UP4. Camera is the same pwc cam. Recently I removed the USB printer that was attached to the same USB controller. So probably it is not a hardware issue related to board or printer. How to proceed next? Udo PS: Info captured soon after one occurrence: # cat /sys/kernel/debug/usb/ohci/*/registers bus pci, device :00:12.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x08f HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead 4000 hcca frame 0x6ed9 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x85fa FRT FR=0x05fa periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0303 LSDA PPS PES CCS roothub.portstatus [2] 0x0100 PPS roothub.portstatus [3] 0x0100 PPS roothub.portstatus [4] 0x0100 PPS bus pci, device :00:13.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x08f HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0026 FNO SF WDH intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead 4000 hcca frame 0x6e9d fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001fcf FRT FR=0x1fcf periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS roothub.portstatus [2] 0x0100 PPS roothub.portstatus [3] 0x0103 PPS PES CCS roothub.portstatus [4] 0x0100 PPS bus pci, device :00:14.5 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x083 HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH hcca frame 0x6e61 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x8cd8 FRT FR=0x0cd8 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS # cat /sys/kernel/debug/usb/devices T: Bus=11 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 P: Vendor=1d6b ProdID=0003 Rev= 3.06 S: Manufacturer=Linux 3.6.6 xhci_hcd S: Product=xHCI Host Controller S: SerialNumber=:02:00.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=10 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 3.06 S: Manufacturer=Linux 3.6.6 xhci_hcd S: Product=xHCI Host Controller S: SerialNumber=:02:00.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=09 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 P: Vendor=1d6b ProdID=0003 Rev= 3.06 S: Manufacturer=Linux 3.6.6 xhci_hcd S: Product=xHCI Host Controller S: SerialNumber=:00:10.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 3.06 S: Manufacturer=Linux 3.6.6 xhci_hcd S: Product=xHCI Host Controller S: SerialNumber=:00:10.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 P: Vendor=1d6b ProdID=0003 Rev= 3.06 S: Manufacturer=Linux 3.6.6 xhci_hcd S: Product=xHCI Host Controller S: SerialNumber=:00:10.0 C:* #Ifs= 1 Cfg#= 1 At
Re: 3.4.4: disabling irq
Well, The issue appeared again. irq 18 was disabled, one pwc webcam was on that irq. This time on new hardware: Gigabyte F2A85X-UP4 with A10-5800K APU. The box was busy with it's raid10 array, this time, by running bonnie++; also a raid-check was in progress. (unknown at the time) So what does this say? It appears not to be a hardware problem per se. Anyone? Kind regards, Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Sun, 15 Jul 2012, Udo van den Heuvel wrote: > On 2012-07-15 17:35, Alan Stern wrote: > > echo :00:13.1 >/sys/bus/pci/drivers/ohci_hcd/unbind > > Afterwards I did: > > > echo :00:13.1 >/sys/bus/pci/drivers/ohci_hcd/bind Um, I think you missed the point. The whole idea of the test is to see what happens while the controller is unbound from the driver. Binding it again defeats the purpose. > And I saw: > > Jul 15 17:50:30 surfplank2 kernel: ohci_hcd :00:13.1: remove, state 1 > Jul 15 17:50:30 surfplank2 kernel: usb usb4: USB disconnect, device number 1 > Jul 15 17:50:30 surfplank2 kernel: usb 4-3: USB disconnect, device number 2 > Jul 15 17:50:30 surfplank2 kernel: ohci_hcd :00:13.1: USB bus 4 > deregistered > Jul 15 17:50:37 surfplank2 kernel: ohci_hcd :00:13.1: OHCI Host > Controller > Jul 15 17:50:37 surfplank2 kernel: ohci_hcd :00:13.1: new USB bus > registered, assigned bus number 4 > Jul 15 17:50:37 surfplank2 kernel: ohci_hcd :00:13.1: irq 18, io mem > 0xfe02a000 > Jul 15 17:50:37 surfplank2 kernel: usb usb4: New USB device found, > idVendor=1d6b, idProduct=0001 > Jul 15 17:50:37 surfplank2 kernel: usb usb4: New USB device strings: > Mfr=3, Product=2, SerialNumber=1 > Jul 15 17:50:37 surfplank2 kernel: usb usb4: Product: OHCI Host Controller > Jul 15 17:50:37 surfplank2 kernel: usb usb4: Manufacturer: Linux 3.4.4 > ohci_hcd > Jul 15 17:50:37 surfplank2 kernel: usb usb4: SerialNumber: :00:13.1 > Jul 15 17:50:37 surfplank2 kernel: hub 4-0:1.0: USB hub found > Jul 15 17:50:37 surfplank2 kernel: hub 4-0:1.0: 3 ports detected > Jul 15 17:50:37 surfplank2 kernel: usb 4-3: new full-speed USB device > number 2 using ohci_hcd > Jul 15 17:50:38 surfplank2 kernel: usb 4-3: New USB device found, > idVendor=0471, idProduct=0311 > Jul 15 17:50:38 surfplank2 kernel: usb 4-3: New USB device strings: > Mfr=0, Product=0, SerialNumber=1 > Jul 15 17:50:38 surfplank2 kernel: usb 4-3: SerialNumber: 0169A500 > Jul 15 17:50:38 surfplank2 mtp-probe: checking bus 4, device 2: > "/sys/devices/pci:00/:00:13.1/usb4/4-3" > Jul 15 17:50:38 surfplank2 mtp-probe: bus: 4, device: 2 was not an MTP > device > Jul 15 17:50:38 surfplank2 kernel: pwc: Philips PCVC740K (ToUCam > Pro)/PCVC840 (ToUCam II) USB webcam detected. > Jul 15 17:50:39 surfplank2 kernel: pwc: Registered as video0. > Jul 15 17:50:39 surfplank2 kernel: input: PWC snapshot button as > /devices/pci:00/:00:13.0/usb3/3-2/input/input8 > Jul 15 17:50:39 surfplank2 kernel: pwc: Philips PCVC740K (ToUCam > Pro)/PCVC840 (ToUCam II) USB webcam detected. > Jul 15 17:50:39 surfplank2 kernel: pwc: Registered as video1. > Jul 15 17:50:39 surfplank2 kernel: input: PWC snapshot button as > /devices/pci:00/:00:13.1/usb4/4-3/input/input9 > Jul 15 17:50:39 surfplank2 kernel: usbcore: registered new interface > driver Philips webcam > Jul 15 17:50:39 surfplank2 colord[3375]: (colord:3375): Cd-WARNING **: > CdMain: failed to emit DeviceAdded: failed to register object: An object > is already exported for the interface > org.freedesktop.ColorManager.Device at > /org/freedesktop/ColorManager/devices/sysfs_0471_0311 > > So I have two webcams on this controller, each on a different port. How do you reach that conclusion? The log above shows only one webcam on bus 4: device 2, attached to port 3. There is another webcam, yes, but it's on bus 3, not bus 4. > The final line is an issue that cam with Fedora 17, nobody could foresee > that one could need a colord *and* have two identical webcams too. (I do > not need colord but have two webcams to be clear) > > After doing this I could modprobe pwc and start mrtg without problem. > > So now I can wait for the next occurrence. You should unbind the controller and leave it unbound. _Then_ wait for the next occurrence. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-07-15 17:55, Udo van den Heuvel wrote: > After doing this I could modprobe pwc and start mrtg without problem. Euh: s/mrtg/motion/ Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-07-15 17:35, Alan Stern wrote: > echo :00:13.1 >/sys/bus/pci/drivers/ohci_hcd/unbind Afterwards I did: > echo :00:13.1 >/sys/bus/pci/drivers/ohci_hcd/bind And I saw: Jul 15 17:50:30 surfplank2 kernel: ohci_hcd :00:13.1: remove, state 1 Jul 15 17:50:30 surfplank2 kernel: usb usb4: USB disconnect, device number 1 Jul 15 17:50:30 surfplank2 kernel: usb 4-3: USB disconnect, device number 2 Jul 15 17:50:30 surfplank2 kernel: ohci_hcd :00:13.1: USB bus 4 deregistered Jul 15 17:50:37 surfplank2 kernel: ohci_hcd :00:13.1: OHCI Host Controller Jul 15 17:50:37 surfplank2 kernel: ohci_hcd :00:13.1: new USB bus registered, assigned bus number 4 Jul 15 17:50:37 surfplank2 kernel: ohci_hcd :00:13.1: irq 18, io mem 0xfe02a000 Jul 15 17:50:37 surfplank2 kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 Jul 15 17:50:37 surfplank2 kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Jul 15 17:50:37 surfplank2 kernel: usb usb4: Product: OHCI Host Controller Jul 15 17:50:37 surfplank2 kernel: usb usb4: Manufacturer: Linux 3.4.4 ohci_hcd Jul 15 17:50:37 surfplank2 kernel: usb usb4: SerialNumber: :00:13.1 Jul 15 17:50:37 surfplank2 kernel: hub 4-0:1.0: USB hub found Jul 15 17:50:37 surfplank2 kernel: hub 4-0:1.0: 3 ports detected Jul 15 17:50:37 surfplank2 kernel: usb 4-3: new full-speed USB device number 2 using ohci_hcd Jul 15 17:50:38 surfplank2 kernel: usb 4-3: New USB device found, idVendor=0471, idProduct=0311 Jul 15 17:50:38 surfplank2 kernel: usb 4-3: New USB device strings: Mfr=0, Product=0, SerialNumber=1 Jul 15 17:50:38 surfplank2 kernel: usb 4-3: SerialNumber: 0169A500 Jul 15 17:50:38 surfplank2 mtp-probe: checking bus 4, device 2: "/sys/devices/pci:00/:00:13.1/usb4/4-3" Jul 15 17:50:38 surfplank2 mtp-probe: bus: 4, device: 2 was not an MTP device Jul 15 17:50:38 surfplank2 kernel: pwc: Philips PCVC740K (ToUCam Pro)/PCVC840 (ToUCam II) USB webcam detected. Jul 15 17:50:39 surfplank2 kernel: pwc: Registered as video0. Jul 15 17:50:39 surfplank2 kernel: input: PWC snapshot button as /devices/pci:00/:00:13.0/usb3/3-2/input/input8 Jul 15 17:50:39 surfplank2 kernel: pwc: Philips PCVC740K (ToUCam Pro)/PCVC840 (ToUCam II) USB webcam detected. Jul 15 17:50:39 surfplank2 kernel: pwc: Registered as video1. Jul 15 17:50:39 surfplank2 kernel: input: PWC snapshot button as /devices/pci:00/:00:13.1/usb4/4-3/input/input9 Jul 15 17:50:39 surfplank2 kernel: usbcore: registered new interface driver Philips webcam Jul 15 17:50:39 surfplank2 colord[3375]: (colord:3375): Cd-WARNING **: CdMain: failed to emit DeviceAdded: failed to register object: An object is already exported for the interface org.freedesktop.ColorManager.Device at /org/freedesktop/ColorManager/devices/sysfs_0471_0311 So I have two webcams on this controller, each on a different port. The final line is an issue that cam with Fedora 17, nobody could foresee that one could need a colord *and* have two identical webcams too. (I do not need colord but have two webcams to be clear) After doing this I could modprobe pwc and start mrtg without problem. So now I can wait for the next occurrence. Kind regards, Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Sun, 15 Jul 2012, Udo van den Heuvel wrote: > > The conclusion is that ohci-hcd is the only driver using IRQ 18. If > > you build a kernel with CONFIG_USB_DEBUG enabled, it will be possible > > to see if the OHCI hardware is responsible for the IRQ problem. > > > > When the IRQ line gets disabled again, make a copy of the > > > > /sys/kernel/debug/usb/ohci/*/registers > > > > files and post them, along with a copy of > > /sys/kernel/debug/usb/devices. > After disabling: This indicates the controller at :00:13.1 has an outstanding interrupt request: > bus pci, device :00:13.1 > OHCI Host Controller > ohci_hcd > OHCI 1.0, NO legacy support registers, rh state running > control 0x08f HCFS=operational IE PLE CBSR=3 > cmdstatus 0x0 SOC=0 > intrstatus 0x0026 FNO SF WDH > intrenable 0x805a MIE RHSC UE RD WDH The WDH bit is set in both intrstatus and intrenable. None of the other controllers show anything similar. Therefore, in the absence of hardware bugs, this controller must be the one causing your problem. You can test this by unbinding that controller from the ohci-hcd driver: echo :00:13.1 >/sys/bus/pci/drivers/ohci_hcd/unbind Do this before the IRQ error occurs, and see if you get another error. If you do, get another copy of those "register" files as quickly afterwards as you can. That's the controller for bus 4, which has one of the webcams. If you prefer, you could simply unplug the webcam from bus 4 instead; the end result should be the same. (Or even unplug both webcams...) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-07-15 16:28, Udo van den Heuvel wrote: > After disabling: And somewhat later: bus pci, device :00:12.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x083 HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead cf82 hcca frame 0x523f fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80002844 FRT FR=0x2844 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000203 POTPGT=2 NPS NDP=3(3) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0100 PPS bus pci, device :00:12.1 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x083 HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead cf862050 ed_bulkhead cf8620a0 hcca frame 0x5203 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80002249 FRT FR=0x2249 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000203 POTPGT=2 NPS NDP=3(3) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0100 PPS bus pci, device :00:13.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x0af HCFS=operational BLE IE PLE CBSR=3 cmdstatus 0x10004 SOC=1 BLF intrstatus 0x0025 FNO SF SO intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead cf840050 ed_bulkhead cf8400f0 ed_bulkcurrent cf8400f0 hcca frame 0x51c7 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001ec8 FRT FR=0x1ec8 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000203 POTPGT=2 NPS NDP=3(3) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0103 PPS PES CCS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0100 PPS bus pci, device :00:13.1 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x083 HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead cf822000 hcca frame 0x517a fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80002254 FRT FR=0x2254 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000203 POTPGT=2 NPS NDP=3(3) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS roothub.portstatus [2] 0x0103 PPS PES CCS bus pci, device :00:14.5 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x083 HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH hcca frame 0x5057 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001864 FRT FR=0x1864 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000202 POTPGT=2 NPS NDP=2(2) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.04 S: Manufacturer=Linux 3.4.4 ohci_hcd S: Product=OHCI Host Controller S: SerialNumber=:00:14.5 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 3.04 S: Manufacturer=Linux 3.4.4 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:13.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=06 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs= 2 P: Vendor=0525 ProdID=a4a2 Rev= 2.16 S: Manufacturer=Linux 2.6.21-omap1/musb_hdrc S: Product=RNDIS/Ethernet Gadget C: #Ifs= 2 Cfg#= 2 Atr=e0 MxPwr= 8mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver= E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr= 8mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=(none) E: Ad=82(I) Atr=0
Re: 3.4.4: disabling irq
On 2012-07-12 16:54, Alan Stern wrote: > On Thu, 12 Jul 2012, Udo van den Heuvel wrote: > >> # cat /proc/interrupts (...) >> 18: 25190 18052161 21311 IO-APIC-fasteoi >> ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 (...) >> So what can we conclude? > The conclusion is that ohci-hcd is the only driver using IRQ 18. If > you build a kernel with CONFIG_USB_DEBUG enabled, it will be possible > to see if the OHCI hardware is responsible for the IRQ problem. > > When the IRQ line gets disabled again, make a copy of the > > /sys/kernel/debug/usb/ohci/*/registers > > files and post them, along with a copy of > /sys/kernel/debug/usb/devices. After boot: bus pci, device :00:12.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x083 HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead cf83f000 hcca frame 0x4771 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001f9b FRT FR=0x1f9b periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000203 POTPGT=2 NPS NDP=3(3) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0100 PPS bus pci, device :00:12.1 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x083 HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead cf809000 hcca frame 0x4735 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x800019d1 FRT FR=0x19d1 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000203 POTPGT=2 NPS NDP=3(3) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0100 PPS bus pci, device :00:13.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x0af HCFS=operational BLE IE PLE CBSR=3 cmdstatus 0x4 SOC=0 BLF intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead cf825050 ed_bulkhead cf8250f0 ed_bulkcurrent cf8250f0 hcca frame 0x46f5 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001642 FRT FR=0x1642 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000203 POTPGT=2 NPS NDP=3(3) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0103 PPS PES CCS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0100 PPS bus pci, device :00:13.1 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x08f HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_periodcurrent cf807050 ed_controlhead cf807000 donehead cf808300 hcca frame 0x46ad fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001338 FRT FR=0x1338 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000203 POTPGT=2 NPS NDP=3(3) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS roothub.portstatus [2] 0x0103 PPS PES CCS bus pci, device :00:14.5 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x083 HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH hcca frame 0x4585 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x8feb FRT FR=0x0feb periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000202 POTPGT=2 NPS NDP=2(2) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.04 S: Manufacturer=Linux 3.4.4 ohci_hcd S: Product=OHCI Host Controller S: SerialNumber=:00:14.5 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 3.04 S: Manufacturer=Linux 3.4.4 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:13.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=06 Lev=01 Prnt=01 Port=04 Cnt=
Re: 3.4.4: disabling irq
On Thu, 12 Jul 2012, Udo van den Heuvel wrote: > # cat /proc/interrupts >CPU0 CPU1 CPU2 CPU3 > 0: 40 0 0 0 IO-APIC-edge timer > 1: 1 4 91884418 IO-APIC-edge i8042 > 4: 1 25 607223 1584 IO-APIC-edge serial > 6: 0 0 8 0 IO-APIC-edge floppy > 7: 1 0 0 0 IO-APIC-edge > parport0 > 9: 0 0 0 0 IO-APIC-fasteoi acpi > 12: 3106 980333 3914 IO-APIC-edge i8042 > 14: 0 5 169732457 IO-APIC-edge > pata_atiixp > 15: 0 0 0 0 IO-APIC-edge > pata_atiixp > 16: 0 0 3038 33 IO-APIC-fasteoi > sata_sil24, ohci_hcd:usb1, ohci_hcd:usb2, snd_hda_intel > 17: 0 4 24053119 IO-APIC-fasteoi > ehci_hcd:usb3 > 18: 25190 18052161 21311 IO-APIC-fasteoi > ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 > 19: 1 9 187895487 IO-APIC-fasteoi > ehci_hcd:usb4 > 20: 71353756346 8907 IO-APIC-fasteoi serial > 22:127719 14673690 33318 IO-APIC-fasteoi ahci > 43:115 1072 33699508 73116 PCI-MSI-edge eth0 > 44: 272523044666 11507 PCI-MSI-edge radeon > 45: 0 0 21 0 PCI-MSI-edge > snd_hda_intel > NMI: 0 0 0 0 Non-maskable interrupts > LOC: 15971203 15548951 13031603 13145359 Local timer interrupts > SPU: 0 0 0 0 Spurious interrupts > PMI: 0 0 0 0 Performance > monitoring interrupts > IWI: 0 0 0 0 IRQ work interrupts > RTR: 0 0 0 0 APIC ICR read retries > RES: 57916374 44634814 19199377 43219640 Rescheduling interrupts > CAL: 2241 2293 2327 2196 Function call interrupts > TLB: 577983 648537 579293 635466 TLB shootdowns > THR: 0 0 0 0 Threshold APIC interrupts > MCE: 0 0 0 0 Machine check exceptions > MCP:581581581581 Machine check polls > ERR: 0 > MIS: 0 > > > > So what can we conclude? The conclusion is that ohci-hcd is the only driver using IRQ 18. If you build a kernel with CONFIG_USB_DEBUG enabled, it will be possible to see if the OHCI hardware is responsible for the IRQ problem. When the IRQ line gets disabled again, make a copy of the /sys/kernel/debug/usb/ohci/*/registers files and post them, along with a copy of /sys/kernel/debug/usb/devices. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-07-12 15:43, Jan Ceuleers wrote: > On 07/12/2012 03:23 PM, Udo van den Heuvel wrote: >> How to list what modules/programs are using that irq? > > cat /proc/interrupts # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 40 0 0 0 IO-APIC-edge timer 1: 1 4 91884418 IO-APIC-edge i8042 4: 1 25 607223 1584 IO-APIC-edge serial 6: 0 0 8 0 IO-APIC-edge floppy 7: 1 0 0 0 IO-APIC-edge parport0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 3106 980333 3914 IO-APIC-edge i8042 14: 0 5 169732457 IO-APIC-edge pata_atiixp 15: 0 0 0 0 IO-APIC-edge pata_atiixp 16: 0 0 3038 33 IO-APIC-fasteoi sata_sil24, ohci_hcd:usb1, ohci_hcd:usb2, snd_hda_intel 17: 0 4 24053119 IO-APIC-fasteoi ehci_hcd:usb3 18: 25190 18052161 21311 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 1 9 187895487 IO-APIC-fasteoi ehci_hcd:usb4 20: 71353756346 8907 IO-APIC-fasteoi serial 22:127719 14673690 33318 IO-APIC-fasteoi ahci 43:115 1072 33699508 73116 PCI-MSI-edge eth0 44: 272523044666 11507 PCI-MSI-edge radeon 45: 0 0 21 0 PCI-MSI-edge snd_hda_intel NMI: 0 0 0 0 Non-maskable interrupts LOC: 15971203 15548951 13031603 13145359 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 57916374 44634814 19199377 43219640 Rescheduling interrupts CAL: 2241 2293 2327 2196 Function call interrupts TLB: 577983 648537 579293 635466 TLB shootdowns THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP:581581581581 Machine check polls ERR: 0 MIS: 0 So what can we conclude? Kind regards, Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 07/12/2012 03:23 PM, Udo van den Heuvel wrote: > How to list what modules/programs are using that irq? cat /proc/interrupts -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-07-11 17:15, Alan Stern wrote: > On Wed, 11 Jul 2012, Udo van den Heuvel wrote: > >> New occurrence: > >> Any clues and/or updates? > > Didn't you see the message I posted on Monday? > > http://marc.info/?l=linux-usb&m=134186054713868&w=2 Nothing changed except the kernel. Main compononent on usb is the pwc webcam. After the occurrence yesterday I unloaded motion and the pwc module. But I got *another* occurrence round 20:47 hours. How to list what modules/programs are using that irq? Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Wed, 11 Jul 2012, Udo van den Heuvel wrote: > New occurrence: > > Jul 11 16:45:26 box3 kernel: irq 18: nobody cared (try booting with the > "irqpoll" option) > Jul 11 16:45:26 box3 kernel: Pid: 1465, comm: irq/18-ohci_hcd Not > tainted 3.4.4 #3 > Any clues and/or updates? Didn't you see the message I posted on Monday? http://marc.info/?l=linux-usb&m=134186054713868&w=2 Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-07-09 15:54, Clemens Ladisch wrote: > (forwarded to linux-usb) > > Udo van den Heuvel wrote: >> >> One moment the box is runing OK. >> One moment the 3.4.4 kernel decides to disable an interrupt. >> Why? >> >> Jul 8 07:43:49 box3 ntpd[5067]: parse: convert_rawdcf: INCOMPLETE DATA - >> time code only has 1 bits >> Jul 8 07:44:53 box3 kernel: irq 18: nobody cared (try booting with the >> "irqpoll" option) >> Jul 8 07:44:53 box3 kernel: Pid: 1501, comm: irq/18-ohci_hcd Tainted: G >>W3.4.4 #1 >> Jul 8 07:44:53 box3 kernel: Call Trace: >> Jul 8 07:44:53 box3 kernel: [] ? >> __report_bad_irq+0x36/0xd0 >> Jul 8 07:44:53 box3 kernel: [] ? >> note_interrupt+0x1cf/0x220 >> Jul 8 07:44:53 box3 kernel: [] ? irq_thread_fn+0x40/0x40 >> Jul 8 07:44:53 box3 kernel: [] ? irq_thread+0x13d/0x180 >> Jul 8 07:44:53 box3 kernel: [] ? >> wake_threads_waitq+0x50/0x50 >> Jul 8 07:44:53 box3 kernel: [] ? kthread+0x85/0x90 >> Jul 8 07:44:53 box3 kernel: [] ? >> kernel_thread_helper+0x4/0x10 >> Jul 8 07:44:53 box3 kernel: [] ? >> kthread_freezable_should_stop+0x50/0x50 >> Jul 8 07:44:53 box3 kernel: [] ? gs_change+0xb/0xb >> Jul 8 07:44:53 box3 kernel: handlers: >> Jul 8 07:44:53 box3 kernel: [] >> irq_default_primary_handler threaded [] usb_hcd_irq >> Jul 8 07:44:53 box3 kernel: [] >> irq_default_primary_handler threaded [] usb_hcd_irq >> Jul 8 07:44:53 box3 kernel: [] >> irq_default_primary_handler threaded [] usb_hcd_irq >> Jul 8 07:44:53 box3 kernel: Disabling IRQ #18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 0 has error -114 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 1 has error -18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 2 has error -18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 3 has error -18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 4 has error -18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 5 has error -18 >> (etc; many more of the pwc messages) New occurrence: Jul 11 16:45:26 box3 kernel: irq 18: nobody cared (try booting with the "irqpoll" option) Jul 11 16:45:26 box3 kernel: Pid: 1465, comm: irq/18-ohci_hcd Not tainted 3.4.4 #3 Jul 11 16:45:26 box3 kernel: Call Trace: Jul 11 16:45:26 box3 kernel: [] ? __report_bad_irq+0x36/0xd0 Jul 11 16:45:26 box3 kernel: [] ? note_interrupt+0x1cf/0x220 Jul 11 16:45:26 box3 kernel: [] ? irq_thread_fn+0x40/0x40 Jul 11 16:45:26 box3 kernel: [] ? irq_thread+0x13d/0x180 Jul 11 16:45:26 box3 kernel: [] ? wake_threads_waitq+0x50/0x50 Jul 11 16:45:26 box3 kernel: [] ? kthread+0x85/0x90 Jul 11 16:45:26 box3 kernel: [] ? kernel_thread_helper+0x4/0x10 Jul 11 16:45:26 box3 kernel: [] ? kthread_freezable_should_stop+0x50/0x50 Jul 11 16:45:26 box3 kernel: [] ? gs_change+0xb/0xb Jul 11 16:45:26 box3 kernel: handlers: Jul 11 16:45:26 box3 kernel: [] irq_default_primary_handler threaded [] usb_hcd_irq Jul 11 16:45:26 box3 kernel: [] irq_default_primary_handler threaded [] usb_hcd_irq Jul 11 16:45:26 box3 kernel: [] irq_default_primary_handler threaded [] usb_hcd_irq Jul 11 16:45:26 box3 kernel: Disabling IRQ #18 Jul 11 16:45:26 box3 kernel: pwc: Iso frame 0 has error -18 Jul 11 16:45:26 box3 kernel: pwc: Iso frame 1 has error -18 (etc) Any clues and/or updates? Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Mon, 9 Jul 2012, Clemens Ladisch wrote: > (forwarded to linux-usb) > > Udo van den Heuvel wrote: > > Hello, > > > > One moment the box is runing OK. > > One moment the 3.4.4 kernel decides to disable an interrupt. > > Why? The kernel disables IRQs when too many interrupts arrive too quickly. In general that means some device is generating an interrupt request and it isn't getting handled by any driver. > > Jul 8 07:43:49 box3 ntpd[5067]: parse: convert_rawdcf: INCOMPLETE DATA - > > time code only has 1 bits > > Jul 8 07:44:53 box3 kernel: irq 18: nobody cared (try booting with the > > "irqpoll" option) > > Jul 8 07:44:53 box3 kernel: Pid: 1501, comm: irq/18-ohci_hcd Tainted: G > > W3.4.4 #1 > ... and, with apparently the same mainboard: > > Simon Jones wrote: > > Hi, > > > > Am not sure where to start with getting help on an issue. > > > > Since buying my motherboard i have found the usb ports are pretty > > unstable, and some devices work on usb2 some on usb3, after a while i > > managed to work out which will work where and it's reasonably stable > > now. > > > > Am on kernel 3.2.16 and tonight i thought i would try 3.4.4, it's all > > been compiled and seemed fine until i ran mythtv and couldn't get a > > smooth picture, then the tuner stopped responding and when looking in > > to the logs it appears IRQ18 assigned to the usb chipset gets disabled > > from what i can tell, it also causes a crash. > > > > Motherboard is Gigabyte GA-990XA-UD3 > > CPU is AMD Bulldozer 6 Core version > > > > I'll attach the 2 dmesg logs, one from 3.2 and other from 3.4, > > hopefully someone can see what's wrong, there is a suggestion to boot > > with irqpoll, but really wanted someone's opinion on this. Simon's log shows a large of number of devices all using the same IRQ. A good place to start would be to unload or unbind the drivers for some or all of the devices -- if that can be done before the IRQ is disabled. Maybe it will turn out that an individual device is responsible for the problem. Another possibility is that some other device is using that IRQ line without the kernel's knowledge. That's not an easy sort of thing to track down, though. In general, how easy is it to reproduce these problems? Does the IRQ line always get disabled after the system has been up for a few seconds? If it does, and if the problem is caused by a software change, git bisection might be the easiest way to track it down. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-07-09 15:54, Clemens Ladisch wrote: > (forwarded to linux-usb) > > Udo van den Heuvel wrote: >> Hello, >> >> One moment the box is runing OK. >> One moment the 3.4.4 kernel decides to disable an interrupt. >> Why? >> >> Jul 8 07:43:49 box3 ntpd[5067]: parse: convert_rawdcf: INCOMPLETE DATA - >> time code only has 1 bits >> Jul 8 07:44:53 box3 kernel: irq 18: nobody cared (try booting with the >> "irqpoll" option) >> Jul 8 07:44:53 box3 kernel: Pid: 1501, comm: irq/18-ohci_hcd Tainted: G >>W3.4.4 #1 >> Jul 8 07:44:53 box3 kernel: Call Trace: >> Jul 8 07:44:53 box3 kernel: [] ? >> __report_bad_irq+0x36/0xd0 >> Jul 8 07:44:53 box3 kernel: [] ? >> note_interrupt+0x1cf/0x220 >> Jul 8 07:44:53 box3 kernel: [] ? irq_thread_fn+0x40/0x40 >> Jul 8 07:44:53 box3 kernel: [] ? irq_thread+0x13d/0x180 >> Jul 8 07:44:53 box3 kernel: [] ? >> wake_threads_waitq+0x50/0x50 >> Jul 8 07:44:53 box3 kernel: [] ? kthread+0x85/0x90 >> Jul 8 07:44:53 box3 kernel: [] ? >> kernel_thread_helper+0x4/0x10 >> Jul 8 07:44:53 box3 kernel: [] ? >> kthread_freezable_should_stop+0x50/0x50 >> Jul 8 07:44:53 box3 kernel: [] ? gs_change+0xb/0xb >> Jul 8 07:44:53 box3 kernel: handlers: >> Jul 8 07:44:53 box3 kernel: [] >> irq_default_primary_handler threaded [] usb_hcd_irq >> Jul 8 07:44:53 box3 kernel: [] >> irq_default_primary_handler threaded [] usb_hcd_irq >> Jul 8 07:44:53 box3 kernel: [] >> irq_default_primary_handler threaded [] usb_hcd_irq >> Jul 8 07:44:53 box3 kernel: Disabling IRQ #18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 0 has error -114 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 1 has error -18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 2 has error -18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 3 has error -18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 4 has error -18 >> Jul 8 07:44:53 box3 kernel: pwc: Iso frame 5 has error -18 >> (etc; many more of the pwc messages) >> >> Kind regards, >> Udo > > ... and, with apparently the same mainboard: Over here: Manufacturer: Gigabyte Technology Co., Ltd. Product Name: GA-MA770-DS3 >> Motherboard is Gigabyte GA-990XA-UD3 >> CPU is AMD Bulldozer 6 Core version AMD 9550 4 core in my case, i.e.: less new. pwc driver is the main user for a webcam on USB. >> I'll attach the 2 dmesg logs, one from 3.2 and other from 3.4, >> hopefully someone can see what's wrong, there is a suggestion to boot >> with irqpoll, but really wanted someone's opinion on this. Any ideas why the IRQ stops working? Udo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
