Re: Use SMP kernel for Alpha (udeb) builds

[Frank Scheiner <frank.scheiner@web.de>]

Hi Philippe,

On 12/9/18 19:12, Philippe Mathieu-Daudé wrote:
> FYI I've added few tests to QEMU to avoid regressions, one is booting
> the DP264 machine (not yet merged, the specific test is here:)

Wow, didn't knew Alpha emulation is already that good with QEMU!

> https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg03082.html
>
> I tested a recent Debian SMP kernel and got:
>
> alpha-softmmu/qemu-system-alpha \
>    -kernel vmlinuz-4.18.0-3-alpha-generic \

This is the non-SMP kernel, but I assume you meant that actually.

>    -append console=srm -initrd initrd.gz \
>    -nographic -net nic -net user -d mmu,unimp \
>    -drive file=debian-503-alpha-businesscard.iso,if=ide,media=cdrom
> PCI: 00:00:0 class 0300 id 1013:00b8
> PCI:   region 0: 10000000
> PCI:   region 1: 12000000
> PCI: 00:01:0 class 0200 id 8086:100e
> PCI:   region 0: 12020000
> PCI:   region 1: 0000c000
> PCI: 00:02:0 class 0101 id 1095:0646
> PCI:   region 0: 0000c040
> PCI:   region 1: 0000c048
> PCI:   region 3: 0000c04c
> [    0.000000] Linux version 4.18.0-3-alpha-generic
> (debian-kernel@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-30))
> #1 Debian 4.18.20-2 (2018-11-23)
> [    0.000000] bootconsole [srm0] enabled
> [    0.000000] Booting GENERIC on Tsunami variation Clipper using
> machine vector Clipper from SRM
> [...]
> [    0.003906] ------------[ cut here ]------------
> [    0.004882] WARNING: CPU: 0 PID: 0 at
> /build/linux-kQe68U/linux-4.18.20/init/main.c:650 start_kernel+0x4dc/0x754
> [    0.004882] Interrupts were enabled early
> [    0.004882] Modules linked in:
> [    0.005859] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.18.0-3-alpha-generic #1 Debian 4.18.20-2
> [    0.006835]        fffffc00018f3dc8 fffffc000216ee70 fffffc000103597c
> fffffc0001898ddc
> [    0.007812]        fffffc00010359f4 fffffc00018ce1b0 fffffc0002171704
> fffffc000216ee70
> [    0.007812]        fffffc000216ee70 0000000000000000 000000000000028a
> fffffc0001898ddc
> [    0.007812]        fffffc0001898ddc 0000000000000000 fffffc000173e371
> fffffc00018f3e88
> [    0.008789]        fffffc0000000018 fffffc000216ee70 0000000000000000
> 0000000000000001
> [    0.008789]        fffffc00018acab8 0000000000000001 0000000000000000
> 0000000000000000
> [    0.008789] Trace:
> [    0.009765] [<fffffc000103597c>] __warn+0x15c/0x180
> [    0.009765] [<fffffc00010359f4>] warn_slowpath_fmt+0x54/0x70
> [    0.009765] [<fffffc000101001c>] _stext+0x1c/0x20
> [    0.009765] [<fffffc0001010000>] _stext+0x0/0x20
> [    0.010742]
> [    0.010742] ---[ end trace c85a0517f87d04be ]---
> [...]
> [    2.127928] ledtrig-cpu: registered to indicate activity on CPUs
> [    2.131834] NET: Registered protocol family 10
> [    2.264647] input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input0
> [...]
>
> Maybe the warning at init/main.c:650 is useful for your real hw?

Maybe Michael and Bob can make something out of this. But a problem is, 
that we actually don't get that far on real hardware with the non-SMP 
kernel. All machines I tested so far either (1) fall back to SRM or (2) 
seem to hang (DS25/ES45 and most likely other Titan based systems) after 
aboot starts the kernel.

Cheers,
Frank

P.S.
BTW, that Avocado stuff looks interesting. I wonder if that could also 
be used to verify (Linux kernel) bootups on real hardware. That would 
definitely ease up testing new kernel versions.