m68k: [v5] Convert to genirq (WIP)

m68k: [v5] Convert to genirq (WIP)

[Geert Uytterhoeven]

I rebased and updated my m68k-genirq branch at

git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git m68k-genirq
http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-genirq

[PATCH 01/24] ide-{cd,floppy,tape}, keyboard: Do not include <linux/irq.>
[PATCH 02/24] m68k/irq: Rename irq_controller to irq_chip
[PATCH 03/24] m68k/irq: Kill irq_node_t typedef, always use struct irq_node
[PATCH 04/24] m68k/irq: Rename irq_node to irq_data
[PATCH 05/24] m68k/irq: Switch irq_chip methods to "struct irq_data *data"
[PATCH 06/24] m68k/irq: Rename setup_irq() to m68k_setup_irq() and
make it static
[PATCH 07/24] m68k/irq: Extract irq_set_chip()
[PATCH 08/24] m68k/irq: Add m68k_setup_irq_controller()
[PATCH 09/24] m68k/irq: Rename {,__}m68k_handle_int()
[PATCH 10/24] m68k/irq: Remove obsolete IRQ_FLG_* definitions and users
[PATCH 11/24] m68k/irq: Add genirq support
[PATCH 12/24] m68k/atari: Convert Atari to genirq
[PATCH 13/24] m68k/atari: Remove code and comments about different irq types
[PATCH 14/24] m68k/amiga: Refactor amiints.c
[PATCH 15/24] m68k/amiga: Convert Amiga to genirq
[PATCH 16/24] m68k/amiga: Optimize interrupts using chain handlers
[PATCH 17/24] m68k/mac: Convert Mac to genirq
[PATCH 18/24] m68k/mac: Optimize interrupts using chain handlers
[PATCH 19/24] m68k/hp300: Convert HP9000/300 and HP9000/400 to genirq
[PATCH 20/24] m68k/vme: Convert VME to genirq
[PATCH 21/24] m68k/sun3: Use the kstat_irqs_cpu() wrapper
[PATCH 22/24] m68k/apollo: Convert Apollo to genirq
[PATCH 23/24] m68k/sun3: Convert Sun3/3x to genirq
[PATCH 24/24] m68k/q40: Convert Q40/Q60 to genirq

Changes:
  - [PATCH 11/24]: Keep m68k_setup_auto_interrupt(), it's still needed for Q40
  - [PATCH 18/24]: m68k/mac: Optimize interrupts using chain handlers (NEW)
  - [PATCH 24/24]: m68k/q40: Convert Q40/Q60 to genirq (NEW)

Todo:
 - Removal of legacy code inside #ifndef CONFIG_GENERIC_HARDIRQ,
 - Proper patch submission emails,
 - Get it merged (For 3.3? Or even 3.2?).

Oh, I almost forgot: testing ;-)! So far I tested it on Atari (ARAnyM)
and Amiga only.

Thanks for testing and feedback!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k: [v5] Convert to genirq (WIP)

[Finn Thain]

On Fri, 26 Aug 2011, Geert Uytterhoeven wrote:

> - [PATCH 18/24]: m68k/mac: Optimize interrupts using chain handlers (NEW)

That patch has a mistake --

	irq_set_chained_handler(IRQ_AUTO_4, psc_irq);
	irq_set_handler_data(IRQ_AUTO_3, (void *)0x40);
	irq_set_chained_handler(IRQ_AUTO_5, psc_irq);
	irq_set_handler_data(IRQ_AUTO_3, (void *)0x50);
	irq_set_chained_handler(IRQ_AUTO_6, psc_irq);
	irq_set_handler_data(IRQ_AUTO_3, (void *)0x60);

should be

	irq_set_chained_handler(IRQ_AUTO_4, psc_irq);
	irq_set_handler_data(IRQ_AUTO_4, (void *)0x40);
	irq_set_chained_handler(IRQ_AUTO_5, psc_irq);
	irq_set_handler_data(IRQ_AUTO_5, (void *)0x50);
	irq_set_chained_handler(IRQ_AUTO_6, psc_irq);
	irq_set_handler_data(IRQ_AUTO_6, (void *)0x60);

I also found that the mac_esp driver probe (when in PIO mode) locks up the 
machine. I worked around this by changing the 
disable_irq(IRQ_VIA2_3)/enable_irq(IRQ_VIA2_3) calls to 
local_irq_save/local_irq_restore, but this is not a good solution.

Apparently genirq doesn't permit nested disable_irq/enable_irq calls. But 
I haven't found any outer disable_irq/enable_irq pair yet, so I'm only 
guessing as to the cause of the problem. I'll keep looking.

On one VIA-based machine that I tested, !CONFIG_USE_GENERIC_HARDIRQS 
gives:

# cat /proc/interrupts
auto       1:       2299 via1
auto       2:       3876 via2
auto       4:        562 SCC
auto       7:          0 NMI
mac       10:        590 pmu-shift
mac       12:         90 pmu-clock
mac       14:       1635 timer
mac       17:       3876 nubus
mac       56:       3879 sonic

whereas, CONFIG_USE_GENERIC_HARDIRQS=y gives:

# cat /proc/interrupts
           CPU0       
  4:       5303      auto  SCC
  7:          0      auto  NMI
 10:       2136       mac  pmu-shift
 12:        607       mac  pmu-clock
 14:      41858       mac  timer
 56:      66876       mac  sonic
ERR:          0

Are there no counters for chained IRQs?

Other than these issues everything looks OK. I will test OSS and Baboon 
when I get the relevant hardware set up.

Finn

Re: m68k: [v5] Convert to genirq (WIP)

[Geert Uytterhoeven]

On Sun, Aug 28, 2011 at 04:08, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Fri, 26 Aug 2011, Geert Uytterhoeven wrote:
>> - [PATCH 18/24]: m68k/mac: Optimize interrupts using chain handlers (NEW)
>
> That patch has a mistake --
>
>        irq_set_chained_handler(IRQ_AUTO_4, psc_irq);
>        irq_set_handler_data(IRQ_AUTO_3, (void *)0x40);
>        irq_set_chained_handler(IRQ_AUTO_5, psc_irq);
>        irq_set_handler_data(IRQ_AUTO_3, (void *)0x50);
>        irq_set_chained_handler(IRQ_AUTO_6, psc_irq);
>        irq_set_handler_data(IRQ_AUTO_3, (void *)0x60);
>
> should be
>
>        irq_set_chained_handler(IRQ_AUTO_4, psc_irq);
>        irq_set_handler_data(IRQ_AUTO_4, (void *)0x40);
>        irq_set_chained_handler(IRQ_AUTO_5, psc_irq);
>        irq_set_handler_data(IRQ_AUTO_5, (void *)0x50);
>        irq_set_chained_handler(IRQ_AUTO_6, psc_irq);
>        irq_set_handler_data(IRQ_AUTO_6, (void *)0x60);

Woops, of course. Thanks!

> On one VIA-based machine that I tested, !CONFIG_USE_GENERIC_HARDIRQS
> gives:
>
> # cat /proc/interrupts
> auto       1:       2299 via1
> auto       2:       3876 via2
> auto       4:        562 SCC
> auto       7:          0 NMI
> mac       10:        590 pmu-shift
> mac       12:         90 pmu-clock
> mac       14:       1635 timer
> mac       17:       3876 nubus
> mac       56:       3879 sonic
>
> whereas, CONFIG_USE_GENERIC_HARDIRQS=y gives:
>
> # cat /proc/interrupts
>           CPU0
>  4:       5303      auto  SCC
>  7:          0      auto  NMI
>  10:       2136       mac  pmu-shift
>  12:        607       mac  pmu-clock
>  14:      41858       mac  timer
>  56:      66876       mac  sonic
> ERR:          0
>
> Are there no counters for chained IRQs?

I noticed the same for Amiga.

> Other than these issues everything looks OK. I will test OSS and Baboon
> when I get the relevant hardware set up.

Thanks again!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k: [v5] Convert to genirq (WIP)

[Geert Uytterhoeven]

On Sun, Aug 28, 2011 at 09:53, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sun, Aug 28, 2011 at 04:08, Finn Thain <fthain@telegraphics.com.au> wrote:
>> On one VIA-based machine that I tested, !CONFIG_USE_GENERIC_HARDIRQS
>> gives:
>>
>> # cat /proc/interrupts
>> auto       1:       2299 via1
>> auto       2:       3876 via2
>> auto       4:        562 SCC
>> auto       7:          0 NMI
>> mac       10:        590 pmu-shift
>> mac       12:         90 pmu-clock
>> mac       14:       1635 timer
>> mac       17:       3876 nubus
>> mac       56:       3879 sonic
>>
>> whereas, CONFIG_USE_GENERIC_HARDIRQS=y gives:
>>
>> # cat /proc/interrupts
>>           CPU0
>>  4:       5303      auto  SCC
>>  7:          0      auto  NMI
>>  10:       2136       mac  pmu-shift
>>  12:        607       mac  pmu-clock
>>  14:      41858       mac  timer
>>  56:      66876       mac  sonic
>> ERR:          0
>>
>> Are there no counters for chained IRQs?
>
> I noticed the same for Amiga.

Thomas, is it intentional that chain handlers don't show counters?
What if we get unexpected interrupts the chain handler can't handle?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k: [v5] Convert to genirq (WIP)

[Finn Thain]

On Sun, 28 Aug 2011, I wrote:

>
> I also found that the mac_esp driver probe (when in PIO mode) locks up 
> the machine. I worked around this by changing the 
> disable_irq(IRQ_VIA2_3)/enable_irq(IRQ_VIA2_3) calls to 
> local_irq_save/local_irq_restore, but this is not a good solution.

This seems to be a bug in my mac_esp code. m68k's disable_irq() is 
actually equivalent to genirq's disable_irq_nosync(). Changing mac_esp to 
use disable_irq_nosync() fixes the issue under genirq.

I think these disable_irq/enable_irq calls are probably redundant. They 
don't seem to make any difference in practice. I'll send a patch when I've 
studied the code some more.

However, I found another problem. pmac_zilog oopses when its TTY is closed 
(see below). And macsonic does the same when the NIC is closed. The trace 
says that irq_shutdown() died trying to call the chip irq_mask routine, 
when desc->irq_data.chip (in a0) was NULL. Any ideas?

Finn


Unable to handle kernel NULL pointer dereference at virtual address   (null)
Oops: 00000000
Modules linked in:
PC: [<00000000>]   (null)
SR: 2700  SP: 02019d84  a2: 02017960
d0: 00000004    d1: 00000007    d2: 0031cadc    d3: 00000004
d4: 00002000    d5: 01c00710    a0: 00000000    a1: 00000000
Process init (pid: 1, task=02017960)
Frame format=7 eff addr=02019e10 ssw=05e6 faddr=00000000
wb 1 stat/addr/data: 0005 02109460 01c13e88
wb 2 stat/addr/data: 0000 0007b474 000771ac
wb 3 stat/addr/data: 0005 01c10b64 00000000
push data: 01c13e88 0201ac80 00000024 00000000
Stack from 02019dec:
        0004ce34 002f7fdc 0210edd0 0004c870 002f7fdc 00000004 0031cadc 00000bb
        002f7fdc 0031cadc 0004c8c6 00000004 0031cadc 00002000 00168b1c 0031cadc
        0017c296 00000004 0031cadc 00302000 00002000 020ca800 0017986e 0031cadc
        020ca820 00000001 00000001 00000000 00002008 020ca800 020f5000 0017a61a
        020f5000 020ca800 0210a7b0 00000000 00000002 01c00710 00000000 00000000
        020f5000 00000000 02109820 02019f34 01c00710 00000000 00164002 ffffffff
Call Trace: [<0004ce34>] irq_shutdown+0x48/0x54
 [<0004c870>] __free_irq+0x128/0x14e
 [<0004c8c6>] free_irq+0x30/0x80
 [<00002000>] _start+0x0/0x8
 [<00168b1c>] tty_chars_in_buffer+0x0/0x1a
 [<0017c296>] pmz_shutdown+0x28/0xe8
 [<00002000>] _start+0x0/0x8
 [<0017986e>] uart_shutdown+0x7e/0xb4
 [<00002008>] do_one_initcall+0x0/0x1c0
 [<0017a61a>] uart_close+0xe0/0x2a0
 [<00164002>] tty_release+0x58/0x472
 [<001640a4>] tty_release+0xfa/0x472
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<0008dace>] alloc_fd+0x82/0x162
 [<00079b94>] fput+0x1aa/0x23a
 [<00079a6e>] fput+0x84/0x23a [<00076bca>] filp_close+0x4a/0x70
 [<00076c50>] sys_close+0x60/0x88
 [<0000269c>] syscall+0x8/0xc
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<0000c012>] res_func+0x48e/0x141a
 [<000021e4>] run_init_process+0x1c/0x22
 [<00002228>] init_post+0x3e/0xce
 [<000862aa>] sys_dup+0x0/0x58
 [<00327ad6>] kernel_init+0xe0/0xe8
 [<003279f6>] kernel_init+0x0/0xe8
 [<00002000>] _start+0x0/0x8
 [<00002960>] kernel_thread+0x3a/0x4e

Code: 0000 0000 0000 0000 0000 0000 0000 0000 Bad PC value.
Disabling lock debugging due to kernel taint

Re: m68k: [v5] Convert to genirq (WIP)

[Geert Uytterhoeven]

On Fri, Sep 2, 2011 at 14:14, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Sun, 28 Aug 2011, I wrote:
> However, I found another problem. pmac_zilog oopses when its TTY is closed
> (see below). And macsonic does the same when the NIC is closed. The trace
> says that irq_shutdown() died trying to call the chip irq_mask routine,
> when desc->irq_data.chip (in a0) was NULL. Any ideas?

> Unable to handle kernel NULL pointer dereference at virtual address   (null)
> Oops: 00000000
> Modules linked in:
> PC: [<00000000>]   (null)

No, it calls a function pointer that's NULL.

void irq_shutdown(struct irq_desc *desc)
{
        irq_state_set_disabled(desc);
        desc->depth = 1;
        if (desc->irq_data.chip->irq_shutdown)
                desc->irq_data.chip->irq_shutdown(&desc->irq_data);
        if (desc->irq_data.chip->irq_disable)
                desc->irq_data.chip->irq_disable(&desc->irq_data);
        else
                desc->irq_data.chip->irq_mask(&desc->irq_data);
        irq_state_set_masked(desc);
}

Oops, seems I misread the code and assumed the second "if" was an "else if",
as I wrote down in my notes that it calls only one of the 3 functions :-(
But it does need either .irq_disable() or .irq_mask().

The following irq_chip structs have both .irq_disable() and .irq_mask() NULL:
  - arch/m68k/apollo/dn_ints.c:apollo_irq_chip
  - arch/m68k/kernel/ints.c:auto_irq_chip
  - arch/m68k/kernel/ints.c:user_irq_chip

Since this is on Mac and mac_irq_chip is OK, I guess this is a non-PSC Mac,
i.e. the IRQ number is IRQ_MAC_SCC == IRQ_AUTO_4?

Thomas: As we cannot disable or mask autovector interrupts at the
autovector level,
IMHO it doesn't make much sense do add a dummy .irq_mask() function.
Can we add an extra check in irq_shutdown() to not call .irq_mask() if
it's NULL?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k: [v5] Convert to genirq (WIP)

[Geert Uytterhoeven]

On Fri, Sep 2, 2011 at 19:24, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, Sep 2, 2011 at 14:14, Finn Thain <fthain@telegraphics.com.au> wrote:
>> On Sun, 28 Aug 2011, I wrote:
>> However, I found another problem. pmac_zilog oopses when its TTY is closed
>> (see below). And macsonic does the same when the NIC is closed. The trace
>> says that irq_shutdown() died trying to call the chip irq_mask routine,
>> when desc->irq_data.chip (in a0) was NULL. Any ideas?
>
>> Unable to handle kernel NULL pointer dereference at virtual address   (null)
>> Oops: 00000000
>> Modules linked in:
>> PC: [<00000000>]   (null)
>
> No, it calls a function pointer that's NULL.
>
> void irq_shutdown(struct irq_desc *desc)
> {
>        irq_state_set_disabled(desc);
>        desc->depth = 1;
>        if (desc->irq_data.chip->irq_shutdown)
>                desc->irq_data.chip->irq_shutdown(&desc->irq_data);
>        if (desc->irq_data.chip->irq_disable)
>                desc->irq_data.chip->irq_disable(&desc->irq_data);
>        else
>                desc->irq_data.chip->irq_mask(&desc->irq_data);
>        irq_state_set_masked(desc);
> }
>
> Oops, seems I misread the code and assumed the second "if" was an "else if",
> as I wrote down in my notes that it calls only one of the 3 functions :-(
> But it does need either .irq_disable() or .irq_mask().

However, include/linux/irq.h says:

 * @irq_shutdown:       shut down the interrupt (defaults to ->disable if NULL)

which gives me the impression the original intention was to have an "else if",
and don't require .irq_disable() or .irq_mask() if .irq_shutdown() is available.

That's also what  __free_irq() used to do, cfr.
3b56f0585fd4c02d047dc406668cb40159b2d340

"genirq: Remove bogus conditional

 The if (chip->irq_shutdown) check will always evaluate to true, as we
 fill in chip->irq_shutdown with default_shutdown in
 irq_chip_set_defaults() if the chip does not provide its own function."

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 33a6ee0..30bc8de 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1057,10 +1057,7 @@ static struct irqaction *__free_irq(unsigned int irq, voi
        /* If this was the last handler, shut down the IRQ line: */
        if (!desc->action) {
                desc->status |= IRQ_DISABLED;
-               if (desc->irq_data.chip->irq_shutdown)
-                       desc->irq_data.chip->irq_shutdown(&desc->irq_data);
-               else
-                       desc->irq_data.chip->irq_disable(&desc->irq_data);
+               desc->irq_data.chip->irq_shutdown(&desc->irq_data);
        }

 #ifdef CONFIG_SMP

(at that time the check had become bogus, as .irq_shutdown() was always set to
.irq_disable() if it was NULL).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k: [v5] Convert to genirq (WIP)

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2075 bytes --]

On Fri, 2 Sep 2011, Geert Uytterhoeven wrote:

> On Fri, Sep 2, 2011 at 14:14, Finn Thain <fthain@telegraphics.com.au> wrote:
> > On Sun, 28 Aug 2011, I wrote:
> > However, I found another problem. pmac_zilog oopses when its TTY is closed
> > (see below). And macsonic does the same when the NIC is closed. The trace
> > says that irq_shutdown() died trying to call the chip irq_mask routine,
> > when desc->irq_data.chip (in a0) was NULL. Any ideas?
> 
> > Unable to handle kernel NULL pointer dereference at virtual address   (null)
> > Oops: 00000000
> > Modules linked in:
> > PC: [<00000000>]   (null)
> 
> No, it calls a function pointer that's NULL.
> 
> void irq_shutdown(struct irq_desc *desc)
> {
>         irq_state_set_disabled(desc);
>         desc->depth = 1;
>         if (desc->irq_data.chip->irq_shutdown)
>                 desc->irq_data.chip->irq_shutdown(&desc->irq_data);
>         if (desc->irq_data.chip->irq_disable)
>                 desc->irq_data.chip->irq_disable(&desc->irq_data);
>         else
>                 desc->irq_data.chip->irq_mask(&desc->irq_data);
>         irq_state_set_masked(desc);
> }
> 
> Oops, seems I misread the code and assumed the second "if" was an "else if",

I think that was supposed to be an "else if". Lemme look at the code
before the overhaul to be sure.

> as I wrote down in my notes that it calls only one of the 3 functions :-(
> But it does need either .irq_disable() or .irq_mask().
> 
> The following irq_chip structs have both .irq_disable() and .irq_mask() NULL:
>   - arch/m68k/apollo/dn_ints.c:apollo_irq_chip
>   - arch/m68k/kernel/ints.c:auto_irq_chip
>   - arch/m68k/kernel/ints.c:user_irq_chip
> 
> Since this is on Mac and mac_irq_chip is OK, I guess this is a non-PSC Mac,
> i.e. the IRQ number is IRQ_MAC_SCC == IRQ_AUTO_4?
> 
> Thomas: As we cannot disable or mask autovector interrupts at the
> autovector level,
> IMHO it doesn't make much sense do add a dummy .irq_mask() function.
> Can we add an extra check in irq_shutdown() to not call .irq_mask() if
> it's NULL?

Yes.

Thanks,

	tglx

Re: m68k: [v5] Convert to genirq (WIP)

[Finn Thain]

On Fri, 2 Sep 2011, Geert Uytterhoeven wrote:

> Since this is on Mac and mac_irq_chip is OK, I guess this is a non-PSC 
> Mac, i.e. the IRQ number is IRQ_MAC_SCC == IRQ_AUTO_4?

Right. Similarly, the sonic driver was using IRQ_AUTO_3 when the same 
issue cropped up there. (I was wondering why the PSC machine didn't 
exhibit the problem -- as you point out, it's only auto vector interrupts 
that are affected.)

Finn

Re: m68k: [v5] Convert to genirq (WIP)

[Michael Schmitz]

Hi Geert,

> Works a treat - and gives about 1.5 to 2 fold higher throughput on scp than
> the 3.0 I used before.

Well, not quite:I have seen the following messages after a while of uptime

irq 12: nobody cared (try booting with the "irqpoll" option)
Call Trace: [<0004dc86>] __report_bad_irq+0xa2/0xae
 [<0004dc18>] __report_bad_irq+0x34/0xae
 [<0004dd64>] note_interrupt+0xaa/0x13c
 [<2102401c>] atari_ei_interrupt+0x1c/0x24 [atari_ethernec]
 [<0004cb32>] handle_irq_event_percpu+0x7e/0x110
 [<000a6cdc>] load_script+0xb4/0x1d8
 [<0009ae0c>] __blkdev_get+0x244/0x34a
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<000c6668>] ext3_link+0x48/0x124
 [<0004cbe4>] handle_irq_event+0x20/0x2c
 [<0004e258>] handle_simple_irq+0x3a/0x4c
 [<0004c5be>] generic_handle_irq+0x20/0x28
 [<00005e9c>] do_IRQ+0x20/0x30
 [<00237970>] schedule+0x0/0x2b6
 [<0000275e>] user_irqhandler_fixup+0x4/0x1a
 [<000028d0>] default_idle+0x0/0x14
 [<00002904>] cpu_idle+0x20/0x30
 [<000029f2>] kernel_thread+0x0/0x50
 [<00236928>] rest_init+0x68/0x6c
 [<000279f4>] printk+0x0/0x18
 [<0031407e>] start_kernel+0x29e/0x2a8
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<0031331e>] _sinittext+0x31e/0x9c0

handlers:
[<21024000>] atari_ei_interrupt
Disabling IRQ #12

Network dead after this; trying to ping out from the Falcon gives:

------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x194/0x1c6()
NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
Modules linked in: ipv6 atari_ethernec 8390 genrtc [last unloaded: atari_91C111]
Call Trace: [<000271fa>] warn_slowpath_common+0x4c/0x64
 [<0002723c>] warn_slowpath_fmt+0x2a/0x32
 [<001ccc98>] dev_watchdog+0x194/0x1c6
 [<0002ff10>] call_timer_fn+0x0/0x70
 [<001ccc98>] dev_watchdog+0x194/0x1c6
 [<001ccb04>] dev_watchdog+0x0/0x1c6
 [<0004cb32>] handle_irq_event_percpu+0x7e/0x110
 [<0002ff22>] call_timer_fn+0x12/0x70
 [<001ccb04>] dev_watchdog+0x0/0x1c6
 [<00030082>] run_timer_softirq+0xc0/0x16e
 [<001ccb04>] dev_watchdog+0x0/0x1c6
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<000c6668>] ext3_link+0x48/0x124
 [<0004c5be>] generic_handle_irq+0x20/0x28
 [<0002b24a>] __do_softirq+0x78/0xc6
 [<00237970>] schedule+0x0/0x2b6
 [<0002b2be>] do_softirq+0x26/0x2c
 [<00002664>] ret_from_exception+0x0/0xc
 [<000028d0>] default_idle+0x0/0x14
 [<00002904>] cpu_idle+0x20/0x30
 [<000029f2>] kernel_thread+0x0/0x50
 [<00236928>] rest_init+0x68/0x6c
 [<000279f4>] printk+0x0/0x18
 [<0031407e>] start_kernel+0x29e/0x2a8
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<0031331e>] _sinittext+0x31e/0x9c0

---[ end trace a81b161261829977 ]---

Unloading / reloading the module makes it work again:

ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com)
<6>atari_ethernec.c 11/10/06 Michael Schmitz (schmitz@debian.org)
 failed to detect IRQ line. Assuming irq 12
 00 00 e8 5d 58 cd
eth%d: RTL8019 found at 0x300, using IRQ 12.
eth0: no IPv6 routers present

Until the interrupt is disabled again:

irq 12: nobody cared (try booting with the "irqpoll" option)
Call Trace: [<0004dc86>] __report_bad_irq+0xa2/0xae
 [<0004dc18>] __report_bad_irq+0x34/0xae
 [<0004dd64>] note_interrupt+0xaa/0x13c
 [<2102401c>] atari_ei_interrupt+0x1c/0x24 [atari_ethernec]
 [<0004cb32>] handle_irq_event_percpu+0x7e/0x110
 [<000a6cdc>] load_script+0xb4/0x1d8
 [<0009ae0c>] __blkdev_get+0x244/0x34a
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<000c6668>] ext3_link+0x48/0x124
 [<0004cbe4>] handle_irq_event+0x20/0x2c
 [<0004e258>] handle_simple_irq+0x3a/0x4c
 [<0004c5be>] generic_handle_irq+0x20/0x28
 [<00005e9c>] do_IRQ+0x20/0x30
 [<00237970>] schedule+0x0/0x2b6
 [<0000275e>] user_irqhandler_fixup+0x4/0x1a
 [<000028d0>] default_idle+0x0/0x14
 [<00002904>] cpu_idle+0x20/0x30
 [<000029f2>] kernel_thread+0x0/0x50
 [<00236928>] rest_init+0x68/0x6c
 [<000279f4>] printk+0x0/0x18
 [<0031407e>] start_kernel+0x29e/0x2a8
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<0031331e>] _sinittext+0x31e/0x9c0

handlers:
[<21024000>] atari_ei_interrupt
Disabling IRQ #12

What will the irqpoll option do in this context?

Are these in the interrupt path, or another (disk) interrupt
preempting the timer D interrupt?

 [<000a6cdc>] load_script+0xb4/0x1d8
 [<0009ae0c>] __blkdev_get+0x244/0x34a
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<000c6668>] ext3_link+0x48/0x124

Cheers,

  Michael