17 Jun
2014
17 Jun
'14
8:07 p.m.
Dear List,
I have a strange and unreproducable error on my laptop, that halts the
entire audio system randomly about once every three weeks.
Jackd quits, with it all clients, and dmesg says:
[21684.947293] irq 19: nobody cared (try booting with the "irqpoll"option)
[21684.947303] Pid: 194, comm: irq/19-ehci_hcd Not tainted 3.2.0-4-rt-amd64 #1 Debian
3.2.54-2
[21684.947309] Call Trace:
[21684.947327] [<ffffffff81098889>] ? __report_bad_irq+0x2c/0xb5
[21684.947336] [<ffffffff81098c6d>] ? note_interrupt+0x16f/0x1f2
[21684.947344] [<ffffffff81097969>] ? irq_thread_fn+0x32/0x32
[21684.947351] [<ffffffff81097969>] ? irq_thread_fn+0x32/0x32
[21684.947358] [<ffffffff8109783c>] ? irq_thread+0x106/0x201
[21684.947367] [<ffffffff81097736>] ? irq_finalize_oneshot+0xb3/0xb3
[21684.947378] [<ffffffff81062ee4>] ? kthread+0x78/0x80
[21684.947385] [<ffffffff8103f2fa>] ? get_parent_ip+0x9/0x1b
[21684.947395] [<ffffffff8136a0f4>] ? kernel_thread_helper+0x4/0x10
[21684.947405] [<ffffffff81062e6c>] ? rcu_read_unlock_sched_notrace+0x2a/0x2a
[21684.947412] [<ffffffff8136a0f0>] ? gs_change+0x13/0x13
[21684.947417] handlers:
[21684.947429] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa003d483>] usb_hcd_irq
[21684.947473] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa025a85a>] ips_irq_handler
[21684.947485] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa04d62cd>] snd_hdsp_interrupt
[21684.947498] Disabling IRQ #19
The sound card is an RME Multiface via an ExpressCard in a Thinkpad
X201s. The card itself had been working reliably since more than ten
years by now (not with the ExpressCard though). Running on Debian RT
Kernel.
I have no way to set/change the IRQ assignments in this BIOS.
Interrupt 19 is shared by modules ehci_hcd:usb2, ips, snd_hdsp,
where the two others are USB and the thermal subsystem.
I assume ehci_hcd:usb2 denotes the second USB bus. If this is correct,
there are no devices connected to it at the moment, according to lsusb
(except for USB hubs).
Web research has shown that people suggest using the kernel option
"irqpoll" or disable "threadirqs", use "noirqdebug" or
"irqdebug" options
(apparently quite expensive in computation), or the irqbalance
package.
https://bbs.archlinux.org/viewtopic.php?id=133327 gives a hint about
deinstalling laptop-mode-tools, which I am running, and which made the
problem go away for the poster.
As the error occurs so infrequently, I can not yet verify if any of
these help, and am hoping for some hints or experience from this list.
Please, any help or ideas are desperately needed, as this is a
production system that is used in live shows in front of large
audiences, and I absolutely need to resolve that error.
Thank you for all ideas,
best, Peter
17 Jun
17 Jun
8:49 p.m.
On 06/17/2014 08:06 PM, Peter P. wrote:
Dear List,
I have a strange and unreproducable error on my laptop, that halts the
entire audio system randomly about once every three weeks.
Jackd quits, with it all clients, and dmesg says:
[21684.947293] irq 19: nobody cared (try booting with the "irqpoll"option)
[21684.947303] Pid: 194, comm: irq/19-ehci_hcd Not tainted 3.2.0-4-rt-amd64 #1 Debian
3.2.54-2
[21684.947309] Call Trace:
[21684.947327] [<ffffffff81098889>] ? __report_bad_irq+0x2c/0xb5
[21684.947336] [<ffffffff81098c6d>] ? note_interrupt+0x16f/0x1f2
[21684.947344] [<ffffffff81097969>] ? irq_thread_fn+0x32/0x32
[21684.947351] [<ffffffff81097969>] ? irq_thread_fn+0x32/0x32
[21684.947358] [<ffffffff8109783c>] ? irq_thread+0x106/0x201
[21684.947367] [<ffffffff81097736>] ? irq_finalize_oneshot+0xb3/0xb3
[21684.947378] [<ffffffff81062ee4>] ? kthread+0x78/0x80
[21684.947385] [<ffffffff8103f2fa>] ? get_parent_ip+0x9/0x1b
[21684.947395] [<ffffffff8136a0f4>] ? kernel_thread_helper+0x4/0x10
[21684.947405] [<ffffffff81062e6c>] ? rcu_read_unlock_sched_notrace+0x2a/0x2a
[21684.947412] [<ffffffff8136a0f0>] ? gs_change+0x13/0x13
[21684.947417] handlers:
[21684.947429] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa003d483>] usb_hcd_irq
[21684.947473] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa025a85a>] ips_irq_handler
[21684.947485] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa04d62cd>] snd_hdsp_interrupt
[21684.947498] Disabling IRQ #19
The sound card is an RME Multiface via an ExpressCard in a Thinkpad
X201s. The card itself had been working reliably since more than ten
years by now (not with the ExpressCard though). Running on Debian RT
Kernel.
I have no way to set/change the IRQ assignments in this BIOS.
Interrupt 19 is shared by modules ehci_hcd:usb2, ips, snd_hdsp,
where the two others are USB and the thermal subsystem.
I assume ehci_hcd:usb2 denotes the second USB bus. If this is correct,
there are no devices connected to it at the moment, according to lsusb
(except for USB hubs).
Web research has shown that people suggest using the kernel option
"irqpoll" or disable "threadirqs", use "noirqdebug" or
"irqdebug" options
(apparently quite expensive in computation), or the irqbalance
package.
https://bbs.archlinux.org/viewtopic.php?id=133327 gives a hint about
deinstalling laptop-mode-tools, which I am running, and which made the
problem go away for the poster.
As the error occurs so infrequently, I can not yet verify if any of
these help, and am hoping for some hints or experience from this list.
Please, any help or ideas are desperately needed, as this is a
production system that is used in live shows in front of large
audiences, and I absolutely need to resolve that error.
Thank you for all ideas,
best, Peter
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
You are not alone with this issue,
I tried to work around this on different hardware by turning off the
devices that share the IRQ in BIOS. I suppose that's not a good idea or
even impossible with the thermal subsystem, but it _seems_ to work on my
system. In my case there was (probably) a USB device causing problems,
but due to the dodgy nature of the problem, I could not reproduce it or
verify a working solution.
As a note, I was also using Kernel 3.2. maybe more recent Kernel
versions don't have this issue?
Can you trigger the Problem somehow? Maybe by connecting and
disconnecting USB devices?
If you try to reproduce this, please take notes on what you are doing
and how.
Greetings
Markus
9:42 p.m.
On Tue, 2014-06-17 at 20:49 +0200, Markus Seeber wrote:
On 06/17/2014 08:06 PM, Peter P. wrote:
> I have no way to set/change the IRQ assignments in this BIOS.
> Interrupt 19 is shared by modules ehci_hcd:usb2, ips, snd_hdsp,
> where the two others are USB and the thermal subsystem.
> I assume ehci_hcd:usb2 denotes the second USB bus. If this is correct,
> there are no devices connected to it at the moment, according to lsusb
> (except for USB hubs).
You are not alone with this issue,
I tried to work around this on different hardware by turning off the
devices that share the IRQ in BIOS.
It's also possible to unbind devices by command line. On my machine the
BIOS is useless too.
Assumed the links mentioned in my script are still available, one of the
scripts describes how to unbind a device.
[rocketmouse@archlinux ~]$ cat /usr/local/sbin/tuning
#!/bin/bash
[snip]
### http://www.mythtv.org/wiki/PCI_Latency
### http://wiki.linuxmusicians.com/doku.php?id=system_configuration#pci_bus_lat…
[snip]
### Unbinding devices
echo -n "0000:00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind
echo -n "0000:00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind
[snip]
exit 0
9:53 p.m.
On Tue, 2014-06-17 at 21:42 +0200, Ralf Mardorf wrote:
On Tue, 2014-06-17 at 20:49 +0200, Markus Seeber
wrote:
^^^^^^^ links ;)
It's this link and it's still available. Take a look at the "Solve IRQ
conflicts by unbinding devices" section of the link.
On 06/17/2014 08:06 PM, Peter P. wrote:
> I have no way to set/change the IRQ assignments in this BIOS.
> Interrupt 19 is shared by modules ehci_hcd:usb2, ips, snd_hdsp,
> where the two others are USB and the thermal subsystem.
> I assume ehci_hcd:usb2 denotes the second USB bus. If this is correct,
> there are no devices connected to it at the moment, according to lsusb
> (except for USB hubs).
You are not alone with this issue,
I tried to work around this on different hardware by turning off the
devices that share the IRQ in BIOS.
It's also possible to unbind devices by command line. On my machine the
BIOS is useless too.
Assumed the links mentioned in my script are still available, one of the
scripts describes how to unbind a device.
10:12 p.m.
On Tue, 2014-06-17 at 21:53 +0200, Ralf Mardorf wrote:
On Tue, 2014-06-17 at 21:42 +0200, Ralf Mardorf
wrote:
Two replies to myself, to help others, are allowed? :D
JFTR, if you unbind USB slots for a tower PC mobo you likely could get
other USB slots by spending less money:
http://www.reichelt.de/AK-666/3/index.html?&ACTION=3&LA=446&ART…
http://www.reichelt.de/AK-674-2/3/index.html?&ACTION=3&LA=446&A…
On Tue, 2014-06-17 at 20:49 +0200, Markus Seeber
wrote:
^^^^^^^ links ;)
It's this link and it's still available. Take a look at the "Solve IRQ
conflicts by unbinding devices" section of the link. On 06/17/2014 08:06 PM, Peter P. wrote:
> I have no way to set/change the IRQ assignments in this BIOS.
> Interrupt 19 is shared by modules ehci_hcd:usb2, ips, snd_hdsp,
> where the two others are USB and the thermal subsystem.
> I assume ehci_hcd:usb2 denotes the second USB bus. If this is correct,
> there are no devices connected to it at the moment, according to lsusb
> (except for USB hubs).
You are not alone with this issue,
I tried to work around this on different hardware by turning off the
devices that share the IRQ in BIOS.
It's also possible to unbind devices by command line. On my machine the
BIOS is useless too.
Assumed the links mentioned in my script are still available, one of the
scripts describes how to unbind a device.
4 Sep
4 Sep
4:24 p.m.
(This is an update to an older thread)
* Markus Seeber <markus.seeber(a)spectralbird.de> [2014-06-17 14:50]:
On 06/17/2014 08:06 PM, Peter P. wrote:
> Dear List,
>
> I have a strange and unreproducable error on my laptop, that halts the
> entire audio system randomly about once every three weeks.
>
> Jackd quits, with it all clients, and dmesg says:
>
> [21684.947293] irq 19: nobody cared (try booting with the "irqpoll"option)
> [21684.947303] Pid: 194, comm: irq/19-ehci_hcd Not tainted 3.2.0-4-rt-amd64 #1
Debian 3.2.54-2
> [21684.947309] Call Trace:
> [21684.947327] [<ffffffff81098889>] ? __report_bad_irq+0x2c/0xb5
> [21684.947336] [<ffffffff81098c6d>] ? note_interrupt+0x16f/0x1f2
> [21684.947344] [<ffffffff81097969>] ? irq_thread_fn+0x32/0x32
> [21684.947351] [<ffffffff81097969>] ? irq_thread_fn+0x32/0x32
> [21684.947358] [<ffffffff8109783c>] ? irq_thread+0x106/0x201
> [21684.947367] [<ffffffff81097736>] ? irq_finalize_oneshot+0xb3/0xb3
> [21684.947378] [<ffffffff81062ee4>] ? kthread+0x78/0x80
> [21684.947385] [<ffffffff8103f2fa>] ? get_parent_ip+0x9/0x1b
> [21684.947395] [<ffffffff8136a0f4>] ? kernel_thread_helper+0x4/0x10
> [21684.947405] [<ffffffff81062e6c>] ?
rcu_read_unlock_sched_notrace+0x2a/0x2a
> [21684.947412] [<ffffffff8136a0f0>] ? gs_change+0x13/0x13
> [21684.947417] handlers:
> [21684.947429] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa003d483>] usb_hcd_irq
> [21684.947473] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa025a85a>] ips_irq_handler
> [21684.947485] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa04d62cd>] snd_hdsp_interrupt
> [21684.947498] Disabling IRQ #19
>
[...]
You are not alone with this issue,
I tried to work around this on different hardware by turning off the
devices that share the IRQ in BIOS. I suppose that's not a good idea or
even impossible with the thermal subsystem, but it _seems_ to work on my
system. In my case there was (probably) a USB device causing problems,
but due to the dodgy nature of the problem, I could not reproduce it or
verify a working solution.
As a note, I was also using Kernel 3.2. maybe more recent Kernel
versions don't have this issue?
Running 3.14-2-rt-amd64 on Debian here since a
few weeks and the above
exception did not occur so far (knock-on-wood) again.
P
5:53 p.m.
On Thu, 4 Sep 2014 10:24:09 -0400
"Peter P." <p8rpp(a)aol.com> wrote:
(This is an update to an older thread)
* Markus Seeber <markus.seeber(a)spectralbird.de> [2014-06-17 14:50]:
For what it's worth, I found Kernel 3.2 far less reliable than 3.1 in all
sorts of ways, but can't seem to get 3.1 now from debian :(
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
On 06/17/2014 08:06 PM, Peter P. wrote:
> Dear List,
>
> I have a strange and unreproducable error on my laptop, that halts the
> entire audio system randomly about once every three weeks.
>
> Jackd quits, with it all clients, and dmesg says:
>
> [21684.947293] irq 19: nobody cared (try booting with the "irqpoll"option)
> [21684.947303] Pid: 194, comm: irq/19-ehci_hcd Not tainted 3.2.0-4-rt-amd64 #1
Debian 3.2.54-2
> [21684.947309] Call Trace:
> [21684.947327] [<ffffffff81098889>] ? __report_bad_irq+0x2c/0xb5
> [21684.947336] [<ffffffff81098c6d>] ? note_interrupt+0x16f/0x1f2
> [21684.947344] [<ffffffff81097969>] ? irq_thread_fn+0x32/0x32
> [21684.947351] [<ffffffff81097969>] ? irq_thread_fn+0x32/0x32
> [21684.947358] [<ffffffff8109783c>] ? irq_thread+0x106/0x201
> [21684.947367] [<ffffffff81097736>] ? irq_finalize_oneshot+0xb3/0xb3
> [21684.947378] [<ffffffff81062ee4>] ? kthread+0x78/0x80
> [21684.947385] [<ffffffff8103f2fa>] ? get_parent_ip+0x9/0x1b
> [21684.947395] [<ffffffff8136a0f4>] ? kernel_thread_helper+0x4/0x10
> [21684.947405] [<ffffffff81062e6c>] ?
rcu_read_unlock_sched_notrace+0x2a/0x2a
> [21684.947412] [<ffffffff8136a0f0>] ? gs_change+0x13/0x13
> [21684.947417] handlers:
> [21684.947429] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa003d483>] usb_hcd_irq
> [21684.947473] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa025a85a>] ips_irq_handler
> [21684.947485] [<ffffffff81096e34>] irq_default_primary_handler threaded
[<ffffffffa04d62cd>] snd_hdsp_interrupt
> [21684.947498] Disabling IRQ #19
>
[...]
You are not alone with this issue,
I tried to work around this on different hardware by turning off the
devices that share the IRQ in BIOS. I suppose that's not a good idea or
even impossible with the thermal subsystem, but it _seems_ to work on my
system. In my case there was (probably) a USB device causing problems,
but due to the dodgy nature of the problem, I could not reproduce it or
verify a working solution.
As a note, I was also using Kernel 3.2. maybe more recent Kernel
versions don't have this issue?
Running 3.14-2-rt-amd64 on Debian here since a
few weeks and the above
exception did not occur so far (knock-on-wood) again.
P
3734
days inactive
3813
days old
linux-audio-user@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Markus Seeber -
Peter P. -
Ralf Mardorf -
Will Godfrey