**** BEGIN LOGGING AT Sun Mar 07 02:59:57 2021
Mar 07 03:00:29 <mangix> patches are taken from http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=clearfog
Mar 07 03:22:26 <lipnitsk> is there a good place to host a datasheet so I can link it in the upstream patch?
Mar 07 03:23:01 <lipnitsk> http://www.anz.ru/files/mediatek/MT7620_ProgrammingGuide.pdf is dead, but the guide is out there, just on non-direct-link sites
Mar 07 04:05:11 <Grommish> damex: ping
Mar 07 06:22:02 <Grommish> damex: https://github.com/openwrt/openwrt/pull/3936#issuecomment-792225251
Mar 07 06:50:49 <guidosarducci> jow: I've a draft of cleaned up and tested code for the fw3 dscp/mark fixes we discussed. I'd appreciate your comments or review: https://github.com/guidosarducci/firewall3/commits/master-fix-dscp-mark
Mar 07 07:09:25 <damex> Grommish: pong.  and still,  no matter how bad it is - i don't see anyone from openwrt reverting that patch at this point considering how badly it was pushed down.
Mar 07 07:38:24 <Grommish> damex: I don't want a revert, I want a discussion on how to fix the issue
Mar 07 07:38:43 <Grommish> damex: Be it by splitting the targets or removing the offending device
Mar 07 07:38:56 <Grommish> damex: Or something else :)
Mar 07 07:39:04 <damex> Grommish: it had to be discussed before creating an issue in the first place
Mar 07 07:39:13 <damex> oh well
Mar 07 07:39:37 <Grommish> damex: eh, we are beyond that.. but now I've got numbers saying that patch reduces RAM throughput by 1/5th
Mar 07 07:39:45 <Grommish> damex: the question is how to fix
Mar 07 07:40:03 <damex> revert -> start discussion -> implement properly
Mar 07 07:40:36 <Grommish> Whie I'd agree,, the argument will be that it was supposed to be working the entire time :/, so I have to go with that angle
Mar 07 07:42:14 <Grommish> You have to admit, it isn't often a broken bug increases perf ;p
Mar 07 07:43:54 <Grommish> Anyway, the only thing that can be done is report the findings.. I posted the script I used so others can do an A/B test if they desire
Mar 07 07:46:51 <damex> Grommish: you need to test 'network' performance if you want to benchmark something decide intends to do
Mar 07 07:47:17 <Grommish> I can do that easy enough
Mar 07 07:47:20 <damex> run iperf with tiny mss and see how well it performs,. with qos, without qos.
Mar 07 07:47:29 <Grommish> I don't run QoS
Mar 07 07:47:30 <damex> it has to be an automated test
Mar 07 07:48:49 <damex> so let's say in generatl you need to see how many pps device can handle and atleast a general/generic forwarding situation.
Mar 07 07:48:54 <Grommish> But, I've got the 1 slot filled with the patched version, 1 without, and the third is my standard load.. Help me do the tests and I'll run them
Mar 07 07:49:04 <damex> in*
Mar 07 07:49:36 <Grommish> but, given the RAM throughput loss, I really don't care about the rest of it because even if Netperf was fine, the system will be slower by rote
Mar 07 07:49:57 <Grommish> Disc IOps were the same for example to the emmc
Mar 07 07:51:24 <Grommish> RAM showed the marked difference.  I'd have to rearrange my network setup again to test throughput, but I've go a speedtest server internal to the ISP i know what I SHOULD and DO get and can test against that
Mar 07 07:53:26 <damex> <we do not care about ram performance if network throughput does not degrade>
Mar 07 07:53:31 <damex> i guess that would be your answer
Mar 07 07:53:46 <damex> you better collect the rest of the details
Mar 07 07:53:50 <Grommish> I get 920/245 down/up to the speedtest server upstream, which is 5 hops, where the first two are the laptop and the edge router
Mar 07 07:54:00 <Grommish> So I can test that
Mar 07 07:54:35 <damex> Grommish: no, wrong. too many factors. it has to be a testing without external factors
Mar 07 07:55:17 <Grommish> cn01plv-spdtst01.zoomtown.com (216.68.5.57)  3.149 ms !X  3.134 ms !X  3.169 ms !X
Mar 07 07:55:24 <Grommish> That is over WiFi
Mar 07 07:55:31 <Grommish> I can't bring it down much more than that
Mar 07 07:55:37 <Grommish> Unless I setup another server internally
Mar 07 07:58:22 <Grommish> I supposed I can setup iperf on the network edge
Mar 07 07:58:34 <Grommish> Meh, but I don't like changing that device if I don't have to
Mar 07 08:01:16 <Grommish> Anyway, I'm willing to run the tests, but I need to know what to run.. It's why I approached you about quantifying the issue before :) I'm just in a position now to actually run the tests
Mar 07 08:06:00 <damex> iperf3 -P 64 -p 5201 -R --set-mss 100 -b 2G -t 300 -c ip
Mar 07 08:06:09 <damex> decent starting point
Mar 07 08:06:55 <Grommish> damex: Ok.. We will start there
Mar 07 08:06:57 <damex> so low mss, 2G/s bw and 5min timeout running in 64 threads
Mar 07 08:07:17 <Grommish> I've got a dual core CPU ;p
Mar 07 08:07:27 <Grommish> So that'll be fun
Mar 07 08:14:17 <Grommish> RUnning and logging internal to the LAN
Mar 07 08:28:41 <Grommish> damex: https://gist.github.com/Grommish/b226d9a685de61e5b3c54273c2efcd32
Mar 07 08:50:14 <Grommish> damex: I'm heading to bed.. If you think of something else to run, let me know. I've also updated the comment in the closed PR regarding the test results and the fact my edge device also is limited due to running a snapshot build from master on it..
Mar 07 09:07:55 <damex> Grommish: what is 89761 and 150727 ?
Mar 07 11:01:54 <rsalvaterra> lipnitsk: RM2100 up and running. Nice work! :)
Mar 07 11:06:15 <rsalvaterra> Still 4-bit ECC, but not complaining anymore about low strength… Don't know if it's expected or not.
Mar 07 11:12:43 <rsalvaterra> lipnitsk: We have some problems, though…
Mar 07 11:13:43 <rsalvaterra> lipnitsk: [   14.983914] mt7603e 0000:02:00.0: Invalid MAC address, using random address ee:ed:2b:0c:5e:0e
Mar 07 11:13:43 <rsalvaterra> lipnitsk: [   17.422018] mt7615e 0000:01:00.0: Invalid MAC address, using random address a2:ee:37:e2:4d:61
Mar 07 11:53:58 <Borromini> lipnitsk: you got an RM2100 as well?
Mar 07 12:11:34 <donald_knooth> Hello Gentlemen. Simple question about OpenWRT packaging/feeds: How are transitive dependencies handled? (If package C depends on package B, and package B depends on package A, do I need to specify package A in the DEPENDS:= block of the makefile for package C?
Mar 07 12:14:19 <olmari> donald_knooth: While I can't really tell you real answer, anything other than immediate dependancy would be high mess
Mar 07 12:14:53 <olmari> C depends on B, B depends on A today, and D today...
Mar 07 12:14:58 <donald_knooth> olmari: I'd imagine so, but... the entire build system is super jank, so don't assume the obvious..
Mar 07 12:15:48 <olmari> I don't think buildroot would stay working even an day if such depency-explanation would be an thing
Mar 07 12:17:28 <donald_knooth> Thanks
Mar 07 12:19:41 <olmari> I do know openwrt buildroot is.. well.. jank is not term I'd use... for developer standpoint it isn't the most basic way... but I think it allows this megalomaniac (program)listing to work and be somewhat maintainable like this... for user side who "just" wanna mostly compile own openwrt the buildroot is super awesome
Mar 07 12:20:00 <olmari> "go select platform and desired programs and compile"
Mar 07 12:26:52 <PaulFertser> donald_knooth: afaict, you only need to select what you really depend on. Everything else goes automatically.
Mar 07 12:27:24 <donald_knooth> Thanks PaulFertser
Mar 07 12:40:01 <olmari> Should my figurative software rely on something small as "nano" (the text editor), I still couldn't keep up and be assumed that I would know on what library version nano needs at what time... and god knows what else the library then depends on.. you see? :)
Mar 07 13:01:06 <Grommish> adrianschmutzler: ping
Mar 07 13:17:17 <Grommish> olmari: If your package requires nano, you'd put DEPENDS:=+nano.. the build system, when seeing that Dep in menuconfig, will see that PACKAGE_NANO requires: Selects: PACKAGE_libncurses [=n] && PACKAGE_libc [=y] && PACKAGE_libpthread [=y] && PACKAGE_librt [=y] and follow the rabbit hole
Mar 07 13:18:00 <olmari> Grommish: exactly
Mar 07 13:18:03 <Grommish> PKG_BUILD_DEPENDS and HOST_BUILD_DEPENDS can be defined for those that need to be in-place prior to compiling vs "just available on the sytem"
Mar 07 13:18:44 <olmari> (I wasn't the claimer for otherwise 😉 )
Mar 07 13:18:51 <Grommish> The only limitation I've found is that the build system (which is based on the kernel build system I believe jow said at one point) is that it can't DESELECT a package conditional on another :(
Mar 07 13:18:58 <Grommish> which is very inconvient at times :D
Mar 07 13:20:15 <olmari> yeah... menuconfig doesn't have permanent storage of what was actually chosen by human and what by depency
Mar 07 13:21:22 <Grommish> *nod* it expects me to know what i'm doing and I'm not comfortable with that
Mar 07 13:24:49 <olmari> Well... it would be awesome to have such data recorded and by extension automated
Mar 07 13:25:54 <olmari> I kinda do realise menuconfig isn't package manager, but openwrt case it acts very much of such =)
Mar 07 13:27:13 <Grommish> Yeah.  I honestly don't find it too bad except for the one issue mentioned, but I was very confused at the start
Mar 07 13:27:56 <Grommish> and the Wikis tend to be all over the place and I have a tendancy to.. not read fully? :p
Mar 07 13:30:06 <olmari> Not first time when I start fresh because I've tried stuff that keeps filling end image... :D
Mar 07 13:30:34 <olmari> ..because of shitton of depencies (human perspective)
Mar 07 13:31:17 <Grommish> hehe
Mar 07 17:01:52 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 98.2% packages reproducible in our current test framework.)
Mar 07 17:19:49 <Borromini> Grommish: you still around?
Mar 07 18:01:32 <rsalvaterra> lipnitsk: Wi-Fi is extremely unstable. Keeps disconnecting all the time.
Mar 07 18:05:58 <rsalvaterra> lipnitsk: ping
Mar 07 18:40:19 <guidosarducci> dangole: ping
Mar 07 18:43:31 <lipnitsk> rsalvaterra: pong
Mar 07 18:43:39 <lipnitsk> rsalvaterra: yeah I haven't tested wi-fi at all - don't have a wi-fi ramips device, sorry..
Mar 07 18:43:56 <lipnitsk> rsalvaterra: is it using mt76 driver?
Mar 07 18:47:38 <dangole> guidosarducci: pong
Mar 07 18:49:14 <jmv09> #19.07.7 appears to a) stop issuing ipv4 addresses (dhcp) and b) disrupts igmp iptv traffic upon other load. E.g. x86 master is much better.
Mar 07 18:50:35 <guidosarducci> dangole: howdy! Can I ask you to look at two simple updates in bpftools, since you've review that before? A macOS fix already upstreamed: https://github.com/openwrt/openwrt/pull/3959, and a pkgconfig fix: https://github.com/openwrt/openwrt/pull/3956.
Mar 07 19:03:12 <rsalvaterra> lipnitsk: Yes, mt76.
Mar 07 19:03:28 <lipnitsk> probably needs some love for 5.10..
Mar 07 19:03:34 <empanisset> Hi I am new in openwrt development. I got a crash in netifd daemon (attempt to access NULL pointer) and I'd like to know where to report the issue
Mar 07 19:04:21 <rsalvaterra> lipnitsk: IIRC, mt76 is using OpenWrt's mac80211 from 5.10, already.
Mar 07 19:04:46 <lipnitsk> anything in dmesg?
Mar 07 19:05:04 <lipnitsk> or cat /proc/interrupts?
Mar 07 19:05:35 <guidosarducci> empanisset: for core issues like that: https://bugs.openwrt.org/ would be best
Mar 07 19:05:52 <jmv09> empanisset: Can you reproduce? In which versions does it occur?
Mar 07 19:06:20 <rsalvaterra> lipnitsk: In dmesg, the only obvious info is what I sent this morning…
Mar 07 19:07:14 <rsalvaterra> lipnitsk: There's also this: [    3.935333] mt7621-pci 1e140000.pcie: Parsing DT failed
Mar 07 19:07:34 <empanisset> I have a commit number on which that happens (checked out this commit) but not sure apparently it's not a crash that happens frequently
Mar 07 19:07:34 <lipnitsk> that's not a problem, pcie reinitializes fine after that message
Mar 07 19:08:44 <rsalvaterra> lipnitsk: Sure, but there's either a problem in the device tree or the parser, which should be fixed (by someone who knows the system better than us). :P
Mar 07 19:09:24 <empanisset> I  happens when network reload event is processed, and further in the call stack attempt is made by proto layer to access l3_dev.dev pointer which is NULL
Mar 07 19:09:26 <lipnitsk> rsalvaterra: https://github.com/openwrt/openwrt/pull/3952#issuecomment-787652985
Mar 07 19:09:38 <lipnitsk> rsalvaterra: please read that thread - that's the author/maintainer of the PCIe driver
Mar 07 19:10:53 <lipnitsk> rsalvaterra: not saying there is no issue at all, but it's not a high priority one and is on his radar for sure
Mar 07 19:11:57 <rsalvaterra> lipnitsk: Just downgraded to 5.4.103.
Mar 07 19:12:42 <empanisset> guidosarducci thanks I'll try to report there
Mar 07 19:13:53 <rsalvaterra> Yikes. I'm now seeing invalid MAC addresses on 5.4 too…? o_O
Mar 07 19:14:21 <rsalvaterra> Not cool.
Mar 07 19:16:01 <Borromini> rsalvaterra: that 'parsing dt'error is endemic
Mar 07 19:16:21 <Borromini> paraka already said in dengqf6's 5.10 ramips PR that it's basically harmless
Mar 07 19:16:49 <rsalvaterra> Borromini: Yeah, I noticed, it's just more "quiet" on 5.4. But the invalid MAC addresses on the Wi-Fi devices are a new issue.
Mar 07 19:19:15 <rsalvaterra> If I'm not mistaken, the firmware stores the MAC address for the Ethernet MAC, and the Wi-Fi addresses are calculated from it.
Mar 07 19:50:25 <ynezz> rsalvaterra: FYI just got mail from GKH, that he has backported that usbip gcc-10 fix into https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git 4.9+
Mar 07 19:50:56 <rsalvaterra> ynezz: Great, thanks!
Mar 07 19:53:48 <dangole> guidosarducci: will take a look once i finish reviewing other things
Mar 07 19:56:13 <guidosarducci> dangole: thanks, I appreciate that, since not many bpf-interested committers around. Let me know of any questions.
Mar 07 20:24:51 <rsalvaterra> Ok, I hexdumped a copy of the mtd3 (factory partition)…
Mar 07 20:25:04 <rsalvaterra> Relevant offsets:
Mar 07 20:25:06 <rsalvaterra> 0000000 7603 0201 d128 bf27 a50d 7603 14c3 ffff
Mar 07 20:25:06 <rsalvaterra> 0008000 7615 00a0 d128 bf27 a60d 0000 0000 0000
Mar 07 20:26:20 <rsalvaterra> These look sane enough…
Mar 07 20:26:37 <rsalvaterra> So, the MAC addresses are there.
Mar 07 20:31:54 <Borromini> even prefixed with the radio types :)
Mar 07 20:32:15 <Borromini> so is the ML still having issues? sent in patches. not showing up on the ML or patchwork.
Mar 07 20:33:18 <rsalvaterra> Borromini: Yeah. But for some unfathomable reason, they aren't being read correctly by the driver.
Mar 07 20:33:36 <Borromini> not even with 5.4 anymore it seems, right?
Mar 07 20:34:49 <rsalvaterra> Borromini: Righto.
Mar 07 20:53:07 <lipnitsk> rsalvaterra: so 5.4 also doesn't work right? Means something broke on master before my 5.10 changes went in
Mar 07 20:53:17 <lipnitsk> rsalvaterra: by doesn't work I mean the MAC thing
Mar 07 20:53:28 <rsalvaterra> lipnitsk: Either master or the kernel itself…
Mar 07 20:53:44 <lipnitsk> hmm yeah might have been the big stable bump
Mar 07 20:54:16 <lipnitsk> rsalvaterra: do you want to bisect it?
Mar 07 20:54:25 <lipnitsk> do you know when it last worked?
Mar 07 20:54:44 <dangole> lipnitsk, rsalvaterra: i've tested 5.10 and 5.4 on RBM11G which I got patched to load MT7615 EEPROM from additional MTD partition at the end of the flash. that works on both 5.4 and 5.10
Mar 07 20:55:12 <rsalvaterra> lipnitsk: I have done kernel bisections before… but never in OpenWrt. :/
Mar 07 20:55:35 <lipnitsk> not kernel, just bisect the openwrt SHAs, if it's the kernel bump then we look there
Mar 07 20:56:59 <rsalvaterra> dangole: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/dts/mt7621_xiaomi_router-ac2100.dtsi;h=7e6b3afcdf008dc6506bd09b207ec64770a59bbf;hb=HEAD
Mar 07 20:57:51 <rsalvaterra> This is the relevant device tree.
Mar 07 20:58:36 <dangole> it's weird to match on the driver, i do compatible = "pci14c3,7615" for the PCIe device
Mar 07 20:58:40 <rsalvaterra> lipnitsk: I'll probably just checkout at each kernel bump.
Mar 07 20:59:59 <dangole> rsalvaterra, lipnitsk: ie. this is what I use and works: https://termbin.com/sqby
Mar 07 21:00:23 <dangole> (obviously the EEPROM needs to be written there before, of course...)
Mar 07 21:00:49 <rsalvaterra> dangole: Thanks, I'll give it a try here.
Mar 07 21:01:21 <dangole> rsalvaterra: you have to adapt the compatible string to match the pci vendor/product id, of course
Mar 07 21:01:26 <rsalvaterra> dangole: What do you mean, written there before?
Mar 07 21:01:54 <rsalvaterra> In this case, it's a factory partition, much like ART on ath79.
Mar 07 21:02:01 <dangole> rsalvaterra: in the compatible string, you encode the PCI vendor ID and product ID
Mar 07 21:02:34 <dangole> rsalvaterra: regarding my rbm11g hack (which is a board without any wifi when it comes from the factory), i added mt7615e module without eeprom and load it from flash in that way.
Mar 07 21:03:29 <rsalvaterra> dangole: Why does MikroTik have to be different from everybody else? :)
Mar 07 21:03:59 <dangole> rsalvaterra: it's just their weird bootloader and that's related to their licensing model, i guess
Mar 07 21:04:10 <dangole> replace with stock u-boot and the hardware is straight forward
Mar 07 21:05:21 <dangole> (apart from rbm4xx boards which got NAND wired up in the weirdest way ever)
Mar 07 21:05:55 <dangole> (they make a parallel SLC NAND into an SPI device by adding shifters on the busses)
Mar 07 21:09:28 <rsalvaterra> dangole: Correct me if I'm wrong, but the "mtd-mac-address = <&eeprom 0x1000>;" points exactly to the first byte of the MAC address, right?
Mar 07 21:09:53 <dangole> exactly. if it doesn't load it from there this must have other reasons
Mar 07 21:10:35 <rsalvaterra> So, from this hex dump… 0008000 7615 00a0 d128 bf27 a60d 0000 0000 0000
Mar 07 21:10:53 <dangole> that looks like an MT7615 wifi EEPROM
Mar 07 21:10:57 <rsalvaterra> … it should point to 0x8004.
Mar 07 21:11:01 <dangole> which does contain a mac address as well
Mar 07 21:11:10 <dangole> and in that case you don't even need to set it explicitely
Mar 07 21:11:51 <dangole> i set it there because i got a generic EEPROM file from the module vendor with a fake mac address there and instead of patching the EEPROM for each board (incl. checksum, ...) i only let dt override the mac address additionally
Mar 07 21:12:36 <rsalvaterra> dangole: Thing is, for some reason I'm getting this… [   16.554338] mt7615e 0000:01:00.0: Invalid MAC address, using random address fe:30:e4:de:f5:46
Mar 07 21:13:18 <dangole> so mt7615e doesn't load that eeprom to begin with. you should also see exceptionally low tx power
Mar 07 21:13:54 <rsalvaterra> dangole: Neither the MT7615 nor the MT7603. [   14.141100] mt7603e 0000:02:00.0: Invalid MAC address, using random address 92:cb:62:38:8e:42
Mar 07 21:14:28 <lipnitsk> rsalvaterra: I wonder if 21.02 is also broken for you?
Mar 07 21:14:40 <rsalvaterra> Which is reeeealy fishy. I know for a fact this was working until I did the mvebu 5.10 bringup (I was using the RM2100 as my main router).
Mar 07 21:17:50 <rsalvaterra> I'm going to checkout at 5d3a6fd970619dfc55f8259035c3027d7613a2a6 (5.4.98 bump, I know this one was working, for sure).
Mar 07 21:20:22 <Hauke> rsalvaterra: I also have problems with MT7612EN
Mar 07 21:20:39 <rsalvaterra> Hauke: Oh dear… same as me?
Mar 07 21:20:51 <Hauke> I think it is relaetd to the mac80211 patches introduced in december
Mar 07 21:21:08 <Hauke> it works more stable without the rate controll patches
Mar 07 21:21:47 <Hauke> it wokre fine with a build from beginning of december, and I have problems since January
Mar 07 21:22:02 <Hauke> with kernel 5.4
Mar 07 21:22:23 <Hauke> normally it works for 12 hours fine, but gets then worse
Mar 07 21:23:28 <rsalvaterra> Hauke: I see, but my situation is different. I haven't had any issues before, until suddenly the driver stopped reading the EEPROM.
Mar 07 21:23:45 <Borromini> Hauke: what kind of problems?
Mar 07 21:23:52 <rsalvaterra> BRB
Mar 07 21:24:18 <Borromini> i retired my rt-ac57u (mt7612 as well) from active duty but i recall it being very unstable with later master builds
Mar 07 21:26:00 <Hauke> rsalvaterra: ok then this is a different problem
Mar 07 21:29:03 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Mar 07 21:48:01 <hurricos> ynezz: ping
Mar 07 22:06:20 <Borromini> dwmw2: i'm seeing this when i try to send to the list: https://paste.debian.net/plainh/e63cb8e1
Mar 07 22:06:47 <Borromini> did anything change on the list settings? I was able to send e-mail in still on Feb 28th.
Mar 07 22:10:56 <Borromini> on a related note, i haven't gotten any e-mails from the list since March 2nd either
Mar 07 22:52:46 <lipnitsk> Borromini: the list was down for a day or so, but has been functioning since then. I think dwmw2 had to move servers, so maybe something did change, but seems the issue is likely on your side
Mar 07 22:54:36 <Borromini> lipnitsk: at least i should still be getting mail right?
Mar 07 22:54:43 <Borromini> not even that is happening.
Mar 07 22:55:09 <lipnitsk> Borromini: yeah that's strange... FWIW I just sent a patch and it showed up in patchwork
Mar 07 22:55:47 <Borromini> yeah i've seen other e-mails from today as well
Mar 07 22:55:57 <Borromini> on the ML online, so...
Mar 07 22:56:16 <Borromini> i already restarted the vps but i'm not seeing anything different so far
Mar 07 23:26:26 <rsalvaterra> lipnitsk: Can't bisect here, too slow. But this really needs to be fixed.
Mar 07 23:26:40 <rsalvaterra> My router is basically unusable.
Mar 07 23:27:10 <lipnitsk> rsalvaterra: well if it's also broken on 5.4 (did you check 21.02?) then I don't think it was my 5.10 changes
Mar 07 23:27:51 <rsalvaterra> lipnitsk: I haven't checked 21.02, but I'm confident it wasn't caused by your changes.
Mar 07 23:28:50 <lipnitsk> did Dan's statement make sense when he mentioned EEPROM not being read at all? are you seeing super low tx power?
Mar 07 23:29:09 <lipnitsk> what else is in the eeprom? some firmware bits? I really have no idea
Mar 07 23:30:04 <rsalvaterra> lipnitsk: Yes, I'm seeing exactly what dangole described.
Mar 07 23:30:29 <rsalvaterra> lipnitsk: Calibration data and MAC addresses, at least. I don't know what else is there.
Mar 07 23:31:08 <lipnitsk> ah calibration stuff - maybe that's it... what controls eeprom read? still mt76?
Mar 07 23:31:43 <dangole> rsalvaterra: so apparently the dt-match doesn't work. did you try using the pci vendor/product IDs instead of just referencing 'mt76' there?
Mar 07 23:32:12 <rsalvaterra> dangole: Not yet, I was trying to bisect, but gave up, it's nigh-impossible on a Pentium 4.
Mar 07 23:32:28 <lipnitsk> so you found a good sha?
Mar 07 23:32:48 <rsalvaterra> dangole: I'll try matching by PCI ID, as you suggested.
Mar 07 23:34:29 <dangole> it's the only difference i can see right now, because mtd-eeprom works well on my rbm11g here
Mar 07 23:34:29 <guidosarducci> dangole: thanks for the review and merge!
Mar 07 23:36:57 <rsalvaterra> dangole: I'm assuming endianness isn't relevant (the data is little-endian).
Mar 07 23:37:16 <rsalvaterra> At least mt76 seems to take care of that.
Mar 07 23:37:30 <dangole> cpu endian is little endian as well on ramips and mt76 eeprom is always LE
Mar 07 23:38:24 <rsalvaterra> FWIW, this is the code that reads the EEPROM data… https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/mediatek/mt76/eeprom.c?h=linux-5.10.y
Mar 07 23:38:40 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.4% packages reproducible in our current test framework.)
Mar 07 23:59:07 <rsalvaterra> dangole: I'll try this first… https://paste.debian.net/1188361/
Mar 07 23:59:47 <dangole> rsalvaterra: yes, exactly, that's what i meant
Mar 08 00:02:31 <rsalvaterra> If it doesn't work, I'll try also adding (to the respective nodes)
Mar 08 00:02:31 <rsalvaterra> mtd-mac-address = <&factory 0x8004>;
Mar 08 00:02:31 <rsalvaterra> mtd-mac-address = <&factory 0x0004>;
Mar 08 00:05:18 <rsalvaterra> Either way, parsing by driver name is borderline insane. How is that even possible? What happens if another driver comes along which matches the same PCI IDs?
Mar 08 00:13:19 <dangole> I also didn't know that even works. Hopefully we don't use that all over that target...
Mar 08 00:37:55 <rsalvaterra> dangole: I… grepped. It's the majority.
Mar 08 00:38:26 <dangole> rsalvaterra: kinda makes me hope that this is not the cause...
Mar 08 00:41:17 <rsalvaterra> dangole: If it's not the cause, I'll just have to keep digging…
Mar 08 00:42:01 <rsalvaterra> … either until I find the cause, or until someone less clueless beats me to the solution. :P
Mar 08 00:46:32 <dangole> grift: just tried the selinux 3.2 update on my Linksys E8450, everything works like a charm so far
Mar 08 00:49:40 <dangole> grift: two small things, probably related to mount_root/fstools changes, but everything works anywhere, apparently: https://termbin.com/waxx
Mar 08 00:52:48 <dangole> grift: complete boot here: https://termbin.com/hnqh
Mar 08 01:27:26 <pinkunicorn> tmn505, hello iv been trying to get your openwrt dvb packages to work with current openwrt and its beyond my abilities!
Mar 08 01:27:47 <pinkunicorn> tmn505, i was wondering if you have any plans on getting your packages to work with current stable openwrt?
Mar 08 01:38:24 <guidosarducci> rsalvaterra: are you planning to upstream that "limits.h" patch for libbpf? Although I couldn't reproduce your build issue, it should probably still get submitted. I was about to send this one before you posted yours: https://github.com/guidosarducci/iproute2/commits/master-fix-bpfglue-limits
Mar 08 01:40:10 <rsalvaterra> guidosarducci: I don't know… I thought about it, but I don't feel comfortable submitting a correction for an issue only I'm seeing. Feels like a hack to me… :/
Mar 08 01:41:30 <guidosarducci> rsalvaterra: I looked at it carefully, and it does seem like an upstream oversight but, yes, I'd like to know it's reproducible too.
Mar 08 01:42:24 <guidosarducci> rsalvaterra: maybe when the build system issues stabilize you can try again and see if it hits you?
Mar 08 01:43:03 <dangole> grift: some more audit logs: https://termbin.com/gdu36
Mar 08 01:43:08 <rsalvaterra> guidosarducci: Sure, will do.
Mar 08 01:44:34 <guidosarducci> russell--: ping
**** ENDING LOGGING AT Mon Mar 08 02:59:57 2021