Re: Amiga, serial and SYSRQ

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Geert,

On 21/05/24 19:07, Geert Uytterhoeven wrote:
>> The interrupt vector number will tell us what interrupt level is causing
>> the storm (if it's an autovector int).
> If it's _not_ an autovector int?
If it isn't an autovector interrupt, the vector address were generated 
by the interrupting hardware, and its offset from the vector base 
register won't tell us anything about the IPL.
>
> Anyway, unlike Atari, Amiga only uses autovector interrupts, and most
> expansion boards use IRQ_AMIGA_PORTS (IRQ_AUTO_2) (some can be jumpered
> for IRQ_AMIGA_EXTER (IRQ_AUTO_6).  As lots of other components use
> IRQ_AUTO_2, these are all shared interrupts.  Hence handle_badint()
> is never called, the "bad" interrupt is never disabled by the irq core
> code, and you end up with an eternal interrupt storm.

Makes perfect sense now. And Paolo's report on successful boot with 
IRQ_AUTO_2 never getting enabled confirms this.

Shame the generic IRQ handlers do not return information about whether 
an interrupt could be handled ...

Cheers,

Michael

>
>>> that didn't change a bit. I understand it requires a new fw from the board
>>> manufacturer or a quirk in the bootloader, but i would like to get something more
>>> verbose before i ping them.
>> Interrupt level and vector number would help the manufacturer to give us
>> the information required to disable the problematic interrupt source.
> IRQ_AMIGA_PORTS :-)
>
> I guess the system would boot if you hack arch/m68k/amiga/amiints.c
> to never enable IRQ_AMIGA_PORTS in amiga_custom.intena, but then you
> would also lose the ability to use e.g. the builtin A1200 IDE.
>
> BTW, code to reset/silence the hardware components on Warp 1260
> could not only be added to Amiboot, but also to e.g.
> arch/m68k/amiga/config.c:amiga_parse_bootinfo().
> Reverse-engineering the AmigaOS interrupt handlers for the board may
> also help.
>
> Gr{oetje,eeting}s,
>
>                          Geert
>