<digitalcircuit>
I've filed a pull request for the ipq8065 regression I noticed above. This doesn't fix my crash, but it should probably be fixed anyways: https://github.com/openwrt/openwrt/pull/4464
<digitalcircuit>
(Still fighting the build, worked on 21.02 but broken on master, not yet sure why)
<slh>
ideally also ping @ansuel in a response
Acinonyx has quit [Ping timeout: 480 seconds]
<digitalcircuit>
slh: Will do! I wanted to wait until I got a successful build so I'm not wasting their time.
<digitalcircuit>
Thanks for the reminder, too :)
<slh>
I'm currently letting nbg6817 and g10 fight an uptime battle, 8 days each (admittedly, the nbg6817 is doing more work (wifi off), with the g10 mostly serving wifi duties for testing)
<slh>
but at least in my case, the crashes also happen on idle background traffic
<digitalcircuit>
Huh, interesting. Granted, I've had crashes on idle background traffic even with 19.07, it just never coincided with my backups. If it did crash during a backup, it was rare enough that I didn't get annoyed into debugging over it.
<digitalcircuit>
Well, go figure. I run a non-parallel verbose build and this time it succeeds.
<digitalcircuit>
(111m36.405s vs roughly 50m for parallel build.. hopefully this isn't a common occurrence.)
<slh>
parallel builds do occassionally fail (but then succeed resuming where they failed previously)
<slh>
some undeclared dependencies hiding somewhere, hard to find...
<lmore377>
how is a device deemed worthy of being part of the release candidate builds? rt4230w is already in the snapshots but it wasn't in rc3 or rc4
<mangix>
nobody backported it
<slh>
lmore377: it was merged after openwrt-21.02 branched off master in late february
<lmore377>
ah okay. i'm not familiar with the process so i wasn't sure. can it still be backported or is it too late for that?
<slh>
after openwrt-21.02 is branched off, nothing moves into the release branch automatically anymore - backports- and cherry-picks are necessary after that point. for relatively easy (device-) additions, it may be possible to convince a developer with a targetted/ tested backport (ideally straight forward cherry-pick, although probably not quite as simple here (as kernel 5.10 related changes would have to
<slh>
be backed out again) - but it's getting very late for new device in that regard
<lmore377>
alright guess i'll just wait until the next release lol
<slh>
you're in good company, the linksys e8450/ belkin rt3200 didn't (and won't) make it to 21.02.x either, despite being very popular among OpenWrt developers
Slimey has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
grid has joined #openwrt-devel
<digitalcircuit>
So if ultimately I do give up, I can still go back to stock builds. But I'm not giving up yet, I've got more QA energy left :D
<digitalcircuit>
Meanwhile, it looks like I can hamfistedly work around this by limiting the maximum CPU speed, e.g. tentatively trying... echo "1400000" > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq # and repeat for "policy1"
<Tusker>
digitalcircuit: so the issue only happens when one of the cores goes higher than a certain amount ?
<digitalcircuit>
Tusker: Well.. I'm still trying to pin that down. From what I can tell, on the NBG6817 (or any ipq8065 platform?), L2 cache only runs at 1.4 GHz when at least one (if not both?) CPU cores are at 1.75 GHz. At 1.4 GHz and below, the L2 cache remains at 1.0 GHz speed. So it might be CPU speed, it might be L2 cache speed, or a combination!
Rentong has joined #openwrt-devel
<mangix>
slh: e8450 needs work looks like
<digitalcircuit>
I can try removing the L2 1.4 GHz cache speed, but I think that'd also limit the CPU to 1.4 GHz (instead of 1.75 GHz top) unless I override the DTS to make that a valid combination. Possibly. (It's been a long day of staring at this code :)
<slh>
mangix: most of all it pretty much hard-depends on kernel 5.10
<digitalcircuit>
mrkiko: Brief update - so far, it *seems* like you can workaround 21.02's crashes that I'm encountering just by limiting the max CPU frequency to 1.4 GHz instead of 1.75 GHz. It's a performance drop, but depending on your workload it might be acceptable. Or stick with 19.07 for now. Or try 21.02, because the crash I'm hitting might not even affect you! (Hardware bugs are fun.)
<mangix>
right
<digitalcircuit>
(Well, firmware/hardware bugs. I don't know if this is a silicon issue or a cpufreq driver issue, voltage regulator, etc.)
<Tusker>
digitalcircuit: yeah, I have a ipq8068 running as my main upstream router at the moment, and CPU0 @ 800000 KHz, CPU1 @ QSB rate. Forcing new rate., CPU1 @ 384000 KHz
<mangix>
back to trying to get this E7350 working...
<Tusker>
L2 @ 384000 KHz
<mangix>
it annoys me that this isn't as easy as it should be
Rentong has quit [Ping timeout: 480 seconds]
<digitalcircuit>
Tusker: That's a good idea - figure out a way to randomly-yet-safely spam the CPU frequency driver. The Deja Dup SFTP backup workload being bursty is probably just that. And I might've not recreated it with stress-ng because previously I had loaded both CPU cores, not just one.
<digitalcircuit>
(I did previously recreate a bursty workload, 3 seconds stress-ng on cache, 1 second pause, but that didn't cause a crash)
jbowen has joined #openwrt-devel
jbowen has quit [Ping timeout: 480 seconds]
brpr has joined #openwrt-devel
<brpr>
Hi all. Since yesterday I've gotten further within the build but I don't know what failed here.
<PaulFertser>
brpr: then rerun with -j1 to see the real error please
<brpr>
I'm doing it now.
Rentong has quit [Ping timeout: 480 seconds]
<brpr>
PaulFertser, another typo LOL!
<Tusker>
:)
<brpr>
I have to re-learn typing on my 60% keyboard because I've been typing on my ThinkPad keyboard for the last 2 months (moving reasons) and it's so different
nitroshift has joined #openwrt-devel
<mangix>
ugh
<mangix>
this router makes no sense
<brpr>
PaulFertser, I now know where the MAC address is stored. Look at bootlog line 107: "Fetching MAC Address from factory"
<Tusker>
it should be pretty quick to use hexdump and grep to search through the factory and caldata partitions
dedeckeh has joined #openwrt-devel
<mangix>
i try matching /proc/mtd between stock firmware and openwrt and pretty much fail at it :)
<Tusker>
can you show the dmesg from factory and openwrt in pastebin?
<Tusker>
we can have a look to see what's wrong
<mangix>
I'll have to migrate it to here
<mangix>
I got a picture of stock /proc/mtd though
<Tusker>
and your version is similar, or the partitions don't line up ?
<mangix>
they don't line up
<mangix>
that is, the first three line up
<mangix>
but not firmware and after
<Tusker>
OK, so do you have your dts handy ? and dmesg usually shows an easier to follow list because it includes all the offsets, rather than just the sizes
<Tusker>
looks like 0x180000 (firmware) is a mtd split partition, and probably the same for alt_firmware
<mangix>
yeah just saw
<Tusker>
do you have a local backup of each partition ?
<Tusker>
easily do binwalk on that firmware and alt_firmware and see what's at what location
<Tusker>
and then when you boot into openwrt, you can verify those locations make sense and adjust the dts accordingly
<mangix>
alright... now to set up tftpd on this desktop...
<brpr>
PaulFertser, ERROR (phandle_references): /ahb/wmac@18100000: Reference to non-existent node or label "art"
valku has quit [Quit: valku]
<Tusker>
my guess is that firmware and alt_firmware partitions, both contain kernel, rootfs and roofs_data, so, I would remove those 3 from your dts, and then firmware and alt_firmware need to be marked so
<mangix>
ugh, this reminds me of old school broadcom firmware that uses nvram
<Tusker>
you seem to have too many }; no ?
<Tusker>
oh, maybe not, just weirdly formatted
<mangix>
yeah. mix of tabs and spacesa
<brpr>
yeah, I kept doing a lot of changes so I'm not worried about formatting yet
<Tusker>
what does make complain about in make -j1 V=sc ?
<brpr>
ERROR (phandle_references): /ahb/wmac@18100000: Reference to non-existent node or label "art"
<Tusker>
maybe add art: partition@000007f00000 {
<Tusker>
so that you have something at least labelled as art
<brpr>
alright, compiling
<brpr>
damnit!
<brpr>
still an error
<Tusker>
same error ? the error should have a line reference to where the issue is
<brpr>
I didn't do it with verbose - Tusker could you tell me how to get better speeds with a high verbosity level?
<brpr>
it takes 5m without verbose - with verbose it takes like 20
<Tusker>
probably be faster if you pipe it to file instead of to the console... if you compiling inside X or over putty, there could be lag introduced because of the rendering of the text
<brpr>
then again - it's that big of a difference?
<Tusker>
dunno... will do a test with and without piping on my build server
<Tusker>
3m40s without piping
danitool has joined #openwrt-devel
<Tusker>
3m30s with piping
<Tusker>
so, ok, on my system rendering of the text has minimal impact
<brpr>
while my system is still compiling
<brpr>
wait a seconf
<brpr>
it's using 1 core
<Tusker>
yeah, -j1 does that usually...
<brpr>
yeah
ldir has quit [Quit: +++Divide by cucumber error+++]
<brpr>
Tusker, I booted the new image and I have three partitions in /proc/mtd. Bootloader, ubi and art. I don't think the ubi partition should be there? I think that there should be the other partitions?
<PaulFertser>
brpr: please show full dmesg
<PaulFertser>
brpr: you can see those volumes after running ubiattach I guess
<PaulFertser>
brpr: I see it's attached already. So does ubinfo -a work?
<brpr>
It does!
<PaulFertser>
Nice
<brpr>
How do I run hexdump on the ubi volume "factory"?
<brpr>
Volume ID is 1
<brpr>
nevermind
<brpr>
I have a weird mac address on the bottom of the device. It doesn't have : and begins in 305. How would I search for it? hexdump -C /dev/ubi0_1 | grep '305' doesnt find anything
<PaulFertser>
brpr: I suggest you boot vendor firmware and write down all addresses it uses (for wan, lan, wifi)
<brpr>
How would I get those addresses?
<brpr>
In bootlog I have 30:5A and so on
<brpr>
PaulFertser, I have found the MAC in the Factory partition
<PaulFertser>
brpr: in "ip l" from vendor firmware
<brpr>
will do
<brpr>
alright, I've got it
<brpr>
so now I need to find all of them in factory PaulFertser?
<PaulFertser>
brpr: I think so. btw, your kernel ubi volume is named "linux", right?
<brpr>
Yes. I can only find one MAC address, in ip l I have two different addresses. One ending in e0 and one ending in e4. I can find the e0 one fine, but the e4 is nowhere to be found.
<PaulFertser>
brpr: in this case you'll need to add a custom platform/upgrade.sh to make sysupgrade work. You can take inspiration from mt7622/base-files/lib/upgrade/platform.sh . The idea is that default OpenWrt nand.sh assumes CI_KERNPART to be "kernel" and you need it "linux" so that the bootloader is able to find it.
<PaulFertser>
brpr: are the addresses probably sequential?
rejoicetreat has joined #openwrt-devel
<PaulFertser>
brpr: hm, probably you can just add 4 then, but it's uncommon.
<brpr>
yes, all the same except the 4 at the end
<brpr>
PaulFertser, so the next step is going to be writing that sysupgrade script?
<PaulFertser>
brpr: have you tested wifi yet? I'd test wifi probably.
<PaulFertser>
brpr: and checked switch ports assignment.
<brpr>
oh yeah, and GPIO
<brpr>
that's another question - how would I check the GPIO pins?
<brpr>
PaulFertser, I would just like to REALLY thank you for helping me a lot. Without you, I wouldn't be here. Anyway, here's dmesg -> https://pastebin.com/zL0p7rFz
Rentong has joined #openwrt-devel
<PaulFertser>
brpr: I'm glad to see you moving forward with this project.
<PaulFertser>
brpr: for ath10k you likely want to try adding a &pci1 section to dts. For ath9k it would be &wmac. See other boards based on the same SoC.
<brpr>
Right. Going straight to it.
<PaulFertser>
brpr: it might be on pcie0 too, so if pcie1 doesn't work just try pcie0.
<stintel>
ah fsck I forgot "bit" in my commit message
<stintel>
lol
jbowen has joined #openwrt-devel
<stintel>
ok then I'm going grocery shopping and to bed afterwards, if I can't even get a commit message right I shouldn't be doing more advanced stuff :P
<hauke>
mangix: could you split the gdb patch into multiple patches, one for the version update, one for the musl fixes and one ofr the arc supprot
<hauke>
I do not know if we really need arc support
<stintel>
if the musl fixes are required for the new version, I'd keep them together otherwise bisecting and arriving on the version bump commit will fail to build
jbowen has quit [Quit: leaving]
<hauke>
they are needed because an otehr patch removes the files from toolchain/musl/include/
<stintel>
about arc, we should imo set it source-only or even mark it broken with all their non-upstream stuff that *still* hasn't been upstreamed
<fpsusername[m]>
Lmfao habbie. I'm still waiting on my soic clip
<Habbie>
fpsusername[m], the second one, right?
<fpsusername[m]>
Yes
<Habbie>
ack
rsalvaterra has joined #openwrt-devel
<Habbie>
that one should be on the way here too
<Habbie>
some day
<Habbie>
also, as far as i can tell, i'll be publishing my exploit next week
<fpsusername[m]>
Uhu 😂
<Habbie>
did you upgrade -all- of your experia wifis?
<fpsusername[m]>
Oh nice. Tag me when you do
dangole has joined #openwrt-devel
<fpsusername[m]>
No, only one. The other one is still at vw8
<fpsusername[m]>
V28*
<Habbie>
ok cool
<Habbie>
then you can make firmware dumps
<Habbie>
i have a good relation with KPN that i want to keep :)
<fpsusername[m]>
That's nice
<abiliomarques>
Habie: are you in NL?
<Habbie>
yes
<fpsusername[m]>
Currently in Germany
<Habbie>
fpsusername[m], you, i presume
<Habbie>
i'm in NL :)
<abiliomarques>
I'm in EHV
<fpsusername[m]>
But what about your exploit, is it fixed in the latest/upcoming firmware?
<Habbie>
abiliomarques, ah, home of UPS :D
<Habbie>
fpsusername[m], i do not have numbers but yes, 'it has been fixed'
<stintel>
Bremerhaven ?
<Habbie>
fpsusername[m], your updated device should not be vulnerable, based on the limited information i have
<fpsusername[m]>
Bremerhaven isn't far from where I am
<abiliomarques>
Experia boxes run OpenWRT?
<Habbie>
abiliomarques, not yet!
<Habbie>
abiliomarques, fpsusername[m] and i are trying our best, with some bumps in the road
<stintel>
EHV = Bremerhaven - at least the un/locode says so :)
<Habbie>
abiliomarques, to answer your question better, several experia boxes are arcadyan mt7621 devices, which should have no trouble running openwrt
abiliomarques has quit [Remote host closed the connection]
<Habbie>
abiliomarques, the experiabox v10 (note, that's not v10a) is not an arcadyan, i don't know what's in that one (it's from ZTE)
<Habbie>
oh
rua has quit [Quit: Leaving.]
<rsalvaterra>
Hmm. I wonder if we could get away with aliasing which to command -v and disabling the which applet from BusyBox altogether...
shibboleth has joined #openwrt-devel
<shibboleth>
it appears as if master is broken for ipq806x (c2600), flashing/sysupgrading the generated image results in zero network traffic/connectivity on either lan or wan port
<stintel>
rsalvaterra: any noticeable size difference ?
<rsalvaterra>
Not much, a handful of bytes in the busybox executable, but it's a difference, nonetheless.
<mangix>
stintel: musl fixes are required to build with 1.2.x
<mangix>
hauke: the ARC patches are not needed in order to build gdb. I figure why not add them. openembedded seems to do a good job of maintaining gdb.
<stintel>
mangix: ah :)
<stintel>
did anyone have musl 1.2.2 bump already ?
<stintel>
like gcc/binutils, I think it's time to bump that too