goliath has quit [Quit: SIGSEGV]
jschwart has quit [Ping timeout: 260 seconds]
jschwart has joined #openwrt-devel
gromero has quit [Remote host closed the connection]
hbug has joined #openwrt-devel
hbug___ has quit [Ping timeout: 268 seconds]
victhor has quit [Ping timeout: 265 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Darkmatter66 has quit [Ping timeout: 264 seconds]
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 256 seconds]
valku has joined #openwrt-devel
glyph has quit [Quit: End of line.]
glyph has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
lukedashjr has joined #openwrt-devel
luke-jr has quit [Ping timeout: 264 seconds]
lukedashjr is now known as luke-jr
daregap has joined #openwrt-devel
Tapper has joined #openwrt-devel
rmilecki has joined #openwrt-devel
valku has quit [Quit: valku]
Strykar has quit [Quit: /quit]
Strykar has joined #openwrt-devel
goliath has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 264 seconds]
muhaha has joined #openwrt-devel
ivanich has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
<ynezz> Pepe: or just send me an email
<ynezz> or /msg ynezz wiki username/email
Tost has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
Borromini has joined #openwrt-devel
goliath has quit [Ping timeout: 256 seconds]
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
goliath has joined #openwrt-devel
Night-Shade has quit [Read error: Connection reset by peer]
feriman has joined #openwrt-devel
<Namidairo> rsalvaterra: it's supposed to be probed, and the amount of ram looks correct here on mine at r15253
<rsalvaterra> Not at r15642, though… :/
feriman has quit [Quit: WeeChat 3.0]
<Borromini> rsalvaterra: i'm seeing ram correctly detected on my R6800 (256 MiB) and DIR-878 A1 (128 MiB)
<Borromini> with r15661
<Namidairo> now I'm starting to wonder whether I actually flashed an image 2 days ago or it just rebooted and didn't sysupgrade
<rsalvaterra> Namidairo: I see that all the time. Sometimes it takes three, four, five tries(!!), until it flashes.
<rsalvaterra> But I'm sure it's a completely unrelated issue, since I see this on every devices I have.
<rsalvaterra> *device
<Namidairo> whelp
<Namidairo> serves me right for not checking uname after I guess
<rsalvaterra> I always check the version after sysupgrading, to be sure. ;)
<rsalvaterra> Namidairo: you also have a Redmi RM2100, right?
<Namidairo> ...yes
<rsalvaterra> Of course, we could just say it's a feature and tell everybody to replace their RAM chips… :P
<Namidairo> they do mix and match parts on there
<rsalvaterra> 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.
<rsalvaterra> 128 MiB should be enough for anybody.
danitool has joined #openwrt-devel
<Borromini> rsalvaterra: that much tries for a device with relatively high ram? that's weird.
<Borromini> 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
<rsalvaterra> Borromini: tell me about it. I see this on my Omnia, with 2 GiB.
<Borromini> eh :-/
<Borromini> rsalvaterra: i kill the wireless before i sysupgrade (wrapper script)
<rsalvaterra> I usually kill Tor, but mostly out of faith. In practice, doesn't seem to help.
<Borromini> that used to be one of the reasons why devices wouldn't sysupgrade
<rsalvaterra> (Tor takes about 25 Mb of RAM, it's the heaviest process I run.)
<rsalvaterra> *MB
Darkmatter66 has joined #openwrt-devel
<mangix> rsalvaterra: insert joke about downloading more RAM
<rsalvaterra> mangix: https://downloadmoreram.com/
hsp has quit [Quit: WeeChat 3.0]
hsp has joined #openwrt-devel
<mangix> wow. that's a big improvement
<rsalvaterra> mangix: enjoy! :P
<mangix> on an unrelated note, gcc's -fanalyzer takes a lot of RAM
<rsalvaterra> Ah, the new static analyser thingy?
<mangix> fedora was killing firefox tabs while running make -j 12
<mangix> yeah
<Namidairo> at least you have 12 threads
<mangix> says who?
<mangix> j parameter should be 1.5x your threads
<rsalvaterra> Uhh… all suggestions I've read say that it should be your number of logical CPUs + 1…
<mangix> that works out when CPUs = 2
<Borromini> mangix: people seemed to recommend j+1 for a long time
<Borromini> i'm on j now again.
<Borromini> so apparently opinion widely varies
<rsalvaterra> Yeah, 1.5x means you're expecting 50 % of your threads to be blocked at any given time, no?
<Borromini> rsalvaterra: do you feel like running through the git log or bisecting for your regression?
* Borromini is just curious
<rsalvaterra> Borromini: I… would like to avoid it… cheap NAND flash and all…
<Borromini> ok
<rsalvaterra> One of my units was DoA, with a bad flash chip…
<rsalvaterra> … I'd rather not push my luck. :P
<Namidairo> they're actually shipping units with bad blocks
<Namidairo> and it's hilarious
snh has quit [Read error: Connection reset by peer]
<Borromini> :-/
<rsalvaterra> Namidairo: a couple of bad blocks is to be expected on NAND.
<rsalvaterra> This unit had basically every second block damaged.
<Namidairo> I never checked if my bad block table was populated
snh has joined #openwrt-devel
<Borromini> openwrt uses ubifs no for nand? or does that depend on the device
<Namidairo> if the flash is non-poop it "just works"
<mangix> rsalvaterra: how difficult is it to solder ona new one?
<rsalvaterra> [ 3.326058] Bad eraseblock 768 at 0x000006000000
<mangix> oh this is nand
<mangix> nvm
<mangix> NOR is easy. just 8 pins
<Borromini> i saw stuff on the ML about mikrotik handling nand... doesn't inspire confidence
<rsalvaterra> NAND isn't terrible too, with the proper equipment and experience, which I don't have. :P
<mangix> uhhhh, NAND is BGA
<mangix> or am I confusing it with emmc?
<rsalvaterra> mangix: I think this one is TSOP48.
<karlp> bga is just packaging,
<karlp> nand can come in whatever.
<mangix> 32 pins
<mangix> that's more than 8
victhor has joined #openwrt-devel
<rsalvaterra> mangix: 48 pins. :P
<karlp> you can get spi nand in 8pin too, for more fun
<mangix> rsalvaterra: that's several orders of magnitude harder :)
<mangix> wait a minute....
<mangix> that should be doable with flux, which i don't have
<rsalvaterra> 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
<mangix> i assume no usb boot :)
<Namidairo> no usb port :)
<rsalvaterra> mangix: what USB? :P
<Namidairo> i think mt7621 needs a preloader anyway
<mangix> i remember owning a pogoplug 4. had USB, SD, SATA, and NAND boot
<rsalvaterra> 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.
<mangix> gold standard
<rsalvaterra> Which means dumping 128 MiB at 115200 bps.
<Namidairo> most of the large partitions on there you can skip anyway
<Namidairo> you'd just need uboot, factory, and uhh
<rsalvaterra> Namidairo: That's my hope, yes.
<mangix> NOR is still easier :)
<rsalvaterra> mangix: sure, just clip it and go. :P
<mangix> I remember several years back bricking my dad's desktop during a BIOS update. I was lucky the chip was removable...
<Namidairo> some of the boards have unpopulated spi
<Namidairo> and you just solder one on and pull down the right pin
<mangix> wonder if asrock still makes motherboards with removable flash chips...
<Namidairo> i think most just end up with two now
<danitool> there's also a clip for TSOP NAND flash chips used with a teensy microcrontroller to read/write
<rsalvaterra> I have a board which downloads and updates the firmware. From the UEFI setup itself, which is downright terrifying (for me, at least).
<mangix> rsalvaterra: that's where it bricked :)
<danitool> that's what Playstation crackers use
<rsalvaterra> mangix: before making it easy to update, they probably should have made it reliable. :P
<rsalvaterra> 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.
<mangix> rsalvaterra: I thought about that actually. their definition of reliable is running the SPI bus at the slowest possible speed
<rsalvaterra> mangix: I used to burn CDs at the lowest possible speed for reliability… :P
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
<mangix> i don't think the two are equivalent
<rsalvaterra> I'm pretty sure they aren't. ;)
<mangix> anyway, my 16MB archer c7v2 flashes the firmware faster than my 16MB motherboard
<Borromini> :P
<Borromini> yeah it's crazy how dog slow a modern x86 is in that regard
<rsalvaterra> Wait, 16 MiB of UEFI…? O_o
<stintel> my Power8 box does Quad SPI it's pretty fast :)
<mangix> rsalvaterra: oh the latest stuff uses 32MB flash chips
* rsalvaterra misses 256 kiB BIOSes…
<mangix> there was controversy around it
<Namidairo> gotta cram the microcode in it too
<mangix> AMD killed support for older chipsets because of those flash chips
<Namidairo> or cpu support or whatever
<mangix> not big enough
<Namidairo> yeah x450 had too small ones apparently
<Namidairo> 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"
<mangix> yep
<rsalvaterra> stintel: Yeah, but large firmware on POWER doesn't scare me. x86, on the other hand, has this atrocious thing called SMM…
<rsalvaterra> … God knows what the firmware could be doing at runtime.
<stintel> :P
<rsalvaterra> Can't wait to move to something saner… ARM64 seems to be the most obvious candidate, at the moment. POWER is still too expensive…
<rsalvaterra> stintel: are you doing OpenWrt builds on POWER? :)
<mangix> rsalvaterra: I've compiled openwrt on an mvebu device. AMA.
<stintel> rsalvaterra: I did
<rsalvaterra> mangix: wait, that's illegal. :P
<Namidairo> how many weeks did it take
<mangix> how so?
<stintel> rsalvaterra: even had a buildslave on it at some point, but the problem was something with the SDK
<mangix> Namidairo: I just left it overnight. It's so slow.
<stintel> stage 2 uses SDK, stage 1 builds SDK and uploads is, so there was a PPC64 SDK in an x86_64 tarbal name :P
<stintel> and that didn't really work very well :P
<rsalvaterra> mangix: well, with enough storage, RAM and free time…
<stintel> or something like that, don't recall 100%
<stintel> it's a 10 core 8way SMT
<mangix> rsalvaterra: https://kobol.io/helios4/
<stintel> but build times were close'ish to my previous workstation, i7 3930k 6c/12t
<stintel> the thing is also really noisy :P
<stintel> and powerhungry
<rsalvaterra> stintel: I think it's "only" really SMT4… SMT8 merges two physical cores, doesn't it?
<stintel> rsalvaterra: dunno. it has 80 "CPUs" in /proc/cpuinfo
<ynezz> did anyone compiled openwrt on apple m1 yet?
<rsalvaterra> mangix: Ah, the Kobols, right.
<stintel> I was looking to get a mac mini for trying a matrix imessages bridge so I can communicate with fanbois in their natural habitat
<stintel> but 2 months wait so I didn't order 1
<rsalvaterra> ynezz: still waiting for marcan and Corellium to upstream support for it. I won't be getting an M1 without full GPU support, though.
<mangix> ynezz: why?
<ynezz> seems to be fast arm
<Borromini> yeah apple went all-out
<ynezz> 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)
<Borromini> they had to. can't afford to replace x86 with something that performs *worse*
<ynezz> stintel: perhaps that HOST_OS/ARCH needs some love?
<mangix> seems homebrew doesn't have full support for m1
<rsalvaterra> Apple, what are you doing? https://twitter.com/marcan42/status/1355907966541565957
<stintel> ynezz: maybe, but the box is mostly switched of, it's too noisy for having it on all the time :)
<ynezz> make me wonder how power8 becomes x86_64 :p
<stintel> maybe that was fixed afterwards
<Borromini> anyone know by heart what to append to the LuCI URL in the browser to force it to clear the cache?
<karlp> hrm, anyone know if there's a trick for packages that use submodules in git?
<Borromini> shift+ctrl+r isn't helping and luci keeps throwing me back to the login page. private window does work.
<ynezz> you need to delete cookie
<Borromini> ok thanks
CrazyLemon has quit [Ping timeout: 260 seconds]
<stintel> 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
<ynezz> ah, different issue
<stintel> we might want to look into that though
<stintel> as I predict a future where more !x86 will be used
<ynezz> we should just not upload the results
<mangix> karlp: elaborate
<stintel> arm, riscv, power to a less extent
<stintel> right, I still need to order that risc-v board
<Borromini> rsalvaterra: you got a helios64??
CrazyLemon has joined #openwrt-devel
<stintel> ow that helios64 looks fancy
<karlp> mangix: nvm, it didnt' seem to be doing the recursive submoudle checkout, but it is, some paths are busted.
<mangix> while on that topic, several people sold theirs on the forums. first batch had some rough edges
<Borromini> mangix: yeah. have kept an eye on it as well
<Borromini> stintel: it sure does but quite its share of teething problems
<Borromini> modern kernel still seems unstable etc.
<mangix> karlp: submodules only work with PKG_SOURCE_PROTO:=git . does not work with codeload
<mangix> Borromini: it's the rockchip platform. it's a disaster.
<mangix> previous one was mvebu
<stintel> Borromini: I see
<karlp> 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
<Borromini> mangix: yes, bad rep
<stintel> 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 :)
<Borromini> stintel: hahaha. here i am with my skylake celeron 'home server' xD
<stintel> but I'm already considering replacing it with EPYC3451D4U-2L2T2O8R :P
<stintel> as the current one is limited to 32GB :(
<mangix> Borromini: it just needs a lot of development. there is a lot of stuff that has not made it upstream.
<mangix> it's similar to sunxi actually...
<karlp> I gave up on rockchip's fragmentation and supported/notsupproted and moved to sunxi personally
<mangix> hmm? elaborate
* Borromini only has exynos/odroid stuff
<Borromini> very happy with that. lucky odroid-xu4 has armbian support now too, though.
<karlp> 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.
<mangix> unfortunate
<karlp> it's hopefully gotten better, but sunxi has always felt more broadly complete, you're not going to get blindsided as much
<mangix> I should start judging platform stability based on the number of out of tree patches
<karlp> because of that, I haven't been following the dev of rk much for the last two yers or so.
<Borromini> :P
<mangix> moar patches = less stability
<karlp> mangix: so, toss all ath79?
<karlp> sunxi was almost zero :)
<Namidairo> i think the helios64 blog posts on "what's broken on what kernel" says it all really
<Borromini> Namidairo: yeah. at least they're acknowledging and working with rockchip it seems, but first batch = guinea pigs with that kind of stuff always
<Borromini> 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...
<mangix> wonder if the smarter thing would have been to stick with mvebu...
<Borromini> was helios4 mvebu?
<mangix> yes
<Borromini> oh. yeah.
<Borromini> when you see espressobin etc i've wondered why they didn't use that too. rockchip was probably cheaper.
<mangix> funny thing is, I have a helios 4 and a turris omnia. both mvebu, both 1.6ghz, both 38x
<Borromini> :)
<mangix> omnia is 385, helios is 388. just a product differentiation. the 388 has 4 sata ports. 385 has 1
<mangix> the omnia has 0 because...
flokli has quit [Ping timeout: 240 seconds]
<Pepe> 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.
flokli has joined #openwrt-devel
<rsalvaterra> Borromini: No, but I wouldn't mind… I'm entertaining the idea of making my own "cloud". :)
<Borromini> :)
<Borromini> with owncloud or another product?
<rsalvaterra> nextCloud, most likely.
<rsalvaterra> Or OpenMediaVault with nextCloud… I don't know, haven't explored the possibilities yet.
Tapper has quit [Ping timeout: 240 seconds]
Tapper has joined #openwrt-devel
<mangix> Pepe: I'm well aware, but to add SATA to it would require a separate controller. The armada SoC comes with one AFAIK.
<mangix> I do have a minipcie one actually. However it is limited by pcie speeds. The armada one connects through SERDES I think.
<mangix> rsalvaterra: I run openmediavault on mine. AMA.
<rsalvaterra> mangix: RAID level? Filesystem(s)?
<mangix> btrfs. RAID 5. metadata RAID1c4
<rsalvaterra> Hmm… btrfs still scares me a bit… the free space issues bit me really badly, years ago.
* rsalvaterra is looking forward to bcachefs…
Tapper1 has joined #openwrt-devel
<mangix> free space issues?
Tapper has quit [Ping timeout: 240 seconds]
Tapper1 has quit [Ping timeout: 240 seconds]
<mangix> 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.
<mangix> It basically requires switching kernel APIs
dedeckeh has joined #openwrt-devel
csrf has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<rsalvaterra> 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.
<Namidairo> 30% can be a lot in todays drives lol
csrf has joined #openwrt-devel
<rsalvaterra> Namidairo: this was my Debian root partition, at the time. About 8 GB, iirc.
<Namidairo> I wonder if synology used btrfs in their roots
feriman has joined #openwrt-devel
<mangix> Sounds wrong. I have around 80% used currently. I get no such warnings.
<rsalvaterra> mangix: I don't know how it is nowadays. I stopped using btrfs about 8 years ago.
<mangix> Makes sense. That was the stone age.
<rsalvaterra> :P
noltari_ has quit [Quit: Bye ~ Happy Hacking!]
<mangix> The design of btrfs unfortunately made it take a long time to get a good degree of stability.
<mangix> In 2021, it's usable.
<karlp> fedora defaults to it now for new installs iirc
dedeckeh has quit [Quit: Connection closed]
<mangix> karlp: red hat wants testers before they put it in RHEL.
noltari has joined #openwrt-devel
Acrisor has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
Acrisor has joined #openwrt-devel
<mangix> stratis is... interesting. Guessing they are looking forward to deprecate it.
Darkmatter66 has quit [Ping timeout: 246 seconds]
gch981213 has joined #openwrt-devel
<mangix> gch981213: rsalvaterra has questions for you :)
<rsalvaterra> mangix: I do? :)
<gch981213> Oh
<Borromini> rsalvaterra: ram autodetection
<rsalvaterra> gch981213: My Redmi RM2100 suddenly doubled the RAM. :P
Tapper has quit [Ping timeout: 240 seconds]
<rsalvaterra> [ 0.000000] Memory: 252180K/262144K available (5320K kernel code, 189K rwdata, 436K rodata, 1276K init, 199K bss, 9964K reserved, 0K cma-reserved)
<rsalvaterra> I'd be happy, if it were true. :)
<rsalvaterra> I guess something happened between r15253 (which Namidairo is running, with the correct RAM size and r15642 (which I'm running)…
<ldir> anyone else had an email 'from github' about "A notice regarding unauthorized personal information in your repository"
<gch981213> I have no idea how that detection can go wrong atm :(
<gch981213> ldir: I'm here for exactly that
<Namidairo> ..did you upload your private key
<ynezz> ldir: gch981213: let's move it to openwrt-adm
<ynezz> #openwrt-adm
<Borromini> guys is feeds.conf.default supposed to be used? I thought the buildroot looked at feeds.conf, not feeds.conf.default
<Borromini> i see freifunk and telephony feeds getting activated in my buildroot while they're commented in feeds.conf, but not in feeds.conf.default
<Borromini> happening since august at least, it seems.
<Borromini> my 19.07 builds don't see that issue (telephony and freifunk are uncommented in feeds.conf.default as well), master builds do
Tapper has joined #openwrt-devel
dxld has joined #openwrt-devel
hsp has quit [Read error: Connection reset by peer]
csrf has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
csrf has joined #openwrt-devel
Tapper has quit [Quit: Instantbird 1.6a1pre -- http://www.instantbird.com]
Tapper has joined #openwrt-devel
hsp has joined #openwrt-devel
<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.)
<karlp> Borromini: iirc, only uses feeds.conf.default if feeds.conf doesn't exist/isn't readable
<Borromini> karlp: ok, will double check
champtar has joined #openwrt-devel
dorf has joined #openwrt-devel
hsp has quit [Read error: Connection reset by peer]
Namidairo has quit [Ping timeout: 240 seconds]
<gch981213> rsalvaterra: If the ram detection goes wrong, adding a ram node in dts is the way to go.
<gch981213> rsalvaterra: Is it always wrong or are there some previous versions working fine on your router?
<rsalvaterra> gch981213: Yeah, I thought about hacking the device tree myself, but I wouldn't do it without confirmation from you. ;)
<rsalvaterra> The thing is, the last (or second to last, I don't remember exactly) build had the RAM detection working correctly.
<rsalvaterra> For that reason, I'm positive it's a regression.
valku has joined #openwrt-devel
hsp has joined #openwrt-devel
SmugLeaf has joined #openwrt-devel
grift has quit [Quit: Bye]
Weedy has quit [Ping timeout: 246 seconds]
grift has joined #openwrt-devel
gromero has joined #openwrt-devel
luke-jr has quit [Ping timeout: 265 seconds]
luke-jr has joined #openwrt-devel
<champtar> 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
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
luke-jr has quit [Ping timeout: 264 seconds]
luke-jr has joined #openwrt-devel
Borromini has quit [Ping timeout: 260 seconds]
Borromini has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
<ynezz> champtar: :)
<ynezz> I've same view on that
<ynezz> don't we sometime attribute someone else's work by simply keeping their Signed-off-by ?
<ynezz> I mean, without explicit written consent
Borromini has joined #openwrt-devel
gch981213 has quit [Read error: Connection reset by peer]
gch981213 has joined #openwrt-devel
<champtar> 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
<tmn505> rsalvaterra: does Your bootloader pass mem= in bootargs? Maybe Linux started ignoring it or the other way around?
<champtar> so this Name/Email is now public for me
<ynezz> yeah, exactly
<champtar> if the SoB is bogus he could have said so publicly ...
<karlp> is this someone hoping to do anon contribs?
<ynezz> and if you base your work on his upstream stuff, then you actually need to do that
<ynezz> karlp: probably someone took his upstream work and is trying to integrate it into openwrt
<ynezz> so adding the proper attribution etc.
<champtar> I can't find the email in linux master
<ynezz> karlp: so now the Signed-off-by is being treated by GitHub as unauthorized personal information :p
<champtar> Maybe he did some contributions without his company approval and trying to fixup ...
<ynezz> let's hope Linus don't plan to do same soon
<champtar> SoB is a public contract, you can't make the signature private
<ynezz> shouldn't GitHub know that? :p
<ynezz> they've explicitly linked only Signed-off-by and Co-developed-by tags in that email notice
<champtar> 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
<ynezz> world of CLAs barriers
<champtar> blocktrron: just so there is no misunderstanding, you are contacting the guy and GitHub ?
<ynezz> he did in private
<Borromini> nbd: ping. have a mt7613be radio here that's dying within the hour with Message 73 timeouts
<champtar> perfect
Tapper has quit [Ping timeout: 240 seconds]
<nbd> Borromini: pong
<Borromini> nbd: hi!
<nbd> hi
<Borromini> i have a tp-link eap235 that svanheule[m] has ported openwrt to. master, latest mt76
<nbd> does the eeprom change that you commented on fix it?
<Borromini> 5 GHz is an mt7613Be radio
<Borromini> nbd: it allows me to select higher tx power (up to 21 dBm) in LuCI
<Borromini> and throughput is very similar to OEM, but the radio dies pretty quickly after it starts throwing the message 73 timeout errors
Tapper has joined #openwrt-devel
<Borromini> SSID completely disappears, and i cannot bring it up until i really restart the devices
<Borromini> * device
<Borromini> https://paste.debian.net/1183591/ < this is how logread looks like. first 10 lines are when it's just booted up.
<nbd> do you know if this is a recent regression, or if older versions have the same issue?
<Borromini> i can try an older driver if you'd like, but i just put openwrt on this thing a few days ago
<Borromini> want me to try an older mt76 version?
<rsalvaterra> 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.
zkrx has quit [Ping timeout: 246 seconds]
<rsalvaterra> And mem= is a debugging aid, not something to be used in production.
<tmn505> Oh! I've got production device where it's used :)
<rsalvaterra> tmn505: It doesn't surprise me, but still doesn't make it right. :P
<rsalvaterra> Whisky Tango Foxtrot…!
<rsalvaterra> I just compiled a new image.
<rsalvaterra> Now the RAM size is correct. *facepalm*
<tmn505> Well if it's there, someone's bound to use it sooner or later.
<Borromini> rsalvaterra: lol.
<rsalvaterra> I bullshit you not.
* tmn505 ^^ doubles that
<rsalvaterra> [ 0.000000] Memory: 122228K/131072K available (5320K kernel code, 189K rwdata, 436K rodata, 1276K init, 199K bss, 8844K reserved, 0K cma-reserved)
<rsalvaterra> I… think I need a drink.
<Borromini> because you were seeing double? ;)
* Borromini hides
<rsalvaterra> Hey, you also saw double, I copied and pasted the dmesg line here… :P
<nbd> Borromini: yes, older mt76 version
* tmn505 think it's Sun waves
<Borromini> nbd: ok. will roll back and keep you posted, thanks. any debugging stuff i should enable additionally?
<Borromini> rsalvaterra: fair enough ;)
<nbd> Borromini: yes. echo 1 > fw_debug in /sys/kernel/debug/ieee80211/phyX/mt76
<Borromini> noted
<rsalvaterra> Borromini: probably some shenanigans in the RAM size detection, though. I wonder if it happens on reboot, once in a while…
<Borromini> you could powercycle it a few times if it's not your main device? add a reboot cronjob :P
<rsalvaterra> I remember, I rebooted it once and it still detected 256 MiB.
zkrx has joined #openwrt-devel
<gch981213> I copied the memory detection logic from here: https://elixir.bootlin.com/linux/latest/source/arch/mips/kernel/setup.c#L94
<gch981213> It seems to be working fine on other SoC for years so I didn't bother to fix the potential cache issue.
<rsalvaterra> Potential cache issue?
<gch981213> It relies on memory chip to ignore invalid address lines, but the read performed in that function is done on cached kseg0.
<gch981213> 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.
Tost has quit [Ping timeout: 240 seconds]
<rsalvaterra> I wonder if I hit that…
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #openwrt-devel
<rsalvaterra> Anyway, I'm glad it's working now. But I'll let you know if I see this again.
gch981213 has quit [Quit: The Lounge - https://thelounge.chat]
Borromini has quit [Ping timeout: 264 seconds]
r3pek has quit [Ping timeout: 246 seconds]
r3pek has joined #openwrt-devel
KGB-0 has quit [Quit: KGB-0]
KGB-0 has joined #openwrt-devel
muhaha has quit [Quit: Connection closed]
lukedashjr has joined #openwrt-devel
luke-jr has quit [Ping timeout: 246 seconds]
lukedashjr is now known as luke-jr
pulec has quit [Quit: fuuuuu]
pulec_ has joined #openwrt-devel
PtitGNU has quit [Remote host closed the connection]
agb[m] has quit [Ping timeout: 244 seconds]
JuniorJPDJ has quit [Ping timeout: 244 seconds]
jacekowski has quit [Ping timeout: 244 seconds]
t4h4[m] has quit [Ping timeout: 244 seconds]
jacekowski has joined #openwrt-devel
PtitGNU has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
Borromini has joined #openwrt-devel
agb[m] has joined #openwrt-devel
JuniorJPDJ has joined #openwrt-devel
Tost has joined #openwrt-devel
SmugLeaf has quit [Ping timeout: 240 seconds]
philipp64 has joined #openwrt-devel
muhaha has joined #openwrt-devel
swex_ has quit [Quit: swex_]
swex has joined #openwrt-devel
noahm has quit [Quit: reboot]
dedeckeh has joined #openwrt-devel
noahm has joined #openwrt-devel
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
Rene__ has quit [Quit: leaving]
<Borromini> 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?
<philipp64> 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...
<nbd> Borromini: so 2021-01-14 is working, but 2021-01-27 fails?
pulec_ is now known as pulec
<Borromini> nbd: yeah
<Borromini> with 2021-01-27 the AP goes down pretty quickly, and i didn't even have clients connected to it
<Borromini> i think with a 100 GB i can say i hammered it, with 2021-01-14 :)
<nbd> do you know how to use git-src / CONFIG_SRC_TREE_OVERRIDE?
<Borromini> yes, i'm familiar with that
<Borromini> ln -s ~/code/lede/mt76/.git package/kernel/mt76/git-src etc
<nbd> can you use it to git bisect in the mt76 tree between 8696919d9aae9b673f916bca41c5e1671eec5b0e (new) and 4c8a09cc45d03897a473c270fede699a0420a483 (old)
<nbd> if the ap goes down pretty quickly, it shouldn't take long to find the faulty commit
<Borromini> will do!
<nbd> thanks
romany3 has joined #openwrt-devel
CrazyMelon has joined #openwrt-devel
fblaese__ has joined #openwrt-devel
Rene__ has joined #openwrt-devel
<f00b4r0> hmm, looks like I can't get usb tethering to work reliably with 19.07.6. *sigh*
zkrx has quit [Ping timeout: 264 seconds]
CrazyLemon has quit [*.net *.split]
fblaese_ has quit [*.net *.split]
romany has quit [*.net *.split]
zjason has quit [*.net *.split]
soma has quit [*.net *.split]
CrazyMelon is now known as CrazyLemon
romany3 is now known as romany
soma has joined #openwrt-devel
zkrx has joined #openwrt-devel
<Borromini> nbd: are patches in patches/ still getting applied with git-src?
<Borromini> ie package/kernel/mt76/patches/
<Borromini> doesn't look like it
finsternis has quit [Remote host closed the connection]
<blocktrron> f00b4r0: what problem are you facing
<aparcar[m]> jow: do you have an opinion on https://patchwork.ozlabs.org/project/openwrt/patch/20210130221155.1459631-1-mail@aparcar.org/ ? CDN for downloads
<nbd> Borromini: no, they aren't
<aparcar[m]> 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?
<Borromini> nbd: added the single eeprom commit on top, thanks
CrazyLemon has quit [Ping timeout: 264 seconds]
<nbd> aparcar[m]: please show me again the current version of the patch that you're testing
<nbd> and which variable access doesn't work
<aparcar[m]> this line looks like it export "some" variables
<nbd> yes, it exports the variables to a target
<aparcar[m]> 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
<nbd> so you need to duplicate that line and modify it for the .json target
<aparcar[m]> oh that sounds simple enough
<aparcar[m]> thank you
CrazyLemon has joined #openwrt-devel
lukedashjr has joined #openwrt-devel
luke-jr has quit [Ping timeout: 246 seconds]
zkrx has quit [Ping timeout: 264 seconds]
lechner has joined #openwrt-devel
lukedashjr has quit [Ping timeout: 240 seconds]
dedeckeh has quit [Ping timeout: 248 seconds]
luke-jr has joined #openwrt-devel
<lechner> Hi, I maintain wolfssl in Debian. How do we get 4.6.0 into as many of your releases as possible, please?
<Hauke> lechner: it is already in master, but 19.07 is still on an older version
<Hauke> lechner: how does debian handle security update of wolfssl?
<Hauke> do you always update to the next major verion or backporg the changes?
luke-jr has quit [Ping timeout: 246 seconds]
lukedashjr has joined #openwrt-devel
lukedashjr is now known as luke-jr
<lechner> 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
zkrx has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 264 seconds]
<Hauke> 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
<Hauke> at least this bussiness model would make sense to me
ivanich has quit [Quit: Konversation terminated!]
<Hauke> lechner: You can send a patch to update wolfssl to 4.6 in openwrt 19.07
<zorun> it looks like wolfssl is not in debian stable
<zorun> so probably the "problem" did not yet show up in debian
<lechner> zorun: not yet but it will be in bullseye. stable backport is available though. Hauke means something else
matteo has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<lechner> Hauke: can you please explain how the openssl stable branch works? i am very close with wolfssl and can get whatever is needed
black_ant has quit [Ping timeout: 260 seconds]
<zorun> 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
<zorun> but this brings tons of other changes, and is possibly not ABI compatible (I haven't checked that last part)
<zorun> it would be nice to have e.g. a 4.5.1 release with just security fixes
<lechner> zorun: same ABI
<zorun> ok, that's good
matteo has joined #openwrt-devel
<zorun> that never break the ABI?
<zorun> *they
<lechner> zorun: we do but i protest every time :) 4.6.0 still supports 24 though
Borromini has quit [Quit: leaving]
<zorun> ok :)
<zorun> what would happen for Debian stable if a new release is not ABI compatible? introduce a new package and rebuild all dependent packages?
<zorun> there is a nice website that compares the ABI of different versions of libs, but I can't find it now
zatwai has quit [Quit: ZNC 1.8.2+deb1~bpo10+1 - https://znc.in]
<lechner> zorun: probably. to minimize that risk i will ask wolfssl to run all symbol removals by me
zatwai has joined #openwrt-devel
<Hauke> lechner: how wil you fix a security problem after bullseye is released?
<Hauke> will you backprot the patch like taking the one you linked here: https://security-tracker.debian.org/tracker/CVE-2020-36177
<Hauke> for CVE-2020-36177
<Hauke> 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
<zorun> agreed
<zorun> but for the next release it's much more critical
<zorun> given the diversity of targets/architectures, the potential for regression is significant
<Hauke> zorun: normally our use case are a bigger problem, hostapd suppro is broken in 4.6.0 for example
<Hauke> *support
<zorun> ah, so we already have regressions :)
<zorun> lechner: btw, I don't see anything about CVE-2020-36177 in the changelog for wolfssl 4.6.0 or in their "vulnerabilities" page
<lechner> Hauke: I can talk to David, but you can't patch Makefiles on your end?
<Hauke> yes we have this patch in our tree
<zorun> it's patched in openwrt already
<zorun> since it broke the build, it was easy to spot I guess
<Hauke> I am just strugeling with the contributor agreement, I hate these documents
<lechner> Hauke: don't worry about it then. those two lines are not worth it.
<karlp> they have a manual CLA process?! that sounds effective...
muhaha has quit [Quit: Connection closed]
<lechner> Hauke: thanks for the pointer on hostapd. in Debian we still use openssl for that
feriman has quit [Ping timeout: 265 seconds]
<Hauke> openwrt has more stoarge constrains than debian
<Hauke> from debian's point of view I would continue with openssl
<Hauke> this is normally the best supported option
rmilecki has quit [Ping timeout: 264 seconds]
<lechner> 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
<ynezz> ouch
<lechner> 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
lnslbrty has quit [Ping timeout: 256 seconds]
swex has quit [Ping timeout: 256 seconds]
Tapper has quit [Ping timeout: 240 seconds]
kontaxis has quit [Remote host closed the connection]
lnslbrty has joined #openwrt-devel
kontaxis has joined #openwrt-devel
<blocktrron> 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
<blocktrron> 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
<owrt-snap-builds> 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 <graysky@archlinux.us>