I just got the following in dmesg a few minutes after booting my
notebook which was idle at the time this occurred. This was with
2.6.25-rc6 but I've seen the same with 2.6.22 (see the attached
dmesg from 2.6.22).
irq 19: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Not tainted 2.6.25-rc6-amd64 #1
Call Trace:
<IRQ> [<ffffffff80271c0b>] __report_bad_irq+0x38/0x7c
[<ffffffff80271e51>] note_interrupt+0x202/0x249
[<ffffffff8027274e>] handle_fasteoi_irq+0xab/0xd0
[<ffffffff8020f82c>] do_IRQ+0x6e/0xda
[<ffffffff8020c65d>] ret_from_intr+0x0/0x19
<EOI> [<ffffffff80221831>] ? native_irq_enable+0x6/0x7
[<ffffffff88006330>] ? :processor:acpi_idle_enter_bm+0x2ab/0x325
[<ffffffff803b5ef3>] ? menu_select+0x70/0x99
[<ffffffff803b52e1>] ? cpuidle_idle_call+0x77/0xa6
[<ffffffff803b526a>] ? cpuidle_idle_call+0x0/0xa6
[<ffffffff8020b187>] ? cpu_idle+0xb1/0xdb
[<ffffffff8042ea16>] ? rest_init+0x5a/0x5c
handlers:
[<ffffffff8806f0f5>] (irq_handler+0x0/0x207 [firewire_ohci])
Disabling IRQ #19
tbm@loric-alpo:~$ lspci
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HBM (ICH8M-E) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
02:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
02:06.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
02:06.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
02:06.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 11)
10:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
--
Martin Michlmayr
http://www.cyrius.com/
Martin Michlmayr wrote:
> I just got the following in dmesg a few minutes after booting my
> notebook which was idle at the time this occurred. This was with
> 2.6.25-rc6 but I've seen the same with 2.6.22 (see the attached
> dmesg from 2.6.22).
>
> irq 19: nobody cared (try booting with the "irqpoll" option)
> Pid: 0, comm: swapper Not tainted 2.6.25-rc6-amd64 #1
>
> Call Trace:
> <IRQ> [<ffffffff80271c0b>] __report_bad_irq+0x38/0x7c
> [<ffffffff80271e51>] note_interrupt+0x202/0x249
> [<ffffffff8027274e>] handle_fasteoi_irq+0xab/0xd0
> [<ffffffff8020f82c>] do_IRQ+0x6e/0xda
> [<ffffffff8020c65d>] ret_from_intr+0x0/0x19
> <EOI> [<ffffffff80221831>] ? native_irq_enable+0x6/0x7
> [<ffffffff88006330>] ? :processor:acpi_idle_enter_bm+0x2ab/0x325
> [<ffffffff803b5ef3>] ? menu_select+0x70/0x99
> [<ffffffff803b52e1>] ? cpuidle_idle_call+0x77/0xa6
> [<ffffffff803b526a>] ? cpuidle_idle_call+0x0/0xa6
> [<ffffffff8020b187>] ? cpu_idle+0xb1/0xdb
> [<ffffffff8042ea16>] ? rest_init+0x5a/0x5c
>
> handlers:
> [<ffffffff8806f0f5>] (irq_handler+0x0/0x207 [firewire_ohci])
> Disabling IRQ #19
...
> 02:06.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
...
According to your 2.6.22 dmesg, this happens a while after the firewire
subsystem seemingly successfully initialized the controller. Could you
please post "dmesg | grep firewire" from 2.6.25-rc6 though?
The __report_bad_irq() and "Disabling IRQ #..." can only have happened
because this condition in fw-ohci.c::irq_handler()
event = reg_read(ohci, OHCI1394_IntEventClear);
if (!event || !~event)
return IRQ_NONE;
happened a lot of times. This means either
- Some MMIO reads return bogus values (all zero or all ones in a
bitfield which should be sparsely populated in a proper interrupt
event),
or
- the interrupt was misrouted by the kernel's IRQ infrastructure was
unable to detect the misrouting, AFAIU.
--
Stefan Richter
-=====-==--- --== =-=-=
http://arcgraph.de/sr/
* Stefan Richter <[email protected]> [2008-03-21 17:31]:
> According to your 2.6.22 dmesg, this happens a while after the firewire
> subsystem seemingly successfully initialized the controller. Could you
> please post "dmesg | grep firewire" from 2.6.25-rc6 though?
firewire_ohci: Added fw-ohci device 0000:02:06.1, OHCI version 1.10
firewire_core: created device fw0: GUID 001b249929010210, S400
I've also attached the complete dmesg from 2.6.25-rc6.
--
Martin Michlmayr
http://www.cyrius.com/
I wrote on 2008-03-21:
> Martin Michlmayr wrote:
>> I just got the following in dmesg a few minutes after booting my
>> notebook which was idle at the time this occurred. This was with
>> 2.6.25-rc6 but I've seen the same with 2.6.22 (see the attached
>> dmesg from 2.6.22).
>>
>> irq 19: nobody cared (try booting with the "irqpoll" option)
>> Pid: 0, comm: swapper Not tainted 2.6.25-rc6-amd64 #1
>>
>> Call Trace:
>> <IRQ> [<ffffffff80271c0b>] __report_bad_irq+0x38/0x7c
>> [<ffffffff80271e51>] note_interrupt+0x202/0x249
>> [<ffffffff8027274e>] handle_fasteoi_irq+0xab/0xd0
>> [<ffffffff8020f82c>] do_IRQ+0x6e/0xda
>> [<ffffffff8020c65d>] ret_from_intr+0x0/0x19
>> <EOI> [<ffffffff80221831>] ? native_irq_enable+0x6/0x7
>> [<ffffffff88006330>] ? :processor:acpi_idle_enter_bm+0x2ab/0x325
>> [<ffffffff803b5ef3>] ? menu_select+0x70/0x99
>> [<ffffffff803b52e1>] ? cpuidle_idle_call+0x77/0xa6
>> [<ffffffff803b526a>] ? cpuidle_idle_call+0x0/0xa6
>> [<ffffffff8020b187>] ? cpu_idle+0xb1/0xdb
>> [<ffffffff8042ea16>] ? rest_init+0x5a/0x5c
>>
>> handlers:
>> [<ffffffff8806f0f5>] (irq_handler+0x0/0x207 [firewire_ohci])
>> Disabling IRQ #19
> ...
>> 02:06.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
>> (rev 04)
> ...
>
> According to your 2.6.22 dmesg, this happens a while after the firewire
> subsystem seemingly successfully initialized the controller. Could you
> please post "dmesg | grep firewire" from 2.6.25-rc6 though?
[According to Martin's answer on 2008-03-22, the initialization of
firewire-ohci also succeeds without noticeable problem under 2.6.25-rc6.]
> The __report_bad_irq() and "Disabling IRQ #..." can only have happened
> because this condition in fw-ohci.c::irq_handler()
>
> event = reg_read(ohci, OHCI1394_IntEventClear);
>
> if (!event || !~event)
> return IRQ_NONE;
>
> happened a lot of times. This means either
> - Some MMIO reads return bogus values (all zero or all ones in a
> bitfield which should be sparsely populated in a proper interrupt
> event),
> or
> - the interrupt was misrouted by the kernel's IRQ infrastructure was
> unable to detect the misrouting, AFAIU.
Martin, please check whether the same happens if you disable
firewire-ohci in the kernel config (or blacklist it in the modprobe
config) and use the ohci1394 driver instead.
Thanks, and sorry for replying so late,
--
Stefan Richter
-=====-==--- --== ====-
http://arcgraph.de/sr/
* Stefan Richter <[email protected]> [2008-03-30 13:11]:
> Martin, please check whether the same happens if you disable firewire-ohci
> in the kernel config (or blacklist it in the modprobe config) and use the
> ohci1394 driver instead.
Yes, I get essentially the same message with the ohci1394 driver:
[ 895.455783] irq 19: nobody cared (try booting with the "irqpoll" option)
[ 895.455783] Pid: 0, comm: swapper Not tainted 2.6.25-rc7-amd64 #1
[ 895.455783]
[ 895.455783] Call Trace:
[ 895.455783] <IRQ> [<ffffffff88078155>] :ohci1394:ohci_irq_handler+0x4b/0x76e
[ 895.455783] [<ffffffff8026c883>] __report_bad_irq+0x30/0x72
[ 895.455783] [<ffffffff8026cac2>] note_interrupt+0x1fd/0x23f
[ 895.455783] [<ffffffff8026d34f>] handle_fasteoi_irq+0xa5/0xc8
[ 895.455783] [<ffffffff8020f53c>] do_IRQ+0x6d/0xd9
[ 895.455783] [<ffffffff8020c46d>] ret_from_intr+0x0/0x19
[ 895.455783] <EOI> [<ffffffff803a25a4>] menu_reflect+0x0/0x75
[ 895.455783] [<ffffffff8800642b>] :processor:acpi_idle_enter_simple+0x18d/0x1fe
[ 895.455783] [<ffffffff803a1b2b>] cpuidle_idle_call+0x7a/0xb3
[ 895.455783] [<ffffffff803a1ab1>] cpuidle_idle_call+0x0/0xb3
[ 895.455783] [<ffffffff8020b06c>] cpu_idle+0xa9/0xd3
[ 895.455783]
[ 895.455783] handlers:
[ 895.455783] [<ffffffff8807810a>] (ohci_irq_handler+0x0/0x76e [ohci1394])
[ 895.455783] Disabling IRQ #19
dmesg is attached.
--
Martin Michlmayr
http://www.cyrius.com/
Martin Michlmayr wrote:
> * Stefan Richter <[email protected]> [2008-03-30 13:11]:
>> Martin, please check whether the same happens if you disable firewire-ohci
>> in the kernel config (or blacklist it in the modprobe config) and use the
>> ohci1394 driver instead.
>
> Yes, I get essentially the same message with the ohci1394 driver:
>
> [ 895.455783] irq 19: nobody cared (try booting with the "irqpoll" option)
> [ 895.455783] Pid: 0, comm: swapper Not tainted 2.6.25-rc7-amd64 #1
> [ 895.455783]
> [ 895.455783] Call Trace:
> [ 895.455783] <IRQ> [<ffffffff88078155>] :ohci1394:ohci_irq_handler+0x4b/0x76e
> [ 895.455783] [<ffffffff8026c883>] __report_bad_irq+0x30/0x72
> [ 895.455783] [<ffffffff8026cac2>] note_interrupt+0x1fd/0x23f
> [ 895.455783] [<ffffffff8026d34f>] handle_fasteoi_irq+0xa5/0xc8
> [ 895.455783] [<ffffffff8020f53c>] do_IRQ+0x6d/0xd9
> [ 895.455783] [<ffffffff8020c46d>] ret_from_intr+0x0/0x19
> [ 895.455783] <EOI> [<ffffffff803a25a4>] menu_reflect+0x0/0x75
> [ 895.455783] [<ffffffff8800642b>] :processor:acpi_idle_enter_simple+0x18d/0x1fe
> [ 895.455783] [<ffffffff803a1b2b>] cpuidle_idle_call+0x7a/0xb3
> [ 895.455783] [<ffffffff803a1ab1>] cpuidle_idle_call+0x0/0xb3
> [ 895.455783] [<ffffffff8020b06c>] cpu_idle+0xa9/0xd3
> [ 895.455783]
> [ 895.455783] handlers:
> [ 895.455783] [<ffffffff8807810a>] (ohci_irq_handler+0x0/0x76e [ohci1394])
> [ 895.455783] Disabling IRQ #19
>
> dmesg is attached.
>
Thanks.
I tend to believe it is a problem to be addressed in the x86 platform
support, not a driver problem.
I Cc'd some random x86 folk... To rehash the issue:
- Controller: Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
Board: PM965/GM965/GL960 based
The R5C832 is known to work with ohci1394 according to
http://hardware4linux.info/component/14348/ and other reports.
- Martin also saw it happen with Linux 2.6.22.
- firewire-ohci + firewire-core as well as ohci1394 + ieee1394
appear to initialize the controller on Martin's laptop just fine.
Among else this means that a number of register reads and writes
succeed.
- Some time later, without having actually used the FireWire
controller, "irq 19: nobody cared"/ "Disabling IRQ #19" occurs.
AFAIU the code, this is apparently because firewire-ohci's or
ohci1394's IRQ handler was called repeatedly but got either 0 or ~0
when reading the chip's interrupt event register.
--
Stefan Richter
-=====-==--- --== ====-
http://arcgraph.de/sr/
On Sun, 30 Mar 2008, Stefan Richter wrote:
> I tend to believe it is a problem to be addressed in the x86 platform support,
> not a driver problem.
Depends. It might be unfixable.
> I Cc'd some random x86 folk... To rehash the issue:
>
> - Controller: Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
> Board: PM965/GM965/GL960 based
> The R5C832 is known to work with ohci1394 according to
> http://hardware4linux.info/component/14348/ and other reports.
>
> - Martin also saw it happen with Linux 2.6.22.
>
> - firewire-ohci + firewire-core as well as ohci1394 + ieee1394
> appear to initialize the controller on Martin's laptop just fine.
> Among else this means that a number of register reads and writes
> succeed.
>
> - Some time later, without having actually used the FireWire
> controller, "irq 19: nobody cared"/ "Disabling IRQ #19" occurs.
> AFAIU the code, this is apparently because firewire-ohci's or
> ohci1394's IRQ handler was called repeatedly but got either 0 or ~0
> when reading the chip's interrupt event register.
Can we please have a full boot log (dmesg) and the output of /proc/interrupts and "lspci -vvv"
Thanks,
tglx
On Sunday 30 March 2008 01:40:45 pm Stefan Richter wrote:
> Martin Michlmayr wrote:
> > * Stefan Richter <[email protected]> [2008-03-30 13:11]:
> >> Martin, please check whether the same happens if you disable
> >> firewire-ohci in the kernel config (or blacklist it in the modprobe
> >> config) and use the ohci1394 driver instead.
> >
> > Yes, I get essentially the same message with the ohci1394 driver:
> >
> > [ 895.455783] irq 19: nobody cared (try booting with the "irqpoll"
> > option) [ 895.455783] Pid: 0, comm: swapper Not tainted 2.6.25-rc7-amd64
> > #1 [ 895.455783]
> > [ 895.455783] Call Trace:
> > [ 895.455783] <IRQ> [<ffffffff88078155>]
> > :ohci1394:ohci_irq_handler+0x4b/0x76e [ 895.455783]
> > [<ffffffff8026c883>] __report_bad_irq+0x30/0x72
> > [ 895.455783] [<ffffffff8026cac2>] note_interrupt+0x1fd/0x23f
> > [ 895.455783] [<ffffffff8026d34f>] handle_fasteoi_irq+0xa5/0xc8
> > [ 895.455783] [<ffffffff8020f53c>] do_IRQ+0x6d/0xd9
> > [ 895.455783] [<ffffffff8020c46d>] ret_from_intr+0x0/0x19
> > [ 895.455783] <EOI> [<ffffffff803a25a4>] menu_reflect+0x0/0x75
> > [ 895.455783] [<ffffffff8800642b>]
> > :processor:acpi_idle_enter_simple+0x18d/0x1fe [ 895.455783]
> > [<ffffffff803a1b2b>] cpuidle_idle_call+0x7a/0xb3 [ 895.455783]
> > [<ffffffff803a1ab1>] cpuidle_idle_call+0x0/0xb3
> > [ 895.455783] [<ffffffff8020b06c>] cpu_idle+0xa9/0xd3
> > [ 895.455783]
> > [ 895.455783] handlers:
> > [ 895.455783] [<ffffffff8807810a>] (ohci_irq_handler+0x0/0x76e
> > [ohci1394]) [ 895.455783] Disabling IRQ #19
> >
> > dmesg is attached.
>
> Thanks.
>
> I tend to believe it is a problem to be addressed in the x86 platform
> support, not a driver problem.
>
> I Cc'd some random x86 folk... To rehash the issue:
>
> - Controller: Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
> Board: PM965/GM965/GL960 based
> The R5C832 is known to work with ohci1394 according to
> http://hardware4linux.info/component/14348/ and other reports.
Its also known to work with the juju firewire stack -- that's the controller
in my own laptop, as well as a few other folks here in the office, all
running the new stack.
--
Jarod Wilson
[email protected]
* Thomas Gleixner <[email protected]> [2008-03-30 22:10]:
> Can we please have a full boot log (dmesg) and the output of /proc/interrupts and "lspci -vvv"
I've attached all of that information.
--
Martin Michlmayr
http://www.cyrius.com/
On Mon, 31 Mar 2008, Martin Michlmayr wrote:
> * Thomas Gleixner <[email protected]> [2008-03-30 22:10]:
> > Can we please have a full boot log (dmesg) and the output of /proc/interrupts and "lspci -vvv"
>
> I've attached all of that information.
Do you have CONFIG_NET_POLL_CONTROLLER enabled in your .config ? If
yes, can you please disable it and check whether the problem persists ?
Thanks,
tglx
On Sun, 30 Mar 2008, Jarod Wilson wrote:
> > I tend to believe it is a problem to be addressed in the x86 platform
> > support, not a driver problem.
> >
> > I Cc'd some random x86 folk... To rehash the issue:
> >
> > - Controller: Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
> > Board: PM965/GM965/GL960 based
> > The R5C832 is known to work with ohci1394 according to
> > http://hardware4linux.info/component/14348/ and other reports.
>
> Its also known to work with the juju firewire stack -- that's the controller
> in my own laptop, as well as a few other folks here in the office, all
> running the new stack.
Hmm, can you please check whether you can reproduce the problem with
the original stack ?
Thanks,
tglx
* Thomas Gleixner <[email protected]> [2008-03-31 12:19]:
> > > Board: PM965/GM965/GL960 based
> > > The R5C832 is known to work with ohci1394 according to
> > > http://hardware4linux.info/component/14348/ and other reports.
> >
> > Its also known to work with the juju firewire stack -- that's the controller
> > in my own laptop, as well as a few other folks here in the office, all
> > running the new stack.
>
> Hmm, can you please check whether you can reproduce the problem with
> the original stack ?
I get virtually the same message with the old and new stack.
--
Martin Michlmayr
http://www.cyrius.com/
Martin Michlmayr wrote:
> * Thomas Gleixner <[email protected]> [2008-03-31 12:19]:
>> > > Board: PM965/GM965/GL960 based
>> > > The R5C832 is known to work with ohci1394 according to
>> > > http://hardware4linux.info/component/14348/ and other reports.
>> >
>> > Its also known to work with the juju firewire stack -- that's the controller
>> > in my own laptop, as well as a few other folks here in the office, all
>> > running the new stack.
>>
>> Hmm, can you please check whether you can reproduce the problem with
>> the original stack ?
>
> I get virtually the same message with the old and new stack.
I can confirm that what Martin previously posted in this thread shows
that firewire-ohci + firewire-core and ohci1394 + ieee1394 fail in the
same way:
- All MMIO reads and writes leading up to chip initialization works,
- first "self ID complete" interrupt and corresponding MMIO reads and
DMAs work and lead up to recognition of the local node by the
firewire/1394 mid layer,
- a while later the IRQ is disabled with "nobody cared".
IRQ handlers are drivers/firewire/fw-ohci.c::irq_handler() and
drivers/ieee1394/ohci1394.c::ohci_irq_handler(). Both return IRQ_NONE
if readl() on the register which contains the interrupt event type
returns 0 or ~0, which both are impossible values _if_ the chip
generated the interrupt _and_ MMIO reads work.
--
Stefan Richter
-=====-==--- --== =====
http://arcgraph.de/sr/
I wrote:
> I can confirm that what Martin previously posted in this thread shows
> that firewire-ohci + firewire-core and ohci1394 + ieee1394 fail in the
> same way
...by looking at his dmesg's. I don't have affected hardware myself.
--
Stefan Richter
-=====-==--- --== =====
http://arcgraph.de/sr/
* Thomas Gleixner <[email protected]> [2008-03-31 12:17]:
> > I've attached all of that information.
>
> Do you have CONFIG_NET_POLL_CONTROLLER enabled in your .config ? If
> yes, can you please disable it and check whether the problem persists ?
CONFIG_NET_POLL_CONTROLLER was indeed set. When I disable it, the
problem goes away.
What does that mean?
--
Martin Michlmayr
http://www.cyrius.com/