Amiga, serial and SYSRQ

Amiga, serial and SYSRQ

[Paolo Pisati]

Hi,

what's the key sequence to trigger SYSRQ on Amiga? And what's the sequence if
i'm redirecting the console via serial?

Some context: i'm trying to collect a backtrace from my Amiga 1200 + Warp
1260[1] + flicker fixer that refuses to boot and shows a solid grey screen.

By using a serial, i've seen it booting up to:

ABCDGHIJK
Linux version 6.6.30-amiga-00006-g809aa9a54cba (flag@amaterasu.local) (m68k-linux-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 4
Saving 454 bytes of bootinfo
printk: console [debug0] enabled
printk: Too late to register bootconsole debug-1
Amiga hardware found: [A1200] VIDEO BLITTER AUDIO FLOPPY A1200_IDE KEYBOARD MOUSE SERIAL PARALLEL A2000_CLK CHIP_RAM PAULA 
Zone ranges:
  DMA      [mem 0x0000000040000000-0x000004dfffffffff]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000040000000-0x000000004dffffff]
Initmem setup node 0 [mem 0x0000000040000000-0x000000004dffffff]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Kernel command line: root=/dev/sda4 debug=ser earlyprintk console=ttyS0,9600n8
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
Sorting __ex_table...
Built 1 zonelists, mobility grouping on.  Total pages: 56840
mem auto-init: stack:all(zero), heap alloc:off, heap free:off
Memory: 221284K/229376K available (3753K kernel code, 472K rwdata, 1184K rodata, 172K init, 149K bss, 8092K reserved, 0K c)
SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
start_kernel::941
start_kernel::976
NR_IRQS: 32
clocksource: ciab: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 2694272661900 ns
start_kernel::990
start_kernel::994
start_kernel::998
start_kernel::1000
start_kernel::1006
start_kernel::1009

I've added some printk around init/main.c::start_kernel() and it *appears* to be
hanging in "local_irq_enable();".

I've tried all stable LTS kernels from 4.4.y to 6.6.y, and they all shows the same
exact symptoms.

Hope it rings a bell.

1: https://amigawarp.eu/product/warp-1260-board-for-amiga-1200/
-- 
bye,
p.

Re: Amiga, serial and SYSRQ

[Michael Schmitz]

Paolo,

please try adding 'initcall_debug' to the kernel command line.

On a serial console, SysRq is BREAK:

On the serial console (PC style standard serial ports only)
         You send a ``BREAK``, then within 5 seconds a command key. Sending
         ``BREAK`` twice is interpreted as a normal BREAK.

(see Documentation/admin-guide/sysrq.rst)

Cheers,

	Michael

Am 19.05.2024 um 06:17 schrieb Paolo Pisati:
> Hi,
>
> what's the key sequence to trigger SYSRQ on Amiga? And what's the sequence if
> i'm redirecting the console via serial?
>
> Some context: i'm trying to collect a backtrace from my Amiga 1200 + Warp
> 1260[1] + flicker fixer that refuses to boot and shows a solid grey screen.
>
> By using a serial, i've seen it booting up to:
>
> ABCDGHIJK
> Linux version 6.6.30-amiga-00006-g809aa9a54cba (flag@amaterasu.local) (m68k-linux-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 4
> Saving 454 bytes of bootinfo
> printk: console [debug0] enabled
> printk: Too late to register bootconsole debug-1
> Amiga hardware found: [A1200] VIDEO BLITTER AUDIO FLOPPY A1200_IDE KEYBOARD MOUSE SERIAL PARALLEL A2000_CLK CHIP_RAM PAULA
> Zone ranges:
>   DMA      [mem 0x0000000040000000-0x000004dfffffffff]
>   Normal   empty
> Movable zone start for each node
> Early memory node ranges
>   node   0: [mem 0x0000000040000000-0x000000004dffffff]
> Initmem setup node 0 [mem 0x0000000040000000-0x000000004dffffff]
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Kernel command line: root=/dev/sda4 debug=ser earlyprintk console=ttyS0,9600n8
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
> Sorting __ex_table...
> Built 1 zonelists, mobility grouping on.  Total pages: 56840
> mem auto-init: stack:all(zero), heap alloc:off, heap free:off
> Memory: 221284K/229376K available (3753K kernel code, 472K rwdata, 1184K rodata, 172K init, 149K bss, 8092K reserved, 0K c)
> SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> start_kernel::941
> start_kernel::976
> NR_IRQS: 32
> clocksource: ciab: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 2694272661900 ns
> start_kernel::990
> start_kernel::994
> start_kernel::998
> start_kernel::1000
> start_kernel::1006
> start_kernel::1009
>
> I've added some printk around init/main.c::start_kernel() and it *appears* to be
> hanging in "local_irq_enable();".
>
> I've tried all stable LTS kernels from 4.4.y to 6.6.y, and they all shows the same
> exact symptoms.
>
> Hope it rings a bell.
>
> 1: https://amigawarp.eu/product/warp-1260-board-for-amiga-1200/
>

Re: Amiga, serial and SYSRQ

[Geert Uytterhoeven]

Hi Michael,

On Sun, May 19, 2024 at 9:37 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> On a serial console, SysRq is BREAK:

s/serial console/virtual console/

Amiga keyboards do not have a SysRq key.  We used to implement it
using SHIFT+ALTGR+HELP in the old drivers/char/amikeyb.c, but that
feature was lost with the transition to drivers/input/keyboard/amikbd.c.

For enabling it, you can s/KEY_HELP/KEY_SYRQ/ in
drivers/input/keyboard/amikbd.c.

> On the serial console (PC style standard serial ports only)

drivers/tty/amiserial.c does support break, so that should work, too.

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: Amiga, serial and SYSRQ

[Paolo Pisati]

On Sun, May 19, 2024 at 07:36:43PM +1200, Michael Schmitz wrote:
> Paolo,
> 
> please try adding 'initcall_debug' to the kernel command line.

I'm afraid that won't work - init/main.c:

bool initcall_debug;
core_param(initcall_debug, initcall_debug, bool, 0644);

#ifdef TRACEPOINTS_ENABLED
static void __init initcall_debug_enable(void);
#else
static inline void initcall_debug_enable(void)
{
}
#endif

and TRACING_SUPPORT:
...
depends on TRACE_IRQFLAGS_SUPPORT
depends on STACKTRACE_SUPPORT
...

which are both missing on m68k, IIUIC.
-- 
bye,
p.

Re: Amiga, serial and SYSRQ

[Geert Uytterhoeven]

Hi Paolo,

On Sun, May 19, 2024 at 3:27 PM Paolo Pisati <p.pisati@gmail.com> wrote:
> On Sun, May 19, 2024 at 07:36:43PM +1200, Michael Schmitz wrote:
> > Paolo,
> >
> > please try adding 'initcall_debug' to the kernel command line.
>
> I'm afraid that won't work - init/main.c:
>
> bool initcall_debug;
> core_param(initcall_debug, initcall_debug, bool, 0644);
>
> #ifdef TRACEPOINTS_ENABLED
> static void __init initcall_debug_enable(void);
> #else
> static inline void initcall_debug_enable(void)
> {
> }
> #endif

That's just a forward declaration for part of the initcall_debug
support.

> and TRACING_SUPPORT:
> ...
> depends on TRACE_IRQFLAGS_SUPPORT
> depends on STACKTRACE_SUPPORT
> ...
>
> which are both missing on m68k, IIUIC.

Without TRACEPOINTS_ENABLED, you get:

    #ifdef TRACEPOINTS_ENABLED
    ...
    #else
    static inline void do_trace_initcall_start(initcall_t fn)
    {
            if (!initcall_debug)
                    return;
            trace_initcall_start_cb(&initcall_calltime, fn);
    }
    static inline void do_trace_initcall_finish(initcall_t fn, int ret)
    {
            if (!initcall_debug)
                    return;
            trace_initcall_finish_cb(&initcall_calltime, fn, ret);
    }
    #endif /* !TRACEPOINTS_ENABLED */

That second part should still work fine.

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: Amiga, serial and SYSRQ

[Paolo Pisati]

On Sun, May 19, 2024 at 03:31:07PM +0200, Geert Uytterhoeven wrote:
> Without TRACEPOINTS_ENABLED, you get:
> 
>     #ifdef TRACEPOINTS_ENABLED
>     ...
>     #else
>     static inline void do_trace_initcall_start(initcall_t fn)
>     {
>             if (!initcall_debug)
>                     return;
>             trace_initcall_start_cb(&initcall_calltime, fn);
>     }
>     static inline void do_trace_initcall_finish(initcall_t fn, int ret)
>     {
>             if (!initcall_debug)
>                     return;
>             trace_initcall_finish_cb(&initcall_calltime, fn, ret);
>     }
>     #endif /* !TRACEPOINTS_ENABLED */
> 
> That second part should still work fine.

Ok, i appended initcall_debug, but i got the same exact output, i wonder if i'm
missing something else:

ABCDGHIJK
Linux version 6.6.30-amiga-00006-g809aa9a54cba (flag@amaterasu.local) (m68k-linux-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #7 Sat May 18 19:55:35 CEST 2024
Saving 470 bytes of bootinfo
printk: console [debug0] enabled
printk: Too late to register bootconsole debug-1
Amiga hardware found: [A1200] VIDEO BLITTER AUDIO FLOPPY A1200_IDE KEYBOARD MOUSE SERIAL PARALLEL A2000_CLK CHIP_RAM PAULA LISA ALICE_PAL PCMCIA ZORRO 
Zone ranges:
  DMA      [mem 0x0000000040000000-0x000004dfffffffff]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000040000000-0x000000004dffffff]
Initmem setup node 0 [mem 0x0000000040000000-0x000000004dffffff]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Kernel command line: root=/dev/sda4 debug=ser earlyprintk console=ttyS0,9600n8 initcall_debug
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
Sorting __ex_table...
Built 1 zonelists, mobility grouping on.  Total pages: 56840
mem auto-init: stack:all(zero), heap alloc:off, heap free:off
Memory: 221284K/229376K available (3753K kernel code, 472K rwdata, 1184K rodata, 172K init, 149K bss, 8092K reserved, 0K cma-reserved)
SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
start_kernel::941
start_kernel::976
NR_IRQS: 32
clocksource: ciab: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 2694272661900 ns
start_kernel::990
start_kernel::994
start_kernel::998
start_kernel::1000
start_kernel::1006
start_kernel::1009

I'm using amiga_defconfig FWIW.
-- 
bye,
p.

Re: Amiga, serial and SYSRQ

[Geert Uytterhoeven]

Hi Paolo,

On Sat, May 18, 2024 at 8:17 PM Paolo Pisati <p.pisati@gmail.com> wrote:
> Some context: i'm trying to collect a backtrace from my Amiga 1200 + Warp
> 1260[1] + flicker fixer that refuses to boot and shows a solid grey screen.

> I've added some printk around init/main.c::start_kernel() and it *appears* to be
> hanging in "local_irq_enable();".

Doh, I missed this part. So it never gets to initcall_debug.

Probably some of the Warp 1260 on-board hardware has its interrupt line
asserted, causing an interrupt storm when Linux enables interrupts.
Amiboot knows how to reset several boards to prevent this, but it
doesn't support Warp 1260 yet.

https://github.com/geertu/m68kboot/blob/master/common/amiga/linuxboot.c#L195

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: Amiga, serial and SYSRQ

[Michael Schmitz]

Paolo,

On 20/05/24 01:54, Paolo Pisati wrote:
> On Sun, May 19, 2024 at 03:31:07PM +0200, Geert Uytterhoeven wrote:
>> Without TRACEPOINTS_ENABLED, you get:
>>
>>      #ifdef TRACEPOINTS_ENABLED
>>      ...
>>      #else
>>      static inline void do_trace_initcall_start(initcall_t fn)
>>      {
>>              if (!initcall_debug)
>>                      return;
>>              trace_initcall_start_cb(&initcall_calltime, fn);
>>      }
>>      static inline void do_trace_initcall_finish(initcall_t fn, int ret)
>>      {
>>              if (!initcall_debug)
>>                      return;
>>              trace_initcall_finish_cb(&initcall_calltime, fn, ret);
>>      }
>>      #endif /* !TRACEPOINTS_ENABLED */
>>
>> That second part should still work fine.
> Ok, i appended initcall_debug, but i got the same exact output, i wonder if i'm
> missing something else:
>
> ABCDGHIJK
> Linux version 6.6.30-amiga-00006-g809aa9a54cba (flag@amaterasu.local) (m68k-linux-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #7 Sat May 18 19:55:35 CEST 2024
> Saving 470 bytes of bootinfo
> printk: console [debug0] enabled
> printk: Too late to register bootconsole debug-1
> Amiga hardware found: [A1200] VIDEO BLITTER AUDIO FLOPPY A1200_IDE KEYBOARD MOUSE SERIAL PARALLEL A2000_CLK CHIP_RAM PAULA LISA ALICE_PAL PCMCIA ZORRO
> Zone ranges:
>    DMA      [mem 0x0000000040000000-0x000004dfffffffff]
>    Normal   empty
> Movable zone start for each node
> Early memory node ranges
>    node   0: [mem 0x0000000040000000-0x000000004dffffff]
> Initmem setup node 0 [mem 0x0000000040000000-0x000000004dffffff]
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Kernel command line: root=/dev/sda4 debug=ser earlyprintk console=ttyS0,9600n8 initcall_debug

Odd - maybe ordering matters here? Ordinarily, it doesn't but I've been 
caught out with using wrong option separators before. So, if ',' isn't 
the correct token to split the console option, the kernel will stop 
parsing there and won't see your initcall_debug option.

I use that option all the time, but I have 'console=tty' instead of 
serial console.

Cheers,

     Michael

> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
> Sorting __ex_table...
> Built 1 zonelists, mobility grouping on.  Total pages: 56840
> mem auto-init: stack:all(zero), heap alloc:off, heap free:off
> Memory: 221284K/229376K available (3753K kernel code, 472K rwdata, 1184K rodata, 172K init, 149K bss, 8092K reserved, 0K cma-reserved)
> SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> start_kernel::941
> start_kernel::976
> NR_IRQS: 32
> clocksource: ciab: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 2694272661900 ns
> start_kernel::990
> start_kernel::994
> start_kernel::998
> start_kernel::1000
> start_kernel::1006
> start_kernel::1009
>
> I'm using amiga_defconfig FWIW.

Re: Amiga, serial and SYSRQ

[Michael Schmitz]

Hi Geert,

On 19/05/24 21:17, Geert Uytterhoeven wrote:
> Hi Michael,
>
> On Sun, May 19, 2024 at 9:37 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> On a serial console, SysRq is BREAK:
> s/serial console/virtual console/
I meant to write 'serial console' there. You will note that I carefully 
avoided the topic of sysrq on the virtual consoles because I could find 
no information on the key combo,
> Amiga keyboards do not have a SysRq key.  We used to implement it
> using SHIFT+ALTGR+HELP in the old drivers/char/amikeyb.c, but that
> feature was lost with the transition to drivers/input/keyboard/amikbd.c

Thanks - same problem in atakbd.c. What key is 'KEY_102ND'? Does it even 
exists on our keyboards?

Cheers,

     Michael


> For enabling it, you can s/KEY_HELP/KEY_SYRQ/ in
> drivers/input/keyboard/amikbd.c.
>
>> On the serial console (PC style standard serial ports only)
> drivers/tty/amiserial.c does support break, so that should work, too.
>
> Gr{oetje,eeting}s,
>
>                          Geert
>

Re: Amiga, serial and SYSRQ

[Geert Uytterhoeven]

Hi Michael,

On Sun, May 19, 2024 at 9:22 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> On 19/05/24 21:17, Geert Uytterhoeven wrote:
> > On Sun, May 19, 2024 at 9:37 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> >> On a serial console, SysRq is BREAK:
> > s/serial console/virtual console/
> I meant to write 'serial console' there. You will note that I carefully
> avoided the topic of sysrq on the virtual consoles because I could find
> no information on the key combo,

Right, I got totally confused by your two lines starting with "On",
incorrectly assuming the first was for virtual consoles, and the second for
serial consoles...

> > Amiga keyboards do not have a SysRq key.  We used to implement it
> > using SHIFT+ALTGR+HELP in the old drivers/char/amikeyb.c, but that
> > feature was lost with the transition to drivers/input/keyboard/amikbd.c
>
> Thanks - same problem in atakbd.c. What key is 'KEY_102ND'? Does it even
> exists on our keyboards?

That is the keycode generated from raw Amiga keycode 0x30?
According to [1] it is present on some international layouts.

[1] https://wiki.amigaos.net/wiki/Keymap_Library#Keyboard_Layout

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: Amiga, serial and SYSRQ

[Paolo Pisati]

On Mon, May 20, 2024 at 07:12:41AM +1200, Michael Schmitz wrote:
>
> Odd - maybe ordering matters here? Ordinarily, it doesn't but I've been
> caught out with using wrong option separators before. So, if ',' isn't the
> correct token to split the console option, the kernel will stop parsing
> there and won't see your initcall_debug option.
> 
> I use that option all the time, but I have 'console=tty' instead of serial
> console.

No dice: i've tried several combinations, and the output doesn't change.
-- 
bye,
p.

Re: Amiga, serial and SYSRQ

[Paolo Pisati]

On Sun, May 19, 2024 at 04:58:17PM +0200, Geert Uytterhoeven wrote:

> Probably some of the Warp 1260 on-board hardware has its interrupt line
> asserted, causing an interrupt storm when Linux enables interrupts.
> Amiboot knows how to reset several boards to prevent this, but it
> doesn't support Warp 1260 yet.
> 
> https://github.com/geertu/m68kboot/blob/master/common/amiga/linuxboot.c#L195

Doesn't the kernel print out something like "too many spurious interrupts etcetc" in
this case?

Anyhow, any debug option i could turn on? I've tried everything IRQ related, but
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.
-- 
bye,
p.

Re: Amiga, serial and SYSRQ

[Michael Schmitz]

Paolo,

On 21/05/24 05:17, Paolo Pisati wrote:
> On Sun, May 19, 2024 at 04:58:17PM +0200, Geert Uytterhoeven wrote:
>
>> Probably some of the Warp 1260 on-board hardware has its interrupt line
>> asserted, causing an interrupt storm when Linux enables interrupts.
>> Amiboot knows how to reset several boards to prevent this, but it
>> doesn't support Warp 1260 yet.
>>
>> https://github.com/geertu/m68kboot/blob/master/common/amiga/linuxboot.c#L195
> Doesn't the kernel print out something like "too many spurious interrupts etcetc" in
> this case?
Used to do that, yes. But I haven't found that message in current mainline.
>
> Anyhow, any debug option i could turn on? I've tried everything IRQ related, but

CONFIG_CONSOLE_LOGLEVEL_DEFAULT should be high enough to print messages 
of level WARN:

asmlinkage void handle_badint(struct pt_regs *regs)
{
         atomic_inc(&irq_err_count);
         pr_warn("unexpected interrupt from %u\n", regs->vector);
}

That would help to verify Geert's reading of the problem (which I have 
no doubt is the correct one).

The interrupt vector number will tell us what interrupt level is causing 
the storm (if it's an autovector int).

CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 is what I have set in my builds.

> 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.

Cheers,

Michael

Re: Amiga, serial and SYSRQ

[Michael Schmitz]

Hi Geert,

On 20/05/24 08:09, Geert Uytterhoeven wrote:
> Hi Michael,
>
> On Sun, May 19, 2024 at 9:22 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> On 19/05/24 21:17, Geert Uytterhoeven wrote:
>>> On Sun, May 19, 2024 at 9:37 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>>> On a serial console, SysRq is BREAK:
>>> s/serial console/virtual console/
>> I meant to write 'serial console' there. You will note that I carefully
>> avoided the topic of sysrq on the virtual consoles because I could find
>> no information on the key combo,
> Right, I got totally confused by your two lines starting with "On",
> incorrectly assuming the first was for virtual consoles, and the second for
> serial consoles...
>
>>> Amiga keyboards do not have a SysRq key.  We used to implement it
>>> using SHIFT+ALTGR+HELP in the old drivers/char/amikeyb.c, but that
>>> feature was lost with the transition to drivers/input/keyboard/amikbd.c
>> Thanks - same problem in atakbd.c. What key is 'KEY_102ND'? Does it even
>> exists on our keyboards?
> That is the keycode generated from raw Amiga keycode 0x30?
> According to [1] it is present on some international layouts.

Pity - that's useless for sysrq in the general case then.

Does anyone really need the Help key? Should we make that one return the 
sysrq keycode rather?

Cheers,

     Michael

>
> [1] https://wiki.amigaos.net/wiki/Keymap_Library#Keyboard_Layout
>
> Gr{oetje,eeting}s,
>
>                          Geert
>

Re: Amiga, serial and SYSRQ

[Andreas Schwab]

On Mai 21 2024, Michael Schmitz wrote:

> CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 is what I have set in my builds.

Which is also the default.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Amiga, serial and SYSRQ

[Michael Schmitz]

Thanks Andreas,

On 21/05/24 09:15, Andreas Schwab wrote:
> On Mai 21 2024, Michael Schmitz wrote:
>
>> CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 is what I have set in my builds.
> Which is also the default.

Begging the question: why do we not see the warning message?

If the interrupt were to use a vector address set up by AmigaOS, 
shouldn't that cause a kernel panic instead?

The Amiga serial console driver does not rely on interrupts but polls 
for transmit completion. Not sure whether interrupts are disabled while 
the serial console driver pushes out data - if not, a pair of 
local_irq_save(flags) / local_irq_restore(flags) around the loop in 
serial_console_write() could help.

Cheers,

Michael

Re: Amiga, serial and SYSRQ

[Geert Uytterhoeven]

Hi Michael,

On Mon, May 20, 2024 at 11:01 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> On 21/05/24 05:17, Paolo Pisati wrote:
> > On Sun, May 19, 2024 at 04:58:17PM +0200, Geert Uytterhoeven wrote:
> >> Probably some of the Warp 1260 on-board hardware has its interrupt line
> >> asserted, causing an interrupt storm when Linux enables interrupts.
> >> Amiboot knows how to reset several boards to prevent this, but it
> >> doesn't support Warp 1260 yet.
> >>
> >> https://github.com/geertu/m68kboot/blob/master/common/amiga/linuxboot.c#L195
> > Doesn't the kernel print out something like "too many spurious interrupts etcetc" in
> > this case?
> Used to do that, yes. But I haven't found that message in current mainline.
> >
> > Anyhow, any debug option i could turn on? I've tried everything IRQ related, but
>
> CONFIG_CONSOLE_LOGLEVEL_DEFAULT should be high enough to print messages
> of level WARN:
>
> asmlinkage void handle_badint(struct pt_regs *regs)
> {
>          atomic_inc(&irq_err_count);
>          pr_warn("unexpected interrupt from %u\n", regs->vector);
> }
>
> That would help to verify Geert's reading of the problem (which I have
> no doubt is the correct one).
>
> 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?

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.

> > 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

-- 
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: Amiga, serial and SYSRQ

[Paolo Pisati]

On Tue, May 21, 2024 at 09:07:33AM +0200, Geert Uytterhoeven wrote:
>
> 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.

You probably meant arch/m68k/amiga/cia.c since:

diff --git a/arch/m68k/amiga/cia.c b/arch/m68k/amiga/cia.c
index b9aee983e6f4..89dc2e8a2965 100644
--- a/arch/m68k/amiga/cia.c
+++ b/arch/m68k/amiga/cia.c
@@ -150,6 +150,7 @@ static void auto_irq_enable(struct irq_data *data)
 {
        switch (data->irq) {
        case IRQ_AUTO_2:
+               break;
                amiga_custom.intena = IF_SETCLR | IF_PORTS;
                break;
        case IRQ_AUTO_6:

made my system finally boot:

https://dpaste.org/ZnYP5

It's definitely $something of the Warp1260 board triggering that interrupt, and we
need a way to disable it.
 
> Reverse-engineering the AmigaOS interrupt handlers for the board may
> also help.

I hope the board manufacturer is willing to help us out here (added them in cc:) - but
just in case, i read a bit about Amiga interrupts today, and it appears
i'll have to disassemble the handler starting from $6c($VBR).
-- 
bye,
p.

Re: Amiga, serial and SYSRQ

[Michael Schmitz]

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
>