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
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 cont
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
> >> pr
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
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 wha
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
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
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.
> kern
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. Tur
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
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
> >> control
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 hel
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 fi
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 ha
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
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 help
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
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 t
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
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/li
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 t
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 th
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
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
> pro
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:
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
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:716721730
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
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
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 t
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
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 htt
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
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 di
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
intr
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
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
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
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.or
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 c
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
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 -
>> ti
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.
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 DAT
44 matches
Mail list logo
