Rentong has quit [Remote host closed the connection]
<Grommish>
Ok.. Silly question, anyone familar with the DSA system want to help me by finishing a patch for enabling net_dsa_debugfs? I've cut the patch by hand into the build system because of the openwrt specific changes, but I don't know C well enough to reasonably correct it within a decent time frame.
<Grommish>
I'm being lazy and don't want to pick up enough C to fix it if I don't have to
<hexagonwin[m]>
Oh, and I also can't gain any shell with uart. I can do tftp mode, just boot, and "flash test" (nand flash test).
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Rentong has joined #openwrt-devel
valku has quit [Quit: valku]
Rentong has quit [Ping timeout: 480 seconds]
<digitalcircuit>
Brief NBG6817 ipq806x 1.4 GHz L2 cache crash debugging update: this upcoming Monday I should have a new, over-specc'd (12VDC 5 amp) power supply, and an independently powered USB 3.0 hub. I'll try to rule out a failing power supply and/or the bus-powered external USB HDD loading the USB 3.0 port on the router. Also still need to look into DTS(I) CPU voltage tweaks.
<digitalcircuit>
In the meantime, I've refreshed my patches (mentioned in the GitHub comparisons linked here: https://lists.openwrt.org/pipermail/openwrt-devel/2021-July/035889.html ) to the latest, slightly-after 21.02.0rc4 code. Which.. broke stress-ng, because the update was backported. Gotta look into that some day.
<digitalcircuit>
(Well, not my patches. I haven't submitted official patches yet because I'm not yet confident the issue is unrelated to this.)
<slh>
digitalcircuit: btw. my nbg6817 suddenly rebooted (again) after 13 days last night, while not doing a whole lot (and wireless being disabled)
<digitalcircuit>
slh: Oh, huh! Hmm... Now I'm wondering if the maximum allowed L2 cache frequency has any impact on your situation (doubtful though).
<fda>
the startlevel are not well sorted. dropbear and firewall have both 19, D is alphabetical before F. as the dropbear init script cant handle new ip (v6) assignments, most people use 0.0.0.0
<slh>
I finally got the second hand ASRock G10 at the end of this week, now working on replicating my setup for a cross check
<fda>
so in a short period of time wan access is allowed for dropbear, and not blocked due to related. it should have level 21 or so
<fda>
ntp has S98, this is bad for things like log, statistrics or vnstat, which have a lower startlevel
<digitalcircuit>
slh: Noted, and good luck!
<fda>
and im also wondering why so less packages have no K(ill) scripts, like samba and its copy ksmbd
<fda>
this could block correct unmount of storages and cause fs errors
<fda>
or better: move firewall down to S15, before all network daemons
<PaulFertser>
hexagonwin[m]: so not really comfortable to read on IRC. To answer your question, those are RAM addresses, they're specified in Makefile, not by DTS, and you shouldn't be changing them.
<PaulFertser>
hexagonwin[m]: usually it's easier to build initramfs images and upload to RAM using bootloader and test that.
<hexagonwin[m]>
I am sorry. I am in matrix not irc..
<hexagonwin[m]>
Thank you for your answer
<hexagonwin[m]>
<PaulFertser> "hexagonwin: usually it's..." <- do you mean tftpboot?
danitool has joined #openwrt-devel
Borromini has quit [Quit: leaving]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
rsalvaterra has joined #openwrt-devel
noltari_ has quit [Read error: Connection reset by peer]
jlsalvador2 has joined #openwrt-devel
danitool has quit [charon.oftc.net liquid.oftc.net]
lynxis has quit [charon.oftc.net liquid.oftc.net]
clayface has quit [charon.oftc.net liquid.oftc.net]
jlsalvador has quit [charon.oftc.net liquid.oftc.net]
pkgadd has quit [charon.oftc.net liquid.oftc.net]
owrt-snap-builds has quit [charon.oftc.net liquid.oftc.net]
retoatwork has quit [charon.oftc.net liquid.oftc.net]
wb9688 has quit [charon.oftc.net liquid.oftc.net]
owrt-2102-builds has quit [charon.oftc.net liquid.oftc.net]
blocktrron_ has quit [charon.oftc.net liquid.oftc.net]
swegener has quit [charon.oftc.net liquid.oftc.net]
nbd has quit [charon.oftc.net liquid.oftc.net]
hauke has quit [charon.oftc.net liquid.oftc.net]
Habbie has quit [charon.oftc.net liquid.oftc.net]
DLange has quit [charon.oftc.net liquid.oftc.net]
jschwart has quit [charon.oftc.net liquid.oftc.net]
Pepes has quit [charon.oftc.net liquid.oftc.net]
rsalvaterra has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
rsalvaterra has joined #openwrt-devel
noltari has joined #openwrt-devel
clayface has joined #openwrt-devel
retoatwork has joined #openwrt-devel
nbd has joined #openwrt-devel
swegener has joined #openwrt-devel
danitool has joined #openwrt-devel
lynxis has joined #openwrt-devel
will[m] has joined #openwrt-devel
pavlix has joined #openwrt-devel
Q__ has joined #openwrt-devel
bluse-blue[m] has joined #openwrt-devel
aparcar[m] has joined #openwrt-devel
Guest3147 has joined #openwrt-devel
DLange has joined #openwrt-devel
owrt-2102-builds has joined #openwrt-devel
owrt-snap-builds has joined #openwrt-devel
blocktrron_ has joined #openwrt-devel
pkgadd has joined #openwrt-devel
Pepes has joined #openwrt-devel
jschwart has joined #openwrt-devel
Habbie has joined #openwrt-devel
wb9688 has joined #openwrt-devel
hauke has joined #openwrt-devel
FLD has joined #openwrt-devel
FLD has quit [Ping timeout: 480 seconds]
owrt-snap-builds has quit [charon.oftc.net liquid.oftc.net]
will[m] has quit [charon.oftc.net liquid.oftc.net]
bluse-blue[m] has quit [charon.oftc.net liquid.oftc.net]
blocktrron_ has quit [charon.oftc.net liquid.oftc.net]
Guest3147 has quit [charon.oftc.net liquid.oftc.net]
aparcar[m] has quit [charon.oftc.net liquid.oftc.net]
owrt-2102-builds has quit [charon.oftc.net liquid.oftc.net]
pavlix has quit [charon.oftc.net liquid.oftc.net]
hauke has quit [charon.oftc.net liquid.oftc.net]
Pepes has quit [charon.oftc.net liquid.oftc.net]
pkgadd has quit [charon.oftc.net liquid.oftc.net]
Habbie has quit [charon.oftc.net liquid.oftc.net]
jschwart has quit [charon.oftc.net liquid.oftc.net]
DLange has quit [charon.oftc.net liquid.oftc.net]
wb9688 has quit [charon.oftc.net liquid.oftc.net]
lynxis has quit [charon.oftc.net liquid.oftc.net]
danitool has quit [charon.oftc.net liquid.oftc.net]
Q__ has quit [charon.oftc.net liquid.oftc.net]
owrt-snap-builds has joined #openwrt-devel
FLD has joined #openwrt-devel
owrt-2102-builds has joined #openwrt-devel
rsalvaterra has quit [Quit: Leaving]
<hexagonwin[m]>
Thank you, with that patch I can boot owrt in my router!!
<hexagonwin[m]>
By the way I can't find swconfig which I need for fixing the lan ports how should I find it? Thanks.
<hexagonwin[m]>
running swconfig returns command not found
<russell-->
hexagonwin[m]: is it using DSA?
<hexagonwin[m]>
russell--: i'm sorry, what is it?
<hexagonwin[m]>
it's a ramips target
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
Rentong has joined #openwrt-devel
<stintel>
ramips is dsa - google it, you'll find the forum post you need
dangole has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Tusker has joined #openwrt-devel
<Tusker>
good day PaulFertser, you in the mood to think about how to get the gmac0 working properly ? :)
<PaulFertser>
Tusker: hey :) I do not really have any more ideas about it unfortunately.
<Tusker>
do you know where I can look for clock frequency for stmmac ? The factory firmware manually puts in some clock speed and turns off auto clock speed... so maybe it is related ?
<Tusker>
or, because it works after pinging in uboot, it's likely to be just some reset on some gpios etc ?
arifre has joined #openwrt-devel
<hexagonwin[m]>
@stintel Sorry but I can't find it :( Sorry but can you please link one? Thanks.
<PaulFertser>
hexagonwin[m]: swconfig is OpenWrt specific way to control integrated switches. OpenWrt is moving to upstream Linux DSA, you should be able to see DSA docks in the kernel Documentation.
hauke has joined #openwrt-devel
<hexagonwin[m]>
Thanks.
fda- has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
<Tusker>
PaulFertser: https://github.com/openwrt/openwrt/pull/4158 looks like a similar device with similar weird gmac issues, perhaps need a reset on one of the gpio, like 6 or 7
<Tusker>
heya clayface, I see you've done some work on the ipq8068 on the mr42 and mr52, how did you figure out the reset-gpios on pin 7 and 6 ?
Tapper has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
rejoicetreat has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
<fda>
blocktrron_: sry, i had a disconnect. not sure if this was visible: "the avm7320 worked good, but after updating git i got this crash. and there where changes related to MAC by you"
<blocktrron_>
That message passed
<blocktrron_>
Did you bisect it to this specific commit / fixes reverting this commit the issue you are facing?
<blocktrron_>
I don't see how they should have caused the kernel trace you've linked
<blocktrron_>
I do much rather suspect a kernel version bump
<fda>
im currently trying to get the device working again, i use it only for testing. with kernel 5.4.138 there is als only "BUG+0x0/0x4" + "kmem_cache_free_bulk"
dedeckeh has quit [Remote host closed the connection]
<fda>
i found on internet only en openwrt bugreport which was related to ksmbd, and ive installed this also on this device
<fda>
but 2second after boot this should not matter
Rentong has joined #openwrt-devel
<fda>
blocktrron_: ive flashed 4baf47b9a8 this works
Rentong has quit [Ping timeout: 480 seconds]
KGB-0 has quit [Quit: KGB-0]
<blocktrron_>
so 4baf47b9a8+1 broke it?
KGB-0 has joined #openwrt-devel
<fda>
blocktrron_: 4baf47b9a8+x , dont know which commit causes it, sadly i wrote some days ago not which was the first bad revision
<fda>
but i wrote above edb6bc1 works too which is 4baf47b9a8+5 ...
KGB-0 has quit [Quit: KGB-0]
KGB-0 has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
<blocktrron_>
You can try to replace the kree call with "return 0;"
<blocktrron_>
at least that loooks the most obviously wrong to me
<blocktrron_>
I've spent a good hour reviewing this hudge patch after the initial patch broke stuff left and right.
<blocktrron_>
If it wouldn't be a huge mess, I'd be for just reverting it and waiting for us to track the upstream kernel which has the feature
<blocktrron_>
given we seem to not win anything from it atm
<fda>
ill try, compiling takes some time
<fda>
thx!
<blocktrron_>
sorry if i sound way to frustrated
<fda>
there are mayn things broken over time on openwrt ...
<fda>
currently is ksmbd not compilable for this device because of an update these days
<fda>
but compile fail is better than boot fail :)
<slh>
global changes like nvmem are always difficult, it's never possible to get testing coverage for all (or enough) targets, let alone all devices
<blocktrron_>
I have no issue with breakage, if fixing it is straightforward
<blocktrron_>
slh: i agree, but i get the feeling instead of throwing massive backports on top of it, taking the step back and taking another shot at it when upstream has it woul've been the better decision
<dangole>
in this case (of/mac-address/nvmem) the breakage is just in a lot of places. none of them is difficult to fix, and most of it was difficult or nearly impossible to predict...
<fda>
global changes are not easy to find. my 1200 was initial also broken with git, and worked with 19
<slh>
it's a difficult judgement call, relatively large changes vs ease of support for newer devices
<blocktrron_>
slh: where is it required for newer devices?
<slh>
blocktrron_: not required, but keeping track of the difference mainline vs OpenWrt (DTS in particular) gets more difficult
<blocktrron_>
To my knowledge, it's set to replace the mtd hack + allows to reference MAc addresses from I2C eeprom (currently done in userspace)
<blocktrron_>
fda: there are most likely more devices out there which broke the same way as the 1200
<slh>
either getting the backport right, once - or having to track down all the devices again at a later point
<blocktrron_>
agreed
<fda>
blocktrron_: how sould the user find the cause for not booting? i had to buy T5 torx and attach serial console. i think most will not do it
<blocktrron_>
I'm not blaming here, I'm just trying to retroactively question the path I / we have taken and maybe if we should have handled it in a different way
<blocktrron_>
fda: booting works, ethernet was one-firection deaf
<fda>
yes, i tested it
<hauke>
blocktrron_: I am just fixing the compile on layerscape and omap which was broken by the of_get_mac_address() patch
<slh>
I wonder how little (as an external bystander without those devices) fallout there's been with the switch to DSA for ramips and mvebu, looking at the details necessary for ipq806x (port order, device quirks, MAC assignments, etc.)
<fda>
funny thing: the 1200 which could not send network ansers or anser pings, filled its arp cache with devices trying to reach it
<blocktrron_>
hauke: thanks - even though i was not aware about that breakage
<blocktrron_>
fda: rx works, so it learns mac addresses from incoming packets
<slh>
most of them small details, some very complex (the quirks handled differently in both drivers), but very difficult to judge without anyone testing the affected hardware (and getting tested-by's is even difficult for common devices)
<blocktrron_>
slh: given mt7621 has en embedded switch, i suspect the breakage is very limited, at least until the pile of hacks for the RGMII / SFP support is used
<blocktrron_>
Funny: that broke when backporting the latest at803x fixes
<fda>
is there an unsupported switch in mt7621?
goliath has quit [Quit: SIGSEGV]
<fda>
with e8450 it a little work to configure vlans, but works like devices with seitches
<fda>
seitches=switches
<slh>
blocktrron_: yeah, mt762x seems to be a bit more uniform across the board, but most ipq806x are technically also all using the same qca8337 switch (aside from very few APs with only two ports). still, it took a lot of effort to get my nbg6817 working (thanks to Ansuel's work to get the MDIO communication working properly, which apparently had slightly different needs as all previously tested devices) -
<slh>
in comparison the ASRock G10 was easy, just having to fix the port order and MAC assignments
<slh>
but still, lots of small details necessary
<fda>
blocktrron_: i compiled head-master with the 1 line changed, works!
<blocktrron_>
fda: thanks, I'll work on a proper fix, ping me in case you don't hear anything itll tomorrow evening
<fda>
does it something which is not visible? (this was alsways this way)
<blocktrron_>
fda: on firstboot: most likely generating SSH keys
<fda>
this 1min-break is always
<blocktrron_>
fda: given you have serial access - you can check which processes are running during this period
<fda>
i have serial acces - otherwise i would not see it without network :)
<blocktrron_>
slh: from my perception, the amount of small fixes necessary for ipq806x come from the limited amount of different boards used with OpenWrt & lacking documentation of the chip itself
<blocktrron_>
It's the same for ipq40xx, which always is sifting through QSDK + GPL tarballs
<fda>
blocktrron_: i exec some "ps" and the /etc/rc.d/SXXxxxxx where running. maybe i thought its always that slow, as i reboot the device only to sysupgrade (which restores overlay after 1st boot?)
<slh>
quite possibly, yes
<slh>
probably also caused by it being more geared towards the higher end, meaning that the more traditional vendors try to diverge from the example devboards to make their devices stand out from the competition, rather than trying to push out the cheapest possible device
<blocktrron_>
fda: if this is the case, restoring the FS is most likely the reason, yes
<fda>
as a new openwrt user im surprised how cheap good devices are! e8450 has everything i need (more ram & cpu i need) for less than 100 euro. a common fritzbox is at 200-250 euro
<slh>
availability and pricing of devices differs a lot. until rather recently, only mvebu or ipq806x would cover the higher end (and ipq806x only up to ~550-650 MBit/s without SQM or ~200 MBit/s with SQM) - for wifi6, there are now a couple of new options, some of them surprisingly cheap - some really expensive
<slh>
e.g. ipq807x (for >=ipq8072) usually starts around 350 EUR, only xiaomi pushes the lower boundaries with their ipq8071a based ax3600 (started around ~110 EUR, now ~70 EUR) and ipq8072a based ax9000 (still around 150 EUR)
<fda>
is there a openwrt supported device which can route+nat 1gbit? imho sqm is not needed for such a bandwith
<slh>
fda: /many/ enthusiast OpenWrt users would disagree about SQM not being necessary for those speeds (never used it myself, and my nbg6817 couldn't keep up with sqm at 400/200 MBit/s anyways)
<fda>
i can also not use it as my bandwitch is 5-150 mbit...
<fda>
btw, i think a additional column in TOH with max routing speed would be great
<slh>
fda: the rt3200 might come close (feedback about that are a bit inconclusive), ipq807x should as well (the verdict is still pending how much of that it can do without NSS offloading for ipq8071a (4*1.4 GHz), but at least >=ipq8072a should be able to do that (4*2.2 GHz))
<slh>
fda: those figures are very hard to come by, as you need reliable feedback from users both having the device and a network connection fast enough (as synthetic benchmarks don't tell the whole picture) - and that's before thinking about the impact of PPPoE (yes, that's still a thing for some fibre ISPs at 1 GBit/s - and PPPoE is a huge performance impact)
<fda>
for the begin, it could be added like "can handle my 500 mbit connection"
<slh>
fda: case in point, I see quite often claims that the archer c7 would achieve over 600 MBit/s (and then complaints about ipq806x only achieving ~550-650 MBit/s), but what they fail to tell (SoC overclocked to 1 GHz, software-flowoffloading or SFE, no PPPoE, etc)
<Tusker>
maybe there should be a similar package like "popularity-contest" from debian, where there is feedback provided automatically from a system package that gathers some basic statistics
<fda>
best would bw plan routing+nat performance, without other, tested with 2 fast computers
<fda>
this would be a "max"
clayface has quit [Read error: Connection reset by peer]
<fda>
and a "min" what some users report
<slh>
I have tested my tl-wdr4300 (ar9344 @560 MHz) on my 400/200 MBit/s connection (plain DHCP, no PPPoE) last week, result: ~170 MBit/s, but veeery jagged results (you really see it ramping up and down on the throughput diagram), so the CPU is overloaded and lags is down the drain (maybe it can do ~120-130 MBit/s without hitting the limits) - with software-flowoffloading it can just achieve 400/200 MBit/s
<slh>
(but I'm not counting software flow-offloading)
clayface has joined #openwrt-devel
<Tusker>
clayface: you actually around ? or just autojoin
<slh>
so yes, the archer c7 runs (depending on the model) at 720-750 MHz and will be ~25% faster - but still, I wouldn't use it above 180-200 MBit/s
<slh>
if I just test iperf3 through an ipq8065 device, I can get 930 MBit/s <-- far from real-world testing (~550-650 MBit/s)
<fda>
my e8450 runs most time at lowest 300mhz, when ther is a max150mbit download it is at 400-600 mhz: https://ibb.co/SBQM23s
<fda>
so i think 500 should no be a problem
<fda>
500mbit
<fda>
before the e8450 i had 1 week a c7v5, but everything including luci where to slow
<fda>
but such an min/max throughput could help to decide for a new device
<slh>
don't get me wrong, I'd very much like to know those figures (and I'm regularly looking for that kind of feedback as well), but it's very hard to come up with dependable figures
<fda>
yes, if during a speedtest some vpn services are running it could take much cpu, and throughput is slower
<fda>
btw, i first bought C7 as many people wrote its very fast :))
<slh>
especially as many/ most e8450/ rt3200 users can't max out their device's performance (contractual WAN speeds not fast enough). the curse of enthusiast devices, when I got my nbg6817 (ipq8065) in 2017, I was still 100/40 MBit/s with no hope for improvments (so vastly overkill for my connection back then, now I'm happy that it can still cope with my new fibre line at 400/200 MBit/s (but without much
<slh>
headroom left, so I am looking for alternatives with more headroom))
jlsalvador has quit [Read error: No route to host]
<slh>
(because 1000/500 MBit/s would be just a phone call, and deeper pockets to pay the higher monthly fees, away)
jlsalvador has joined #openwrt-devel
<Tusker>
slh: yeah, it is definitely tempting to just get 1000/400, but given that I don't saturate my 100/40, it is not justified :)
<fda>
hey, i was upgraded last year to new haispeed 50/10 (maximum, not reachable)
<slh>
Tusker: I wouldn't have needed the speedup either, but it was a matter of getting fibre (the physical connection of the house) for 'free' or having to pay >750 EUR a few years later to get connected
<Tusker>
*nods* so far the fibre upgrade would cost me too much per month, to have it included for free
<slh>
+5 EUR in my case, relative to my previous 100/40 MBit/s VDSL2 connection (~94/34 MBit/s achievable)
<Tusker>
then definitely worth doing :)
<slh>
so a break-even of ~7-8 years, all in (counting all the small fees involved)
<fda>
some of the above listed 1gbit devices are very expensive, up to 500 euro ^^
<slh>
fda: RPi4 or x86_64 with additional APs and a managed switch make sense at those speeds
<fda>
from this pov a avm7590 with 4x1ghz cpu and 512mb could be an option - but no openwrt support currently
<fda>
a rpi4 can handle this? 2nd lan then by usb3 or as vlan?
<fda>
wow, as i gought RT3200 it was 88 euro, now its 152 at amazon!
<slh>
fda: according to many, yes - even with SQM. second USB3 ethernet card (or RPi CM4 compute module with e.g. dfrobot dual-gbit/s carrier board, which connects a second ethernet cards via PCIe)
<slh>
it has been 94-95 EUR for the last couple of weeks from amazon.de (even until yesterday)
<slh>
https://www.dfrobot.com/product-2242.html that or the r4s have been tempting me for a while, but all-in, the prices are a bit too high for my taste (considering that those still need a managed switch and APs to compete with a more traditional router)
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
<fda>
i did a quick test with my rpi4-4gb, it seems it could not receive by samba at constant speed 1gbit, cpu load was 3,99
<fda>
so for 1gbit nothing else should run on this device
<slh>
samba/ cifs is a bit of a different question than 'just' routing
<fda>
i know
<fda>
but pppoe, ....
<fda>
nat, iptables
<fda>
i wrote to an attached usb3 ssd, so usb speed should also be "okay"