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 <[email protected]> > > --- > > 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 <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
