The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
--- Begin Message ---
On 14/08/2024 12:26, Bjørn Mork wrote:
Bas Mevissen via openwrt-devel <openwrt-devel@lists.openwrt.org> writes:
I acquired an HP 1920-24G and gave this branch a spin. Unfortunately,
it does not boot with this branch. Booting 23.05.4 and current main
branch are fine.
System application is starting...[ 0.000000] Linux version 6.6.41
(bas@lenovo) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 4
[ 0.000000] RTL838X model is 83826800
[ 0.000000] SoC Type: RTL8382
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 00019070 (MIPS 4KEc)
[ 0.000000] MIPS: machine is HPE 1920-24G (JG924A)
[ 0.000000] earlycon: ns16550a0 at MMIO 0x18002000 (options '38400n8')
[ 0.000000] printk: bootconsole [ns16550a0] enabled
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] Using appended Device Tree.
[ 0.000000] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
[ 0.000000] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16
bytes
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
So there is work to do. Not sure where to start as this is very early
in the kernel boot...
This is even earlier than expected so I'm unsure if there's another
problem here,. But I noticed that your normal boot log looks like the
console server is eating a few chars here and there:
Yes, I only use a lazy 3-wire serial line and a somewhat flaky RS232 to
USB converter. Will be fine for console output and manual input.
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists,
mobility grouping on. Total pages: 32480
[ 0.000000] Kernel command line: earlycon
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes,
linear)
So I'm crossing my fingers that this is what's happening to the
remaining part of the hanging boot too :-)
Please test https://github.com/bmork/openwrt/commits/realtek-6.6-test/
if you can. It is mostly @howels test branch with a couple of
additional workarounds which made my GS108Tv3 work.
Same result:
....................................................................Done!
System application is starting...[ 0.000000] Linux version 6.6.41
(bas@lenovo) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 r
27000-48454ae4da) 13.3.0, GNU ld (GNU Binutils) 2.42) #0 Thu Aug 8 06:54:39
2024
[ 0.000000] RTL838X model is 83826800
[ 0.000000] SoC Type: RTL8382
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 00019070 (MIPS 4KEc)
[ 0.000000] MIPS: machine is HPE 1920-24G (JG924A)
[ 0.000000] earlycon: ns16550a0 at MMIO 0x18002000 (options '38400n8')
[ 0.000000] printk: bootconsole [ns16550a0] enabled
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] Using appended Device Tree.
[ 0.000000] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
[ 0.000000] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16
bytes
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
(pasted as quotation to avoid line breakage)
The complete boot log from my initial attempt with @howels branch is
found here:
https://github.com/bmork/openwrt/commit/f858f8e78963693097256ca7498f46d35217db6a
The problem was the irq-realtek-rtl driver, and simply disabling our
VPE/SMP hack made it work again. This should be fine on RTL838X.
But we do need someone with an RTL839X to test this, and maybe port the
hack? Or preferable find some solution which can be pushed upstream...
I'm willing to test. So please tell me how I can help.
Bas.
Bjørn
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--- End Message ---
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
