**** BEGIN LOGGING AT Mon Feb 01 02:59:57 2021 Feb 01 08:04:44 Pepe: or just send me an email Feb 01 08:05:06 or /msg ynezz wiki username/email Feb 01 08:35:32 rsalvaterra: it's supposed to be probed, and the amount of ram looks correct here on mine at r15253 Feb 01 08:37:18 Not at r15642, though… :/ Feb 01 08:50:45 rsalvaterra: i'm seeing ram correctly detected on my R6800 (256 MiB) and DIR-878 A1 (128 MiB) Feb 01 08:50:56 with r15661 Feb 01 08:55:20 now I'm starting to wonder whether I actually flashed an image 2 days ago or it just rebooted and didn't sysupgrade Feb 01 08:57:39 Namidairo: I see that all the time. Sometimes it takes three, four, five tries(!!), until it flashes. Feb 01 08:58:32 But I'm sure it's a completely unrelated issue, since I see this on every devices I have. Feb 01 08:58:40 *device Feb 01 09:00:23 whelp Feb 01 09:00:52 serves me right for not checking uname after I guess Feb 01 09:01:15 I always check the version after sysupgrading, to be sure. ;) Feb 01 09:03:45 Namidairo: you also have a Redmi RM2100, right? Feb 01 09:04:40 ...yes Feb 01 09:05:22 Of course, we could just say it's a feature and tell everybody to replace their RAM chips… :P Feb 01 09:06:11 they do mix and match parts on there Feb 01 09:07:29 Yeah, I remember reading somewhere about the possibility of extending the RAM to 512 MiB by replacing the chip, but I'm not going there… not in the near future, at least. Feb 01 09:07:51 128 MiB should be enough for anybody. Feb 01 09:11:49 rsalvaterra: that much tries for a device with relatively high ram? that's weird. Feb 01 09:12:26 Namidairo: i have a small script that does nothing but pull openwrt versions off all the devices in the house here, to make sure the upgrade actually happened Feb 01 09:12:33 Borromini: tell me about it. I see this on my Omnia, with 2 GiB. Feb 01 09:12:42 eh :-/ Feb 01 09:12:52 rsalvaterra: i kill the wireless before i sysupgrade (wrapper script) Feb 01 09:13:34 I usually kill Tor, but mostly out of faith. In practice, doesn't seem to help. Feb 01 09:13:35 that used to be one of the reasons why devices wouldn't sysupgrade Feb 01 09:14:42 (Tor takes about 25 Mb of RAM, it's the heaviest process I run.) Feb 01 09:15:13 *MB Feb 01 09:24:30 rsalvaterra: insert joke about downloading more RAM Feb 01 09:26:54 mangix: https://downloadmoreram.com/ Feb 01 09:34:19 wow. that's a big improvement Feb 01 09:34:44 mangix: enjoy! :P Feb 01 09:35:18 on an unrelated note, gcc's -fanalyzer takes a lot of RAM Feb 01 09:35:39 Ah, the new static analyser thingy? Feb 01 09:35:50 fedora was killing firefox tabs while running make -j 12 Feb 01 09:35:51 yeah Feb 01 09:36:05 at least you have 12 threads Feb 01 09:36:22 says who? Feb 01 09:36:43 j parameter should be 1.5x your threads Feb 01 09:38:03 Uhh… all suggestions I've read say that it should be your number of logical CPUs + 1… Feb 01 09:38:55 that works out when CPUs = 2 Feb 01 09:42:57 mangix: people seemed to recommend j+1 for a long time Feb 01 09:43:04 i'm on j now again. Feb 01 09:43:34 so apparently opinion widely varies Feb 01 09:44:09 Yeah, 1.5x means you're expecting 50 % of your threads to be blocked at any given time, no? Feb 01 09:45:43 rsalvaterra: do you feel like running through the git log or bisecting for your regression? Feb 01 09:45:49 * Borromini is just curious Feb 01 09:46:57 Borromini: I… would like to avoid it… cheap NAND flash and all… Feb 01 09:47:29 ok Feb 01 09:47:39 One of my units was DoA, with a bad flash chip… Feb 01 09:47:47 … I'd rather not push my luck. :P Feb 01 09:47:53 they're actually shipping units with bad blocks Feb 01 09:47:56 and it's hilarious Feb 01 09:48:10 :-/ Feb 01 09:48:19 Namidairo: a couple of bad blocks is to be expected on NAND. Feb 01 09:48:53 This unit had basically every second block damaged. Feb 01 09:48:58 I never checked if my bad block table was populated Feb 01 09:49:25 openwrt uses ubifs no for nand? or does that depend on the device Feb 01 09:49:25 if the flash is non-poop it "just works" Feb 01 09:49:49 rsalvaterra: how difficult is it to solder ona new one? Feb 01 09:49:52 [ 3.326058] Bad eraseblock 768 at 0x000006000000 Feb 01 09:49:59 oh this is nand Feb 01 09:50:00 nvm Feb 01 09:50:25 NOR is easy. just 8 pins Feb 01 09:50:37 i saw stuff on the ML about mikrotik handling nand... doesn't inspire confidence Feb 01 09:50:54 NAND isn't terrible too, with the proper equipment and experience, which I don't have. :P Feb 01 09:51:17 uhhhh, NAND is BGA Feb 01 09:51:30 or am I confusing it with emmc? Feb 01 09:52:26 mangix: I think this one is TSOP48. Feb 01 09:52:28 bga is just packaging, Feb 01 09:52:33 nand can come in whatever. Feb 01 09:53:12 32 pins Feb 01 09:53:12 that's more than 8 Feb 01 09:53:53 mangix: 48 pins. :P Feb 01 09:54:01 you can get spi nand in 8pin too, for more fun Feb 01 09:54:27 rsalvaterra: that's several orders of magnitude harder :) Feb 01 09:55:11 wait a minute.... Feb 01 09:55:27 that should be doable with flux, which i don't have Feb 01 09:56:20 mangix: And remember, I need to dump the NAND of a working unit, change a couple of bytes at a specific offset (the MAC address) and flash the new chip with it. :P Feb 01 09:57:26 i assume no usb boot :) Feb 01 09:57:32 no usb port :) Feb 01 09:57:37 mangix: what USB? :P Feb 01 09:57:59 i think mt7621 needs a preloader anyway Feb 01 09:58:58 i remember owning a pogoplug 4. had USB, SD, SATA, and NAND boot Feb 01 09:59:01 So, aside from desoldering the chip of a working router and dumping it, my only option would be to dump the flash through the serial port. Feb 01 09:59:04 gold standard Feb 01 09:59:27 Which means dumping 128 MiB at 115200 bps. Feb 01 09:59:58 most of the large partitions on there you can skip anyway Feb 01 10:00:11 you'd just need uboot, factory, and uhh Feb 01 10:00:14 Namidairo: That's my hope, yes. Feb 01 10:00:52 NOR is still easier :) Feb 01 10:01:14 mangix: sure, just clip it and go. :P Feb 01 10:01:29 I remember several years back bricking my dad's desktop during a BIOS update. I was lucky the chip was removable... Feb 01 10:01:41 some of the boards have unpopulated spi Feb 01 10:02:01 and you just solder one on and pull down the right pin Feb 01 10:03:16 wonder if asrock still makes motherboards with removable flash chips... Feb 01 10:03:38 i think most just end up with two now Feb 01 10:05:13 there's also a clip for TSOP NAND flash chips used with a teensy microcrontroller to read/write Feb 01 10:05:16 I have a board which downloads and updates the firmware. From the UEFI setup itself, which is downright terrifying (for me, at least). Feb 01 10:05:38 rsalvaterra: that's where it bricked :) Feb 01 10:05:40 that's what Playstation crackers use Feb 01 10:07:13 mangix: before making it easy to update, they probably should have made it reliable. :P Feb 01 10:09:18 But firmware is usually written by hardware engineers… and we all know the only worse thing than a software engineer with a soldering iron is a hardware engineer with a compiler. Feb 01 10:09:24 rsalvaterra: I thought about that actually. their definition of reliable is running the SPI bus at the slowest possible speed Feb 01 10:10:26 mangix: I used to burn CDs at the lowest possible speed for reliability… :P Feb 01 10:12:17 i don't think the two are equivalent Feb 01 10:12:32 I'm pretty sure they aren't. ;) Feb 01 10:12:50 anyway, my 16MB archer c7v2 flashes the firmware faster than my 16MB motherboard Feb 01 10:13:14 :P Feb 01 10:13:28 yeah it's crazy how dog slow a modern x86 is in that regard Feb 01 10:14:00 Wait, 16 MiB of UEFI…? O_o Feb 01 10:14:20 my Power8 box does Quad SPI it's pretty fast :) Feb 01 10:14:22 rsalvaterra: oh the latest stuff uses 32MB flash chips Feb 01 10:14:34 * rsalvaterra misses 256 kiB BIOSes… Feb 01 10:14:38 there was controversy around it Feb 01 10:14:41 gotta cram the microcode in it too Feb 01 10:14:57 AMD killed support for older chipsets because of those flash chips Feb 01 10:14:58 or cpu support or whatever Feb 01 10:15:06 not big enough Feb 01 10:15:11 yeah x450 had too small ones apparently Feb 01 10:15:41 then they finally went "fine we'll put some out where we drop the old cpu support so we can fit the new one in" Feb 01 10:16:03 yep Feb 01 10:16:23 stintel: Yeah, but large firmware on POWER doesn't scare me. x86, on the other hand, has this atrocious thing called SMM… Feb 01 10:16:54 … God knows what the firmware could be doing at runtime. Feb 01 10:18:14 :P Feb 01 10:19:35 Can't wait to move to something saner… ARM64 seems to be the most obvious candidate, at the moment. POWER is still too expensive… Feb 01 10:20:49 stintel: are you doing OpenWrt builds on POWER? :) Feb 01 10:22:09 rsalvaterra: I've compiled openwrt on an mvebu device. AMA. Feb 01 10:22:27 rsalvaterra: I did Feb 01 10:22:43 mangix: wait, that's illegal. :P Feb 01 10:23:06 how many weeks did it take Feb 01 10:23:06 how so? Feb 01 10:23:11 rsalvaterra: even had a buildslave on it at some point, but the problem was something with the SDK Feb 01 10:23:28 Namidairo: I just left it overnight. It's so slow. Feb 01 10:23:48 stage 2 uses SDK, stage 1 builds SDK and uploads is, so there was a PPC64 SDK in an x86_64 tarbal name :P Feb 01 10:23:55 and that didn't really work very well :P Feb 01 10:24:08 mangix: well, with enough storage, RAM and free time… Feb 01 10:24:13 or something like that, don't recall 100% Feb 01 10:24:39 it's a 10 core 8way SMT Feb 01 10:24:58 rsalvaterra: https://kobol.io/helios4/ Feb 01 10:25:21 but build times were close'ish to my previous workstation, i7 3930k 6c/12t Feb 01 10:25:36 the thing is also really noisy :P Feb 01 10:25:40 and powerhungry Feb 01 10:25:43 stintel: I think it's "only" really SMT4… SMT8 merges two physical cores, doesn't it? Feb 01 10:26:01 rsalvaterra: dunno. it has 80 "CPUs" in /proc/cpuinfo Feb 01 10:26:24 did anyone compiled openwrt on apple m1 yet? Feb 01 10:26:53 mangix: Ah, the Kobols, right. Feb 01 10:26:59 I was looking to get a mac mini for trying a matrix imessages bridge so I can communicate with fanbois in their natural habitat Feb 01 10:27:29 but 2 months wait so I didn't order 1 Feb 01 10:28:05 ynezz: still waiting for marcan and Corellium to upstream support for it. I won't be getting an M1 without full GPU support, though. Feb 01 10:28:39 ynezz: why? Feb 01 10:28:53 seems to be fast arm Feb 01 10:31:43 yeah apple went all-out Feb 01 10:31:56 stintel: it seems like the tarball name for the sdk comes from SDK_NAME:=$(VERSION_DIST_SANITIZED)-sdk-$(if $(CONFIG_VERSION_FILENAMES),$(VERSION_NUMBER)-)$(BOARD)$(if $(SUBTARGET),-$(SUBTARGET))$(if $(GCCV),_gcc-$(GCCV))$(DIR_SUFFIX).$(HOST_OS)-$(HOST_ARCH) Feb 01 10:32:00 they had to. can't afford to replace x86 with something that performs *worse* Feb 01 10:32:10 stintel: perhaps that HOST_OS/ARCH needs some love? Feb 01 10:32:47 seems homebrew doesn't have full support for m1 Feb 01 10:34:04 Apple, what are you doing? https://twitter.com/marcan42/status/1355907966541565957 Feb 01 10:34:48 ynezz: maybe, but the box is mostly switched of, it's too noisy for having it on all the time :) Feb 01 10:35:56 make me wonder how power8 becomes x86_64 :p Feb 01 10:36:22 maybe that was fixed afterwards Feb 01 10:36:59 anyone know by heart what to append to the LuCI URL in the browser to force it to clear the cache? Feb 01 10:37:01 hrm, anyone know if there's a trick for packages that use submodules in git? Feb 01 10:37:17 shift+ctrl+r isn't helping and luci keeps throwing me back to the login page. private window does work. Feb 01 10:37:41 you need to delete cookie Feb 01 10:37:58 ok thanks Feb 01 10:38:15 ynezz: 21|15:13:13< jow> stintel: I disabled your buildslave for now. Since it is a PPC host, it produces IB and SDK binaries unusable by x86 users Feb 01 10:38:39 ah, different issue Feb 01 10:38:42 we might want to look into that though Feb 01 10:39:02 as I predict a future where more !x86 will be used Feb 01 10:39:11 we should just not upload the results Feb 01 10:39:15 karlp: elaborate Feb 01 10:39:18 arm, riscv, power to a less extent Feb 01 10:39:32 right, I still need to order that risc-v board Feb 01 10:39:32 rsalvaterra: https://forum.armbian.com/topic/15431-helios64-support/page/9/?tab=comments#comment-111978 <-- fix for ethernet speeds :) Feb 01 10:40:01 https://www.sifive.com/boards/hifive-unmatched Feb 01 10:40:08 rsalvaterra: you got a helios64?? Feb 01 10:40:57 ow that helios64 looks fancy Feb 01 10:41:15 mangix: nvm, it didnt' seem to be doing the recursive submoudle checkout, but it is, some paths are busted. Feb 01 10:41:25 while on that topic, several people sold theirs on the forums. first batch had some rough edges Feb 01 10:41:58 mangix: yeah. have kept an eye on it as well Feb 01 10:42:08 stintel: it sure does but quite its share of teething problems Feb 01 10:42:17 modern kernel still seems unstable etc. Feb 01 10:42:19 karlp: submodules only work with PKG_SOURCE_PROTO:=git . does not work with codeload Feb 01 10:42:54 Borromini: it's the rockchip platform. it's a disaster. Feb 01 10:43:00 previous one was mvebu Feb 01 10:43:13 Borromini: I see Feb 01 10:43:21 mangix: yeah, I knew that, this is doing a git clone, and it has done the right thing, I'll figure out what paths I've got wrong Feb 01 10:45:20 mangix: yes, bad rep Feb 01 10:45:25 Borromini: well I have a self-built thing anyway, silverstone cs381 with ASRock Rack E3C224D4I-14S, 8x SAS2 + 4x SATA3 + 2x SATA2 + extra Intel X550-T2 :) Feb 01 10:45:44 stintel: hahaha. here i am with my skylake celeron 'home server' xD Feb 01 10:46:03 but I'm already considering replacing it with EPYC3451D4U-2L2T2O8R :P Feb 01 10:47:50 as the current one is limited to 32GB :( Feb 01 10:50:00 Borromini: it just needs a lot of development. there is a lot of stuff that has not made it upstream. Feb 01 10:50:27 it's similar to sunxi actually... Feb 01 10:51:05 I gave up on rockchip's fragmentation and supported/notsupproted and moved to sunxi personally Feb 01 10:51:42 hmm? elaborate Feb 01 10:51:44 * Borromini only has exynos/odroid stuff Feb 01 10:52:07 very happy with that. lucky odroid-xu4 has armbian support now too, though. Feb 01 10:52:33 rockchip has/had no support for even _slightly_ older stuff, the bootloader tooling was way harder to work with, and while rk employees seemed to be doing upstream work, it was only for very specific targets, other rk targes were completely sidelined. Feb 01 10:52:58 unfortunate Feb 01 10:52:58 it's hopefully gotten better, but sunxi has always felt more broadly complete, you're not going to get blindsided as much Feb 01 10:53:41 I should start judging platform stability based on the number of out of tree patches Feb 01 10:53:47 because of that, I haven't been following the dev of rk much for the last two yers or so. Feb 01 10:53:47 :P Feb 01 10:53:54 moar patches = less stability Feb 01 10:53:55 mangix: so, toss all ath79? Feb 01 10:54:04 sunxi was almost zero :) Feb 01 10:54:32 i think the helios64 blog posts on "what's broken on what kernel" says it all really Feb 01 10:56:04 Namidairo: yeah. at least they're acknowledging and working with rockchip it seems, but first batch = guinea pigs with that kind of stuff always Feb 01 10:56:30 i wouldn't mind such a form factor, very neat. but i have the space to just tuck away a regular atx box, so for now... Feb 01 10:57:04 wonder if the smarter thing would have been to stick with mvebu... Feb 01 10:57:12 was helios4 mvebu? Feb 01 10:57:16 yes Feb 01 10:57:20 oh. yeah. Feb 01 10:57:43 when you see espressobin etc i've wondered why they didn't use that too. rockchip was probably cheaper. Feb 01 10:57:46 funny thing is, I have a helios 4 and a turris omnia. both mvebu, both 1.6ghz, both 38x Feb 01 10:57:57 :) Feb 01 10:58:51 omnia is 385, helios is 388. just a product differentiation. the 388 has 4 sata ports. 385 has 1 Feb 01 10:59:12 the omnia has 0 because... Feb 01 11:13:37 That was not fair mangix. :) Turris Omnia has two minipcie slots and the third is minipcie/msata. You might add miniPCIe controller which adds 2 or 4 SATA ports (e.g. IOCREST Marvell 9215). Also, there are 2 USB 3 ports without using hub. Feb 01 11:22:00 Borromini: No, but I wouldn't mind… I'm entertaining the idea of making my own "cloud". :) Feb 01 11:22:20 :) Feb 01 11:22:29 with owncloud or another product? Feb 01 11:22:41 nextCloud, most likely. Feb 01 11:23:29 Or OpenMediaVault with nextCloud… I don't know, haven't explored the possibilities yet. Feb 01 11:29:32 Pepe: I'm well aware, but to add SATA to it would require a separate controller. The armada SoC comes with one AFAIK. Feb 01 11:30:50 I do have a minipcie one actually. However it is limited by pcie speeds. The armada one connects through SERDES I think. Feb 01 11:31:43 rsalvaterra: I run openmediavault on mine. AMA. Feb 01 11:32:20 mangix: RAID level? Filesystem(s)? Feb 01 11:32:56 btrfs. RAID 5. metadata RAID1c4 Feb 01 11:33:54 Hmm… btrfs still scares me a bit… the free space issues bit me really badly, years ago. Feb 01 11:35:34 * rsalvaterra is looking forward to bcachefs… Feb 01 11:38:15 free space issues? Feb 01 11:41:46 Interesting tidbit: the armada SoC has an XOR offload engine that speeds up RAID parity calculations. mdadm uses it. btrfs does not (neither does bcachefs). I brought it up on the btrfs mailing list. The head honcho loved the idea. I hope it gets implemented. Feb 01 11:43:00 It basically requires switching kernel APIs Feb 01 12:03:30 mangix: Yes. When you have your volume about 70 % full. When I used btrfs, I had problems with that, the system complaining I had no free space, when I still had quite a bit. Feb 01 12:05:17 30% can be a lot in todays drives lol Feb 01 12:07:28 Namidairo: this was my Debian root partition, at the time. About 8 GB, iirc. Feb 01 12:08:29 I wonder if synology used btrfs in their roots Feb 01 12:21:53 Sounds wrong. I have around 80% used currently. I get no such warnings. Feb 01 12:23:38 mangix: I don't know how it is nowadays. I stopped using btrfs about 8 years ago. Feb 01 12:24:08 Makes sense. That was the stone age. Feb 01 12:24:22 :P Feb 01 12:25:09 The design of btrfs unfortunately made it take a long time to get a good degree of stability. Feb 01 12:25:28 In 2021, it's usable. Feb 01 12:25:48 fedora defaults to it now for new installs iirc Feb 01 12:26:29 karlp: red hat wants testers before they put it in RHEL. Feb 01 12:28:52 stratis is... interesting. Guessing they are looking forward to deprecate it. Feb 01 12:30:13 gch981213: rsalvaterra has questions for you :) Feb 01 12:30:34 mangix: I do? :) Feb 01 12:30:37 Oh Feb 01 12:30:52 rsalvaterra: ram autodetection Feb 01 12:31:24 gch981213: My Redmi RM2100 suddenly doubled the RAM. :P Feb 01 12:31:32 [ 0.000000] Memory: 252180K/262144K available (5320K kernel code, 189K rwdata, 436K rodata, 1276K init, 199K bss, 9964K reserved, 0K cma-reserved) Feb 01 12:31:40 I'd be happy, if it were true. :) Feb 01 12:34:44 I guess something happened between r15253 (which Namidairo is running, with the correct RAM size and r15642 (which I'm running)… Feb 01 12:35:50 anyone else had an email 'from github' about "A notice regarding unauthorized personal information in your repository" Feb 01 12:35:57 I have no idea how that detection can go wrong atm :( Feb 01 12:36:06 ldir: I'm here for exactly that Feb 01 12:36:08 ..did you upload your private key Feb 01 12:37:05 ldir: gch981213: let's move it to openwrt-adm Feb 01 12:37:13 #openwrt-adm Feb 01 12:41:45 guys is feeds.conf.default supposed to be used? I thought the buildroot looked at feeds.conf, not feeds.conf.default Feb 01 12:42:21 i see freifunk and telephony feeds getting activated in my buildroot while they're commented in feeds.conf, but not in feeds.conf.default Feb 01 12:43:02 happening since august at least, it seems. Feb 01 12:44:24 my 19.07 builds don't see that issue (telephony and freifunk are uncommented in feeds.conf.default as well), master builds do Feb 01 13:42:35 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 98.4% packages reproducible in our current test framework.) Feb 01 13:48:55 Borromini: iirc, only uses feeds.conf.default if feeds.conf doesn't exist/isn't readable Feb 01 13:49:09 karlp: ok, will double check Feb 01 13:59:37 rsalvaterra: If the ram detection goes wrong, adding a ram node in dts is the way to go. Feb 01 14:00:37 rsalvaterra: Is it always wrong or are there some previous versions working fine on your router? Feb 01 14:05:45 gch981213: Yeah, I thought about hacking the device tree myself, but I wouldn't do it without confirmation from you. ;) Feb 01 14:06:28 The thing is, the last (or second to last, I don't remember exactly) build had the RAM detection working correctly. Feb 01 14:11:20 For that reason, I'm positive it's a regression. Feb 01 14:37:06 ynezz: Hi, I was CCed on the github email, I'll not discuss it further on Github, but claiming Signed-off-by is personal information is just mind blowing for me, except if really the Signed-off-by was put by someone else without consent Feb 01 15:04:12 champtar: :) Feb 01 15:04:25 I've same view on that Feb 01 15:05:06 don't we sometime attribute someone else's work by simply keeping their Signed-off-by ? Feb 01 15:05:23 I mean, without explicit written consent Feb 01 15:09:27 I can find 3 patches in this patchwork where he has both From and SoB set to the problematic address https://patchwork.kernel.org/project/linux-rockchip/list/?page=2 Feb 01 15:09:33 rsalvaterra: does Your bootloader pass mem= in bootargs? Maybe Linux started ignoring it or the other way around? Feb 01 15:10:31 so this Name/Email is now public for me Feb 01 15:10:53 yeah, exactly Feb 01 15:11:03 if the SoB is bogus he could have said so publicly ... Feb 01 15:11:16 is this someone hoping to do anon contribs? Feb 01 15:11:28 and if you base your work on his upstream stuff, then you actually need to do that Feb 01 15:11:50 karlp: probably someone took his upstream work and is trying to integrate it into openwrt Feb 01 15:12:03 so adding the proper attribution etc. Feb 01 15:12:50 I can't find the email in linux master Feb 01 15:13:29 karlp: https://github.com/openwrt/openwrt/pull/3701#issuecomment-770841946 Feb 01 15:14:07 karlp: so now the Signed-off-by is being treated by GitHub as unauthorized personal information :p Feb 01 15:14:40 Maybe he did some contributions without his company approval and trying to fixup ... Feb 01 15:15:13 let's hope Linus don't plan to do same soon Feb 01 15:15:31 SoB is a public contract, you can't make the signature private Feb 01 15:16:15 shouldn't GitHub know that? :p Feb 01 15:16:48 they've explicitly linked only Signed-off-by and Co-developed-by tags in that email notice Feb 01 15:16:52 He is not EU or California resident I think, but if people start to weaponise GDPR / right to forget / ... it's going to be messy Feb 01 15:17:20 world of CLAs barriers Feb 01 15:20:19 blocktrron: just so there is no misunderstanding, you are contacting the guy and GitHub ? Feb 01 15:20:28 he did in private Feb 01 15:20:51 nbd: ping. have a mt7613be radio here that's dying within the hour with Message 73 timeouts Feb 01 15:23:22 perfect Feb 01 15:25:04 Borromini: pong Feb 01 15:25:18 nbd: hi! Feb 01 15:25:22 hi Feb 01 15:25:37 i have a tp-link eap235 that svanheule[m] has ported openwrt to. master, latest mt76 Feb 01 15:25:53 does the eeprom change that you commented on fix it? Feb 01 15:25:58 5 GHz is an mt7613Be radio Feb 01 15:26:11 nbd: it allows me to select higher tx power (up to 21 dBm) in LuCI Feb 01 15:26:37 and throughput is very similar to OEM, but the radio dies pretty quickly after it starts throwing the message 73 timeout errors Feb 01 15:26:53 SSID completely disappears, and i cannot bring it up until i really restart the devices Feb 01 15:26:57 * device Feb 01 15:29:26 https://paste.debian.net/1183591/ < this is how logread looks like. first 10 lines are when it's just booted up. Feb 01 15:31:29 do you know if this is a recent regression, or if older versions have the same issue? Feb 01 15:32:28 i can try an older driver if you'd like, but i just put openwrt on this thing a few days ago Feb 01 15:32:39 want me to try an older mt76 version? Feb 01 15:34:03 tmn505: The bootloader (u-boot) doesn't pass any arguments to the kernel, that I know of. The kernel command line is embedded in the kernel itself. Feb 01 15:36:47 And mem= is a debugging aid, not something to be used in production. Feb 01 15:38:32 Oh! I've got production device where it's used :) Feb 01 15:39:45 tmn505: It doesn't surprise me, but still doesn't make it right. :P Feb 01 15:40:19 Whisky Tango Foxtrot…! Feb 01 15:40:23 I just compiled a new image. Feb 01 15:40:34 Now the RAM size is correct. *facepalm* Feb 01 15:40:40 Well if it's there, someone's bound to use it sooner or later. Feb 01 15:40:47 rsalvaterra: lol. Feb 01 15:41:08 I bullshit you not. Feb 01 15:41:18 * tmn505 ^^ doubles that Feb 01 15:41:25 [ 0.000000] Memory: 122228K/131072K available (5320K kernel code, 189K rwdata, 436K rodata, 1276K init, 199K bss, 8844K reserved, 0K cma-reserved) Feb 01 15:41:53 I… think I need a drink. Feb 01 15:42:16 because you were seeing double? ;) Feb 01 15:42:18 * Borromini hides Feb 01 15:42:56 Hey, you also saw double, I copied and pasted the dmesg line here… :P Feb 01 15:43:08 Borromini: yes, older mt76 version Feb 01 15:43:18 * tmn505 think it's Sun waves Feb 01 15:45:16 nbd: ok. will roll back and keep you posted, thanks. any debugging stuff i should enable additionally? Feb 01 15:45:32 rsalvaterra: fair enough ;) Feb 01 15:46:29 Borromini: yes. echo 1 > fw_debug in /sys/kernel/debug/ieee80211/phyX/mt76 Feb 01 15:46:41 noted Feb 01 15:47:00 Borromini: probably some shenanigans in the RAM size detection, though. I wonder if it happens on reboot, once in a while… Feb 01 15:48:46 you could powercycle it a few times if it's not your main device? add a reboot cronjob :P Feb 01 15:49:50 I remember, I rebooted it once and it still detected 256 MiB. Feb 01 15:51:30 I copied the memory detection logic from here: https://elixir.bootlin.com/linux/latest/source/arch/mips/kernel/setup.c#L94 Feb 01 15:54:18 It seems to be working fine on other SoC for years so I didn't bother to fix the potential cache issue. Feb 01 15:55:08 Potential cache issue? Feb 01 15:57:25 It relies on memory chip to ignore invalid address lines, but the read performed in that function is done on cached kseg0. Feb 01 16:01:12 I don't understand how that would happen but if it read back cached data before u-boot extracts kernel, the detection can go wrong. Feb 01 16:02:27 I wonder if I hit that… Feb 01 16:07:51 Anyway, I'm glad it's working now. But I'll let you know if I see this again. Feb 01 19:52:57 nbd: i switched to 2021-01-14 and i pushed a 100 GB through the AP with iperf3, max tx power (21 dBm). do you need logread output? Feb 01 19:53:37 sigh... racking my brain trying to get isc-dhcp 4.4.2 to build but can't get the synthesized Makefile to include a simple patch... Feb 01 19:54:35 Borromini: so 2021-01-14 is working, but 2021-01-27 fails? Feb 01 19:55:15 nbd: yeah Feb 01 19:55:39 with 2021-01-27 the AP goes down pretty quickly, and i didn't even have clients connected to it Feb 01 19:56:03 i think with a 100 GB i can say i hammered it, with 2021-01-14 :) Feb 01 19:56:47 do you know how to use git-src / CONFIG_SRC_TREE_OVERRIDE? Feb 01 19:57:10 yes, i'm familiar with that Feb 01 19:57:28 ln -s ~/code/lede/mt76/.git package/kernel/mt76/git-src etc Feb 01 19:57:50 can you use it to git bisect in the mt76 tree between 8696919d9aae9b673f916bca41c5e1671eec5b0e (new) and 4c8a09cc45d03897a473c270fede699a0420a483 (old) Feb 01 19:58:11 if the ap goes down pretty quickly, it shouldn't take long to find the faulty commit Feb 01 20:01:37 will do! Feb 01 20:01:54 thanks Feb 01 20:23:55 hmm, looks like I can't get usb tethering to work reliably with 19.07.6. *sigh* Feb 01 20:40:42 nbd: are patches in patches/ still getting applied with git-src? Feb 01 20:41:02 ie package/kernel/mt76/patches/ Feb 01 20:43:11 doesn't look like it Feb 01 21:08:54 f00b4r0: what problem are you facing Feb 01 21:14:50 jow: do you have an opinion on https://patchwork.ozlabs.org/project/openwrt/patch/20210130221155.1459631-1-mail@aparcar.org/ ? CDN for downloads Feb 01 21:22:12 Borromini: no, they aren't Feb 01 21:23:35 nbd: I still couldn't figure out how to make the profile variables available during initramfs building. Do you have any idea how to do that or can you explain how that's different from the image building step, where all variables are available? Feb 01 21:24:26 nbd: added the single eeprom commit on top, thanks Feb 01 21:25:53 aparcar[m]: please show me again the current version of the patch that you're testing Feb 01 21:26:04 and which variable access doesn't work Feb 01 21:26:56 nbd: https://github.com/aparcar/openwrt/commit/2d99261adf4678b1e9d52c913c600e2916e4aca6 Feb 01 21:27:15 this line looks like it export "some" variables Feb 01 21:27:16 https://github.com/aparcar/openwrt/commit/2d99261adf4678b1e9d52c913c600e2916e4aca6#diff-a2b0aa97bfb01148df53ca7ec71c30d039c22fc67e1d52685613b5b2597da4aeR482 Feb 01 21:28:13 yes, it exports the variables to a target Feb 01 21:28:17 on the other hand when image is build, it's wrapped with an eval https://github.com/aparcar/openwrt/blob/2d99261adf4678b1e9d52c913c600e2916e4aca6/include/image.mk#L560 Feb 01 21:28:25 so you need to duplicate that line and modify it for the .json target Feb 01 21:30:21 oh that sounds simple enough Feb 01 21:30:22 thank you Feb 01 21:45:32 Hi, I maintain wolfssl in Debian. How do we get 4.6.0 into as many of your releases as possible, please? Feb 01 21:47:29 lechner: it is already in master, but 19.07 is still on an older version Feb 01 21:47:41 lechner: how does debian handle security update of wolfssl? Feb 01 21:48:01 do you always update to the next major verion or backporg the changes? Feb 01 21:57:58 Hauke: we backport consuming packages to the new version but avoid targeted patches (since the valgrind/openssl snafoo from 2006-2008) https://www.schneier.com/blog/archives/2008/05/random_number_b.html Feb 01 21:58:36 Hauke: it would be for https://security-tracker.debian.org/tracker/CVE-2020-36177 Feb 01 22:05:09 lechner: I am missing a stable branch for wolfssl like openssl has it that would make maintaining it easier, you probably only get this as a paying customer Feb 01 22:05:19 at least this bussiness model would make sense to me Feb 01 22:05:47 lechner: You can send a patch to update wolfssl to 4.6 in openwrt 19.07 Feb 01 22:09:32 it looks like wolfssl is not in debian stable Feb 01 22:10:45 so probably the "problem" did not yet show up in debian Feb 01 22:10:53 zorun: not yet but it will be in bullseye. stable backport is available though. Hauke means something else Feb 01 22:13:00 Hauke: can you please explain how the openssl stable branch works? i am very close with wolfssl and can get whatever is needed Feb 01 22:13:24 lechner: what Hauke means is that to we need to update from e.g. 4.5.X to 4.6.X to get security fixes Feb 01 22:13:43 but this brings tons of other changes, and is possibly not ABI compatible (I haven't checked that last part) Feb 01 22:14:02 it would be nice to have e.g. a 4.5.1 release with just security fixes Feb 01 22:14:06 zorun: same ABI Feb 01 22:15:08 ok, that's good Feb 01 22:15:31 that never break the ABI? Feb 01 22:15:33 *they Feb 01 22:16:24 zorun: we do but i protest every time :) 4.6.0 still supports 24 though Feb 01 22:20:05 ok :) Feb 01 22:21:14 what would happen for Debian stable if a new release is not ABI compatible? introduce a new package and rebuild all dependent packages? Feb 01 22:22:04 there is a nice website that compares the ABI of different versions of libs, but I can't find it now Feb 01 22:22:49 zorun: probably. to minimize that risk i will ask wolfssl to run all symbol removals by me Feb 01 22:24:52 lechner: how wil you fix a security problem after bullseye is released? Feb 01 22:25:15 will you backprot the patch like taking the one you linked here: https://security-tracker.debian.org/tracker/CVE-2020-36177 Feb 01 22:25:21 for CVE-2020-36177 Feb 01 22:26:00 I think we should update wolfssl to 4.6.0 in openwrt 19.07, it is not used very much so if something breaks probably not so many people will complain Feb 01 22:26:25 agreed Feb 01 22:26:34 but for the next release it's much more critical Feb 01 22:27:36 given the diversity of targets/architectures, the potential for regression is significant Feb 01 22:28:50 zorun: normally our use case are a bigger problem, hostapd suppro is broken in 4.6.0 for example Feb 01 22:28:55 *support Feb 01 22:29:31 ah, so we already have regressions :) Feb 01 22:30:55 zorun: https://github.com/wolfSSL/wolfssl/pull/3610 Feb 01 22:33:16 lechner: btw, I don't see anything about CVE-2020-36177 in the changelog for wolfssl 4.6.0 or in their "vulnerabilities" page Feb 01 22:35:21 Hauke: I can talk to David, but you can't patch Makefiles on your end? Feb 01 22:36:53 yes we have this patch in our tree Feb 01 22:36:58 it's patched in openwrt already Feb 01 22:37:09 since it broke the build, it was easy to spot I guess Feb 01 22:37:22 I am just strugeling with the contributor agreement, I hate these documents Feb 01 22:38:36 Hauke: don't worry about it then. those two lines are not worth it. Feb 01 22:38:54 they have a manual CLA process?! that sounds effective... Feb 01 22:40:59 Hauke: thanks for the pointer on hostapd. in Debian we still use openssl for that Feb 01 22:43:11 openwrt has more stoarge constrains than debian Feb 01 22:43:27 from debian's point of view I would continue with openssl Feb 01 22:43:36 this is normally the best supported option Feb 01 22:45:51 zorun: i am not sure why the CVE is not mentioned but they approached me, and it's a 9.8 on the NVD scale Feb 01 22:54:07 ouch Feb 01 22:58:37 Hauke: just in case you are wondering. David asked me to help him. I have known him for many years, and packaged wolfssl in Debian for six Feb 01 23:40:54 karlp: just to answer your question about arc - I've just discovered the crappy quantenna based WiFi mesh extender I have around here is based on arc Feb 01 23:41:37 So yes, there looks like there's platforms out there in the wild using it. Not that this matters to mush about how we go on with it Feb 01 23:52:33 build #734 of apm821xx/nand is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fnand/builds/734 blamelist: John Audia Feb 02 00:03:20 lechner: I will backport wolfssl 4.6.0 to openwrt 19.07 in the next days Feb 02 01:03:27 Hauke: thanks! please let me know if you need anything. lechner@debian.org **** ENDING LOGGING AT Tue Feb 02 02:59:57 2021