Bug#992238: debian-installer: Installation fails on HP ProLiant m400 Server: additional cores crash, kernel hangs in acpi_init
On Mon, Aug 16, 2021 at 01:24:14PM +0200, Justus Winter wrote:
>Steve McIntyre <steve@einval.com> writes:
>>
>> OK, and my upgrade worked just fine. The key difference that I'm
>> seeing is that on my system ACPI is *not* used:
>>
>> root@mustang4:/home/steve# grep ACPI /var/log/syslog
>> Aug 16 11:20:27 mustang4 kernel: [ 0.000000] efi: ACPI=0x43fa700000 ACPI 2.0=0x43fa700014 SMBIOS 3.0=0x43fa9db000 ESRT=0x43ff006d18 MOKvar=0x43fd2b2000 MEMRESERVE=0x43fa5e0718
>> Aug 16 11:20:27 mustang4 kernel: [ 1.293700] ACPI: Interpreter disabled.
>> Aug 16 11:20:27 mustang4 kernel: [ 1.322457] pnp: PnP ACPI: disabled
>>
>> Basically, the firmware on these older machines is too old for ACPI to
>> work well. This brings back memories of X-Gene 1 oddities - the way
>> they boot the extra CPU cores depends on specific setup in the DTB. My
>> machine is working that way, but I'm guessing that maybe whatever in
>> the kernel determines this is *not* automatically disabling ACPI on
>> your machine.
>>
>> Pondering: do things work better for you if you add "acpi=off" to the
>> kernel command line?
>
>Interesting. Yeah, I actually tried that last week, but it failed:
:-( Argh.
Oh wow, just noticed:
>U-Boot 2013.04 (Oct 02 2015 - 14:44:51)
I moved all my Mustangs over to UEFI (edk2) rather than U-Boot, but I
honestly don't know if that's an option for the m400.
...
>[ 0.000000] Kernel command line: BOOT_IMAGE=/debian-installer/arm64/linux --- console=ttyS0,115200 earlycon=uart,mmio32,0x1c021000 initcall_debug keep_bootcon efi=debug debug earlyprintk=efi,keep acpi=off
>[ 0.000000] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear)
>[ 0.000000] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear)
>[ 0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
>[ 0.000000] software IO TLB: mapped [mem 0x00000040f8000000-0x00000040fc000000] (64MB)
>[ 0.000000] Memory: 5107712K/67104768K available (11776K kernel code, 2436K rwdata, 7008K rodata, 5440K init, 598K bss, 1407976K reserved, 65536K cma-reserved)
>[ 0.000000] random: get_random_u64 called from __kmem_cache_create+0x38/0x560 with crng_init=0
>[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>[ 0.000000] ftrace: allocating 38533 entries in 151 pages
>[ 0.000000] ftrace: allocated 151 pages with 5 groups
>[ 0.000000] rcu: Hierarchical RCU implementation.
>[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
>[ 0.000000] Rude variant of Tasks RCU enabled.
>[ 0.000000] Tracing variant of Tasks RCU enabled.
>[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
>[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
>[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
>[ 0.000000] Kernel panic - not syncing: No interrupt controller found.
>[ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-8-arm64 #1 Debian 5.10.46-3
>[ 0.000000] Call trace:
>[ 0.000000] dump_backtrace+0x0/0x1e4
>[ 0.000000] show_stack+0x24/0x30
>[ 0.000000] dump_stack+0xd0/0x12c
>[ 0.000000] panic+0x168/0x370
>[ 0.000000] init_IRQ+0xe8/0x104
>[ 0.000000] start_kernel+0x3a8/0x5ac
>[ 0.000000] ---[ end Kernel panic - not syncing: No interrupt controller found. ]---
OK, this is not looking good. I'll ask some of the Arm folks to have a
look here in case they can help.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Dance like no one's watching. Encrypt like everyone is.
- @torproject
Reply to: