<dwfreed>
christophe: 'disassemble' is generally nicer than doing it manually; also would be nice if you stripped the control codes before pasting, because that output is *really* hard to read
<dwfreed>
disassemble also puts a pointer where the current instruction is
<scomp>
I just asked in the main channel about a lua problem that I've been running into while writing a lua plugin for prometheus-node-exporter-lua. I keep getting the interrupted system call error while reading the output of a program in lua.
<scomp>
anyone familiar with this issue?
dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
MAbeeTT has joined #openwrt-devel
G10h4ck_ has quit [Ping timeout: 480 seconds]
MAbeeTT4 has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
<aparcar[m]>
blocktrron: hi how is poemgr supposed to work? there is pretty literally no output at all
<blocktrron>
It has a init script which should enable them on startup
<blocktrron>
Maybe you need to reboot the device once after firstboot
<schmars[m]>
Init.d start
<aparcar[m]>
did already
<blocktrron>
This should do the trick
<blocktrron>
Otherwise you could try run it from cli
<blocktrron>
It is not a nice Programm nor elegant built.into OpenWrt. It was more of a tech-demo which never got into production for me
<blocktrron>
Just to keep expectations in line with reality
<blocktrron>
Can you query the status?
<aparcar[m]>
is there an alternative?
<djfe>
robimarko: in-case you don't check github mentions https://github.com/openwrt/openwrt/pull/12209 someone asked for your help in getting this PR merged (readds device with DSA support and new nvmem stuff)
<aparcar[m]>
poemgr status gives no response
<schmars[m]>
Does work though ;) and now there's a third user for it ;)
<aparcar[m]>
could you please provide a basic workflow with this thing? none of the commands print anything except the status command
<aparcar[m]>
done. but show prints the same as before
<blocktrron>
aparcar[m]: i don't want to sound rude, but i have no time for that. I wrote it for a external project that never materialized and jsut worked it to a basic state back then in hopes it is useful for somebody
<blocktrron>
I don't even have acess to the H/W anymore
<aparcar[m]>
sure fine with me, I just tried it since it's mentioned in the commit message which added usw-flex itself
<blocktrron>
The thing is abstracted.
<aparcar[m]>
anyway, I'll check for alternatives, thanks for your time
<blocktrron>
You have enable which activates the PSE chip (It is off by-default on the USW Flex)
<blocktrron>
You have "apply" which writes the UCI config to the chip
Borromini has joined #openwrt-devel
<blocktrron>
"disable" --> Turn Off PSE chip
<aparcar[m]>
i guess I need to find a way to enable it 🙂
<blocktrron>
"show" --> dump PSE chip status
<schmars[m]>
and the PSE chip's state survives a reboot (unless power is cut)
<blocktrron>
Can you install i2c-tools and check if the chip is present?
<aparcar[m]>
okay I'll do that
<aparcar[m]>
I gotta run, cu soon
<aparcar[m]>
and thanks, again
<schmars[m]>
feel free to ping me about it too, i have multiple usw-flex running
<blocktrron>
If your device is new, i suspect UBNT might have changed the PSe chip. The devie was long not available and we weren't able to source the microsemi part in there
<blocktrron>
too
<schmars[m]>
i have one device of the newer batch which didn't give me problems
<blocktrron>
aparcar[m]: no worries, it they didn't change the chip i suspect it migt have broke in the enable logic activating the chip.
<blocktrron>
I've just arrived in hamburg and had to switch trains, so brain might not be on point
tidalf has quit [Ping timeout: 480 seconds]
<blocktrron>
I'd like to see better PoE support in OpenWrt, especially as i don't see something materializing in the kernel in the near future (~5 years), given that building an abstract subsystem is very tedious there
hober has quit [Quit: Page closed]
MaxSoniX has quit [Quit: Konversation terminated!]
G10h4ck_ has joined #openwrt-devel
<Borromini>
blocktrron: no progress on PoE support being integrated into ethtool then?
<scomp>
How can I debug wifi driver issues in openwrt? I am not familiar with kernel dev, and I am not sure where I should start
cbeznea has quit [Quit: Leaving.]
<scomp>
If I do something wrong, and the kernel crashes with segfault when booting up, do I have to reflash my device?
<scomp>
what's the typical workflow for developing drivers?
mkennedy is now known as hurricos
<hurricos>
scomp: Linux, Linux, Linux. But what driver?
<scomp>
hurricos: mt7615e
<scomp>
If I have to reflash my device a lot, that would be kind of annoying
schwicht has joined #openwrt-devel
philipp64 has joined #openwrt-devel
danitool has joined #openwrt-devel
<robimarko>
djfe: I will take a look over the weekend
guidosarducci_ has quit [Remote host closed the connection]
<hurricos>
scomp: I mean, it's a kernel module. You can just as easily recompile the driver for your kernel and upload it to an HTTP site, then uninstall / reinstall
<hurricos>
Oh. I see your context now, scomp. There's IMO no typical workflow -- it's C code. If you know the driver well, you'll know where to do your debugging - tons of options; I'm a newbie and add printf / kprintf lines so I can review my expectations about state
<hurricos>
but also, mt7615e is pretty mautre
<hurricos>
use mainline Linux and you shouldn't have issues
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<scomp>
I think the issue that I am experiencing might be roaming related
schwicht has joined #openwrt-devel
dangole has quit [Remote host closed the connection]