05:19 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (98.7% images and 100.0% packages reproducible in our current test framework.)

07:03 <jow> what's the recommeded protocol for cherry picking master fixes into openwrt 23.05 now? The mirror hashes are incompatible since the zstd changes, right

07:03 <jow> ?

07:04 <jow> and I probably can't just switch branches and redo the bumps either since I most not use the master tools for packing 23.05 tarballs, or does that work?

07:52 <T-Bone> jow: i think it does work. IIRC I did something close to that for backporting my uspot changes into 23.05

07:53 <f00b4r0> you can always try, open a PR and let CI tell you if it's all good. That's what I did :)

08:32 <jow> hm, sometimes clang analyzer is a bit too stupid

08:33 <jow> it always assumes that an external function call returning some sort of pointer is allocating memory this pointer is pointing to, and there appears to be no annotation to tell it otherwise

09:40 <Ansuel> jow i wonder if we should switch 23.05 to zstd too??? aside from that i think any cherry-pick for pkg bump need the hash fixed...

10:05 <rtznprmpftl> hello, i am currently trying to port openwrt to the ubiquiti edgerouter infinity (octeon, similar to edgerouter 4, just bigger). When booting, the kernel panics when trying to initialize PCIe (cvmx_pcie_rc_initialize), i don't think this machine has PCIe, how can i disable this?

10:13 <Habbie> on another octeon, i had to disable usb due to panics, that was 'usbcore.nousb' on the kernel command line

10:13 <Habbie> i bet something similar for pcie exists?

10:13 <Habbie> that one does show pcie in uboot, btw

10:57 <rtznprmpftl> https://gist.github.com/nicolasberens/e4364f648054b47db4298138844c7054 my current notes (uboot does not mention pcie, thats why i assume it does not have it)

11:00 <Habbie> ok, checking my notes closer, my uboot only mentions pcie in 'help' :D

11:12 <PaulFertser> If you do not need pcie then do not enable it in DT.

11:46 <cousin_luigi> Greetings.

11:47 <cousin_luigi> hauke: Hello. Would it be a stretch to say that you are the ppp maintainer?

11:47 <cousin_luigi> If so, is there a particular reason why it was not updated to 2.50?

11:52 <Ansuel> referring to this? https://github.com/openwrt/openwrt/pull/12848

11:53 <Ansuel> main reason is.... +198 −3,170

11:56 <Strykar> From (https://twitter.com/mtaht/status/1792378674953720124), is this patch ever going to be accepted - https://patchwork.kernel.org/project/linux-wireless/patch/CAA93jw6NJ2cmLmMauz0xAgC2MGbBq6n0ZiZzAdkK0u4b+O2yXg@mail.gmail.com/ ?

12:03 <Ansuel> Strykar if only it was submitted without making it a clear complain and rant out of nothing....

12:36 <jow> Strykar: why the presure on openwrt? if it ends up in upstream linux, openwret will inherit it automatically

12:45 <enyc> jow: please can you advise on trying to debug / narrow down issues with PPPoE not working 23.05.3 vs 22.03.6-ok ? Can I rebuild upstream OpenWRT to use 2.50 ppp -or- something else you would reccomend? It seems this is a messy area and there doesn't seem to be a clear bug report anywhere, but lots of nebulous/rumours/muddles .........

12:49 <jow> enyc: first of all, a complete logread would be useful

12:49 <jow> also uci set network.wan.pppd_options=debug; ifup wan; logread -f

12:59 <rtznprmpftl> @PaulFertser i don't think i have pcie enabled in my DT https://github.com/nicolasberens/openwrt/blob/ea6b1343657c67036675322d96e7c651717184a1/target/linux/octeon/files/arch/mips/boot/dts/cavium-octeon/cn7360_ubnt_edgerouter-8-xg.dts

13:00 <PaulFertser> rtznprmpftl: oh shit it's unconditional arch/mips/pci/pcie-octeon.c:arch_initcall(octeon_pcie_setup);

13:01 <PaulFertser> rtznprmpftl: but there's a command line parameter

13:02 <enyc> jow: Thankyou! Can you also advise if any benefit trying master snapshot openwrt or 23.05-SNAPSHOT ?

13:05 <enyc> cousin_luigi: ^^ i may try onsite, eenutalyl, u bay be a while until i'm able to be there with relevant route etc

13:06 <PaulFertser> rtznprmpftl: I just can't understand what module name it is yet

13:14 <slh64> any potential bugfix would need to go through master anyways, so checking that and basing any potential patches against it makes sense

13:15 <PaulFertser> rtznprmpftl: probably "pci.pcie_disable=1" in kernel command line

13:16 <PaulFertser> rtznprmpftl: or pcie_octeon.pcie_disable=1

13:27 <rtznprmpftl> PaulFertser: thanks, i will try that when i get home

13:39 <PaulFertser> rtznprmpftl: an easy and reliable way to tell for sure which module name is there is to add a syntax error to arch/mips/pci/pcie-octeon.c and then check the command line for -DKBUILD_MODNAME value

16:51 <Edu4rdSHL> Any opinions on this? https://lore.kernel.org/linux-wireless/CAA93jw6NJ2cmLmMauz0xAgC2MGbBq6n0ZiZzAdkK0u4b+O2yXg@mail.gmail.com/

17:16 <rtznprmpftl> PaulFertser: and it boots, thanks for the hint

22:20 <PaulFertser> rtznprmpftl: so what was the right option?