Le 12/12/2016 à 04:45, Finn Thain a écrit :
In macints.c there is some startup code which disables the SONIC interrupt
in an attempt to avoid an unhandled slot interrupt, which would be fatal.
This only works on those machines where the SONIC device is on-board.
When the mac_sonic driver is built-in, there's little point in doing this,
because the device will be initialized a few seconds later anyway. But
when mac_sonic is a module, the window for an unhandled interrupt is
longer.
Either way, we've already run the gauntlet for 5 or 10 seconds by the time
we get around to disabling this particular device. It's only by sheer luck
that we got this far.
Really, this is too little too late. The general problem of unhandled
early interrupts also affects other devices on other models. There are
better ways to resolve this problem.
1) When using the Penguin bootloader, boot Mac OS with extensions disabled
(by holding down the shift key at startup or by use of the Extensions
Manager control panel). The Penguin docs already contain this advice,
as it is always effective.
2) Have the Penguin bootloader disable the interrupt. It already attempts
to disable slot interrupts. But since some hardware cannot mask slot
interrupts, Penguin should probably close the relevant device drivers
instead.
3) Use Emile instead of Penguin. AFAIK the boot ROM never enables network
device interrupts and hence they don't need to be disabled.
We should remove this hack. It requires maintenance and it doesn't solve
the problem. It improves the odds in a small number of cases. Far better
to simply set CONFIG_MAC_SONIC=y.
Signed-off-by: Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx>
---
BTW, is it possible to get an error message printed to the console when an
irq is raised for which there is no handler? (Neglecting that this could
happen even before the early console starts...)
Index: linux/arch/m68k/mac/macints.c
===================================================================
--- linux.orig/arch/m68k/mac/macints.c 2016-12-12 12:04:54.000000000 +1100
+++ linux/arch/m68k/mac/macints.c 2016-12-12 13:03:10.000000000 +1100
@@ -125,8 +125,6 @@
#include <asm/hwtest.h>
#include <asm/irq_regs.h>
-#define SHUTUP_SONIC
-
extern void show_registers(struct pt_regs *);
irqreturn_t mac_nmi_handler(int, void *);
@@ -151,16 +149,6 @@ void __init mac_init_IRQ(void)
#endif
m68k_setup_irq_controller(&mac_irq_chip, handle_simple_irq, IRQ_USER,
NUM_MAC_SOURCES - IRQ_USER);
- /* Make sure the SONIC interrupt is cleared or things get ugly */
-#ifdef SHUTUP_SONIC
- printk("Killing onboard sonic... ");
- /* This address should hopefully be mapped already */
- if (hwreg_present((void*)(0x50f0a000))) {
- *(long *)(0x50f0a014) = 0x7fffL;
- *(long *)(0x50f0a010) = 0L;
- }
- printk("Done.\n");
-#endif /* SHUTUP_SONIC */
/*
* Now register the handlers for the master IRQ handlers
It seems this hack appears in kernel 2.4.5.2:
commit 4fdbe71c852f4b44203913c93a5d3a8a12041167
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Mon Feb 4 18:35:36 2002 -0800
v2.4.5.1 -> v2.4.5.2
- Takanori Kawano: brlock indexing bugfix
- Ingo Molnar, Jeff Garzik: softirq updates and fixes
- Al Viro: rampage of superblock cleanups.
- Jean Tourrilhes: Orinoco driver update v6, IrNET update
- Trond Myklebust: NFS brown-paper-bag thing
- Tim Waugh: parport update
- David Miller: networking and sparc updates
- Jes Sorensen: m68k update.
- Ben Fennema: UDF update
- Geert Uytterhoeven: fbdev logo updates
- Willem Riede: osst driver updates
- Paul Mackerras: PPC update
- Marcelo Tosatti: unlazy swap cache
- Mikulas Patocka: hpfs update
Perhaps Jes has something to add (CC:)?
Thanks,
Laurent
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
