<russell-->
the revert from the issue got eth1 working again
<dwfreed>
yeah, but if you're going to run snapshot, you have to be willing to bisect :P
<stintel>
yep, running snapshot / master is yak shaving
<f00b4r0>
;)
* f00b4r0
is reluctantly about to do it, to test things
<jow>
hm, I'm debugging an ucode crash issue on ath79/generic. The problem is that every once in a while, the read of a very specific memory location returns a different value than what is expected
<jow>
during bytecode compilation, 0x80 is written to address 0x77e16b65
<jow>
and every once in a while (totally random, sometimes afther three program runs, sometimes after several dozen) reading a byte from this address yields 0x00 instead of 0x80
<jow>
it is also an off set well into the program bytecode, so nothing particular special about it, it's not the first or the last
<jow>
I was thinking about some quirkyness with TLB caches, but that's just random speculation. I currently have no clue an how to debug this further
<jow>
I think I can rule out hardware issue (like broken ram) since I got at least three reports showing the same symptoms
<jow>
the only thing notable about the faulty address is that it is not aligned, but reading an off offset from a uint8_t * pointer shouldn't result in unaligned memory access
<f00b4r0>
this only happens on ath79?
<jow>
yes
<f00b4r0>
being equally clueless, I'd start by adding canaries before/after the target address, and use a slightly more useful value such as 0xAA or 0x55, because right now you don't know if it's the last bit that's cleared or the entire byte that's wiped
vincejv has quit [Remote host closed the connection]
<jow>
good idea
<f00b4r0>
then you'll have a better picture telling you if you're not reading *where* you think you are, and/or trashing memory
<f00b4r0>
that it only happens on ath79 is definitely odd, but I haven't dug deep enough into ucode bowels to make an educated guess :)
<jow>
there's at least a realloc() w/ move involved between writing and reading the value
<jow>
replacing the write with a fixed byte sequence for that specific offset and substituting that fixed byte sequence with the expected value does not reproduce the issue anymore
<jow>
so it seems to be a side effect of calculations involved in writing the bytes
<f00b4r0>
a bug in the vm is certainly more likely than a TLB problem which would likely affect other code as well :)
<russell-->
i DONOT understand why tftp is not working for U-Boot Version: 2.0.2.1 (May 21 2021 - 12:21:20)
* russell--
had tried everything he can think of
<russell-->
model=ZyXEL_GS1900_10HPv2 and Model: ZyXEL_GS1900_24Ev2
Guest2488 has quit [Quit: Leaving.]
gromero has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit []
<russell-->
Filename '0101A8C0.img'.
<russell-->
Load address: 0xb4100000
<russell-->
Loading: #T #T T T T
<jow>
weirdness conmtinues
<jow>
writing 0xaa or 0x81 never "flips"
<jow>
writing 0x80 does occasionally
<jow>
0xff does not flip either, nor does any subsequent of the four byte sequence
<f00b4r0>
the kernel that was built is kernel_6.6.44~7a35baa0c08237f6d41dad11d6c02e4d-r1_mipsel_24kc.ipk
<f00b4r0>
how does that even happen
Daanct12 has quit [Quit: WeeChat 4.3.5]
<f00b4r0>
nbd: is it ok if I test current mt76 on top of 23.05 instead? Master is really a headaches in terms of integrating in the test environment
<f00b4r0>
-s
felix has joined #openwrt-devel
Felix_ has quit [Ping timeout: 480 seconds]
<f00b4r0>
and it doesn't build on 23.05 :(
<f00b4r0>
nbd: is there a way to get the actual patches that matter for the testing? that would help a lot
vincejv has joined #openwrt-devel
<nbd>
f00b4r0: you could try backporting the mac80211 package as well
<f00b4r0>
that's a little more involved given all the patches
<f00b4r0>
let's see if I can cherry pick the commits in order
<f00b4r0>
hmm no I can't because 23.05's version apparently never existed in master?!
<f00b4r0>
how's that even possible
goliath has quit [Quit: SIGSEGV]
<f00b4r0>
let's be brutal, and copy/paste package/kernel/mac80211 from master to 23.05
<f00b4r0>
see if it blows up
<f00b4r0>
of course it does. It looks like this is not going to be fun
<f00b4r0>
nbd: is there a smart way to go about this? I'm not familiar with this part of the build so I'm not sure how to go about this. 23.05 is on 6.1.97 while master is on 6.9.9, that's no small gap.
hexa- has joined #openwrt-devel
gromero has quit [Quit: Leaving]
GNUmoon has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
minimal has quit [Quit: Leaving]
<schmars[m]>
f00b4r0: maybe take the config.buildinfo from downloads.openwrt.org - somehow you ended up with a different kernel "checksum". but i'm not sure either
<schmars[m]>
also if you already have a toolchain to build kmods, it doesnt seem expensive to build a whole image? :)
<schmars[m]>
(i'm a frequent IB user too btw hehe)
gromero has joined #openwrt-devel
<schmars[m]>
ooor build a custom IB with the patches included. I've been meaning to do the exact same to test mt76 patches
<schmars[m]>
let me know if you go the custom IB route and run into problems, i have a script
<nbd>
f00b4r0: i'll attempt a mac80211 backport to 23.05
<f00b4r0>
schmars[m]: that's what I did tho
<f00b4r0>
nbd: thanks, that would certainly help a lot
rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
valku has joined #openwrt-devel
<nbd>
f00b4r0: what platform are you building for?