Simon McVittie dixit:
>I was not aware of any mips* buildds still on 4.9 (Debian 9 kernel). The
>only mips family architecture listed on buildd.debian.org is mips64el, for
I think 4.9 is some mipsel buildds. Shortly after the discussion,
which I’m attaching as I don’t know where it’s otherwise archived,
mipsel was removed from sid with no fanfare or announcement, so I
think those now only build for the old releases’ security support,
but the porters/buildd admins would know. Also unsure whether any
derivative distro still has mipsel with sid packages (but it then
is their problem to obtain newer kernels).
>If there are unofficial mips* buildds outside the buildd.debian.org
>infrastructure, then I would hope that either they can be upgraded to a
>Debian 10 or later kernel, or they can run a Debian 12 or older user-space
>(in particular, not keeping up with the latest sbuild).
Or that.
>However, if I'm
>reading kernel git history correctly, the patch proposed on #1079124
>should in principle work with any 4.7+ kernel (not tested). This would
>not have been broad enough compatibility in 2017, but seems OK now.
Yes, certainly.
Thanks,
//mirabilos
--
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival
--- Begin Message ---
Hi,
On 2023-08-04 21:40, Thorsten Glaser wrote:
> Hi,
>
> some of the buildds still use Linux 4.19 but klibc has started to
> require Linux 5.1-specific features with the latest sid upload.
> This has implications on mksh (for the mksh-static and lksh binaries
> and for passing the testsuite) as well.
>
> Could we please get the buildds to run with the stable or at least
> the oldstable kernel?
Unfortunately newer kernels do not work on those buildds:
https://lists.debian.org/debian-mips/2023/07/msg00052.html
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
--- End Message ---
--- Begin Message ---
On Fri, 2023-08-04 at 23:58 +0200, Aurelien Jarno wrote:
> Hi,
>
> On 2023-08-04 21:40, Thorsten Glaser wrote:
> > Hi,
> >
> > some of the buildds still use Linux 4.19 but klibc has started to
> > require Linux 5.1-specific features with the latest sid upload.
> > This has implications on mksh (for the mksh-static and lksh binaries
> > and for passing the testsuite) as well.
> >
> > Could we please get the buildds to run with the stable or at least
> > the oldstable kernel?
>
> Unfortunately newer kernels do not work on those buildds:
>
> https://lists.debian.org/debian-mips/2023/07/msg00052.html
I have to wonder why this did not disqualify mips{,64}el as release
architectures for bookworm.
The error messages are coming from of_irq_parse_pci(), which wasn't
called at all in the buster kernel because we didn't enable CONFIG_OF
or CONFIG_OF_IRQ. That changed with:
commit 8a788b0708ba1593f1fd4f3c585b7d5466a29f16
Author: YunQiang Su <s...@debian.org>
Date: Sat May 23 23:17:42 2020 +0800
Enable CONFIG_OF and CONFIG_SERIAL_OF_PLATFORM for Loongson-3
Loongson64, aka loongson-3 switch to devicetree, and the console
cannot accept input anymore due to SERIAL_OF_PLATFORM is
not enabled.
While SERIAL_OF_PLATFORM depends on OF, we need to enable it
at the same time.
These options can only work with 5.7+.
Do you have an FDT for these systems, and is the boot loader passing
it? I'm guessing not, because we currently don't build or package any
FDTs in the kernel. In 6.1 these sources are available:
arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts
arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dts
arch/mips/boot/dts/loongson/loongson64c_4core_rs780e.dts *
arch/mips/boot/dts/loongson/loongson64c_8core_rs780e.dts *
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dts
arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts
Hopefully one of those marked with an asterisk would be suitable.
Relatedly, I see that eller is also running a 4.19 kernel. What's the
story there?
Ben.
--
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
On Sat, 2023-08-05 at 02:09 +0200, Ben Hutchings wrote:
[...]
> Do you have an FDT for these systems, and is the boot loader passing
> it? I'm guessing not, because we currently don't build or package any
> FDTs in the kernel.
[...]
That has actually been fixed post-bookworm, but should probably be
backported to bookworm:
https://salsa.debian.org/kernel-team/linux/-/commit/7b4954db7823d75ef2e3097ae4e3ce7bdcdb4bbe
Can you test whether providing the appropriate FDT from
linux-image-6.4.0-1-loongson-3 fixes the issue?
Ben.
--
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
Hi,
On 2023-08-05 02:09, Ben Hutchings wrote:
> On Fri, 2023-08-04 at 23:58 +0200, Aurelien Jarno wrote:
> > Hi,
> >
> > On 2023-08-04 21:40, Thorsten Glaser wrote:
> > > Hi,
> > >
> > > some of the buildds still use Linux 4.19 but klibc has started to
> > > require Linux 5.1-specific features with the latest sid upload.
> > > This has implications on mksh (for the mksh-static and lksh binaries
> > > and for passing the testsuite) as well.
> > >
> > > Could we please get the buildds to run with the stable or at least
> > > the oldstable kernel?
> >
> > Unfortunately newer kernels do not work on those buildds:
> >
> > https://lists.debian.org/debian-mips/2023/07/msg00052.html
>
> I have to wonder why this did not disqualify mips{,64}el as release
> architectures for bookworm.
Yes, this should have disqualified them. We have been able to
successfully upgrade the most recent hosts, and slacked at debugging the
issues of the other hosts. Unfortunately in the meantime the most recent
hosts at manda started to fail.
> The error messages are coming from of_irq_parse_pci(), which wasn't
> called at all in the buster kernel because we didn't enable CONFIG_OF
> or CONFIG_OF_IRQ. That changed with:
>
> commit 8a788b0708ba1593f1fd4f3c585b7d5466a29f16
> Author: YunQiang Su <s...@debian.org>
> Date: Sat May 23 23:17:42 2020 +0800
>
> Enable CONFIG_OF and CONFIG_SERIAL_OF_PLATFORM for Loongson-3
>
> Loongson64, aka loongson-3 switch to devicetree, and the console
> cannot accept input anymore due to SERIAL_OF_PLATFORM is
> not enabled.
>
> While SERIAL_OF_PLATFORM depends on OF, we need to enable it
> at the same time.
>
> These options can only work with 5.7+.
>
> Do you have an FDT for these systems, and is the boot loader passing
> it? I'm guessing not, because we currently don't build or package any
> FDTs in the kernel. In 6.1 these sources are available:
>
> arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts
> arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dts
> arch/mips/boot/dts/loongson/loongson64c_4core_rs780e.dts *
> arch/mips/boot/dts/loongson/loongson64c_8core_rs780e.dts *
> arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dts
> arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts
>
> Hopefully one of those marked with an asterisk would be suitable.
Unfortunately I do not know how to pass them to the PMON bootloader.
YunQiang, do you know how to do that?
> Relatedly, I see that eller is also running a 4.19 kernel. What's the
> story there?
The buster and bookworm kernel also do not boot:
| Hit any key to stop autoboot: 0
| Allocated 0x800000 bytes at address: 0xf100000, name: initrd
| 6134060 bytes read in 19 ms (307.9 MiB/s)
| 20222128 bytes read in 50 ms (385.7 MiB/s)
| Allocating memory for ELF segment: addr: 0xffffffff81100000 (adjusted to:
0x1100000), size 0x2fdf020
| ## Loading little-endian Linux kernel with entry point: 0xffffffff81a32968 ...
| Bootloader: Done loading app on coremask:
| 0xf
| Starting cores:
| 0xf
After bisecting the issue, I have found that it is due to the following
commit:
| commit 8d04b29e2cbfa9804e78a05a8cec5548b907d0f8
| Author: Ben Hutchings <b...@decadent.org.uk>
| Date: Sat Oct 5 22:31:59 2019 +0100
|
| [mips*] Revert "Only define MAX_PHYSMEM_BITS on Loongson-3"
|
| This was applied to fix a regression on Loongson-2, which we no
| longer support.
Reverting the revert, I have been able to get the kernel booting a bit
further, but it still fails:
| [ 34.200138] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@0:
Whitelisted compatible string. Please remove
| [ 34.211197] process '/usr/bin/kmod' started with executable stack
| [ 34.224381] irq: :soc@0:gpio-controller@1070000000800 didn't like
hwirq-0x7 to VIRQ47 mapping (rc=-22)
| [ 34.233945] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@1:
Whitelisted compatible string. Please remove
| [ 34.251705] irq: :soc@0:gpio-controller@1070000000800 didn't like
hwirq-0x7 to VIRQ47 mapping (rc=-22)
| [ 34.261266] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@2:
Whitelisted compatible string. Please remove
| [ 34.279034] irq: :soc@0:gpio-controller@1070000000800 didn't like
hwirq-0x7 to VIRQ47 mapping (rc=-22)
| [ 34.288587] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@3:
Whitelisted compatible string. Please remove
| [ 34.306400] irq: :soc@0:gpio-controller@1070000000800 didn't like
hwirq-0x7 to VIRQ47 mapping (rc=-22)
| [ 34.315944] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@4:
Whitelisted compatible string. Please remove
| [ 34.333772] irq: :soc@0:gpio-controller@1070000000800 didn't like
hwirq-0x7 to VIRQ47 mapping (rc=-22)
| [ 34.343321] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@5:
Whitelisted compatible string. Please remove
| [ 34.361078] irq: :soc@0:gpio-controller@1070000000800 didn't like
hwirq-0x7 to VIRQ47 mapping (rc=-22)
| [ 34.370623] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@6:
Whitelisted compatible string. Please remove
| [ 34.388409] irq: :soc@0:gpio-controller@1070000000800 didn't like
hwirq-0x7 to VIRQ47 mapping (rc=-22)
| [ 34.397953] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@7:
Whitelisted compatible string. Please remove
| [ 34.415706] irq: :soc@0:gpio-controller@1070000000800 didn't like
hwirq-0x7 to VIRQ47 mapping (rc=-22)
| [ 34.425260] mdio_octeon 1180000001800.mdio: Probed
| [ 34.430586] [Firmware Warn]: /soc@0/mdio@1180000001900/ethernet-phy@0:
Whitelisted compatible string. Please remove
| [ 34.448406] irq: :soc@0:gpio-controller@1070000000800 didn't like
hwirq-0x7 to VIRQ47 mapping (rc=-22)
| [ 34.457949] mdio_octeon 1180000001900.mdio: Probed
| [ 34.463183] mousedev: PS/2 mouse device common for all mice
| [ 34.469257] i2c-octeon 1180000001000.i2c: probed
| [ 34.474070] ERROR: Incompatible bootmem descriptor version: -1.-1 at addr:
(____ptrval____)
| [ 34.482445] ERROR: Incompatible bootmem descriptor version: -1.-1 at addr:
(____ptrval____)
| [ 34.490800] octeon_wdt: Error: Cannot allocate boot vector.
| [ 34.496466] ledtrig-cpu: registered to indicate activity on CPUs
| [ 34.505748] Interface 0 has 4 ports (SGMII)
| [ 34.509966] ERROR: Incompatible bootmem descriptor version: -1.-1 at addr:
(____ptrval____)
| [ 57.269224] random: crng init done
| [ 58.933205] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [swapper/0:1]
I have attached the full build log to this mail. It would be nice if you
have some ideas, as obviously we are the only users or this hardware.
Cheers
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
Hit any key to stop autoboot: 0
Allocated 0x800000 bytes at address: 0xf100000, name: initrd
6135228 bytes read in 51 ms (114.7 MiB/s)
20222128 bytes read in 261 ms (73.9 MiB/s)
Allocating memory for ELF segment: addr: 0xffffffff81100000 (adjusted to:
0x1100000), size 0xfe0020
## Loading little-endian Linux kernel with entry point: 0xffffffff81a33068 ...
Bootloader: Done loading app on coremask:
0xf
Starting cores:
0xf
[ 0.000000] OF: fdt: No chosen node found, continuing without
[ 0.000000] Linux version 5.10.0-23-octeon (debian-ker...@lists.debian.org)
(mipsel-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU
Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.179-3+test (2023-08-04)
[ 0.000000] Skipping L2 locking due to reduced L2 cache size
[ 0.000000] CVMSEG size: 1 cache lines (128 bytes)
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 000d9602 (Cavium Octeon III)
[ 0.000000] FPU revision is: 00739600
[ 0.000000] Byteswapped initrd detected
[ 0.000000] Initial ramdisk at: 0x800000000f100000 (6135228 bytes)
[ 0.000000] Using passed Device Tree.
[ 0.000000] software IO TLB: mapped [mem
0x00000000036c1000-0x00000000076c1000] (64MB)
[ 0.000000] Primary instruction cache 78kB, virtually tagged, 39 way, 16
sets, linesize 128 bytes.
[ 0.000000] Primary data cache 32kB, 32-way, 8 sets, linesize 128 bytes.
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000efffffff]
[ 0.000000] Normal [mem 0x00000000f0000000-0x000000020fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000000fffffff]
[ 0.000000] node 0: [mem 0x0000000020000000-0x000000020fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000020fffffff]
[ 0.000000] percpu: Embedded 31 pages/cpu s86304 r8192 d32480 u126976
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2064384
[ 0.000000] Kernel command line: bootoctlinux 0x20000000 numcores=4
rd_start=0x8f100000 rd_size=0x5d9dbc root=/dev/sda2 console=ttyS0,115200
[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608
bytes, linear)
[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304
bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 0.000000] Memory: 3831116K/8388608K available (9457K kernel code, 1676K
rwdata, 2440K rodata, 2280K init, 384K bss, 232120K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 27621 entries in 108 pages
[ 0.000000] ftrace: allocated 108 pages with 4 groups
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
[ 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=4
[ 0.000000] NR_IRQS: 512
[ 0.000000] CIB interrupt controller probed: 800107000000e000 23
[ 0.000000] CIB interrupt controller probed: 800107000000e200 12
[ 0.000000] CIB interrupt controller probed: 800107000000e400 6
[ 0.000000] CIB interrupt controller probed: 800107000000ec00 15
[ 0.000000] CIB interrupt controller probed: 800107000000e600 4
[ 0.000000] CIB interrupt controller probed: 800107000000e800 11
[ 0.000000] CIB interrupt controller probed: 800107000000e900 11
[ 26.765094] clocksource: OCTEON_CVMCOUNT: mask: 0xffffffffffffffff
max_cycles: 0x159f22938a9, max_idle_ns: 440795218881 ns
[ 26.776208] Console: colour dummy device 80x25
[ 26.780556] Calibrating delay loop (skipped) preset value.. 3000.00 BogoMIPS
(lpj=6000000)
[ 26.788770] pid_max: default: 32768 minimum: 301
[ 26.793555] LSM: Security Framework initializing
[ 26.798037] Yama: disabled by default; enable with sysctl kernel.yama.*
[ 26.804693] AppArmor: AppArmor initialized
[ 26.808683] TOMOYO Linux initialized
[ 26.812323] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes,
linear)
[ 26.819810] Mountpoint-cache hash table entries: 16384 (order: 5, 131072
bytes, linear)
[ 26.829287] Performance counters: Either hardware does not support
performance counters, or not yet implemented.
[ 26.839422] rcu: Hierarchical SRCU implementation.
[ 26.844925] smp: Bringing up secondary CPUs ...
[ 26.849706] SMP: Booting CPU01 (CoreId 1)...
[ 26.853974] CPU1 revision is: 000d9602 (Cavium Octeon III)
[ 26.853976] FPU revision is: 00739600
[ 26.854476] SMP: Booting CPU02 (CoreId 2)...
[ 26.867825] CPU2 revision is: 000d9602 (Cavium Octeon III)
[ 26.867828] FPU revision is: 00739600
[ 26.868344] SMP: Booting CPU03 (CoreId 3)...
[ 26.881695] CPU3 revision is: 000d9602 (Cavium Octeon III)
[ 26.881698] FPU revision is: 00739600
[ 26.881816] smp: Brought up 1 node, 4 CPUs
[ 26.987633] node 0 deferred pages initialised in 92ms
[ 26.993702] devtmpfs: initialized
[ 26.999485] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 7645041785100000 ns
[ 27.009104] futex hash table entries: 1024 (order: 5, 131072 bytes, linear)
[ 27.016686] NET: Registered protocol family 16
[ 27.021128] audit: initializing netlink subsys (disabled)
[ 27.026580] audit: type=2000 audit(0.188:1): state=initialized
audit_enabled=0 res=1
[ 27.026868] thermal_sys: Registered thermal governor 'fair_share'
[ 27.034175] thermal_sys: Registered thermal governor 'bang_bang'
[ 27.040229] thermal_sys: Registered thermal governor 'step_wise'
[ 27.046217] thermal_sys: Registered thermal governor 'user_space'
[ 27.065246] PCIe: Initializing port 0
[ 27.078148] PCIe: BIST2 FAILED for port 0 (0x0000000000000003)
[ 29.083834] PCIe: Link timeout on port 0, probably the slot is empty
[ 29.090178] PCIe: Initializing port 1
[ 29.096985] PCIe: BIST2 FAILED for port 1 (0x0000000000000003)
[ 31.102668] PCIe: Link timeout on port 1, probably the slot is empty
[ 31.113110] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[ 32.049941] vgaarb: loaded
[ 32.052761] SCSI subsystem initialized
[ 32.056660] EDAC MC: Ver: 3.0.0
[ 32.060434] NetLabel: Initializing
[ 32.063698] NetLabel: domain hash size = 128
[ 32.068018] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 32.073705] NetLabel: unlabeled traffic allowed by default
[ 32.079329] PCI host bridge to bus 0000:00
[ 32.083298] pci_bus 0000:00: root bus resource [mem 0x1000000000000]
[ 32.089640] pci_bus 0000:00: root bus resource [io 0x0000]
[ 32.095181] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
[ 32.101949] pci_bus 0000:00: No busn resource found for root bus, will use
[bus 00-ff]
[ 32.110342] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[ 32.117213] clocksource: Switched to clocksource OCTEON_CVMCOUNT
[ 32.168998] VFS: Disk quotas dquot_6.6.0
[ 32.172853] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 32.180147] AppArmor: AppArmor Filesystem Enabled
[ 32.190607] NET: Registered protocol family 2
[ 32.195101] IP idents hash table entries: 131072 (order: 8, 1048576 bytes,
linear)
[ 32.206241] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4,
65536 bytes, linear)
[ 32.214839] TCP established hash table entries: 65536 (order: 7, 524288
bytes, linear)
[ 32.223236] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes,
linear)
[ 32.231100] TCP: Hash tables configured (established 65536 bind 65536)
[ 32.237656] UDP hash table entries: 4096 (order: 5, 131072 bytes, linear)
[ 32.244462] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes,
linear)
[ 32.251789] NET: Registered protocol family 1
[ 32.256007] NET: Registered protocol family 44
[ 32.260409] PCI: CLS 0 bytes, default 128
[ 32.264554] Trying to unpack rootfs image as initramfs...
[ 34.087331] Freeing initrd memory: 5988K
[ 34.092098] Initialise system trusted keyrings
[ 34.096451] Key type blacklist registered
[ 34.100543] workingset: timestamp_bits=46 max_order=21 bucket_order=0
[ 34.111364] zbud: loaded
[ 34.114393] integrity: Platform Keyring initialized
[ 34.119129] Key type asymmetric registered
[ 34.123184] Asymmetric key parser 'x509' registered
[ 34.128072] Block layer SCSI generic (bsg) driver version 0.4 loaded (major
251)
[ 34.135587] io scheduler mq-deadline registered
[ 34.141802] octeon_gpio 1070000000800.gpio-controller: OCTEON GPIO driver
probed.
[ 34.149423] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 34.156342] printk: console [ttyS0] disabled
[ 34.160490] 1180000000800.serial: ttyS0 at MMIO 0x1180000000800 (irq = 43,
base_baud = 25000000) is a OCTEON
[ 34.170280] printk: console [ttyS0] enabled
[ 34.170280] printk: console [ttyS0] enabled
[ 34.178594] printk: bootconsole [early0] disabled
[ 34.178594] printk: bootconsole [early0] disabled
[ 34.188497] 1180000000c00.serial: ttyS1 at MMIO 0x1180000000c00 (irq = 44,
base_baud = 25000000) is a OCTEON
[ 34.200138] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@0:
Whitelisted compatible string. Please remove
[ 34.211197] process '/usr/bin/kmod' started with executable stack
[ 34.224381] irq: :soc@0:gpio-controller@1070000000800 didn't like hwirq-0x7
to VIRQ47 mapping (rc=-22)
[ 34.233945] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@1:
Whitelisted compatible string. Please remove
[ 34.251705] irq: :soc@0:gpio-controller@1070000000800 didn't like hwirq-0x7
to VIRQ47 mapping (rc=-22)
[ 34.261266] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@2:
Whitelisted compatible string. Please remove
[ 34.279034] irq: :soc@0:gpio-controller@1070000000800 didn't like hwirq-0x7
to VIRQ47 mapping (rc=-22)
[ 34.288587] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@3:
Whitelisted compatible string. Please remove
[ 34.306400] irq: :soc@0:gpio-controller@1070000000800 didn't like hwirq-0x7
to VIRQ47 mapping (rc=-22)
[ 34.315944] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@4:
Whitelisted compatible string. Please remove
[ 34.333772] irq: :soc@0:gpio-controller@1070000000800 didn't like hwirq-0x7
to VIRQ47 mapping (rc=-22)
[ 34.343321] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@5:
Whitelisted compatible string. Please remove
[ 34.361078] irq: :soc@0:gpio-controller@1070000000800 didn't like hwirq-0x7
to VIRQ47 mapping (rc=-22)
[ 34.370623] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@6:
Whitelisted compatible string. Please remove
[ 34.388409] irq: :soc@0:gpio-controller@1070000000800 didn't like hwirq-0x7
to VIRQ47 mapping (rc=-22)
[ 34.397953] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@7:
Whitelisted compatible string. Please remove
[ 34.415706] irq: :soc@0:gpio-controller@1070000000800 didn't like hwirq-0x7
to VIRQ47 mapping (rc=-22)
[ 34.425260] mdio_octeon 1180000001800.mdio: Probed
[ 34.430586] [Firmware Warn]: /soc@0/mdio@1180000001900/ethernet-phy@0:
Whitelisted compatible string. Please remove
[ 34.448406] irq: :soc@0:gpio-controller@1070000000800 didn't like hwirq-0x7
to VIRQ47 mapping (rc=-22)
[ 34.457949] mdio_octeon 1180000001900.mdio: Probed
[ 34.463183] mousedev: PS/2 mouse device common for all mice
[ 34.469257] i2c-octeon 1180000001000.i2c: probed
[ 34.474070] ERROR: Incompatible bootmem descriptor version: -1.-1 at addr:
(____ptrval____)
[ 34.482445] ERROR: Incompatible bootmem descriptor version: -1.-1 at addr:
(____ptrval____)
[ 34.490800] octeon_wdt: Error: Cannot allocate boot vector.
[ 34.496466] ledtrig-cpu: registered to indicate activity on CPUs
[ 34.505748] Interface 0 has 4 ports (SGMII)
[ 34.509966] ERROR: Incompatible bootmem descriptor version: -1.-1 at addr:
(____ptrval____)
[ 57.269224] random: crng init done
[ 58.933205] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [swapper/0:1]
[ 58.940167] Modules linked in:
[ 58.943227] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.0-23-octeon #1
Debian 5.10.179-3+test
[ 58.952009] $ 0 : 0000000000000000 ffffffff826ec5d0 ffffffffffffffff
7202b6becfb92cb2
[ 58.960020] $ 4 : ffffffff83173090 0000000000000000 80000000f0157630
800000000006c108
[ 58.968029] $ 8 : 0000000000000000 c0000000ffffefff 0000000000000003
000000000007c80e
[ 58.976039] $12 : 80000000f0157918 ffffffff82c4699c 0000000000000000
80000000f015764f
[ 58.984048] $16 : 0000000000000000 00000000000003f8 0000000000000000
ffffffff83173090
[ 58.992058] $20 : ffffffff83660000 ffffffff83660000 ffffffffffffffff
80000000f01579f8
[ 59.000067] $24 : 8000000170157647 ffffffff82cc8c50
[ 59.008077] $28 : 80000000f0154000 80000000f01578e0 0000000000000000
ffffffff826ec5d0
[ 59.016087] Hi : 00000000007c80e4
[ 59.019659] Lo : dd2f1a9fbf0aa1c4
[ 59.023242] epc : ffffffff826e7f9c
cvmx_bootmem_phy_named_block_find+0x1bc/0x1d8
[ 59.030810] ra : ffffffff826ec5d0 cvmx_cmd_queue_initialize+0x1e0/0x2b8
[ 59.037682] Status: 14109ce3 KX SX UX KERNEL EXL IE
[ 59.042656] Cause : 40808000 (ExcCode 00)
[ 59.046663] PrId : 000d9602 (Cavium Octeon III)
[ 59.051279] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.0-23-octeon #1
Debian 5.10.179-3+test
[ 59.060061] Stack : 00000000000000bd 0000000dbfbb039c ffffffff8300d058
7202b6becfb92cb2
[ 59.068071] 7202b6becfb92cb2 0000000000000000 80000000f012bb58
ffffffff831ba0f8
[ 59.076080] 80000000f012ba18 0000000000000000 c0000000ffffefff
0000000000000003
[ 59.084089] 000000000000c84f 80000000f012bd08 ffffffff82c469a0
0000000000000000
[ 59.092098] 80000000f012ba40 ffffffff832c0000 0000000000000000
0000000000000000
[ 59.100107] ffffffff831c0000 ffffffff832c5640 0000000000000016
0000000000000000
[ 59.108117] 80000000f0157750 800000017012ba37 ffffffff82cc8c50
0000000000000010
[ 59.116126] ffffffff83660010 80000000f0154000 80000000f012bb50
8000000001045810
[ 59.124135] ffffffff8300d058 0000000000000000 ffffffff831ba0f8
ffffffff82c2792c
[ 59.132145] 0000000000000000 ffffffff831ba0f8 ffffffff826fd6bc
0000000000000001
[ 59.140154] ...
[ 59.142601] Call Trace:
[ 59.145048] [<ffffffff826fd6bc>] show_stack+0x4c/0x138
[ 59.150192] [<ffffffff8300d058>] dump_stack+0xa0/0xd0
[ 59.155246] [<ffffffff82818c10>] watchdog_timer_fn+0x2c0/0x350
[ 59.161079] [<ffffffff827c8d8c>] __hrtimer_run_queues+0x194/0x340
[ 59.167171] [<ffffffff827c96b0>] hrtimer_interrupt+0x138/0x388
[ 59.173004] [<ffffffff82703d84>] c0_compare_interrupt+0x94/0xa8
[ 59.178925] [<ffffffff827a0a58>] __handle_irq_event_percpu+0x98/0x298
[ 59.185365] [<ffffffff827a0c94>] handle_irq_event_percpu+0x3c/0xa0
[ 59.191546] [<ffffffff827a7d04>] handle_percpu_irq+0x94/0xc8
[ 59.197205] [<ffffffff8279fb10>] generic_handle_irq+0x50/0x70
[ 59.202953] [<ffffffff8301aca4>] do_IRQ+0x24/0x30
[ 59.207657] [<ffffffff826e73b8>] plat_irq_dispatch+0xc8/0xf0
[ 59.213317] [<ffffffff826f6dcc>] handle_int+0x14c/0x158
[ 59.218543] [<ffffffff826e7f9c>]
cvmx_bootmem_phy_named_block_find+0x1bc/0x1d8
[ 59.225764] [<ffffffff826ec5d0>] cvmx_cmd_queue_initialize+0x1e0/0x2b8
[ 59.232291] [<ffffffff826ea9c4>] cvmx_pko_config_port.part.0+0x264/0x560
[ 59.238991] [<ffffffff826ed0c8>] __cvmx_helper_interface_setup_pko+0xf0/0x130
[ 59.246125] [<ffffffff826ee81c>]
cvmx_helper_initialize_packet_io_global+0x1a4/0x2e0
[ 59.253868] [<ffffffff82dcdca8>] cvm_oct_probe+0x128/0xad8
[ 59.259355] [<ffffffff82cdf6b0>] platform_drv_probe+0x50/0xc0
[ 59.265100] [<ffffffff82cdc794>] really_probe+0x114/0x578
[ 59.270498] [<ffffffff82cdd158>] driver_probe_device+0x120/0x1a0
[ 59.276503] [<ffffffff82cdd618>] device_driver_attach+0xf0/0xf8
[ 59.282422] [<ffffffff82cdd728>] __driver_attach+0x108/0x1e0
[ 59.288080] [<ffffffff82cd9870>] bus_for_each_dev+0x88/0xd8
[ 59.293652] [<ffffffff82cdb618>] bus_add_driver+0x190/0x280
[ 59.299224] [<ffffffff82cde074>] driver_register+0xa4/0x170
[ 59.304795] [<ffffffff826e0e3c>] do_one_initcall+0x5c/0x270
[ 59.310368] [<ffffffff83427340>] kernel_init_freeable+0x2c0/0x334
[ 59.316461] [<ffffffff830133e4>] kernel_init+0x20/0x124
[ 59.321686] [<ffffffff826f6a50>] ret_from_kernel_thread+0x14/0x1c
[ 59.327778]
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On Sat, 2023-08-05 at 17:00 +0200, Aurelien Jarno wrote:
> Hi,
>
> On 2023-08-05 02:09, Ben Hutchings wrote:
[...]
>
> > Do you have an FDT for these systems, and is the boot loader passing
> > it? I'm guessing not, because we currently don't build or package any
> > FDTs in the kernel. In 6.1 these sources are available:
> >
> > arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts
> > arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dts
> > arch/mips/boot/dts/loongson/loongson64c_4core_rs780e.dts *
> > arch/mips/boot/dts/loongson/loongson64c_8core_rs780e.dts *
> > arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dts
> > arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts
> >
> > Hopefully one of those marked with an asterisk would be suitable.
>
> Unfortunately I do not know how to pass them to the PMON bootloader.
> YunQiang, do you know how to do that?
I've looked a bit further and it seems that the FDTs are actually built
into the kernel. There's also logic to pick the right one based on
some ID registers if the boot loader doesn't pass one:
https://sources.debian.org/src/linux/6.4.4-2/arch/mips/loongson64/init.c/?hl=104#L104
https://sources.debian.org/src/linux/6.4.4-2/arch/mips/loongson64/env.c/?hl=57#L57
In the boot log you posted I see "The bridge chip is RS780E or SR5690"
and I don't see "Failed to determine built-in Loongson64 dtb", so this
seems to be working.
> > Relatedly, I see that eller is also running a 4.19 kernel. What's the
> > story there?
>
> The buster and bookworm kernel also do not boot:
>
> > Hit any key to stop autoboot: 0
> > Allocated 0x800000 bytes at address: 0xf100000, name: initrd
> > 6134060 bytes read in 19 ms (307.9 MiB/s)
> > 20222128 bytes read in 50 ms (385.7 MiB/s)
> > Allocating memory for ELF segment: addr: 0xffffffff81100000 (adjusted to:
> > 0x1100000), size 0x2fdf020
> > ## Loading little-endian Linux kernel with entry point: 0xffffffff81a32968
> > ...
> > Bootloader: Done loading app on coremask:
> > 0xf
> > Starting cores:
> > 0xf
>
> After bisecting the issue, I have found that it is due to the following
> commit:
>
> > commit 8d04b29e2cbfa9804e78a05a8cec5548b907d0f8
> > Author: Ben Hutchings <b...@decadent.org.uk>
> > Date: Sat Oct 5 22:31:59 2019 +0100
> >
> > [mips*] Revert "Only define MAX_PHYSMEM_BITS on Loongson-3"
> >
> > This was applied to fix a regression on Loongson-2, which we no
> > longer support.
>
Well, shit. Sorry about that, but I hope you can see my reasoning...
> Reverting the revert, I have been able to get the kernel booting a bit
> further, but it still fails:
>
> > [ 34.200138] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@0:
> > Whitelisted compatible string. Please remove
> > [ 34.211197] process '/usr/bin/kmod' started with executable stack
> > [ 34.224381] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > [ 34.233945] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@1:
> > Whitelisted compatible string. Please remove
> > [ 34.251705] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > [ 34.261266] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@2:
> > Whitelisted compatible string. Please remove
> > [ 34.279034] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > [ 34.288587] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@3:
> > Whitelisted compatible string. Please remove
> > [ 34.306400] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > [ 34.315944] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@4:
> > Whitelisted compatible string. Please remove
> > [ 34.333772] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > [ 34.343321] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@5:
> > Whitelisted compatible string. Please remove
> > [ 34.361078] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > [ 34.370623] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@6:
> > Whitelisted compatible string. Please remove
> > [ 34.388409] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > [ 34.397953] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@7:
> > Whitelisted compatible string. Please remove
> > [ 34.415706] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > [ 34.425260] mdio_octeon 1180000001800.mdio: Probed
> > [ 34.430586] [Firmware Warn]: /soc@0/mdio@1180000001900/ethernet-phy@0:
> > Whitelisted compatible string. Please remove
> > [ 34.448406] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > [ 34.457949] mdio_octeon 1180000001900.mdio: Probed
So this is for GPIO interrupt setup. Not sure whether it matters.
> > [ 34.463183] mousedev: PS/2 mouse device common for all mice
> > [ 34.469257] i2c-octeon 1180000001000.i2c: probed
> > [ 34.474070] ERROR: Incompatible bootmem descriptor version: -1.-1 at
> > addr: (____ptrval____)
> > [ 34.482445] ERROR: Incompatible bootmem descriptor version: -1.-1 at
> > addr: (____ptrval____)
> > [ 34.490800] octeon_wdt: Error: Cannot allocate boot vector.
> > [ 34.496466] ledtrig-cpu: registered to indicate activity on CPUs
> > [ 34.505748] Interface 0 has 4 ports (SGMII)
> > [ 34.509966] ERROR: Incompatible bootmem descriptor version: -1.-1 at
> > addr: (____ptrval____)
> > [ 57.269224] random: crng init done
> > [ 58.933205] watchdog: BUG: soft lockup - CPU#2 stuck for 22s!
> > [swapper/0:1]
>
> I have attached the full build log to this mail. It would be nice if you
> have some ideas, as obviously we are the only users or this hardware.
The full log says:
[ 0.000000] Using passed Device Tree.
so you successfully passed an FDT from the boot loader. But if you
passed the generic "octeon_3xxx.dtb" this is probably the *wrong* thing
to do! The octeon flavour also has built-in FDTs *and* it has some
code to adjust them based on ID registers.
These error messages:
[ 34.474070] ERROR: Incompatible bootmem descriptor version: -1.-1 at addr:
(____ptrval____)
come from the same file (arch/mips/cavium-octeon/executive/cvmx-
bootmem.c) as the function mentioned in the soft lockup message:
[ 59.023242] epc : ffffffff826e7f9c
cvmx_bootmem_phy_named_block_find+0x1bc/0x1d8
Can you check whether the "Incompatible bootmem descriptor" message
appears in a successful boot log with 4.19? The error message was
already present there and the code in that source file is largely
unchanged between 4.19 and 5.10.
Ben.
--
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
Hi,
On 2023-08-07 00:31, Ben Hutchings wrote:
> On Sat, 2023-08-05 at 17:00 +0200, Aurelien Jarno wrote:
> > Hi,
> >
> > On 2023-08-05 02:09, Ben Hutchings wrote:
> [...]
> >
> > > Do you have an FDT for these systems, and is the boot loader passing
> > > it? I'm guessing not, because we currently don't build or package any
> > > FDTs in the kernel. In 6.1 these sources are available:
> > >
> > > arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts
> > > arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dts
> > > arch/mips/boot/dts/loongson/loongson64c_4core_rs780e.dts *
> > > arch/mips/boot/dts/loongson/loongson64c_8core_rs780e.dts *
> > > arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dts
> > > arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts
> > >
> > > Hopefully one of those marked with an asterisk would be suitable.
> >
> > Unfortunately I do not know how to pass them to the PMON bootloader.
> > YunQiang, do you know how to do that?
>
> I've looked a bit further and it seems that the FDTs are actually built
> into the kernel. There's also logic to pick the right one based on
> some ID registers if the boot loader doesn't pass one:
>
> https://sources.debian.org/src/linux/6.4.4-2/arch/mips/loongson64/init.c/?hl=104#L104
> https://sources.debian.org/src/linux/6.4.4-2/arch/mips/loongson64/env.c/?hl=57#L57
>
> In the boot log you posted I see "The bridge chip is RS780E or SR5690"
> and I don't see "Failed to determine built-in Loongson64 dtb", so this
> seems to be working.
Ok, thanks for the investigation. And given that the "Failed to determine
built-in Loongson64 dtb" does not appear, it means it has loaded one
DTB. Given the code path, it very likely loaded the good one.
That said rs780e-pch.dtsi, included from loongson64c_4core_rs780e.dts
looks a bit empty to me compared to ls7a-pch.dtsi:
https://sources.debian.org/src/linux/6.4.4-2/arch/mips/boot/dts/loongson/rs780e-pch.dtsi/
https://sources.debian.org/src/linux/6.4.4-2/arch/mips/boot/dts/loongson/ls7a-pch.dtsi/
It seems to me that it misses all the PCIe devices with their
interrupts...
> > > Relatedly, I see that eller is also running a 4.19 kernel. What's the
> > > story there?
> >
> > The buster and bookworm kernel also do not boot:
> >
> > > Hit any key to stop autoboot: 0
> > > Allocated 0x800000 bytes at address: 0xf100000, name: initrd
> > > 6134060 bytes read in 19 ms (307.9 MiB/s)
> > > 20222128 bytes read in 50 ms (385.7 MiB/s)
> > > Allocating memory for ELF segment: addr: 0xffffffff81100000 (adjusted to:
> > > 0x1100000), size 0x2fdf020
> > > ## Loading little-endian Linux kernel with entry point:
> > > 0xffffffff81a32968 ...
> > > Bootloader: Done loading app on coremask:
> > > 0xf
> > > Starting cores:
> > > 0xf
> >
> > After bisecting the issue, I have found that it is due to the following
> > commit:
> >
> > > commit 8d04b29e2cbfa9804e78a05a8cec5548b907d0f8
> > > Author: Ben Hutchings <b...@decadent.org.uk>
> > > Date: Sat Oct 5 22:31:59 2019 +0100
> > >
> > > [mips*] Revert "Only define MAX_PHYSMEM_BITS on Loongson-3"
> > >
> > > This was applied to fix a regression on Loongson-2, which we no
> > > longer support.
> >
>
> Well, shit. Sorry about that, but I hope you can see my reasoning...
Yes, no problem. I'll try to submit something upstream.
> > Reverting the revert, I have been able to get the kernel booting a bit
> > further, but it still fails:
> >
> > > [ 34.200138] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@0:
> > > Whitelisted compatible string. Please remove
> > > [ 34.211197] process '/usr/bin/kmod' started with executable stack
> > > [ 34.224381] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > > [ 34.233945] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@1:
> > > Whitelisted compatible string. Please remove
> > > [ 34.251705] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > > [ 34.261266] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@2:
> > > Whitelisted compatible string. Please remove
> > > [ 34.279034] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > > [ 34.288587] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@3:
> > > Whitelisted compatible string. Please remove
> > > [ 34.306400] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > > [ 34.315944] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@4:
> > > Whitelisted compatible string. Please remove
> > > [ 34.333772] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > > [ 34.343321] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@5:
> > > Whitelisted compatible string. Please remove
> > > [ 34.361078] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > > [ 34.370623] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@6:
> > > Whitelisted compatible string. Please remove
> > > [ 34.388409] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > > [ 34.397953] [Firmware Warn]: /soc@0/mdio@1180000001800/ethernet-phy@7:
> > > Whitelisted compatible string. Please remove
> > > [ 34.415706] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > > [ 34.425260] mdio_octeon 1180000001800.mdio: Probed
> > > [ 34.430586] [Firmware Warn]: /soc@0/mdio@1180000001900/ethernet-phy@0:
> > > Whitelisted compatible string. Please remove
> > > [ 34.448406] irq: :soc@0:gpio-controller@1070000000800 didn't like
> > > hwirq-0x7 to VIRQ47 mapping (rc=-22)
> > > [ 34.457949] mdio_octeon 1180000001900.mdio: Probed
>
> So this is for GPIO interrupt setup. Not sure whether it matters.
>
> > > [ 34.463183] mousedev: PS/2 mouse device common for all mice
> > > [ 34.469257] i2c-octeon 1180000001000.i2c: probed
> > > [ 34.474070] ERROR: Incompatible bootmem descriptor version: -1.-1 at
> > > addr: (____ptrval____)
> > > [ 34.482445] ERROR: Incompatible bootmem descriptor version: -1.-1 at
> > > addr: (____ptrval____)
> > > [ 34.490800] octeon_wdt: Error: Cannot allocate boot vector.
> > > [ 34.496466] ledtrig-cpu: registered to indicate activity on CPUs
> > > [ 34.505748] Interface 0 has 4 ports (SGMII)
> > > [ 34.509966] ERROR: Incompatible bootmem descriptor version: -1.-1 at
> > > addr: (____ptrval____)
> > > [ 57.269224] random: crng init done
> > > [ 58.933205] watchdog: BUG: soft lockup - CPU#2 stuck for 22s!
> > > [swapper/0:1]
> >
> > I have attached the full build log to this mail. It would be nice if you
> > have some ideas, as obviously we are the only users or this hardware.
>
> The full log says:
>
> [ 0.000000] Using passed Device Tree.
The kernel 4.19 also outputs this message.
> so you successfully passed an FDT from the boot loader. But if you
> passed the generic "octeon_3xxx.dtb" this is probably the *wrong* thing
> to do! The octeon flavour also has built-in FDTs *and* it has some
> code to adjust them based on ID registers.
We do not explicitly load a DT in u-boot, so my guess is that a u-boot
built-in one is passed and might have become out of date.
> These error messages:
>
> [ 34.474070] ERROR: Incompatible bootmem descriptor version: -1.-1 at addr:
> (____ptrval____)
>
> come from the same file (arch/mips/cavium-octeon/executive/cvmx-
> bootmem.c) as the function mentioned in the soft lockup message:
>
> [ 59.023242] epc : ffffffff826e7f9c
> cvmx_bootmem_phy_named_block_find+0x1bc/0x1d8
>
> Can you check whether the "Incompatible bootmem descriptor" message
> appears in a successful boot log with 4.19? The error message was
> already present there and the code in that source file is largely
> unchanged between 4.19 and 5.10.
Not it is not displayed in 4.19, but it's not clear to me immediately
why it suddenly happens.
Cheers
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
--- End Message ---
