On Mon, Aug 16, 2021 at 01:24:14PM +0200, Justus Winter wrote: >Steve McIntyre <[email protected]> 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. [email protected] Dance like no one's watching. Encrypt like everyone is. - @torproject
