kontaxis has joined #openwrt-devel
mattsm has joined #openwrt-devel
kontaxis has quit [Ping timeout: 268 seconds]
kontaxis has joined #openwrt-devel
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<mangix> Grommish: ping
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
gromero has quit [Remote host closed the connection]
gromero has joined #openwrt-devel
hbug has joined #openwrt-devel
victhor_ has quit [Ping timeout: 272 seconds]
hbug___ has quit [Ping timeout: 268 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
<Grommish> mangix: Hey.. What's up?
<Grommish> Borromini: Most uboot I've seen also support YModem, which is faster, if that might be an option
<Grommish> mangix: hit me up when you see it.. I'm heading to bed and will catch it in the morning :)
xback has quit [Ping timeout: 265 seconds]
xback has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 272 seconds]
dangole has quit [Remote host closed the connection]
kontaxis has quit [Remote host closed the connection]
Darkmatter66 has joined #openwrt-devel
kontaxis has joined #openwrt-devel
<hurricos> nbd: Would you mind a question or three about minstrel_ht?
<hurricos> I notice something of a 'lock-on' effect in the rate control on a standard ath9k chip -- `watch -n2 -d cat rc_stats` while iperf3'ing with the ath9k as tx-mostly, I can see how once I lock on to MCS15 I keep it easily, but when I lose it and drop back to one of the one-chain MCS indexes it takes a while to get back onto the 2x2 ones.
<hurricos> is this expected from minstrel_ht, or is there some hardware quirk expected with MIMO here?
<hurricos> The one thing I notice most shockingly is that when MIMO stops it really stops -- rc_stats shows an increase of a few dozen attempts but *none* are successful
<hurricos> I also suspect my client chipset too (intel 8265).
<hurricos> whereas when MIMO starts again it really starts -- goes from 5% to about 85% avg(prob) in two or three seconds.
<hurricos> Finally, what are the meanings of ABCDPS under 'best rate' in /sys/kernel/debug/ieee80211/phy*/netdev:wlan*/stations/$STATION/rc_stats?
<mangix> Grommish: I'd like a test on https://github.com/openwrt/packages/pull/14728 . I don't have the hardware.
Darkmatter66 has quit [Read error: Connection reset by peer]
blb4393 has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
<nbd> hurricos: ABCD are the 4 best throughput rates (in order), P is a reliable rate with decent throughput, S is a rate that will be tested next
<nbd> regarding your MIMO issues, i suspect that this has nothing to do with rate control, but might be SMPS (powersave mode that turns off extra receive/transmit chains to conserve power) on the intel side
<nbd> if i remember correctly, many intel clients make aggressive use of that
<nbd> hurricos: i think some changes might be needed to either minstrel_ht or mac80211 for smps to work properly
<nbd> i will look into it
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
ldir has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
veonik_ has joined #openwrt-devel
heffer_ has joined #openwrt-devel
Spr0cket has quit [Ping timeout: 240 seconds]
Spr0cket has joined #openwrt-devel
Spr0cket has quit [Changing host]
Spr0cket has joined #openwrt-devel
Spr0cket has joined #openwrt-devel
veonik has quit [Ping timeout: 258 seconds]
ldir- has quit [Ping timeout: 258 seconds]
finsternis has quit [Ping timeout: 258 seconds]
heffer has quit [Ping timeout: 258 seconds]
veonik_ is now known as veonik
rmilecki has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 246 seconds]
finsternis has joined #openwrt-devel
feriman has joined #openwrt-devel
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 98.3% packages reproducible in our current test framework.)
Borromini has joined #openwrt-devel
decke[m] has quit [*.net *.split]
whyz has quit [*.net *.split]
Dagger has quit [*.net *.split]
embargo has quit [*.net *.split]
Namidairo has quit [*.net *.split]
kab-el has quit [*.net *.split]
gaspode has quit [*.net *.split]
larsc has quit [*.net *.split]
dedeckeh has quit [*.net *.split]
veonik has quit [*.net *.split]
ldir has quit [*.net *.split]
mattsm has quit [*.net *.split]
zkrx has quit [*.net *.split]
mkresin has quit [*.net *.split]
hgl has quit [*.net *.split]
SergioCabral has quit [*.net *.split]
fredrikhl has quit [*.net *.split]
nslu2-log has quit [*.net *.split]
KGB-0 has quit [*.net *.split]
gladiac133779 has quit [*.net *.split]
rsalvaterra has quit [*.net *.split]
protodave has quit [*.net *.split]
cp- has quit [*.net *.split]
linmob has quit [*.net *.split]
anonzadas has quit [*.net *.split]
slh64 has quit [*.net *.split]
Rene__ has quit [*.net *.split]
JuniorJPDJ has quit [*.net *.split]
stux|RC-only has quit [*.net *.split]
invisiblek has quit [*.net *.split]
AndyCap has quit [*.net *.split]
quark_ has quit [*.net *.split]
phong has quit [*.net *.split]
Borromini has quit [*.net *.split]
finsternis has quit [*.net *.split]
vdl has quit [*.net *.split]
xback has quit [*.net *.split]
carlomaragno has quit [*.net *.split]
Tsesarevich has quit [*.net *.split]
Monkeh has quit [*.net *.split]
svanheule has quit [*.net *.split]
Nyakajima has quit [*.net *.split]
ephemer0l has quit [*.net *.split]
noahm has quit [*.net *.split]
whyameye has quit [*.net *.split]
indy___ has quit [*.net *.split]
grift has quit [*.net *.split]
pgwipeout[m] has quit [*.net *.split]
voltagex has quit [*.net *.split]
takimata has quit [*.net *.split]
th3g1z has quit [*.net *.split]
lemmi has quit [*.net *.split]
decke[m] has joined #openwrt-devel
Namidairo has joined #openwrt-devel
Dagger has joined #openwrt-devel
embargo has joined #openwrt-devel
gaspode has joined #openwrt-devel
whyz has joined #openwrt-devel
kab-el has joined #openwrt-devel
larsc has joined #openwrt-devel
nslu2-log_ is now known as nslu2-log
_lore_ has quit [Ping timeout: 264 seconds]
tmn505 has quit [Ping timeout: 264 seconds]
tmn505 has joined #openwrt-devel
xback has joined #openwrt-devel
vdl has joined #openwrt-devel
Borromini has joined #openwrt-devel
carlomaragno has joined #openwrt-devel
Tsesarevich has joined #openwrt-devel
svanheule has joined #openwrt-devel
Monkeh has joined #openwrt-devel
Nyakajima has joined #openwrt-devel
ephemer0l has joined #openwrt-devel
finsternis has joined #openwrt-devel
noahm has joined #openwrt-devel
whyameye has joined #openwrt-devel
indy___ has joined #openwrt-devel
nslu2-log is now known as 7JTAB7RM4
veonik has joined #openwrt-devel
zkrx has joined #openwrt-devel
SergioCabral has joined #openwrt-devel
protodave has joined #openwrt-devel
gladiac133779 has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
ldir has joined #openwrt-devel
anonzadas has joined #openwrt-devel
KGB-0 has joined #openwrt-devel
mattsm has joined #openwrt-devel
nslu2-log has joined #openwrt-devel
linmob has joined #openwrt-devel
fredrikhl has joined #openwrt-devel
mkresin has joined #openwrt-devel
hgl has joined #openwrt-devel
cp- has joined #openwrt-devel
feriman has quit [Quit: WeeChat 3.0.1]
_lore_ has joined #openwrt-devel
agb[m] has quit [Ping timeout: 244 seconds]
shalzz has quit [Ping timeout: 244 seconds]
stux|RC-only has joined #openwrt-devel
decke[m] has quit [Ping timeout: 258 seconds]
nick[m]1 has quit [Ping timeout: 265 seconds]
MatMaul has quit [Ping timeout: 265 seconds]
aparcar[m] has quit [Ping timeout: 272 seconds]
olmari has quit [Ping timeout: 268 seconds]
fblaese has quit [Ping timeout: 268 seconds]
pavlix has quit [Ping timeout: 268 seconds]
cp- has quit [Max SendQ exceeded]
dedeckeh has joined #openwrt-devel
t4h4[m] has quit [Ping timeout: 265 seconds]
koniu has quit [Remote host closed the connection]
grift has joined #openwrt-devel
th3g1z has joined #openwrt-devel
takimata has joined #openwrt-devel
lemmi has joined #openwrt-devel
cp- has joined #openwrt-devel
feriman has joined #openwrt-devel
<nbd> hurricos: here's a completely untested ath9k patch that might take care of your issue: http://nbd.name/560-ath9k-tx-smps.patch
<nbd> please let me know if it works for you
<nbd> if it does, i'll send it upstream
Rene__ has joined #openwrt-devel
invisiblek has joined #openwrt-devel
phong has joined #openwrt-devel
slh64 has joined #openwrt-devel
quark_ has joined #openwrt-devel
AndyCap has joined #openwrt-devel
danitool has joined #openwrt-devel
Tapper has joined #openwrt-devel
koniu has joined #openwrt-devel
ivanich has joined #openwrt-devel
llewellyn has joined #openwrt-devel
nick[m]1 has joined #openwrt-devel
pavlix has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
shalzz has joined #openwrt-devel
aparcar[m] has joined #openwrt-devel
agb[m] has joined #openwrt-devel
fblaese has joined #openwrt-devel
t4h4[m] has quit [Ping timeout: 240 seconds]
shalzz has quit [Ping timeout: 246 seconds]
pavlix has quit [Ping timeout: 258 seconds]
nick[m]1 has quit [Ping timeout: 240 seconds]
aparcar[m] has quit [Ping timeout: 265 seconds]
agb[m] has quit [Ping timeout: 268 seconds]
fblaese has quit [Ping timeout: 265 seconds]
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
victhor_ has joined #openwrt-devel
hsp_ has joined #openwrt-devel
hsp has quit [Read error: Connection reset by peer]
<Grommish> mangix: Sure, I can test it. I'm not sure what it is, but I can run a build on it
hsp_ has quit [Quit: WeeChat 3.0.1]
hsp has joined #openwrt-devel
<Grommish> mangix: just target all the boost libraries to see what happens?
voltagex has joined #openwrt-devel
pgwipeout[m] has joined #openwrt-devel
decke[m] has joined #openwrt-devel
olmari has joined #openwrt-devel
Borromini has quit [Ping timeout: 265 seconds]
JuniorJPDJ has joined #openwrt-devel
Tost has joined #openwrt-devel
MatMaul has joined #openwrt-devel
shalzz has joined #openwrt-devel
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
aparcar[m] has joined #openwrt-devel
agb[m] has joined #openwrt-devel
pavlix has joined #openwrt-devel
llewellyn has quit [Quit: Connection closed]
nick[m]1 has joined #openwrt-devel
fblaese has joined #openwrt-devel
<Grommish> mangix: cp: cannot stat '/home/grommish/openwrt/build_dir/target-mips64_octeonplus_64_musl/boost_1_75_0/ipkg-install/lib/libboost_fiber*.so*': No such file or directory <- There is only a libboost_fiber.a MIPS64 is a dynamically linked arch
<Grommish> In any case, its looking for the .so in your Package/install and erroring because it can't find it
voxadam has quit [Read error: Connection reset by peer]
<mangix> Grommish: locally the PR compiles
<mangix> I was talking mostly about run testing :)
<Grommish> Yeah, I'm going to unselect boost fiber and check.. Did you test all libraries in it?
<Grommish> and I'm game to test whatever you need.. Like I said, I don't know that I've use those libs for anything, so any suggestions?
<mangix> The PR only concerns boost-context
<mangix> actually, hmmm. that's interesting
<Grommish> I should find a way to setup a isolated box you can use to test a box. I've got a serial connection for them
<Grommish> and I've got 2 shields sitting here
<Grommish> but it seems like an awful lot fo work and i'm pretty lazy honestly hehe
<mangix> well, I think QEMU also works
<mangix> erm malta target
<Grommish> isn't that just mips though?
<mangix> it's 4 things
<Grommish> Ah
<mangix> MIPS32/63 BE/LE
<mangix> *64
<Grommish> Gotcha.. Mine is a 64BER
<Grommish> err BE
<Grommish> I'm rebuilding without the fiber to see what happens
<mangix> I find it interesting that boost on mips64 has been broken since forever
<mangix> O64 is the wrong ABI
<mangix> which musl has no support for
<Grommish> libunwind is broken for mips64 too.. it isn't in the deps for it, but works
<mangix> Hmm?
<Grommish> I use libunwind for suricata6, but I had to add a mips64 dep check on it
<Grommish> locally anyway
<Grommish> That was as an aside "things mips64 is "broken with" comment, not related to boost
<mangix> the libunwind depends line is pretty funny
<Grommish> Yeah.. I put in a PR but got pissy over the comments I got (my fault) and never bothered to redo it
<mangix> I'm probably to blame for the DEPENDS not being DEPENDS:=!arc
<Grommish> removing boost_fiber seems to let it go and build.. Now.. what can I use to test these in a way that is meaningful for ya?
<mangix> pdns
<mangix> erm
<mangix> pdns-recursor
<Grommish> Ok.. I'll run a build with that too :) Will that conflict with default packages?
<mangix> just running it with a --version parameter is good enough for me
<mangix> i don't think so
<Grommish> Ok.. Gimme a few :)
<mangix> I'll look into the fiber issue
<mangix> ICU is taking forever to compile...
<Grommish> just pdns-recursor?
<mangix> yeah. only pdns-recursor uses boost-context
<mangix> there was another series of packages but I nuked them
<Grommish> Ok
<mangix> I just realized I'm not using ccache...
<mangix> no wonder compilation is slow
csrf has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
csrf has joined #openwrt-devel
Borromini has joined #openwrt-devel
<mangix> Error: opcode not supported on this processor: mips64 (mips64) `pause'
<Grommish> I don't use ccache, it seems to cause more problems than not for me
<mangix> I've fixed all of them :)
<mangix> good for me
<Grommish> Nice.. I'll have to give it a go again then
<Grommish> Anything else you need tested?
<mangix> no that's all. I'll fix up boost fiber and update the PR
<Grommish> Alright. I'll keep an eye out and update to test
<mangix> hmmm....
<mangix> asm volatile ("pause" ::: "memory");
<mangix> why does this fail under mips64?
<Grommish> Check to make sure that opcode is in octeon+
<Grommish> Remember, Openwrt lumps everything under octeon+
<enyc> Borromini: how does the 'testing kernel' case work -- ever an installable package? alternate "build" images installable exchangably?
<Grommish> enyc: Testing kernel is the alternate version in the target Makefile
<Grommish> enyc: turning it on simply builds out the alt major version listed
<Grommish> ie: 4.19 might be the KERNEL_VERSION but 5.4 would be the Testing version
<enyc> Grommish: so manual build of separate image for the target... and that affects the set of kmod- packages ..........
<Grommish> Anytime you change the kernel or toolchain, it all has to be wiped and rebuilt, yeah
<Grommish> So if you buikd with the Testing version, it'll rebuild all the kmods
<mangix> Grommish: where do i find a lost of opcodes?
<Grommish> it woud have to
<enyc> Grommish: hrrm I'm used to x86 linux distros and having quite a wide range of kernels possible to work ........
<Grommish> enyc: Keep in mind OpenWrt is considered embedded though
<enyc> Grommish: right yes =) so not designed for kernel to be interchanged at all, other than "upgrade whole image"
<Grommish> enyc: So i'm not sure you can just swap kernels like in a PC distro
<Grommish> I had a mess of a time with Suricata6 and Rust because of MIPS64 issues with things like statically vs dynamically linked libs
<Grommish> It would compile fine and when I went to run it, it would dump.. I had a hell of a time trying to debug it
<Grommish> turns out a copy opcode was being used that it didb't support
rsalvaterra1 has joined #openwrt-devel
<Grommish> Its how I learned about the remote-dgb script hehe
<mangix> PAUSE opcode is listed there
<mangix> guess octeon is broken in more than one way
rsalvaterra has quit [Ping timeout: 240 seconds]
<Grommish> What is throwig the error?
<mangix> what's strange is that the octeon compiler returns 1 for __mips_isa_rev
<mangix> and it's still evaluating to true
<Borromini> enyc: new image, can't just replace the kernel
<Borromini> ok Grommish already answered you :)
<enyc> Borromini: from what you were saying... 21.02 to be all kernel 5.4 and thus, testing-kernels are only about helping master in preparation for 22.x
<Grommish> Does the build system separate MIPS64 vs MIPS with that flag?
<Grommish> or does it assume MIPS64 is just "MIPS"
<Borromini> enyc: they are a stepping stone to the next kernel to be used in master, yes
<mangix> BOOST_ARCH_MIPS evaluates to 32 or 64
<Grommish> not that is should matter, PAUSE was introduyced into MIPS32 in 2008
<mangix> or 0
<mangix> erm, undefined i mean
<enyc> Borromini: when is the bost useful time to test 21.02 in prep for release, are there specific rc? images or just daily builds, etc?
<Borromini> enyc: once it get branched you'll get prepped pre-21.02 images
<Borromini> did you see the e-mail on openwrt-devel?
<enyc> Borromini: *goes looking*
<mangix> i see this elsewhere in boost code: #if !defined(__mips_isa_rev) || (__mips_isa_rev < 6)
<mangix> wonder if I should just do that
<Grommish> Wait..
<Grommish> PAUSE wasn't introduced until revision 2.60
<Grommish> Revision 2.60: June 25, 2008: added PAUSE instruction
<Grommish> Would that make a difference?
<enyc> Borromini: found thread =)
<mangix> Grommish: run ./staging_dir/toolchain-mips64_octeonplus_64_gcc-8.4.0_musl/bin/mips64-openwrt-linux-gcc -dM -E - < /dev/null | sort -u | grep -i mips
<mangix> note __mips_isa_rev
<Grommish> I use 10.2 FYI
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
<mangix> oh no
<mangix> i figured it out
<rsalvaterra> Bugger. The pca953x GPIO driver from Linux 5.11-rc7 still has the same problem on the Omnia.
<mangix> mips64 supports mips16
<mangix> so PKG_USE_MIPS16:=0 turns __mips_isa_rev to 2
<enyc> Borromini: right so it looks like testing the new builds in all their different wifi configs, client mode and other less-usual setups -- r.e. mac80211 change is going to be especially helpful
<mangix> now i need a good way to ifdef it out :)
<Grommish> mangix: build system defaults to MIPS16 unless told not to?
<Borromini> enyc: yes, especially wireless drivers
<Borromini> if you have spare devices it never hurts to run master on some of them
<Borromini> especially smaller flash devices tend to break when running into kernel size limits and whatnot
<mangix> Grommish: yes. adjustable under advanced toolchain settings
<Borromini> of course better also have serial at hand if things break
<rsalvaterra> Guys, anyone running master on an Omnia? Or anything with an Armada 38x?
<mangix> rsalvaterra: Helios 4, AMA
<rsalvaterra> mangix: do you see spurious GPIO interrupts?
<rsalvaterra> And I mean tons of them, about 50/s.
<mangix> Grommish: lol HAS_MIPS16 depends on depends on (mips || mipsel || mips64 || mips64el) but is not hit under octeon
<Grommish> mangix: Do you know your devices triples offhand? xxxx-openwrt-linux-musl?
<mangix> 50: 0 0 f1018100.gpio 23 Edge 0-0020
<mangix> 51: 0 0 f1018100.gpio 20 Edge f10d8000.sdhci cd
<mangix> 52: 3 0 f1018100.gpio 18 Edge Wake-On-LAN
<mangix> rsalvaterra: that what you mean?
<rsalvaterra> 52: 26711 0 f1018140.gpio 14 Level 8-0071
<rsalvaterra> And counting.
<Grommish> I know it's an aside, but since you'd probably know offhand, I can use it for my rust testing
<mangix> i do not actually
<mangix> i shouldn't be awake right now :P
<Grommish> haha me either.. I feel your pain
<rsalvaterra> After a while, the kernel just gives up and shuts the handler up, with a stack trace.
<enyc> Borromini: I noticed my BT-HomeHub-v5-Type-A just wouldn't client-mode on ath10k in 19.07 but it DOES work with master and all the updated ath10k-firmware etc etc that includes... I'll definitely test all of these with 20.x .....
<enyc> err 21.02 ;p
<rsalvaterra> And this is happening on the normal snapshot builds, on the Omnia. It's not my config.
<rsalvaterra> I'm tempted to just disable the pca953x interrupt controller feature. It "fixes" the problem for me.
<mangix> what kernel?
<rsalvaterra> Lunch time. bbl.
<mangix> i'm running 5.9
<rsalvaterra> mangix: 5.4.97, on master.
<mangix> maybe upstream broke it
<rsalvaterra> 5.4.97 with the pca953x GPIO driver from 5.11-rc7 has the same problem.
<rsalvaterra> I backported it yesterday for testing.
<mangix> I updated the kernel on my helios 4 but haven't rebooted. Looks like no kernel 5.10 for me :)
<russell--> [ 1.230581] Kernel unaligned instruction access[#1]:
<russell--> on an mt7621-based dir860l
<mangix> exit
<russell--> was fine about a week ago
<russell--> also, tools/fakeroot build is failing for me
<russell--> libfakeroot.c: In function 'chown':
<russell--> libfakeroot.c:99:40: error: '_STAT_VER' undeclared (first use in this function) 99 | #define INT_NEXT_STAT(a,b) NEXT_STAT64(_STAT_VER,a,b)
Borromini has quit [Ping timeout: 272 seconds]
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 256 seconds]
<russell--> https://bugs.archlinux.org/task/69572 (patches at the bottom seem to fix my problem)
feriman has quit [Ping timeout: 268 seconds]
<russell--> [ 1.178045] mt7621-pci 1e140000.pcie: Parsing DT failed ... that doesn't look good.
black_ant has quit [Ping timeout: 240 seconds]
goliath has joined #openwrt-devel
* enyc wonders about the DSA situation for 21.02, not much mention of that lately.
<Grommish> I thought the DSA issues were the reason it's been pushed back for as long as it has been
<russell--> did a make dirclean on the dir860l, still hangs the Parsing DT failed doesn't seem to be related, it showed up in the successful firmware built last week too.
<enyc> Grommish: https://openwrt.org/docs/guide-developer/releases/goals/21.02 links to old thread on the topic... I see jow asking similar on the linked LuCI github pull thread
<Grommish> unfortunately, I don't have a Switch in my device, so I can't test anything
victhor_ has quit [Remote host closed the connection]
ericzolf has joined #openwrt-devel
dangole has joined #openwrt-devel
<russell--> r15727-c382fe857d works
* russell-- suspects the last kernel bump
Borromini has joined #openwrt-devel
<russell--> r15731-dba76a85de works
Tapper has quit [Ping timeout: 240 seconds]
<russell--> yep, next commit dies
<russell--> r15732-e95b1b23f1 kills the dir860l
gromero has quit [Ping timeout: 272 seconds]
Immanuel has quit [Ping timeout: 240 seconds]
<Borromini> russell--: what are we talking about?
* Borromini has a dir-860l as well
<Borromini> russell--: oh the kernel bump?
<Borromini> i have an eap235-wall (mt7621 as well) working just fine on 5.4.97
<Borromini> russell--: can you get your hands on a boot log?
HeN has quit [Quit: Connection closed for inactivity]
HeN has joined #openwrt-devel
gromero has joined #openwrt-devel
<Borromini> russell--: the pice: parsing dt failed pops up on most mt7621 devices. i think the stacktrace will be more useful
<Borromini> i see that every time on otherwise perfectly functional mt7621 hardware
Immanuel has joined #openwrt-devel
feriman has joined #openwrt-devel
linzst has joined #openwrt-devel
Immanuel has quit [Ping timeout: 240 seconds]
linzst has quit [Remote host closed the connection]
Tost has quit [Ping timeout: 246 seconds]
heffer_ has quit [Quit: heffer_]
Tapper has joined #openwrt-devel
Immanuel has joined #openwrt-devel
<Grommish> Borromini: Did you everget to check if your uboot supports Ymodem?
<Borromini> Grommish: no, how so?
<Borromini> you mean for the archer c2?
<Borromini> i just found out yesterday about kermit.
<dangole> kermit rules them all (lantiq bootrom also speaks kermit, if i'm not mistaking. used ckermit a lot with that back in the days)
<Grommish> uboot supports kermit, but most also support Ymodem
<Grommish> which is faster and has CRC checking
<Grommish> In case it happens again, might be worth checking into
<dangole> sure, uboot gives you choice, depending on what is compiled in. the burn-in romloader in charge of loading uboot from flash to the cpu cache usually doesn't give you choice there...
<Grommish> I dealt with the pain of tryig to up a 90Mb image via Kermit haha
<Borromini> Grommish: thanks, will keep that in mind :)
<Borromini> luckily it was 7 MB only here :P
<Grommish> Of course, I'm old enough that my first modem was a 1200 Baud
<Grommish> So I remember when Xmodem was it and Zmodem was just coming out
<Grommish> and I hate kermit with a paaaasion
* dangole grew up in Zmodem days with 36kbit/s
<Borromini> dangole: hi! you merged my MT7613 patch into iwinfo but i noticed only afterwards that i might have messed up the order. the PCI ID is 7663 but the device is MT7613 (it's related to the MT7663 though). so i don't know if that needs reordering.
<Grommish> Yep.. I had a USR 16.6 that you had to replace the chip with a paperclip to et 19.2
<Borromini> i think we had 56k. but at that point computers were only for the occasional game if my dad let me :P
<dangole> Borromini: if i recall correctly the ordering there wasn't all straight to beging with. would be nice to clean it and make it consistent
<Grommish> Looked like a hard-back book :D
* dangole was 2:2480/300.38 on FIDOnet, ie. USENET and Mail over UUCP...
<Borromini> dangole: oh that makes my finger mistake less bad then :P
<Grommish> I remember Fidonet.. and gopher.. and Youngstown Ohio shudder
<Grommish> the days of starboards is behind us, thankfully
<Grommish> dangole: You got any luck with making uboot compile?
* dangole mostly remembers wos.* (World-of-Sound), sdc.* (Sound Distributor Channel), ... FIDO file groups, ordered by netlabel groups people published Amiga MOD, FastTracker2 XM, ImpulseTracker IT, ScreamTracker S3M, ... and me was full on into that when me was 14 ;)
<dangole> Grommish: I got U-Boot 2020.10 and ATF 2.2 built from source running on MT7622 on front of me :)
<Grommish> I just donated an old A600 to a retro gmaing channel who restored it after 20+ years sitting.. I've got the A3000 around here somwhere and an original 1084S monitor in front of me :)
<Grommish> dangole: is there a trick to compiling it for the CN70xx
<Grommish> I can't get it to build and my uboot is 2013
<dangole> Grommish: probably you need to use an old toolchain matching the epoch of that U-Boot...
<Grommish> I can't get even Marvell's Uboot repo to build ;x
<Grommish> I'm probably just not doing it right
<dangole> Grommish: that's odd, we got uboot-mvebu building in our tree and it seems to work fine
<dangole> Grommish: package/boot/uboot-mvebu
<Grommish> I don't have a mvebu board though
<dangole> uboot-kirkwood then...?
<Grommish> cavium octeon3
<Grommish> Because Marvell is difficult in the best of times
<Grommish> I'llhave to dig back into it and see what I"m screwing up
Immanuel has quit [Ping timeout: 240 seconds]
<dangole> oh, i imagine... try using the toolchain which comes with it in a OS container sufficiently old...
* Borromini broke a tl-wr1043nd v1 that way
<Borromini> old uboot, new toolchain :P
<Grommish> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell is what they have, but I can't get it to build
<Grommish> But then again, they're last kernel is 4.14, so..
MichaelOF has joined #openwrt-devel
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
Immanuel has joined #openwrt-devel
shibboleth has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
voxadam has joined #openwrt-devel
Tost has joined #openwrt-devel
victhor has joined #openwrt-devel
blb4393 has joined #openwrt-devel
<hurricos> Groomish:
<hurricos> RE: Cavium U-Boot: You can and should try using Cavium's SDK.
<hurricos> It's not public, but for some reason they haven't DMCA'd any copies off Github.
MichaelOF has quit [Quit: Konversation terminated!]
<hurricos> Cavium NEVER mainlined their stuff. Or well, they re-hired Aaron Williamson to take another run at it, most recent commits to U-boot mainline were like December 2020.
<hurricos> grommish:
<hurricos> it doesn't help that Cavium Octeon processors, especially the higher-end ones, are ridiculously overengineered.
<hurricos> I think most CN68XX boards are like, 32 cores, 8GB RAM.
<hurricos> and CN78XX boards have like 128 cores or something insane like that
<hurricos> whatever passes for "embedded" these days. It's like Xeon Phi before Xeon Phi was well-known
dhewg has quit [Ping timeout: 256 seconds]
<Borromini> guys a question: if my board's serial header is 3,3V i shouldn't connect to it right?
<Borromini> or am i wrong?
<Borromini> so far i've done rx/tx/gnd and that works just fine in general
<urjaman> yeah unless you have a voltage translator or something that'd use the reference, it doesnt matter (or a converter to old RS-232 that needs the power...)
<Borromini> ok, thanks
<PaulFertser> Borromini: depends on what you're attaching to that UART. In certain (relatively rare) cases UART adapters can adjust their output voltage to a reference (or just be powered externally) and then you need that board's Vcc as a reference. But most USB UART devices have fixed output voltage so you just need to ensure it matches but do not actually connect Vcc.
<urjaman> (or well, could even cause issues if you power half of an USB-serial thing from the device accidentally, or try to power the device with an USB-serial dongle ...)
<PaulFertser> Those "self-powered" dongles are often problematic, they keep powering the target through Tx (target's Rx) pin while the target is turned off. So it would be much better in general if USB UART devices were actually using that Vcc pin for the reference.
<Borromini> ok, thanks guys
<PaulFertser> In "more professional" settings such as JTAG adapters most often than not connecting target's Vcc is mandatory.
<urjaman> yeah i often tack in resistors both ways on the data lines (to limit the cross-powering) if i expect there to be partially powered situations
<PaulFertser> Yep
<PaulFertser> Good workaround, but it's not always handy.
dhewg has joined #openwrt-devel
<nbd> Hauke: ping
* mwalle doesn't understand the linux/target/. is that loosely based on per SoC?
<shibboleth> yes?
<mwalle> but will that also assume it has the same boot method, for example?
<Borromini> mwalle: no, bootloader isn't something openwrt handles?
<mwalle> Borromini: its more than just the bootloader, e.g. where does the bootloader get the image from. raw nand? partition? what about device trees, and so on. Can this be different for each target inside a linux/target/<subdir>
<mwalle> for example, why isn't there an linux/target/armv8 ? there are rockchip boards octeontx boards, and so on, which are all armv8
<Borromini> i think by now all targets are dts
<Borromini> * dts based
<mwalle> it looks like one major difference are the kernel patches per "SoC/architecture"
<mwalle> but what if you'd need no kernel patches at all because everything is upstream
<Borromini> then you'd have a clean target
<mwalle> right but that target could be a rockchip board or a layercape board. thus why are there different subdirectories for rockchip and layerscape
<mwalle> if i look at the Makefiles there is a thing called "FEATURES" which is different across the various architectures, but there seem to be both SoC specifc stuff as well as board specific stuff
<Hauke> nbd: pong
Borromini has quit [Ping timeout: 265 seconds]
<nbd> Hauke: if you want to push the mac80211 update, you can simply remove 300-mac80211-optimize-skb-resizing.patch
<nbd> i don't have time to rework it at the moment and it's not very important
ericzolf has quit [Remote host closed the connection]
<Hauke> nbd: ok
<nbd> are you going to update it to the latest 5.10 stable version as well?
<Hauke> I plan to prepare that in the next days
<nbd> ok, great
<Hauke> I will first update openwrt to 5.10-rc6
<nbd> ok
feriman has quit [Quit: WeeChat 3.0.1]
feriman has joined #openwrt-devel
Borromini has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
danitool has quit [Read error: No route to host]
<Hauke> nbd: the adapted patch is in the 19.07 branch, see https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=0a59e2a76e6d58d95b8a0bdeca86090ceb794a59
<Hauke> this more or less reverts the upstream change which conflicts with this
<Hauke> should we better remove it there too?
Darkmatter66 has joined #openwrt-devel
adrianschmutzler has joined #openwrt-devel
adrianschmutzler has quit [Client Quit]
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #openwrt-devel
victhor has quit [Read error: Connection reset by peer]
victhor has joined #openwrt-devel
<nbd> Hauke: yes
lipnitsk has joined #openwrt-devel
<nbd> lipnitsk: hi, just wanted to let you know that i've pushed some updates to the flow offload code in my 5.10 patches
<nbd> with a bit of luck there should be no more structural changes coming to the core api
<lipnitsk> hey - I saw - thanks
<lipnitsk> I'll see if I can cobble together PPPoE offload.
<nick[m]1> can someone merge the javascript rewrite of the luci-app-babeld (I'm maintainer)? I would like to go on with further functionality https://github.com/openwrt/luci/pull/4791
<lipnitsk> nbd: question - why does offload seem to stop at DSA when checking the path? I'm imagining a packet flowing from eth0 (WAN) via LAN bridge to eth1. Reading the code, when walking the net_device_path_stack it seems to break out of the loop if it finds the DSA device - don't we want to continue routing until reaching eth1?
<lipnitsk> both xt_FLOWOFFLOAD (hw?) and nft_flow_offload (sw?) seem similar in that regard
victhor has quit [Remote host closed the connection]
<lipnitsk> so the simple route is eth0->dsa->bridge->eth1
<nick[m]1> ping aparcar Why do u need those apply acl lua code stuff?
<lipnitsk> what I want to implement is adding a VLAN at eth0 as well as PPPoE, so the route will be something like eth0->eth0.VLAN->pppoe->dsa->bridge->eth1
Jonny[m]1 has joined #openwrt-devel
<russell--> Borromini: i don't get a stack trace every time, and the messages i do see are different every time
<russell--> it looks to me (from the messages that appear in working boots vs nonworking) like something to do with enumerating the CPUs, possibly some null pointer dereference in an interrupt handler, but just a guess.
rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
eliasmagn has joined #openwrt-devel
<eliasmagn> I would like to discuss the benefits of a stable release branch. I could write a script parsing the github site to find the latest stable release, but when something changes i have to change it. A stable branch would make this unaccessary. In the moment we have tags and releases equal each other. What you people think about that. am i wrong here
<eliasmagn> for such a question?
<aparcar[m]> nick: context?
<nick[m]1> aparcar: javascript rewrite of sysupgrade luci app
<nick[m]1> I can link to code
<nick[m]1> 1s
<nick[m]1> why do u need this?
<nick[m]1> I first used that also in my javascript app, and Jonny removed it
<nick[m]1> the acl seems to work even without doing that lua code
<aparcar[m]> It's old code, before the time where it was possible to write everything in javascript
<aparcar[m]> this is the new code
<nick[m]1> Ah I see thanks! seems like I have to rewrite again ^^
<aparcar[m]> sorry for that
<aparcar[m]> what are you working on?
<nick[m]1> yeah, but just need to rewrite the ubus calls and stuff like this.
<nick[m]1> Could u merge for now this: https://github.com/openwrt/luci/pull/4791 ?
<nick[m]1> its definitely better than the lua code I wrote
<aparcar[m]> there are multiple comments that aren't marked as resolved
<owrt-snap-builds> build #781 of archs38/generic is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/archs38%2Fgeneric/builds/781 blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Stijn Segers <foss@volatilesystems.org>, Daniel Golle <daniel@makrotopia.org>, Martin Kennedy <hurricos@gmail.com>,
<owrt-snap-builds> Rapha?l M?lotte <raphael.melotte@mind.be>
<aparcar[m]> also the table generation doesn't seem to be particularity pretty, isn't there a better way?
<russell--> eliasmagn: is this not a stable release branch? https://github.com/openwrt/openwrt/tree/openwrt-19.07
<nbd> lipnitsk: dsa has a handler for the tc flow block setup
<nbd> in the slave device
<nbd> that handler forwards the call to eth0/eth1
<lipnitsk> okay, so two hash entries instead of one?
<nick[m]1> @apa
<lipnitsk> basically we offload up to dsa and then again dsa and beyond?
<nbd> lipnitsk: same number of flow entries as before
<nbd> no, the full thing gets offloaded
<nbd> just the way it's called is a bit different
<nbd> i preferred the old approach, but pablo really wants it this way
<lipnitsk> well whatever makes it upstream I guess
<nick[m]1> aparcar: I was not able to mark them as resolved. I deleted them now. Yes. this implementation looks more elegant.
<nick[m]1> thanks for pointing me to this
<lipnitsk> I was just confused, because I thought we had to walk the full path from eth0 to eth1 when computing the destination address, but the logic seems to stop short at dsa
<aparcar[m]> nick: I'm fine merging that and it's improved in some future, your choice
Net147_ has quit [Quit: Quit]
Net147 has joined #openwrt-devel
feriman has quit [Quit: WeeChat 3.0.1]
<nick[m]1> aparcar Nice. Yeah, I just wrote Jonny that he should put also the uci-default into it that enables ubus on babeld. Afterwards, I ping u again. :)
<aparcar[m]> nick: ack
shibboleth has quit [Quit: shibboleth]
danitool has joined #openwrt-devel
pocock has joined #openwrt-devel
pocock has quit [Quit: Leaving]
Borromini has quit [Quit: Lost terminal]
<eliasmagn> russell--  you are right i am blind; thank you!
<russell--> eliasmagn: np
rmilecki has quit [Ping timeout: 240 seconds]
adrianschmutzler has joined #openwrt-devel
adrianschmutzler has quit [Client Quit]
voxadam has quit [Ping timeout: 264 seconds]
Tost has quit [Ping timeout: 246 seconds]
blb4393 has quit [Ping timeout: 264 seconds]
ivanich has quit [Remote host closed the connection]
dedeckeh has quit [Quit: Connection closed]
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #openwrt-devel