<rsalvaterra>
[OT] Holy hell, rpc.idmapd still requires dnotify… in Debian Sid…?! This was fixed in 2018…! o_O http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=cec1278cdb385188cdf6b693fda1b00f9b93df55
ivanich has quit [Quit: Konversation terminated!]
Bubz0 has quit [Quit: Connection closed]
Grommish has quit [Read error: Connection reset by peer]
romany has quit [Quit: Ping timeout (120 seconds)]
romany has joined #openwrt-devel
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
<Grommish>
Can anyone point me in the direction to where I can find the stock compat string for the the ER10x on the stock system so I can put it into the SUPPORTED_DEVICES string in the .mk?
zkrx has quit [Ping timeout: 276 seconds]
<Grommish>
/tmp/device_model?
<lipnitsk>
rsalvaterra: both gdma and hsdma are marked "disabled" in mt7621.dtsi, does any device actually enable them?
Cabral has quit [Quit: I left, Guys. To send a hello chat@sergiocabral.com]
heffer has joined #openwrt-devel
SergioCabral has joined #openwrt-devel
max-b has quit [Ping timeout: 268 seconds]
max-b has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 256 seconds]
jmv09 has quit [Ping timeout: 240 seconds]
dengqf6 has quit [Ping timeout: 272 seconds]
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
dengqf6 has joined #openwrt-devel
silverwhitefish has joined #openwrt-devel
luke-jr has quit [Read error: Connection reset by peer]
<Grommish>
Well.. I've got Openwrt installed, the lower ports set, running 5.10.20 on this ER10x.. Now the fun can begin
<Grommish>
although I'm not impressed with the throughput, but I think that's a known limitation
luke-jr has joined #openwrt-devel
rmilecki has joined #openwrt-devel
<damex>
Grommish: there is two 1gbe links and to forward something close to it - it needs hw acceleration. mt7621 has it
<damex>
device is supposed to be <two switches on one board>
<damex>
to be/ to have
<Grommish>
Yeah, I'v got ports 0-4 working, 5-9 not yet, but the port 2 to 0 speedtest maxes out at under 600 down
<damex>
Grommish: stock have nothing to do about it. you need a working device tree where you define your device name that later be used across the tree. mt7621.
<Grommish>
damex: Well, I was being particularly dense about the device. Ubiquity is hash checking under v2
<damex>
second switch is RTL8367RB
<Grommish>
damex: So I can't just load the bin via the online internet or add system image command
<damex>
it might work like on er-x but i have no clue what exactly is needed to make it work
<damex>
check er-x implementation - it works upgrading from some edgeos firmwares. not all of them
mangix has quit [Remote host closed the connection]
mangix has joined #openwrt-devel
<Grommish>
Yeah, v1 I think you could, v2 you can't
<Grommish>
damex: I just tftp load the initial image and be done with it.. Now, I need to figure out hte rest of it
<Grommish>
damex: mt7530 mdio-bus:1f: configuring for fixed/rgmii link mode rgmii seems to be up, but nothing on the ports
<Rene__>
Grommish: because the switch is on port 5 of the MT7621 switch, you have to the RGMII2 group to function RGMII.
<Rene__>
brb, reboot the system
Rene__ has quit [Quit: leaving]
<Grommish>
Rene__: I'm showing the mac@1 under the ethernet as disabled.. I'm going to try to set it to Okay and see what happens
goliath has joined #openwrt-devel
<russell-->
Grommish: when i was testing the 5-port ERX a few years ago i would see either 500Mbps, 750Mbps or about a gig on different runs of iperf through a NAT, but it was consistent within the run
<russell-->
the er10x seems to be unavailable at the moment, i was thinking of buying one, but i guess not
<Grommish>
I've got the stock dts I pulled and I'm trying to see what is different from the dts I pulled from the openwrt run
nslu2-log has quit [Remote host closed the connection]
gnslu2-lo has quit [Remote host closed the connection]
nslu2-log has joined #openwrt-devel
nslu2-log_ has joined #openwrt-devel
Tost has joined #openwrt-devel
Rene__ has joined #openwrt-devel
<mangix>
Rene__: I'm showing the mac@1 under the ethernet as disabled.. I'm going to try to set it to Okay and see what happens <-- Grommish
<rsalvaterra>
lipnitsk: Yes, some do, so they're probably disabled for some reason, I don't know which.
<Grommish>
So, I'll turn it on and see if it actually does anything :D
<Rene__>
Grommish: do you have the dmesg of ubnt firmware? look for "change HW-TRAP to 0x" to see how the mt7530 is configured.
<Grommish>
Rene__: Sure.. one minute.. I'm building and I'll flash and check
<rsalvaterra>
mangix: I now have a 100 % working configuration with Linux 5.10 on ramips/mt7621. I'm going to apply your musl series, make dirclean an build a new image. Hopefully the problems I've been seeing were caused by a dirty tree.
<Grommish>
Rene__: Bootlogs.. OpenWrt on top, Stock EdgeOS at the bottom
<Rene__>
Grommish: Based on the HW-TRAP settings from stock firmware. P5 is used and set in RGMII mode. Based on the gsw_mt7621 code no extra delay is needed so phy-mode = "rgmii";
ivanich has joined #openwrt-devel
victhor has joined #openwrt-devel
<Grommish>
Rene__: in the mt7621.dtsi, pcie: pcie@1e140000 is status = "disabled"; Would that make a difference?
<Grommish>
Sorry, again, my tree knowledge is almost non-existant
<Rene__>
Grommish: no, I am also not a dt expert, but pcie has no part in the ethernet part.
<guidosarducci>
rsalvaterra: I knew you'd say that, but really it's more about what's better/correct rather than less weird. Things aren't ideal now with kitchen-sink packages like kmod-sched, but the proposed change is still an improvement. jow was pinged as part of the prior discussion so I hope to hear from him too.
<Rene__>
Grommish: Is the realtek rtl8367b a mainline kernel driver?
<rsalvaterra>
guidosarducci: Sure, it's just my €0,02. ;) The kmod-sched package really needs to be split up (and probably sqm-scripts, since most people just want to "eat" cake)…
<russell-->
guidosarducci: it's up to the taste police ... i still kind of like my add a package for the script, it's no different size-wise than your patch, you need all the parts one way or the other. secondly, if you really want to save space by splitting the kmod, it doesn't look that difficult.
<rsalvaterra>
russell--: The problem is, if you split kmod-sched, sqm-scripts will still depend on all the split packages, because I contains scripts which use all the schedulers, even if you're not using them at all.
<russell-->
no different than now
<guidosarducci>
rsalvaterra: not a problem: compat virtual packages, etc.
<guidosarducci>
and consumers of those packages would *want* to adjust their own dependencies.
<guidosarducci>
rsalvaterra: I think russell-- is only talking about splitting off kmod-sched-teql, and not the larger refactoring I've wanted for a long time. That's doable, I just worry about having time. Do we know when 21.02 is expected, 'cause I'd like to get the latest iproute2 in there?
<rsalvaterra>
mangix: Not yet, on 5.10. I think nbd is working on it.
<mangix>
oh it's not working in general? what about 5.4?
<nbd_>
mangix: please try it with 5.10 (using the commit from my staging tree) and let me know if it works for you
<rsalvaterra>
guidosarducci: I believe the timeframe is the usual one, "when it's done", but since it was branched already, it should be out in the next few months, I wager… :/
<guidosarducci>
russell--: I'll look into splitting off a kmod-sched-teql. Suggestions for the top-level teql pkg name?
<mangix>
nbd_: great
koniu has quit [Ping timeout: 268 seconds]
<rsalvaterra>
noltari: I see GPON definitions on that header…! :O
<Rene__>
Grommish: I see mixed results about the MDIO bus of realtek device. I may work on the MDIO bus of the internal switch. If that is that case that you have to say to the realtek driver which mdio bus to use.
<guidosarducci>
russell--: but how likely is that split teql package to be backported? There's a good case to be made for iproute2...
<rsalvaterra>
noltari: Is there an easy way to find the CFE password? :)
<Rene__>
Other option is that it uses gpio-bit-banging to transfer mdio data to the realtek device. Then you have to specify the two gpio pins that are used.
<noltari>
rsalvaterra: first time I know about such thing as a CFE password xD
<rsalvaterra>
noltari: Oh, my… :P
<noltari>
none of my devices have a CFE password
<russell-->
guidosarducci: teql-script
<russell-->
or something
<rsalvaterra>
Yeah, when you try to break the boot process, CFE asks for a password. :)
<noltari>
BCM6838 seems to be newer, maybe that's why it has a password...
<guidosarducci>
russell--: do we have "hotplug" packages?
<noltari>
rsalvaterra: maybe you could find the password in the official firmware or GPL sources (if available)
<Rene__>
Grommish: An other thing is that currently MT7530 doesn't support fixed link on PORT 5 when used as switch port. It always expect an PHY on the other side.
<rsalvaterra>
noltari: I sent an email to Altice asking for the sources. The answer was crickets, of course. :P
<guidosarducci>
WTH, visting family and seeing 10% packet loss and up to 600ms latencies. Congratulations on your Puma6 modem purchase!
<noltari>
rsalvaterra: yeah I sent a request to ZyXEL a month ago and I got the same answer
<russell-->
git grep PKG_NAME
<noltari>
"This firmware was released more than 3 years ago, so we aren't forced to keep the GPL sources that long"
<noltari>
WTF?
<russell-->
3 years is a relevant duration if they provided a written offer in lieu of distributing source with the binary, iirc
<guidosarducci>
russell--: already did: we have things like "button-hotplug", so "teql-hotplug" sounds good.
<russell-->
there is qos-scripts too
<guidosarducci>
russell--: true, though that class of packages has pretty broad functionality...
<russell-->
and a bunch more in the packages feed
<russell-->
no $foo-hotplug in packages feed
<guidosarducci>
russell--: I was thinking under package/kernel rather than package feed. Problem?
koniu has joined #openwrt-devel
<russell-->
no, just surveying existing PKG_NAMES
<russell-->
who actually uses teql?
<rsalvaterra>
noltari: If they actually delete the sources (I doubt it), it should be forbidden… :/
<guidosarducci>
russell--: no one that I know, but someone will surely scream if it breaks...
<rsalvaterra>
russell--: dwmw2 uses (or used) teql. He actually wrote that script.
<mangix>
rsalvaterra: reboot and holding power button were not enough on this laptop
<rsalvaterra>
mangix: To me it feels like Intel does the bare minimum to get their Wi-Fi devices working. I don't know why, they should take a long look at their graphics team, to learn how it's done.
<mangix>
rsalvaterra: we talking linux or windows?
<plntyk>
rsalvaterra, well even graphics team takes time to fix bugs - like ~4 stable kernel releases to fix non usable graphics (5.7(broken)->5.10)
<rsalvaterra>
mangix: I only tal Linux, sorry if it wasn't clear. :)
<rsalvaterra>
*talk
snh has quit [Ping timeout: 265 seconds]
<mangix>
rsalvaterra: that card might be one with dead support unfortunately
<mangix>
the 8265 is still well supported oddly enough
<rsalvaterra>
mangix: Can't replace it. Lenovo signed BIOS, card whitelist. It's atrocious.
<guidosarducci>
mangix: FYI, your commit message said problem with "__maybe_inline" definition, about which I could find *nothing* when I last looked, but your logs instead show a problem with "__always_inline". Important distinction :) I'm more worried about the 2700 "invalid symbol" error messages in that log, which I've never seen. I gather the patch makes it compile finally, but does it actually work?
<plntyk>
arent those whitelists/lenovo bios entries hackable ?
<rsalvaterra>
plntyk: Signed bios… change the signature and it won't flash.
<plntyk>
ah k
<mangix>
guidosarducci: why wouldn't it?
<plntyk>
so there previous hacks where on unsigned hw
<plntyk>
bios
<mangix>
rsalvaterra: ahem
<mangix>
spi flash
<rsalvaterra>
mangix: Don't tell me to desolder the flash chip, please.
<mangix>
lol no
<mangix>
use a SOIC8 clip
<rsalvaterra>
mangix: Have you tried to disassemble a cheap laptop? It's not pretty. :P
<mangix>
i have unfortunately
<rsalvaterra>
I've read somewhere someone did it, and actually hacked the BIOS (some Portuguese guy, actually; even crazier than me).
* russell--
recalls a linuxconf talk, i think it was about keyboards though
<mangix>
anyway, these signed BIOSes are annoyingh
<dwmw2>
russell--: The ticket made the use case fairly clear, didn't it? I had bonded ADSL lines, needed to use them both equally for uplink
<mangix>
rsalvaterra: my interpretation of the commit i linked to is that those are the currently supported models. those and newer.
linzst has joined #openwrt-devel
JuniorJPDJ has quit [Quit: Bridge terminating on SIGTERM]
decke[m] has quit [Quit: Bridge terminating on SIGTERM]
<russell-->
dwmw2: yes, that is clear
aparcar[m]1 has quit [Quit: Bridge terminating on SIGTERM]
lipnitsk has quit [Quit: Bridge terminating on SIGTERM]
MatMaul has quit [Quit: Bridge terminating on SIGTERM]
olmari has quit [Quit: Bridge terminating on SIGTERM]
Jonny[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Q_ has quit [Quit: Bridge terminating on SIGTERM]
pgwipeout[m] has quit [Quit: Bridge terminating on SIGTERM]
voltagex has quit [Quit: Bridge terminating on SIGTERM]
agb[m] has quit [Quit: Bridge terminating on SIGTERM]
nick[m] has quit [Quit: Bridge terminating on SIGTERM]
fblaese has quit [Quit: Bridge terminating on SIGTERM]
shalzz has quit [Quit: Bridge terminating on SIGTERM]
<mangix>
rsalvaterra: this was actually always a problem, but musl’s headers never caused any issues until 1.2 where __BIG and __LITTLE_ENDIAN are always defined by every header.
<stintel>
so the image is signed somehow, breaking the metadata check ?
<noltari>
stintel: there were some changes from the RPi Foundation on latest patches update which added support for LEDs on newer devices, but it could affect the old ones...
<stintel>
noltari: the LED was already supported and disabled when boot finished (after wifi)
<rsalvaterra>
lipnitsk: Ah, yes, I already read your email exchange with Eric W. Biederman. :)
<lipnitsk>
i think we need to investigate what's calling stuff so early but it's not a showstopper
<rsalvaterra>
Oh, and Linus chimed in too.
<lipnitsk>
yeah...
<rsalvaterra>
"MOST of the later MIPS architectures walked away from the pure virtual cache setups."
<rsalvaterra>
Yeah, this is one of them. Caches are either PIPT or VIPT.
<rsalvaterra>
No issue there.
<lipnitsk>
some hotplug call or something is just happening way too early, before MM is even fully initialized
<jow>
stintel: at that time I might have thought that lldpcli needs it
<jow>
stintel: or it might have been the case / I might have thought that lldpd needs at least one existing interface to start, hence loopback to give it something to work with
<jow>
stintel: in any case feel free to drop it if you cannot figure out a sane usecase for it to be there
<rsalvaterra>
… south. I'll have to TFTP my out of this one.
<rsalvaterra>
Oh, well…
<Borromini>
jow: how does nlbwmon check for ipv6 connectivity? I have native ipv6 and yet nlbwmon on my router (with multiple openwrt devices downstream) shows my network as 0 ipv6 capable devices >_>
<Borromini>
it used to be better, with a few reboots of switches/APs downstream sometimes, but now it stubbornly keeps reporting zero
black_an- has quit [Quit: simplicity does not kill]
<Borromini>
this is on 21.02 but i suppose master codebase doesn't diverge much at this point