<hanetzer> sure, use it :P
<mangix> oh hmm it uses this kernel@1 thing
<hanetzer> yeah.
<hanetzer> kernel@1, dtb@1, ramdisk@1
<hanetzer> just check u-boot's uImage.FIT documentation. its pretty straightforward.
<slh> FIT is basically just a (semi-)standardized container for firmwares (kernel, dts, rootfs)
<slh> multi-platform capable, meaning the bootloader can tell the kernel which of the embedded dtb@xxx to use
<slh> one firmware (-update) for multiple devices (or h/w revisions)
<mangix> hmmm
<mangix> this ubiquity partition table makes no sense
<schmars[m]> i was thinking the same thing the other day
<schmars[m]> different ubiquiti device, same level of partition weirdness
<mangix> hmmm found a potential issue
<mangix> OpenWrt uses kernel-1 for its FIT image. stock firmware uses kernel@1
<slh> I think @ is an invalid character for this
<slh> (yes, OEMs still use it quite often)
<mangix> sounds like some fix similar to https://github.com/openwrt/openwrt/commit/ac5675ec8f63d8cce5af066fa1fcf3906b9e8b2c would be needed
<slh> yep
<mangix> hmmm I can't find where kernel- is specified
<mangix> bah I'm pretty sure this involves taking the device appart
<mangix> the more I look at this the more I think this PR is mistaken in that it installs OpenWrt in the first partition. It looks like most devices install to the second one.
mangix has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest1444
srslypascal has joined #openwrt-devel
mangix has joined #openwrt-devel
srslypascal is now known as Guest1445
srslypascal has joined #openwrt-devel
<mangix> bricked my device, AGH.
Guest1444 has quit [Ping timeout: 480 seconds]
Guest1445 has quit [Ping timeout: 480 seconds]
<mangix> behind door 1: restore. behind door 2: open up device and get this FIT thing working.
goliath has quit [Quit: SIGSEGV]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<hurricos> has anyone else here experienced "searching" state with realtek-poe?
<hurricos> mangix: compatible denx,fit is correct
<hurricos> mangix: fit! fit!
minimal has quit [Quit: Leaving]
lynxis has quit [Remote host closed the connection]
lynxis has joined #openwrt-devel
srslypascal is now known as Guest1452
srslypascal has joined #openwrt-devel
srslypascal has quit []
Guest1452 has quit [Ping timeout: 480 seconds]
<neggles> mangix: you should definitely be using FITs if the stock firmware does, it's nice and easy, and you don't need to open it up
<neggles> this is the u6-lite right?
srslypascal has joined #openwrt-devel
<neggles> mangix: https://gist.github.com/neg2led/59e9cb893ba304bcd99f7c0694749c53 it doesn't boot kernel@1, it boots config@1 - don't we already have this in master?
<neggles> hm. i suspect I am not right about this being for u6-lite
<neggles> but same process works for all the UAP fw images
<owrt-snap-builds> Build [#19](https://buildbot.openwrt.org/master/images/#builders/78/builds/19) of `at91/sama7` completed successfully.
<mangix> neggles: no
<mangix> adding compatible = "denx,fit"; to the alt_firmware partition broke booting
<mangix> to get this garbage working, I'd most likely need to open the device and test with initramfs
<neggles> ah right
<hurricos> question: to compile a single package (.ipk), shouldn't `make package/$PACKAGE/install` work?
<neggles> hurricos: is it a feeds package
<neggles> e.g. `make feeds/packages/utils/zstd/compile`
<neggles> wait derp no that'd be `make package/utils/zstd/{clean,compile,install}`
<hurricos> utils/
<hurricos> Hmmm
<hurricos> I have a patched-in package (realtek-poe) which sits at package/network/config/realtek-poe
<mangix> make package/zstd/{clean,compile,install}
<hurricos> so
<mangix> no utils
<neggles> yeah i've not had a lot of luck working out what path to call for a given package tbh.
<neggles> oh? neat
<hurricos> No
<hurricos> It's not. It's a source of controversy
<hurricos> :^)
<hurricos> Ah! Neat! OK! adding config/network/ to the path fixed it.
<neggles> i believe it's related to where it appears in the menuconfig tree
<hurricos> Thanks, that was very helpful
<hurricos> No, I'm currently stuck trying to write ubus logic to "send arbitrary PoE command frame".
<hurricos> Because whenever I plug in a PoE device, it goes from state "Searching" to state "unknown"
<mangix> hrm. I really don't want to open this device
<hurricos> do it :^)
<hurricos> it's just glueee
<neggles> mangix: do you have a flash dump or fw_printenv output
<mangix> I do not
<mangix> why?
<hurricos> you'll never be able to^w^w^w have to open it again
<mangix> this router has two partitions. wonder how to get it to boot from the second one
<neggles> mangix: that's why i ask for the u-boot environment :P
<hurricos> I bought four mt76 cards from asiarf
<hurricos> I hope I don't regret this.
<mangix> neggles: I mean the variable is called bootimage. =1 boots the first partition, =2 boots the second one
<neggles> mangix: yes, but what's important is what bootcmd (and anything else it calls) is doing with that information
<neggles> since it looks like stock fw doesn't use a FIT
<mangix> it does
<mangix> bootcmd is something like mtk_boot
<neggles> mangix: right, then `KERNEL := kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb` and put `compatible = "denx,fit";` in the firmware partition you want to use in the DTS should do it, then if you want ubifs there's a few extra bit
<mangix> neggles: I have a commit I wanted to test. https://gist.github.com/neheb/ed62121aab9560216a0323a46c9b6735 . I ended up doing the denx,fit thing without that
<mangix> that's why no boot right now
<neggles> mangix: the kernel_initramfs line you've put there is redundant in this case
<mangix> that...sounds like it needs further dts changesa
<neggles> well
<neggles> do you have a separate kernel/rootfs
<neggles> partition pair i mean
<neggles> ah yes okay
<neggles> so KERNEL_IN_UBI is a no
<neggles> and we can't mess with the default partition layout or their custom uboot script will get angry
<mangix> should kernel be in ubi?
<neggles> from a sheer technical perspective, yes, the way this *should* be done is with a single mtdpart on the NAND that's just UBIFS, with the kernels as ubivols, but nobody does that except sophos that i've found
<mangix> I know of dango doing that
<neggles> it would be easy to convert to that if not for the custom u-boot shenanigans they're doing.
<neggles> what you have instead is, kernel is a FIT image in a partition, then ubifs where rootfs_data is (the 'ubi' partition) - also why on earth is alt_firmware so huge??
<mangix> good question :)
<mangix> alt_firmware is partition 2. I didn't bother subdividing it.
<mangix> sorry, bootimage 2
<neggles> ah, so it contains its own u_env/factory/kernel/ubi or?
<neggles> just kernel/ubi?
<mangix> probably just kernel/ubi
<mangix> the beginning is definitely the kernel
<neggles> alrighty, well you should definitely break those two partitions out in the dts as kernel2/ubi2, but
<mangix> somebody posted the stock firmware layout in the forum
<neggles> ah yep found it
<neggles> oh now that's interesting
<mangix> hmm?
<neggles> well for one their stock fw mapping overlaps 'config' with 'factory'
<neggles> which is probably just a typo
<neggles> i.e. it's probably meant to look like https://gist.github.com/neg2led/53e757f61f779732404889245056dcc5
<mangix> hmmm what does Factory contain?
<neggles> almost certainly radio calibration data
<neggles> mac addresses
<mangix> good joke
<mangix> anyway
<neggles> may also be "literally nothing"
<neggles> but you've got chunks of it in your OpenWrt dts - devinfo, s_env
<neggles> wait no that's all in config. nvm.
<mangix> ah ty for asking
<mangix> so the stock firmware lumps up everything in a single partition
<neggles> i forgot how base16 works for a moment there.
<mangix> I subdivided it
<mangix> the devinfo partition is configuration information for the stock firmware
<neggles> yeah, the question is whether it's loading the fit image from ubifs or not and it looks like no >:(
<mangix> the s_env partition is mostly empty
ekathva has joined #openwrt-devel
<mangix> CBTInfo is completely useless
<neggles> yeah not surprised
<mangix> hmmm I see mediatek,mtd-eeprom = <&factory 0x0000>;
<mangix> so I guess factory is mostly useless
<neggles> well no, it's got the mediatek radio eeprom/cal data in it :P
<neggles> but you'd want to flag it read-only
<mangix> I wonder why I subdivided kernel and ubi. stock firmware seems to not do that.
<neggles> based on their gpl sources, CBTInfo seems to be the NAND bad block map
<neggles> oh hey
<mangix> hey
<neggles> it's also where it's storing... u-boot version info?
<neggles> ahhh device info
<neggles> just some strings, would ignore
<mangix> strings on CBTInfo returns 5 strings. They all look useless
<neggles> they are
<neggles> but the CBT_BOOT_VERSION string is checked by the mtkboardboot command
<mangix> sigh. looks like I have to disassemble this to investigate
<neggles> however it *is* just a command, and it's only called by bootcmd=, not by anything fancy/hardcoded like overriding bootcmd
<neggles> does the stock firmware have `fw_setenv` / `fw_printenv` ?
<mangix> beats me
<neggles> fair enough
<neggles> can't get root on it?
<mangix> I mean if I disassemble it and hook up serial, yes
<neggles> what've you been doing so far? trying to feed it an image over recovery?
<mangix> nothing. it's just sitting on my desk. I have no idea how to activate the tftp client
<mangix> through serial it's option 3 or something like that
<neggles> ah okay
<neggles> it will also start a http recovery thing if autoboot fails
<mangix> pretty sure autoboot succeeds
<mangix> and then fails
<neggles> yeah
<neggles> you'd have to purposefully corrupt both flash banks
<mangix> I mean there are two partitions
<mangix> there should be a way to boot firmware2
<neggles> there is, it boots firmware2 if u-boot environment variable bootimage = 2
<neggles> runs `nboot firmware_2`
<mangix> no idea how to get it set to 2
<neggles> can't ssh into the factory fw?
<mangix> I doubt it
rua has quit [Ping timeout: 480 seconds]
<mangix> actually, the device doesn't boot right now
<mangix> well, it does but ends up failing
<neggles> it's kinda weird
<neggles> they've got two firmwares, and it's counting how many times boot has failed
<neggles> but it doesn't do anything with that info
<neggles> normally you'd have a "if ( bootcount >= 10 ) { boot the other image }" type block
<mangix> I mean I'm sure it does
<neggles> am looking at the code rn
<neggles> it does not
<mangix> that jeff guy was complaining about the PR not handling that
<neggles> ah, no, no i'm blind it does
rua has joined #openwrt-devel
<neggles> if bootcount >= 3, change 1 to 2 and 2 to 1
<neggles> i would say you will need to take the thing apart, yeah. and ugh their u-boot is compiled with no ubifs support. typical.
<mangix> I mean it's Cybertan crapware
<neggles> they were *so close* to doing this correctly
rua has quit [Ping timeout: 480 seconds]
<neggles> oh that's bloody clever of them </s>
<neggles> mangix: they've got a codepath in here that brings up the failsafe web ui... except they've disabled the failsafe webui.
<neggles> and it doesn't look like it does any checking for buttons to trigger a tftp recovery. so if it won't boot at all, uart's all you've got.
<neggles> er, s/boot at all/boot to a state you can get into it from/
<mangix> lolwut?
<neggles> if it can't load either kernel, there's a failsafe webui it'll try to load, but only if it was turned on at compile time
<neggles> and the config they've used, has it turned off
<mangix> would be fun to replace the bootloader with breed, but I doubt breed would support this unit properly
<neggles> so if neither kernel loads it just goes back to sitting at the u-boot shell
<neggles> it would be trivial to replace the u-boot with one that does have UBI/FIT support
<mangix> which sounds great
<neggles> but flashing it from an unopened device / without uart might be difficult depending on whether you're root if you ssh into the stock firmware
<neggles> and booting/installing with stock bootloader still needs to be possible, so you'd end up with something like what we have for U6-LR - two targets, one for modded/custom uboot, one for factory
rua has joined #openwrt-devel
<neggles> but yeah it just runs nandboot <first sector of firmware or firmware_2> depending
<neggles> and some scripts need to be fiddled with to handle the bootcount and alternate firmware banks
<neggles> mangix: I have to correct myself again, your KERNEL := and KERNEL_INITRAMFS := are correct - the tp-link eap615-wall is very similar just using NOR instead of NAND and with a single image
<neggles> and tp-link's usual shenanigans we can ignore
<mangix> from the fit patch?
<neggles> yeah, it'll boot a FIT, it just has to be the bare FIT at the start of the partition
<neggles> so for factory bootloader you'll need to decide how much to set aside for kernel, then split firmware and firmware_2 - like you already did for firmware
<neggles> then if you want to ignore the alternate image bank, add a line to the sysupgrade script that does a `fw_setenv bootimage 1`
<neggles> it's not super difficult to support booting from either / flashing to the alternate though, we've got scripts doing that for other devices
<mangix> got an example?
<neggles> yes actually - alfa-network,quad-e4g
<neggles> openwrt/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
<neggles> that has some extra bits wrapped around it, all you really need to do is `fw_printenv bootimage` and see if it's 1 or 2
<neggles> you could also follow the asus method there of copying the current booted kernel to the alternate, then overwriting current booted
<mangix> i'll check it out. unit disassembled. time to hook up serial, if I even remember the pinout
<mangix> neggles: fml so looks like the stock firmware's booting
<mangix> didn
<mangix> 't need to open it up. oh well.
<mangix> neggles: lmao stock firmware has fw_printenv
<mangix> neggles: so the ethernet mac address is stored in devinfo. Instead of dealing with that, would it make sense to use ubootenv to store the mac address?
<neggles> not really, i imagine it's at a fixed offset?
<mangix> sort of
<mangix> hw_mac_addr=$(mtd_get_mac_ascii devinfo wan_hwaddr)
<neggles> i would just use that then
<neggles> even if you put them in the uboot env, there would have to be a check for that on every boot in case the default env had been set
<neggles> ideally you'd find them at some fixed offset in flash and use nvmem
<mangix> good point
<mangix> neggles: nvmem does not support ascii
<mangix> and no, it;s not present anywhere else
<mangix> unless i suck at looking
<mangix> neggles: didn't work
<neggles> oh
<mangix> Second try with DEVICE_DTS_CONFIG
<mangix> doubt it'll work
<mangix> strange that it says lzma error
<owrt-2203-builds> Build [#15](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/11/builds/15) of `at91/sama5` completed successfully.
<mangix> didn't work
<mangix> neggles: any idea what's wrong?
<owrt-2203-builds> Build [#15](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/41/builds/15) of `apm821xx/nand` completed successfully.
<neggles> mangix: unfortunately yes
<neggles> wait s second
<neggles> that's only showing the fdt
<neggles> where'd the actual kernel go
<mangix> it's a partial log. I'll send a more complete one in a bit
<neggles> ah ok
<mangix> wait a minute...
<mangix> now it's not booting at all
<neggles> O_o
<neggles> your fit should have a kernel and a FDT and a default config - you don't actually need to set DEVICE_DTS_CONFIG
<neggles> it's not booting a specific config, it just boots the default
<mangix> I think what's happening is that it's flashing firmware 2.
<mangix> and it's not booting because the current setup only works with firmware1
<mangix> let me try initramfs
<neggles> that shouldn't stop it from booting entirely...
<mangix> can't figure out why it hates FIT
<ynezz> hauke: thanks for the at91 config fixes
<neggles> *sigh* it doesn't
<neggles> mangix: your kernel image needs to be 8MB or less when uncompressed.
<neggles> mangix: yeah, so, u-boot allocates a fixed-size buffer for lzmadec/gunzip(), the size of which is a compile-time-only option
<neggles> the default is 8MB and vendors NEVER CHANGE IT
cbeznea has joined #openwrt-devel
<mangix> not sure I folloqw
<mangix> *follow
<mangix> under image.mk, I have KERNEL_SIZE := 4096k
<neggles> that's the compressed size
<neggles> in the build_dir kernel dir how big is vmlinux
<mangix> so, am I looking for the size of vmlinux?
<mangix> 57M
<neggles> that's with debug info
<neggles> there should be a stripped one
<neggles> uImage or zImage or vmlinux
<neggles> er, vmlinuz
<mangix> vmlinuz is 17M
<neggles> and there's yer problem
<neggles> if you change `fit lzma` to `fit none` it should work
<mangix> I mean, it's not like I have some option enabled that bloats it
<neggles> no, no you are not
<mangix> and no, it doesn't
<mangix> tried that
<neggles> but kernel 5.10/5.15 are a lot bigger than 4.4 :(
<neggles> what's your current KERNEL := line? same as in PR?
<mangix> yes, 4096K
<mangix> oh wait kernel
<mangix> KERNEL := kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb
<mangix> I think I'd need to get rid of lzma and fit lzma
<neggles> kernel-bin | fit none $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb
<neggles> yeah
<neggles> forgot about the extra lzma
<neggles> it's allocating 32MiB for uncompressed kernels >:(
<mangix> lolwut?
<mangix> I find it strange that all other ramips devices use fit lzma though
<neggles> it's a u-boot config option.
<neggles> imo it's a u-boot bug.
<neggles> but it's hardly their fault that vendor SDK kits / OEMs don't bother to actually learn how any of it works, and if your kernel image is <8MiB you never notice
<neggles> lzma-loader could help you out here, or splitting initrd/rootfs into their own components of the FIT
<mangix> the interesting part is, this limitation I seem to hit only with fit
<mangix> oh
<neggles> legacy image is self-decompressing
<mangix> compilation failed
<neggles> ah yeah KERNEL_SIZE
<neggles> set that to 32768K for now
<mangix> yeah I'm suspicious here
<mangix> the other ramips devices seem to work find
<mangix> *fine
<mangix> image too big
<mangix> yeah can't get this to work
<mangix> time to abandon fit
Misanthropos has quit [Ping timeout: 480 seconds]
<mangix> wonder if I should try flashing breed
<mangix> gch981213: ping
mangix_ has joined #openwrt-devel
<mangix_> back in production with the wrong mac address
<mangix_> rofl
mangix is now known as Guest1461
mangix_ is now known as mangix
Guest1461 has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<owrt-snap-builds> Build [#511](https://buildbot.openwrt.org/master/images/#builders/14/builds/511) of `bcm63xx/generic` completed successfully.
<neggles> mangix: sorry had conf call
<neggles> ahhhhh
<neggles> um
<neggles> mangix: stock firmware image: Load Address: 0x81001000
<neggles> default for mt7621 target: Load Address: 0x80001000
<neggles> add KERNEL_LOADADDR := 0x81001000 and try again w/lzma...
<neggles> may need to add `relocate-kernel 0x80001000` after `kernel-bin` in KERNEL := - see define Device/iptime_ax2004m in mt7621.mk
pepe2k has joined #openwrt-devel
<mangix> neggles: joy
<neggles> mangix: quite
<neggles> looking again they *may* have configured it to assign a 32MiB buffer - CONFIG_SYS_BOOTM_LEN=0x2000000
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
<mangix> neggles: wonder why non fit works
<mangix> i also wonder why this thing just rebooted
<owrt-2203-builds> Build [#15](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/50/builds/15) of `apm821xx/sata` completed successfully.
<ynezz> jow: that default theme in 22.03 is dope, it even respects my dark scheme preferences
<jow> thanks, it's rare to hear something positive about theme changes :)
<ynezz> ooh, even luci-statistics has dark mode, cool
<neggles> mangix: non fit uses a kernel which decompresses itself
<neggles> i think?
<neggles> jow: ever since the automagic light/dark bootstrap theme dropped in I haven't bothered with using/trying out any others, it's really nice :)
<owrt-2203-builds> Build [#13](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/26/builds/13) of `ramips/rt305x` completed successfully.
<owrt-1907-builds> Build [#4](https://buildbot.openwrt.org/openwrt-19.07/images/#builders/17/builds/4) of `sunxi/cortexa53` completed successfully.
<stintel> re eap660hd: no I do not have such unit and apparently it's qca so I never will
<neggles> yeah they're ipq8074
<neggles> QCN5024 + QCN5054 + QCA8081
<stintel> re bbt, check the bootloader output, there are iirc 3 different types of bad block management used by mtk, zr-2662 for example uses nmbm
<mangix> mtdblock: MTD device 'cbtinfo' is NAND, please consider using UBI block devices instead.
<mangix> yeah... not really possible
<mangix> neggles: btw do you know about this? https://gist.github.com/neheb/b41e9de06f461905c32b544b8d0d6de9
<neggles> mangix: bad block table info wrong
<stintel> most likely not using bbt, see my previous message
<neggles> i.e. what stintel just said :P
<neggles> lemme check the sources
<mangix> although that's just copy/paste from other devices
<stintel> oh, hmm
<stintel> sorry
<owrt-2203-builds> Build [#14](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/63/builds/14) of `at91/sama7` completed successfully.
<owrt-2203-builds> Build [#14](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/64/builds/14) of `mpc85xx/p1010` completed successfully.
<mangix> stintel: strings /dev/mtd0 | grep -i bbt
<mangix> mt7621_nand_bbt_compat: Unable to allocate %d bytes for BBT
<neggles> stintel: they're doing some kind of weird custom thingy
<stintel> neggles: it's just proprietary mtk stuff, there is bmt v2, bbt and nmbm
<stintel> see target/linux/generic/files/drivers/mtd/nand/
<neggles> fairo
robimarko has joined #openwrt-devel
<stintel> also, I have 2 zr-2662, one of them shows it's initializing nmbm in bootloader output, the other doesn't, I suspect I nuked that part from the nand during my attempts to get the thing to boot
<mangix> oh i see
mangix has quit [Remote host closed the connection]
<stintel> also I don't have that BBT string in my mtd0 (bootloader), but having that string shouldn't necessarily mean the device uses BBT, I would suspect the bootloader can support it regardless of it being used
<stintel> I also don't find nmbm ...
<neggles> stintel: #define CONFIG_COMPAT_NAND_BBT 1
<neggles> for the e7350
<neggles> so, whichever the old one is
<neggles> the gpl tarball for this thing is very complete h
<slh> neggles: the good news would be ipq8072a (and not plain ipq8072, which would not have ath11k support and will probably never get any), but secure boot might still be enabled... other than that, have a look at https://github.com/robimarko/openwrt/tree/ipq807x-5.15
<robimarko> Its probably IPQ8072A
<robimarko> I dont think that there ever was v1 of anything else other than IPQ8074
mangix has joined #openwrt-devel
<neggles> it is ipq8072a yes
<neggles> but I don't have one :P
<neggles> and I don't super wanna buy one, they don't even have 160mhz support
<neggles> secure boot is enabled but trivial to disable
<neggles> based on the brief poke around i had in a friend's one, it's the classic fw_setenv verify no
<robimarko> What do you mean it doesnt have 160MHz?
<neggles> EAP660 HD will not do 160MHz channels
<robimarko> That smells like a artificial limit
<neggles> gotta get this one
<neggles> which drops to 2x2 on 2.4GHz but gains 160mhz on 5.8
<robimarko> I can tell you that even the IPQ8071A which is the cost cut version does 160MHz at 2x2
<neggles> does the QCA5054?
<owrt-2203-builds> Build [#14](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/25/builds/14) of `sunxi/cortexa7` completed successfully.
<robimarko> It does for sure, that exact combo is used in Xiaomi AX3600 and AX9000
<robimarko> QCA5054 is the most common one for 5G
<neggles> i guess they probably just didn't get it certified then
<neggles> the 670 hasn't shown up at the FCC yet so can't tell if there are any hw differences
<robimarko> It can do 4x4 80Mhz, 2x2 160Mhz
<neggles> ah yeah
<neggles> the 660 is a 4x4 AP
<robimarko> But 149-161 MHz it can only do 80MHz as far as I remember
<neggles> the 670 does 4x4 160MHz
<robimarko> I bet the 670 then has a QCN9024/9074 card
<neggles> (and yes i mistyped i meant QCN5024+QCN5054)
<neggles> and that would check out, though it's dropped down to 2x2 on 2.4GHz as well
<mangix> swapped router again
<neggles> so probably QCN5024 + QCN9054? if that's an option?
<mangix> whatever firmware I had was unstable
<stintel> also, the unifi 6 lite is easy to open, I managed to do mine without damaging it
<robimarko> neggles: There is no QCN9054
<stintel> unifi 6 lr was a bit harder, some damage but still able to close it afterwards
<neggles> robimarko: okay i clearly need to stop doing nerd things for today because I am barely awake >.> 9074
<robimarko> neggles: QCN5024 can do 4x4 on 2.4GHz just fine
<robimarko> They would be the first one to artificially limit stuff
<neggles> hm
<neggles> I've no idea why they've got 4x4 2.4 + 4x4 @ 80mhz 5.8, and 2x2 2.4 + 4x4 @ 160MHz 5.8
<neggles> possibly 4x4 on 2.4GHz is mostly pointless?
<robimarko> It is pointless for anything else than padding the PHY rates
<neggles> yeah
<neggles> same goes for 160mhz really
<robimarko> Yeah, unless you have a really specific short range high throughput application without interference
<neggles> point to point with some big angry dishes/horns
<robimarko> Yeah, ideally that
<neggles> it makes more sense once 6GHz gets involved
<robimarko> Then it works over quite a distance
<neggles> and discontinuous channel bonding
dedeckeh has joined #openwrt-devel
dedeckeh has quit []
dedeckeh has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
rua has joined #openwrt-devel
<owrt-2203-builds> Build [#13](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/70/builds/13) of `sunxi/cortexa53` completed successfully.
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
<robimarko> rsalvaterra: What are the plans for mvebu 5.15?
<rsalvaterra> robimarko: Given that mwlwifi is fixed (for some value of "fixed", since we're talking about mwlwifi)…
<rsalvaterra> … I guess the only pending issue is this one: https://github.com/openwrt/openwrt/pull/9582#issuecomment-1089194283
<rsalvaterra> Seems like wired links aren't working, for some reason. Probably DSA driver issues.
<rsalvaterra> Unfortunately I don't have the hardware to test…
<robimarko> Yeah, mwlwifi is fixed in the sense it works
<robimarko> Rango uses which SoC?
<rsalvaterra> Armada 385, I think. Let me see…
<rsalvaterra> Confirmed. The switch is an 88E6352.
<robimarko> Unfortunately, dont have any Armadas 38x nor that switch
<rsalvaterra> The SoC on my Omnia is the 385, but unfortunately it also has a different switch (which works perfectly).
fanthos has joined #openwrt-devel
<ynezz> there should be a lot of users with wrt3200acm, which should've same specs
fanthos has quit [Remote host closed the connection]
<ynezz> mv88e6085 f1072004.mdio-mii:00: switch 0x3520 detected: Marvell 88E6352, revision 1
<ynezz> ah, codenames, it's rango then :p
<rsalvaterra> ynezz: You have a Rango?
goliath has joined #openwrt-devel
<ynezz> rsalvaterra: yep, but it's currently my router/uplink so don't know when I can boot test 5.15 on it
<rsalvaterra> :(
<ynezz> it's using 5.10.109 and works fine with multiple devices connected directly to it over ethernet
<rsalvaterra> Speaking of which, 5.10.110 and 5.15.33 will probably be out today, and they'll huge updates.
bluew has quit [Quit: Leaving]
pepe2k has quit [Remote host closed the connection]
<Tapper> Hi people is k 5.15 running on the r7800?
ekathva has quit [Quit: Leaving]
<slh64> Tapper: if you enable the testing kernel, it should (works on my nbg6817/ g10)
<Tapper> slh64 OK thanks
xback has joined #openwrt-devel
<owrt-snap-builds> Build [#514](https://buildbot.openwrt.org/master/images/#builders/17/builds/514) of `ramips/rt305x` failed.
mattytap has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
arthur_melo has joined #openwrt-devel
<neggles> rsalvaterra: they fix mips64 :D
<rsalvaterra> neggles: I saw it! About time! :)
rua has joined #openwrt-devel
<neggles> the patch mysteriously appeared in the stable queue a few hours after I replied to the patch and CC'd gregkh
<neggles> coincidence? probably! but i'm still going to claim credit :P
pepe2k has joined #openwrt-devel
<rsalvaterra> And it's in 5.15 stable now! Surely in 5.10 too (both released moments ago).
<rsalvaterra> Patch generic-backport/350-v5.18-MIPS-pgalloc-fix-memory-leak-caused-by-pgd_free.patch can be reverse-applied
<neggles> yes 5.10.110 has it
<rsalvaterra> Never been happier to see this error. :)
<neggles> and 5.15.33
<neggles> i think 5.16 got it too
<stintel> yep
<stintel> ./releases/5.16.19/mips-pgalloc-fix-memory-leak-caused-by-pgd_free.patch
<neggles> hah literally released 28 and 11 min ago
<Habbie> is that the longstanding octeon leak?
<neggles> yep!
<Habbie> awesome
<neggles> it was not just octeon
<Habbie> ack
<neggles> the entire mips64 architecture has been broken since 5.9 T_T
<Habbie> wow
<neggles> but i imagine most mips64 systems out there are octeons or loongsons
<neggles> so running older/vendored kernels
<robimarko> Its a classic case of nobody actually using mainline kernel
<robimarko> Especially since MIPS64 is exotic at best
<neggles> it's probably not a coincidence that it was found and fixed by a windriver guy shortly after 5.15 was released
<neggles> robimarko: it's only exotic if you don't make firewall appliances :P
<neggles> ...or like half of cisco's other misc appliances
<robimarko> But that doesnt matter at all in mainline kernel
<neggles> yeah
<robimarko> Since they are just using whatever SDK
<neggles> OpenWrt is probably the only project with any real user count that tries to run mainline-or-close-to-mainline on octeons
<stintel> an snic10 would be very easy to set up some kind of automated testing, maybe we should look into that
<neggles> true, you can bash script your way into whatever on those
<robimarko> OpenWrt is probbaly the only project running on such a variety of mainline kernels
<neggles> i should load a tiny kernel into the NOR on my 2nd one and boot it up standalone
<stintel> yeah, I've an openrc init script to boot mine automatically
<stintel> with overlay on NOR
<stintel> but for any real use we should forward port the NAND driver
<neggles> oh you mean the one that *doesn't work*
<neggles> even in the octeon SDK?
<stintel> no idea, never tried the SDK
<stintel> but there are 2 octeon NAND drivers out there even, iirc
<neggles> I did - I built their 4.14 kernel, with their toolchain, and a 19.07 userland
<neggles> doesn't work.
<robimarko> Those SNIC-s use Octeon III or?
<neggles> octeon II
<neggles> CN6640 8-core
<neggles> and there's a bunch of commit history in the octeon kernel repo with discussions around the NAND driver being various kinds of broken
<neggles> i just checked my notes and it does detect the chip and read/write, but the ECC calculations don't work right
<rsalvaterra> I'm starting to think the PCIe Aardvark driver hates me.
<neggles> no combination i tried would match what u-boot was doing
<neggles> and iirc i couldn't even read back things i'd only written from linux after a reboot
<neggles> rsalvaterra: oh? aardvark is the 3720 right
<neggles> 3700
<rsalvaterra> Right.
<neggles> regrettably while i have one of those it has no pcie devices
<rsalvaterra> neggles: Not even internally?
<robimarko> Whats the issue with Aardvark again?
<robimarko> I though it was sorted out
<neggles> sadly no :( it's an oc200
<rsalvaterra> robimarko: It was… until 5.15.33 came out, half an hour ago. :)
<rsalvaterra> Now I have to manually rebase patches.
<robimarko> Ok, I can give it a look in the evening
<rsalvaterra> And IRQ handling code can be rather finicky.
<neggles> i've been trying to make dsa play nice with it but I don't know how the devicetree should look for "qca8k dsa attached to a marvell soc"
<robimarko> And test on Espressobin Ultra since it has a 88W8997 card
<robimarko> negless: SoC vendor doesnt matter for qca8k at all
<robimarko> Just place it under the MDIO node and set the correct CPU port PHY mode
<neggles> yeah i think the cpu port phy mode is what i was missing
<neggles> i just added it
<neggles> so we'll find out in 3... 2... 1...
<neggles> oh hey a new error!
<stintel> as long as there isn't any smoke ... :)
<robimarko> neggles: What do you see?
<neggles> wait a second i think it worked
<robimarko> stintel: I dont think Marvell/Cavium ever got NAND working
<robimarko> Cause notes from SDK 5.1.0 (Last one)
<neggles> that was my conclusion from their commit notes
<neggles> etc
<robimarko> Special notes: NAND device not supported, NAND support will be added in a future patch release.
<neggles> another reason why i would kill a man for a more recent SDK :(
<robimarko> Recent is a loose term
<robimarko> From 2017
<neggles> omfg it's working
<neggles> mvneta is unhappy i think i fed it something i shouldn't have but
<robimarko> What PHY mode are they using?
<neggles> mii
<neggles> 100mbps
<robimarko> Are you sure?
<neggles> 110%
<robimarko> Thats weird, never seen qca8k switch on 100M uplink
<neggles> have a boot log
<neggles> it's not technically supported
<stintel> I carry a patch for that
<neggles> it's an AR8236
<robimarko> Oh, thats a different thing
<neggles> fun fact
<neggles> the AR8236 and AR8327 have near-identical register maps
<neggles> save for the lack of 1G config bits
<robimarko> Yeah, that is how AR8327 got support in swconfig
<neggles> i think the mistake i made here was i passed a phy-handle to eth0
<neggles> so mvneta and qca8k are arguing over mdio stuff
<robimarko> stintel: Oh, they actually got NAND working in 5.1.0 patch 1 release
<neggles> for octeon ii or only octeon iii ?
<stintel> do you have access to that source ?
<neggles> i did manage to get it to detect the chip and read/write it, but the ecc was all broked
<stintel> hmmm, I don't recall exactly what I had to do to mvneta to make it work on the oc200
<robimarko> The familly is not listed, it just says: Added NAND driver support in linux kernel
<robimarko> Yeah, I have Extranet acess
<neggles> !
<neggles> they wouldn't even give it to the company i work for despite us having a quite legitimate reason for it at the time :(
<robimarko> Thats weird
<robimarko> Extranet acess was way easier to get then any other NDA based stuff
<neggles> they asked for the various company details for NDA reasons, i replied with same, heard nothing
<robimarko> And unlike QCA and others its quite detailed
<neggles> chased it up a few times, silence
<robimarko> Thats weird, they have been granting stuff rather quickly
<neggles> the doubly weird thing is if i go try to log in it says i have an account associated with my email
<neggles> but the reset password email never arrives
<robimarko> Yeah, cause they never approved the account
<robimarko> I had a collegue with the same issue
<neggles> also prevents me from opening another application
<neggles> i've sent a dozen emails and the only replies i've had since last year are autoreplies saying one of the people i was emailing no longer works for marvell
<stintel> create an alias? :P
<stintel> I probably have >100 aliases by now :P
<neggles> I mena
<owrt-2102-builds> Build [#4](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/41/builds/4) of `ath79/tiny` completed successfully.
<neggles> I have global admin on exchange online
<neggles> ...and everything else
<neggles> I'd assumed they were ignoring me on purpose
<rsalvaterra> Ok, I seem to have left Aardvark behind. Onwards, then…
<neggles> but hanlon's razor and all...
<neggles> robimarko: out of curiosity, what's the latest version that's on there? is it still just patches on 5.1?
<robimarko> Yeah, 5.1.0 Patch 2
<neggles> interesting
<neggles> seems what we have is 5.1.0 no-patch
<neggles> if they fixed the nand controller driver that would be really useful to have, then these snic10es will actually be usable without a host PC
<robimarko> Was the kernel 4.9.57?
<neggles> let me check
<neggles> 4.9.57 yep
<robimarko> Then WTF do they have a 4.14 tree on Github?
<neggles> which is interesting given that https://github.com/MarvellEmbeddedProcessors/Octeon-Linux-kernel-4.14 is 4.14.76 and the ubiquiti kernel is 4.9.79
<neggles> robimarko: i've also seen references to an octeon sdk v6 in a few places
<robimarko> No idea, I only see SDK3,5,10 and 11
<robimarko> 10 and 11 are Armada/Octeon universal
pepe2k has quit [Remote host closed the connection]
<neggles> robimarko: do they still include mips support? or octeontx/tx2 only?
<robimarko> ARM only for 10/11
<robimarko> 11 is TX2 only I think
<neggles> maybe they'll only give you the newer mips stuff if you're wind river or juniper
<robimarko> Its probably only contract based support
<neggles> 'cause wind river support octeon 2 and 3 with a 5.4 BSP
<neggles> and presumably 5.10 now if the memleak fix is anything to go by
<robimarko> Oh, they actually added Armada 7k to SDK11 as well
<robimarko> Probably a lot of users were pissed of with them trying to kill Armada 7k/8k and move everything to TX2
<neggles> I mean the CN9130 is really the armada 9040
<neggles> :P
<neggles> oh. i put 'rgmii' in instead of 'mii', like a fool
Tapper has quit [Ping timeout: 480 seconds]
<hurricos> It was someone from Windriver that reported / sent in a patch for the mips64 memleak
<hurricos> glad to hear NAND is working!
<hurricos> ... on someone's proprietary patchset :groan
<neggles> hurricos: apparently there are two patch vers of 5.1.0 above the one we have
<neggles> and the first one has "fixed nand"
<hurricos> :vomiting:
* neggles curses marvell
<hurricos> =_=
<neggles> GIVE US PATCHES, MARVELL
<hurricos> Well, when they bought Cavium, they really just bought Cavium's customers
<neggles> and their accelerator IP
<hurricos> which are very expensive customers as it's very expensive and powerful hardware
<neggles> scooped the MIPS out, shoved some shiny ARM in
<hurricos> so I'm not surprised they're not exactly opening everything up
<neggles> the doubly weird thing is 5.1.0p2 seems to have the same kernel patchver as 5.1.0
<neggles> which is a 4.9, and there's a 4.14 on their github?
<hurricos> Honestly, all I want is a DSA-supported 10GbE switch.
minimal has joined #openwrt-devel
<hurricos> that's all I want. I'm waiting on Realtek for that at this point.
<hurricos> that should tell you all you have to know about how messed up the space is
<neggles> ah yeah all the prestera stuff's switchdev isn't it
<neggles> mikrotik's routeros v7 sources might have something you can use - they use DSA for their port extender shenanigans iirc
<hurricos> No
<hurricos> It requires a lot of hackery out-of-tree stuff (CPSS)
<neggles> ah
<hurricos> I actually requested and got those sources too :P
<neggles> classic marvell
<hurricos> I had a CRS309-1G-8S+IN
<hurricos> I bought it for just under $200
<hurricos> I'm sure I could fetch nearly $500 now for it lol
<neggles> you seen their new 100G box?
<hurricos> Oh no
<hurricos> I can't, they still make them. Thank God for Mikrotik
<hurricos> No, but then I don't have any access to 100G cards :^)
<neggles> the 309 isn't going anywhere anytime soon
<neggles> nor is the 317
<hurricos> Yeah, Mikrotik gets my kudos for being consitent. It's just that I don't want to use their firmware ;)
<neggles> hurricos: neither do i, but a 4x100G switch is also a 16x25G switch and 25G NICs are getting cheap
<hurricos> err, what?
<neggles> you can split a QSFP28 into 4x SFP28 with a DAC or a SR4 optic and an MTP breakout
<hurricos> are you telling me there's some crazy kind of 100G QSFP
<hurricos> ...
<hurricos> octopus. Wow, OK.
<neggles> all 100G is QSFP28
<hurricos> Well, I still don't need 25G.
<neggles> unless it's part of 400G but shh
<hurricos> :P
<neggles> i have a CCR2004-1G-2XS-PCIe on the way
<neggles> it's been delayed a month and a half though :(
<hurricos> I've got one use-case for it
<hurricos> hook fast, new, tiny-silicon crap to lots of spinning rust
<hurricos> can't do it with anything but ethernet.
<hurricos> at least nothing *cheap* other than ethernet.
<neggles> what kind of fast new tiny silicon crap
<robimarko> Edgecore EPS300 for those wanting 48x10G SFP+ with switchdev
<hurricos> A Lab member is (for some reason) buying an M1 Max and is planning to leave it at the Lab
<hurricos> I've promised not to destroy it, I probably will in the process of getting Linux on it though.
<neggles> mac studio or laptop?
<hurricos> Studio
<neggles> cause asahi won't run on studio very well yet
<neggles> and you can't destroy it
<hurricos> Oh no?
<hurricos> Oh no
<hurricos> "yet"
<neggles> well the devs have it running
<neggles> it'll be "yeah this works" pretty soon
<hurricos> No, they haven't even ordered it yet. Their work is buying it for them when they have their computer refresh up in July
<neggles> half the peripherals are inaccessible as of yet
<neggles> cause they're hanging off die 2
<hurricos> Bah
<neggles> but yeah those machines are effectively unbrickable as long as you're not insane enough to touch the 8mib SPI NOR
<hurricos> uh
<neggles> DFU-mode restore from any other mac
<hurricos> oh.
<hurricos> when you say touch ...
<neggles> you can read it
<neggles> just don't write to it
<hurricos> you know, never mind. I'll just start browsing through OCP :rofl:
<hurricos> OCP stuff on eBay.
<neggles> there's nothing useful in there anyway
<hurricos> The problem is that our build host is ancient and sucks power
<neggles> and m1n1 hard write-locks it
<neggles> even if you do nuke the SPI, apple can restore it, but that chip contains a number of machine-specific bits of caldata and certificate/crypto key
<neggles> but there's just no reason at all to touch it, and if you don't you can *always* DFU restore
<neggles> hmm, solidrun honeycomb lx2?
<hurricos> Our problem is, we can't find a combination of cheap, poewr-efficient and able to access enough storage media (we have a minio instance people have come to depend on)
<hurricos> pulling one socket and half the RAM out of the storage server drops the power consumption nearly in half, which is surprising given the number of disks
<hurricos> (it's an R510)
<neggles> oh god
<neggles> what's it idle at?
<neggles> 300w?
<hurricos> 310.
<neggles> replace it with a 720 or a 730 and you'll idle at under 100
<hurricos> Fine in the winter.
<hurricos> Really, now?
<neggles> yes.
<neggles> the 710 is westmere
<neggles> 720 is sandy/ivy
<neggles> 730 is haswell/broadwell
<hurricos> as is the 510. I wasn't aware westmere was that much worse
<neggles> it's half the performance for twice the power.
<hurricos> my impression was that westmere-ep was half as awful as the previous gen :^)
<neggles> 11G poweredges all belong in ewaste.
<hurricos> Lol
<neggles> despite what r/homelab would have you believe.
<neggles> actually
<neggles> 12 disks? how big?
<hurricos> 16 actual drives; 11 slots total for 3TB SAS HDDs; 10 of them are in the RAID10 array, I think we're using 7T of storage.
<hurricos> then bcache on 2x NVMe drives in RAID1
<hurricos> I should probably focus on the social problem at hand.
<hurricos> Getting people to get their shit off of it.
<minimal> hurricos: have you looked at minio alternatives after their mucking about its license?
<hurricos> I haven't even touched it in a while, and that's sort of my problem
<minimal> hurricos: ok. been meaning to look at seaweedfs as a S3-compatible alternative to minio
<owrt-2102-builds> Build [#4](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/71/builds/4) of `bcm27xx/bcm2708` completed successfully.
<hurricos> It's why I was hacking on OpenWrt NASes for a while, because I could have just had the people hogging up space (incl. myself) come in with new drives of their own and bring stuff home
<neggles> hurricos: R730XD, 12x IronWolf Pro 12TB drives, 2x1TB SATA SSDs, 2x E5-2650v3 with all power saving disabled and set to max performance https://i.imgur.com/GmTXfJ4.png
<hurricos> JFC
<neggles> the peak there is a backup copy job
<neggles> if i switch it to a more energy efficient mode it drops 70w off
<neggles> but it's in a DC and we're not hitting the 3kW we pay for so
<hurricos> mind giving me an fio? :^)
<hurricos> I can give you the exat run
<neggles> it's a windows box
<neggles> but i have windows fio so
<hurricos> oh
<neggles> the other DC has a 720XD with 12x8TB ironwolf pro and that one idles at 220
<neggles> here is a fun fact: windows cannot count to 100 trillion
<hurricos> lo
<neggles> https://i.imgur.com/7TUL2J0.png it will sit there showing "working" forever
<hurricos> `fio -filename=$FILEPATH -direct=1 -rw=randwrite -bs=4k -size=1G -name=randwrite -runtime=60`
<neggles> size=1G will tell you nothing useful with this controller
<neggles> it has 2gb of DRAM cache
<hurricos> Oh.
<hurricos> Well, bump it up as needed
<hurricos> I'll try 10.
<neggles> i usually go for 4 or 8
<Habbie> is there a central UID/GID registry for packages?
<neggles> not noticed a significant difference with a H730P above 8GB
<hurricos> Send me the numbers :^)
<neggles> hm.
<neggles> fio does not want to start.
<neggles> that's. odd.
<hurricos> I end up somewhere around 26MB/s, 6563 iops, lat .... lat (usec) : 100=14.26%, 250=84.42%, 500=0.75%, 750=0.01%, 1000=0.08%
<neggles> fixed it
<neggles> ok lets see
felix has quit [Read error: No route to host]
<neggles> hurricos: this is also particularly unfair here because i'm using ReFS with 64k clusters :P
felix has joined #openwrt-devel
<hurricos> right.
<hurricos> and I've got bcache against NVMe :grimacing:
<hurricos> I wonder if the PCIe slots on these 1U OCPs have enough space for NVMe risers?
<hurricos> Oh, right, but .... robimarko: that 48-port switchdev compatible device
<owrt-snap-builds> Build [#512](https://buildbot.openwrt.org/master/images/#builders/44/builds/512) of `mediatek/mt7622` completed successfully.
<hurricos> it draws >200W, doesn't it? :^)
<neggles> most of them have at least one or two nvme slots on them, the ocp bois
<neggles> 1G and 4G filesize
<robimarko> hurricos: Nope, its Armada 7040
<neggles> but what's the switch asic
<robimarko> I havent measured the idle, but its gonna be low
felix has quit [Read error: No route to host]
<robimarko> Its Prestera Aldrin-2
<neggles> hurricos: if i do bs=64k so every write isn't an RMW, https://paste.neggles.dev/A6W6y
felix has joined #openwrt-devel
<hurricos> neggles: those are all bare disks, aren't they?
<hurricos> plain, spinning media? Yes, with 2G of cache, but still.
<neggles> it's RAID6'd behind a PERC H730P but otherwise it's 12x12TB IronWolf Pro
<hurricos> smh
<neggles> the 720 in the other DC has a shittier raid controller and 4k clusters
<neggles> lemme try dat
mattytap_ has joined #openwrt-devel
<neggles> i expect badness
<hurricos> For some reason, bcache collapses when asked to deal with 64K blocks, though it's probably bcache trying to merge writes because it thinks 10G is small enough
<hurricos> it does absolutely no better with 50G though
<hurricos> Yep, it's frantically trying to merge writes that are not mergeable. 4K averages 6K iops, 64K averages under 1500. My SSDs are probably also at fault, they're nothing enterprise
<hurricos> WDC PC SN720 ... oh, wait, these are out of laptops.
felix_ has joined #openwrt-devel
mattytap has quit [Read error: Connection reset by peer]
felix has quit [Ping timeout: 480 seconds]
<neggles> older box with the 12x8 and uh
<neggles> it looks like it was in the middle of doing an office 365 backup
<hurricos> lol
<hurricos> 6TB SAS drives are $69.
<hurricos> I think it's time for me to upgrade the server :^)
<neggles> go for a 13G if you can
<neggles> they're not that much more exxy in the US and they'll stay useful much longer
<hurricos> I've actually been looking for a long time at OCP servers
<hurricos> err
<hurricos> servers written to OCP standards*
<hurricos> s/written/built/
<hurricos> they seem to always have 10G SFP+ builtin
<neggles> 4x10G cards for the 720/30 are like $70
<neggles> not even
<neggles> intel XL710 rNDC
<neggles> trivial to patch the eeprom to remove the transceiver whitelist
<neggles> ok with the veeam backup stopped it's pulling iops : min= 68, max= 4697, avg=2120.62, stdev=1010.14, samples=112 and avg 8.5MB/sec
<hurricos> on plain drives
<neggles> yup, H710P there so 1GB cache
<neggles> but it looks like i have this one set to bypass said cac- ah yes
* hurricos sighs
<neggles> yes i do because the battery died
<neggles> I am glad the box that's 3 years newer is a lot faster :P
<hurricos> so I've been compensating for how slow these 3TB SAS drives are this entire time.
<hurricos> and, sorry
<hurricos> how slow this entire machine is
<neggles> well that and westmere's lack of bandwid-
<neggles> yeup
<neggles> 11G dells are worthless.
<neggles> despite what reddit seems to think. replace it, flip it for $350 to some r/homelab moron
<neggles> okay not quite worthless, they make good heaters?
<hurricos> despite what neggles thinks, I don't enjoy shipping servers :^)
<hurricos> lol
<hurricos> I'll find a way.
<neggles> who said anythign about shipping
<hurricos> ah true
<neggles> there *will* be someone local
<neggles> reddit absolutely froths the 12 year old dells
<neggles> they're nuts
<hurricos> The problem is, now I have to go hunt down the friend that borrowed my CRS309 :^)
<neggles> oh yeah and you can fit 16 3.5" drives in a 730XD
<neggles> https://www.ebay.com/itm/183536298684 m i d p l a n e (not worth it tho)
<neggles> there's also the weird ultra-long 1U 16x3.5 boxes
<hurricos> It's only 7TB!
<neggles> also if you want fast switch that's cheap and low-power
<hurricos> That, I do
<neggles> mellanox SX6012/6018/6036
<hurricos> Oh, those ah
<neggles> SX6012 = 12x40G with breakout, full layer 3, idles at 45w
<hurricos> I have a Linux tree for thoes somewhere don't I?
<hurricos> Yes, they use P2020 for management
<hurricos> let me double check
<neggles> yeah but switchx drivers
<neggles> i have a bundle you can use to flash them with the latest mlnx-os for them and apply a license key with ALL THE FEATURES including the secret 'get root console' feature key
<hurricos> Oh, I recently rm rf'd that tree while cleaning up
<hurricos> :(
<hurricos> lol
<neggles> eh they're pretty bog-standard fsl with u-boot on the mgmt board side.
<hurricos> You say "cheap and low power", but this is $1K.
<neggles> 36-port idles at 70w
<neggles> less if you swap the fans
<hurricos> Oh!
<neggles> SwitchX-2 is a really nice ASIC
<hurricos> I suppose a good reason not to go with OCP is that I can actually get QSFP
<neggles> they'll do 56GbE with ConnectX-3 Pro ENs as well
<neggles> it's unreliable though and needs fancy expensive mellanox DACs
<hurricos> "I dunno, does the switch support DSA?"
<hurricos> :^)
<hurricos> JOKE.
<hurricos> joke.
<neggles> honestly? maybe
<neggles> i know Spectrum does
<hurricos> It doesn't, unless said support has never been mentioned on a kernel mailing list
<hurricos> ignal
<neggles> probably not, no
<neggles> Spectrum has full SONiC support at least
<robimarko> Only Prestera, Spectrum and Sparx-5 have upstream switchdev drivers
<hurricos> Sparx-5
<hurricos> Ah, I recall that name
<neggles> also i would suggest making a $200 offer on an 18-port https://www.ebay.com/itm/274825274073 rather than the 36 just cause they're quieter and a bit lower power.
<robimarko> Sparx-5 is cool cause registers and full datasheet are public
<robimarko> No HW though
<hurricos> That's why I mentioned as much :^)
<neggles> https://forums.servethehome.com/index.php?threads/beware-of-emc-switches-sold-as-mellanox-sx6xxx-on-ebay.10786/post-322914 oh look it's me :P
<hurricos> So, explain infiniband to me a bit
<robimarko> Still havent received my reference board for it, been waiting since decemember
<neggles> these do ethernet or infiniband or both at once
<hurricos> those are QSFP slots, though?
<neggles> yes
<hurricos> Got it. And so I necessarily need QSFP hardware.
<neggles> nope
<neggles> breakout
<hurricos> Oh god
<hurricos> right.
<hurricos> Could you show me the cursed thing?
<hurricos> :^)
<neggles> hardly cursed
<hurricos> I also just realized this is the wrong IRC channel.
<neggles> shall we move to the other one
<neggles> or another one
<hurricos> I have no idea which that would be :rofl:
<neggles> fair. but yeah that cable turns a QSFP+ on a switch port into 4xSFP+. they also come in AOC and "an optic" forms.
<neggles> this does *not* work with a NIC. only a switch.
<hurricos> Right
<neggles> the mellanox connectx VPI NICs support IB and Eth at the same time, the connectx EN are ethernet only, switch does both with a license key. the license key generation secret is fixed/static across all SwitchX and Spectrum switches.
<hurricos> I think part of my problem is figuring out how to network this with anything we've got. With SFP+ ports, it's easy -- 1G SFP DACs which go straight into a ZyXEL or (probably) our HP PoE switch
<neggles> you can drop a QSA into it and turn a 40G into a 10G which you can then drop a 10G-T transceiver into, or a 1/10G optic
<hurricos> Whence my problem
<hurricos> why not just a 10G switch? :^)
<neggles> well yeah that's what i do :P
<neggles> breakout cable into 4x10G on my 1G switch
<neggles> pro tip if you replace the fans: they use a horrifically nonstandard pinout, and if you miswire it and hook the fan's ground wire to the tacho output pin, you'll blow out one of the i2c multiplexers and kill half the ports.
<hurricos> speaking from experience
<neggles> an F for my first SX6012.
<neggles> annoyingly the only thing that's actually damaged is the i2c mux - it can't read the SFP module ID EEPROMs so no link.
<neggles> if I can find an SX1012 (unmanaged IB-only version) I can drop the management COM from this one into it and magically it becomes a full-function SX6012 - the 1012 is just a 6012 with no mgmt COM
<neggles> they used standard 4-pin molex KK254 headers... but the pinout is something like +V GND PWM TACH
<neggles> jerks
<neggles> anyway yeah. mine idles at 25w with noctuas in it
cyrozap has quit [Ping timeout: 480 seconds]
<neggles> full line-rate L3, ipv4, ipv6, BGP, IS-IS even I think? OSPF of course, blah blah
<neggles> and DCB for RoCEv1/v2.
<neggles> and it is 1am so i must sleep, but have fun :P
cyrozap has joined #openwrt-devel
<hurricos> thanks for the braindump :D
<neggles> anytime :D I lied though my maybe-fixed oc200 image is built so lets see if i can haz dsa
<neggles> nope. and now when it initializes ttyMV0 I lose serial console???
<neggles> ok this is a tomorrow problem
<hurricos> good night, neggles :^)
<neggles> g'night :)
felix_ is now known as felix
dedeckeh has quit [Remote host closed the connection]
mirko has joined #openwrt-devel
<mirko> nbd: ping
<mirko> nbd: dealing with an ugly cpp error when compiling an Qt binding within OpenWrt >=21.02 : https://pb.nanl.de/show.php?id=45459&hash=16494349&mode=raw
<mirko> it's using libubus which uses libubox which defines `fallthrough` in a way Qt's compiler detection macros break
Tapper has joined #openwrt-devel
valku has joined #openwrt-devel
<mirko> clashing parts: https://git.openwrt.org/?p=project/libubox.git;a=blob;f=utils.h;h=dacac6e41092e2b395f3867fa6dd91812a40acf8;hb=HEAD#l234 ff and https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qcompilerdetection.h#n1317 ff
Misanthropos has joined #openwrt-devel
arthur_melo has quit []
sf has joined #openwrt-devel
mirko has quit [Ping timeout: 480 seconds]
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
dangole has joined #openwrt-devel
mattytap__ has joined #openwrt-devel
mattytap_ has quit [Ping timeout: 480 seconds]
<Tapper> My r7800 is running with k5.15 now but ksmbd still does not work and the network shairs link does not show up in luci after flashing.
<Tapper> The package is installed
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
pepe2k has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
pepe2k has quit [Remote host closed the connection]
<owrt-1907-builds> Build [#4](https://buildbot.openwrt.org/openwrt-19.07/images/#builders/4/builds/4) of `armvirt/64` completed successfully.
robimarko has quit [Quit: Leaving]
<mangix> Tapper: kernel 5.15 is a bit special. ksmbd is part of linux now. The out of tree module should not be used.
<Tapper> mangix So what do I need to do?
<Tapper> Remove the packages in make menuconfig?
<Tapper> Will luci-app-ksmbd work?
<Tapper> mangix If it's all fucked up for now I can switch back to k5.10 for now.
<mangix> yes it is messed up currently.
<mangix> in multiple ways
valku has quit [Quit: valku]
<olmari> ..to history... I've never really thought of using openwrt on fileserver... or was that talk about osme backbone switching?
<Tapper> mangix I am just going back to k5.10 then for now and see if ksmbd works.
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
<Tapper1> mangix I flashed back to k5.10 but luci-app-ksmbd sstill not showing up in luci
<mangix> what are your versions of ksmbd and ksmbd-tools?
<mangix> neggles: didn't work
bluew has joined #openwrt-devel
dvn has quit [Quit: bye]
dvn has joined #openwrt-devel
Movedtomkg20001mkg20001io[m] has joined #openwrt-devel
mkg20001 has joined #openwrt-devel
Movedtomkg20001mkg20001io[m] has left #openwrt-devel [#openwrt-devel]
Movedtomkg20001mkg20001io[m] has joined #openwrt-devel
<Movedtomkg20001mkg20001io[m]> Hi, I've set CONFIG_DEBUG=y and my packages still get stripped during build. Where did I fuck up?
mattytap_ has joined #openwrt-devel
bluew has quit [Read error: Connection reset by peer]
bluew has joined #openwrt-devel
mattytap__ has quit [Ping timeout: 480 seconds]
<Grommish> Go to Global | Toolchain setting I believe and turn Strip'ing off
<Grommish> Might be in Advanced, I can't check at the moment
<Tapper1> mangix ksmbd-server - 3.4.4-1
<Tapper1> ksmbd-utils - 3.4.4-1
<Tapper1> That's from latest master.
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
xdarklight has quit [Remote host closed the connection]
xdarklight has joined #openwrt-devel
digitalcircuit has quit [Remote host closed the connection]
Rondom has quit [Remote host closed the connection]
digitalcircuit has joined #openwrt-devel
enyc has quit [Remote host closed the connection]
Rondom has joined #openwrt-devel
<mkg20001> Grommish k, thx. that did it. it sets CONFIG_NO_STRIP=y
<Grommish> mkg20001: the CONFIG_DEBUG sets -ggdb and maybe some other things.. if you have a specific package youa re trying to debug, you can add a TARGET_CFLAGS+=-ggdb3 to force it
dansan has quit [Ping timeout: 480 seconds]
mangix_ has joined #openwrt-devel
Tapper1 has quit [Ping timeout: 480 seconds]
mirko has joined #openwrt-devel
dansan has joined #openwrt-devel
mangix has quit [Ping timeout: 480 seconds]
mangix_ has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
PtitGNU has quit [Quit: No Ping reply in 180 seconds.]
PtitGNU has joined #openwrt-devel