clayface has joined #openwrt-devel
cmonroe has joined #openwrt-devel
okibcn has quit [Remote host closed the connection]
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
blukey has joined #openwrt-devel
<blukey> what all do i need from the gpl source code
blukey has quit [Remote host closed the connection]
jlsalvador has joined #openwrt-devel
user95 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
rua has joined #openwrt-devel
minimal has quit [Quit: Leaving]
rua has quit [Quit: Leaving.]
danitool has quit [Ping timeout: 480 seconds]
lucenera has quit [Server closed connection]
lucenera has joined #openwrt-devel
<mangix> nbd: Yeah I was wondering about those when doing the update. The CI didn't complain.
<mangix> I left them out as I assumed upstream fixed the issue in a different way.
gladiac has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
evils[m] has quit [Server closed connection]
evils[m] has joined #openwrt-devel
gladiac has quit [Quit: k thx bye]
gladiac has joined #openwrt-devel
srslypascal is now known as Guest1437
srslypascal has joined #openwrt-devel
Guest1437 has quit [Remote host closed the connection]
danitool has joined #openwrt-devel
Borromini has joined #openwrt-devel
<nbd> mangix: without those changes, fakeroot compiles, but is unusable since the injected lib has unresolved symbols
ecloud has quit [Ping timeout: 480 seconds]
lemmi has quit [Quit: WeeChat 3.4]
ecloud has joined #openwrt-devel
lemmi has joined #openwrt-devel
whatevs111[m] has quit [Server closed connection]
whatevs111[m] has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
Misanthropos has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
Grommish has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
will[m] has quit [Server closed connection]
will[m] has joined #openwrt-devel
Borromini has joined #openwrt-devel
rua has joined #openwrt-devel
c0sm1cSlug has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
c0sm1cSlug has joined #openwrt-devel
goliath has joined #openwrt-devel
rua has quit [Quit: Leaving.]
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Misanthropos has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Quit: Leaving.]
floof58 has quit [Ping timeout: 480 seconds]
clayface has quit [Ping timeout: 480 seconds]
floof58 has joined #openwrt-devel
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Grommish has joined #openwrt-devel
_lore_ has quit [Server closed connection]
_lore_ has joined #openwrt-devel
owrt-1907-builds has quit [Server closed connection]
owrt-1907-builds has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
srslypascal is now known as Guest1463
srslypascal has joined #openwrt-devel
Guest1463 has quit [Ping timeout: 480 seconds]
cmonroe has quit [Ping timeout: 480 seconds]
clayface has joined #openwrt-devel
<f00b4r0> hauke: re #3271 I had suggested some changes in my review, these seems to have not been picked up by whoever grabbed that patch and pushed it to our tree. Not a big deal but some of said changes may help mainlining
clayface has quit [Ping timeout: 480 seconds]
clayface has joined #openwrt-devel
<stintel> hmmm looks like I'm having performance issues on realtek
<stintel> switched traffic of ~80Mbps results in very high sirq (seen up to 85%)
<hurricos> stintel: which board?
<stintel> gs108t-v3
<hurricos> :nods: I'm working on installing some ZyXEL realtek switches in our building, so I'll keep a look out for any issues.
<stintel> hope the flash is large enough to include perf
<hurricos> You can always install to RAM temporarily, too.
<hurricos> nasty as that might be. I recall seeing a way to force that with some env vars to opkg
<hurricos> but now I can't find it.
<stintel> /dev/mtdblock8 7.2M 368.0K 6.8M 5% /overlay
<stintel> that should be plenty
shibboleth has joined #openwrt-devel
<stintel> 5.84% [kernel] [k] rtl838x_hw_receive
<svanheule> stintel: did you inlcude Bjørn's patch in your build?
<svanheule> stintel: if you didn't, all traffic gets flooded to the CPU...
<hurricos> svanheule: Mind linking the patch? I'm rebuilding for my switches now already.
<stintel> svanheule: is that in master yet?
<stintel> ok
<stintel> that sounds exactly like what's happening :)
<svanheule> stintel: a little traffic and RIP little MIPS CPU
<stintel> ;)
<hauke> f00b4r0: It looks like the patch which was send upstream was used
<stintel> svanheule: thanks for the info, building with that patch now, if it works I'll push it
<hurricos> stintel: wait for me, I'm building now with a slower machine but was already actively testing :D
<hurricos> not sure what's in your netgear, but GS1900-24's are all on RTL8382M, which seems popular
<svanheule> hurricos: I think you need an HPC cluster to have a faster build machine than stintel's ;)
<hurricos> I am aware.
<stintel> LOL
<stintel> and I'm considering replacing this thing because I'm finding it slow :/
<f00b4r0> hauke: aye. It's slightly suboptimal. Hopefully John will catch up.
<stintel> seems to fix the problem
<hurricos> Waiting on sysupgrade to wrap up.
<hurricos> FWIW, I was not switching any traffic, nor do I have perf set up on my GS1900-24HP v1. I can give you a dmesg diff if you like.
<hurricos> Assuming it comes back up.
<hurricos> It's back up. LGTM.
<hurricos> Not that anyone expected dmesg to change.
shibboleth has quit [Quit: shibboleth]
<hurricos> My PoE switch is consuming too much power, looks like: https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/1272
<hurricos> (sarcasm)
<stintel> hurricos: shall I add a tested-by then ?
<hurricos> Grr. I'd avoid it. I did not meaningfully test, only compiled and booted.
<stintel> ok
bluse-blue[m] has quit [Server closed connection]
bluse-blue[m] has joined #openwrt-devel
<hurricos> Hard call, but then it's more honest.
decke[m] has quit [Server closed connection]
decke[m] has joined #openwrt-devel
fieryeagle954[m] has quit [Server closed connection]
fieryeagle954[m] has joined #openwrt-devel
<hurricos> also, if something's wrong with the patch, it won't bite me in the ass :^)
fpsusername[m] has quit [Server closed connection]
fpsusername[m] has joined #openwrt-devel
John[m]12345678 has quit [Server closed connection]
John[m]12345678 has joined #openwrt-devel
nick[m]1234 has quit [Server closed connection]
nick[m]1234 has joined #openwrt-devel
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
minimal has joined #openwrt-devel
<svanheule> hurricos: mining crypto on a PoE powered device, are we :^)
<hurricos> svanheule: Ha-ha, very funny.
<hurricos> I wish I were better at reading and debugging C. I'm fairly sure I won't be able to uh
<hurricos> you know
<hurricos> it occurs to me I could just use socat to export /dev/ttyS1 to another machine to debug `realtek-poe` with
<svanheule> we should consolidate the PoE daemons at some point... there's another one to manage PoE on ubiquiti switches
<svanheule> but we don't have actual documentatoin on the Broadcom PoE platform used on most Realtek switches, so that's hard to get right :-/
<hurricos> Right. Since realtek-poe doesn't work with the PoE board on the GS1900-24HP, though, I figure fixing that is a priority.
<hurricos> "implementation as documentation"
<svanheule> that device uses BCM59111-s, that's an older version of the BCM59121 used on other supported devices AFAICT
<svanheule> hurricos: I dove into decompiles firmwares a while back to create this page: https://svanheule.net/switches/software/broadcom_poe_control_protocol
<svanheule> that should document the commands, but not so much the start-up procedure and runtime management
Lechu has quit [Remote host closed the connection]
Lechu has joined #openwrt-devel
<hurricos> svanheule: Do you have any documentation about your discovery process?
<svanheule> hurricos: what do you mean by "discovery process"?
<PaulFertser> hurricos: if you use realtek-poe make sure this typo is fixed: https://www.mail-archive.com/openwrt-devel%40lists.openwrt.org/msg59960.html
<hurricos> svanheule: I mean the notes you took before you published a nice page :^)
<hurricos> PaulFertser: I will patch it in and recompile. Thanks.
<svanheule> hurricos: errrr... not really :-/ I basically refactored that page as I went along discovering more things, having annotations (variable names, rebuilt structs) in the decompiled code
<svanheule> hurricos: and probably some notes on paper so I didn't have to keep everything in my head, but I'm sure I wouldn't be able to make head or tails out of that if I saw them again
<hurricos> No problem, I understand. Just trying to get a sense of where to start with this crash. PaulFertser: Funny enough, objdump pointed at a `mode.3` somewhere. I can't see what this should be, what's your diff to fix this?
<hurricos> Oh, 0x11, not 0x18
Borromini has joined #openwrt-devel
GNUmoon has quit [Ping timeout: 480 seconds]
<hurricos> s/11/17/
<PaulFertser> hurricos: the crash must be something different. mode.3 sounds like an inlined instance of a function probably.
swegener has quit [Quit: leaving]
swegener has joined #openwrt-devel
<hurricos> I think I misread the error anyways. It's an invalid memory access *to* 04020cc, then looked for 4020cc in less and found a word of machine code '004020cc'.
<hurricos> so once misread by looking at where it was accessing, whether or not it was trying to execute at that address, and then once because I read machine code as an address.
<hurricos> I don't even know what's supposed to be in the ra register in mips.
<hurricos> Oh, the return address.
<hurricos> Oh yeah, so it crashes the first time it runs ULOG_ERR.
<Borromini> hurricos: for me it compiles/runs fine, on recent master
<Borromini> except for the weirdness with my GS1900-8HP v1 not doing any PoE anymore on OpenWrt altogether
<Borromini> but realtek-poe doesn't segfault here or anything
<hurricos> Borromini: Does it work on oem firmware?
<Borromini> hurricos: yep. without a hitch
<Borromini> first thought was hardware failure too, but PoE stopped working for me somewhere between a post-release 21.02 build and master
<Borromini> lowering the PoE budget seemed to fix it very briefly but it broke down anyway somehow
<hurricos> I wish I knew which framework was going to be adopted for PoE stuff. I notice ynezz posted robimarko's driver for a ... TPS? PoE injector.
<hurricos> err. Injector. Hardware.
<Borromini> rebooting into OEM powers up my PoE client consistently
<hurricos> but that's in-kernel, it gives a good idea for how it might ought to work
<hurricos> which I don't really yet understand beyond that it exports some basic stuff to sysfs
<Borromini> my GS1900-10HP, however, it works flawlessly with 21.02 HEAD and realtek-poe
Ntemis has joined #openwrt-devel
<Ntemis> hello
<Borromini> hurricos: to me the hex values realtek-poe -d outputs is chinese though, i have no idea how to debug it
<Borromini> hurricos: was reading back the C daemon discussion on Patchwork and bumped into this as well, haven't given this a shot yet: https://github.com/blocktrron/poemgr
<Borromini> so far seems to support just one type of PoE hardware - Microsemi PD69104
<hurricos> Borromini: Each line is a 12-byte frame.
<hurricos> (I *think*)
<Borromini> hurricos: ok thanks. gonna run that on my 8HP v1.
noltari has quit [Server closed connection]
noltari has joined #openwrt-devel
<hurricos> Well, no, sorry, I know. You just menitoned it was realtek. svanheule clarified that they all use Broadcom stuff.
gladiac has quit [Quit: k thx bye]
<hurricos> poemgr would need to have code written for it to work here. I also read, but may have misunderstood, that the intent with poemgr isn't to provide a ubus API, which is sort of a shame
<Borromini> no worries :)
<Borromini> i think the 8HP v1 uses an older Broadcom chip
<hurricos> Borromini: Oh, hmm.
<Ntemis> There is an issue with zyxel_nbg-419n-v2 ramips-rt305x
<Ntemis> never worked on -21.02.x
<Ntemis> i think is a kernel issue
<Ntemis> works fine up to 19.07.9
<Borromini> hurricos: STMicro PoE controller (?) seems to be identical between both - STM32F100C8
<hurricos> Borromini: Same Broadcom chips, see https://wikidevi.wi-cat.ru/images/e/e3/GS1900-24HP-poe-pcb.JPG
<hurricos> 59111's on mine.
<hurricos> Do you have a chance to pop it up in OpenWrt and compare what you get with `ubus call poe list`?
<Borromini> the 8HP v1?
<hurricos> Yes. My `realtek-poe` crashes pretty quickly but not before I get a little bit of info
<hurricos> v17.1! Same firmware revision on the ST.
<Borromini> i'm not sure if 'list' is a command it recognises?
<hurricos> err, info. Sorry.
<hurricos> First time calling it was today :^)
<Borromini> =)
<Borromini> i've only enabled PoE on the first two ports for testing purposes
<hurricos> Maybe I've misconfigured /etc/config/poe for this device.
<Borromini> the first port that shows 'unknown' is the only one with an actual PoE PD
<Borromini> sec
<Borromini> i'll show you mine the configs should be pretty simple really
<Borromini> https://paste.debian.net/1233228/ < my GS1900-10HP
<Borromini> here as well I got it on just the first four ports
<Borromini> this is what 'realtek-poe -d' shows on my 8HP v1 (with the 'unknown' status): https://paste.debian.net/1233229/
<hurricos> Just that one line?
<Borromini> yop
<hurricos> You should (probably) bisect for the issue.
<Borromini> on realtek-poe? or on the openwrt codebase itself you mean?
<Borromini> realtek-poe hasn't changed in ages, AFAIK.
<hurricos> OpenWrt codebase. You did mention it stopped working somewhere between versions.
<Borromini> yeah. wife will kill me though.
<hurricos> Not that that makes much sense, but maybe it stopped working because of driver changes that impacted serial communications
<hurricos> Oh. Buy another, then.
<Borromini> fair question
<Borromini> hahaha :D
<Borromini> the 8HP v1 is a testing device, luckily
<Borromini> the 10HP is production. you can understand I am reluctant to upgrade at this point :^)
<Borromini> i've had my share of flash dumping / debugging / timewasting / guinea piggery with the RTL930x platform lately :(
<hurricos> Sorry to hear :\
<hurricos> I am thankful they are dual-partition devices. I can just fw_setenv bootpart and reboot
<hurricos> (if I need ZyXEL's functionality)
<Borromini> yeah. i'm happy with that too.
<Borromini> except the XGS1250-12 e.g. doesn't seem to be dual-partition.
<Borromini> but yeah, the GS1900 series is :)
ephemer0l has quit [Server closed connection]
ephemer0l has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
Borromini has quit [Quit: leaving]
<Grommish> neggles: stintel: I just tried 5.10(.103) again, I've lost nearly 250Mb in 17 hours of uptime without an apparently source of what's using it :(
<stintel> I've also hit the leak again after trying to reproduce it for 2 weeks and acking the switch to 5.10 because I was unable to
<stintel> typical
romany has quit [Server closed connection]
romany has joined #openwrt-devel
<neggles> guh
<neggles> that's just weird
<neggles> mine's been idle for a while, I managed to kernel panic the system it's in a few days ago (by running ripgrep???) and didn't reload
drikus_ has quit [Server closed connection]
drikus_ has joined #openwrt-devel
Sagi has quit [Server closed connection]
Sagi has joined #openwrt-devel
Ntemis has quit [Quit: Page closed]
* Slimey chokes hurricos with a smiley printed in china
<stintel> ツ
clayface has quit [Ping timeout: 480 seconds]
szy_mat has quit [Server closed connection]
szy_mat has joined #openwrt-devel
clayface has joined #openwrt-devel
cmonroe_ has joined #openwrt-devel
<stintel> Grommish: which device were you seeing this on?
<owrt-snap-builds> Build [#464](https://buildbot.openwrt.org/master/images/#builders/34/builds/464) of `lantiq/xrx200` completed successfully.
goliath has quit [Quit: SIGSEGV]
<swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
<hurricos> OK, so you're not going to believe this
<hurricos> The very common Powerdsine 9012G ...
<stintel> Grommish: and do you happen to use sqm-scripts or qosify? or manually configure cake?
<hurricos> is an m68k CPU connected to a tiny Freescale mcu driving a PD69104
<Grommish> stintel: Nope.. It's on the Itus Shield. It's a fairly defconfig build
<hurricos> m68k hasn't been OpenWrt supported since ever, and in fact I'm pretty sure these ... yeah, no mmu
<hurricos> CONFIG_M5272 depends on ! CONFIG_MMU
<hurricos> so if they run linux it ain't much. But this thing probably doesn't
<Slimey> i have some of those midspans sitting in storage
<hurricos> I have this devilish idea -- strap the serial or a USB-to-serial (there's a CP2102 on-board) from an OpenWrt device and implement poemgr stuff for it
<hurricos> and if need be, reverse engineer the firmware running on the little guy to make it easier
<Grommish> hurricos: Sometimes, you just gotta do what you love...
<hurricos> OR, and this one's all the sweeter, pull the MCF5257 module, whip up something in kicad with an AR9331 or similar, and plant it in the old socket
<hurricos> actually
<hurricos> the pitch is exactly right for raspi headers. Let me trace the voltages
<hurricos> it probably won't work
<hurricos> because you know, the chances of the right pins being SPI for the many 595 expanders and VCC etc are like 0
<hurricos> but
<hurricos> 8M RAM
<hurricos> the daughter board: https://paste.c-net.org/CordsFleet