Steve McIntyre <st...@einval.com> writes: > On Mon, Aug 16, 2021 at 01:24:14PM +0200, Justus Winter wrote: >>Steve McIntyre <st...@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.
I put the cartridge in UEFI mode. AIUI, it starts using U-Boot, then chainloads UEFI. >>[ 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. Thanks! Justus
signature.asc
Description: PGP signature
