Battista has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
cmonroe has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
frwol has quit [Ping timeout: 480 seconds]
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
cmonroe_ has quit [Ping timeout: 480 seconds]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
goliath has joined #openwrt-devel
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
felix has quit []
felix has joined #openwrt-devel
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
mzvd has joined #openwrt-devel
borek has joined #openwrt-devel
Battista has joined #openwrt-devel
biboc has quit [Remote host closed the connection]
borek has quit [Ping timeout: 480 seconds]
biboc has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
danitool has joined #openwrt-devel
srslypascal is now known as Guest1928
srslypascal has joined #openwrt-devel
Guest1928 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<stintel>
f00b4r0: got your m300 yet? :P
<stintel>
need a victim to test fit image ;)
bluew has quit [Quit: Leaving]
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
rsalvaterra has quit []
Battista has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
Battista has quit [Read error: Connection reset by peer]
frwol has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
indy has joined #openwrt-devel
indy has quit []
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
mzvd has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
indy has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
dangole has joined #openwrt-devel
<f00b4r0>
stintel: I did, I need to unpack it now :)
<stintel>
neat
<stintel>
I have a commit in my staging tree (master branch) that switches to fit image for kernel+dtb, if you have some time, could you test installing a current image and then migrating to fit image? instructions are in commit messages
Battista has joined #openwrt-devel
<stintel>
it worked for me but would be nice if at least one other person can confirm the same before I push the change
<f00b4r0>
ok. I'll do that now (save the time to acquaint myself with the beast)
<stintel>
much appreciated!
<f00b4r0>
np :)
<f00b4r0>
stintel: haven't RTFM yet, I assume the console serial is RS232 levels, not TTL?
mzvd has joined #openwrt-devel
<aleksander>
jow, I'm still working on a clean way to avoid the modem managed by ModemManager getting out of sync with the netifd interface. The suggestion to use a dummy monitor process e.g. running `trap TERM 'mmcli whatever'; while true; do sleep 60; done` ends up being quite complex, because I need to take care of not launching it multiple times upon multiple ifdown/ifup cycles and such
<jow>
aleksander: flock the modem device?
awgh_ has joined #openwrt-devel
<aleksander>
I wonder if there is no better simpler awy to handle this; e.g. something like "when netifd starts make sure the interfaces of protocol 'modemmanager' are all brought down explicitly; or "when netifd starts, check the status of the interface in modemManager to say if it's already connected"; or even "restart ModemManager if netifd is restarted"
<stintel>
f00b4r0: yes
<stintel>
pfff, my main m300 *again* doesn't survive sysupgrade
<f00b4r0>
thx, I need to grab extra hw then :)
<jow>
aleksander: well when netifd restarts it has no state
mzvd has quit [Read error: Connection reset by peer]
<f00b4r0>
I'll fire up a build meanwhile, i see there's no snapshot for it
<jow>
aleksander: so whatever is doing that has to be implemetned outside of netifd
<jow>
aleksander: likely within the init script
<jow>
aleksander: which will then need to gain a lot of logic to deduce related processes from ifaces configured in /e/c/network
<jow>
aleksander: alternatively a kind of network-start hook
<stintel>
f00b4r0: ah right, it's source-only
<jow>
but that'd require establishing a whole new subsystem
<aleksander>
jow, so the best thing in your opinion is still to try to manage that from the outside in a separate monitor process somehow
<f00b4r0>
stintel: it's ok, i have suitable firepower. Should be done in ~20mn
<jow>
yes, and using exclusive file locking to serialize invocations (or to prevent multiple ones)
<f00b4r0>
meanwhile I'll take the thing appart so I can access the innards :)
<aleksander>
jow, wouldn't really need to be one monitor per interface at this point though, right? I need to disconnect explicitly *all* modems upon a network restart, not just some of them
<aleksander>
well, unless some were connected out of netifd
<jow>
aleksander: but netifd restarts are not really anything "Normal"
<stintel>
starting to suspect something might be broken on my main m300 - it died completely when I was abroad, didn't have console attached, nothing in logs, and every time I sysupgrade something messes up
<jow>
so it seems like you're solving a really specific corner case
<jow>
I thought your main issue is desync
<jow>
when interfaces go down / undefined, users will try ifup/ifdown or reboot
<f00b4r0>
stintel: sounds like dead SD
<jow>
rarelys if ever, someone restarts the netifd process
<aleksander>
jow, see, this company using all this seems to be *killing* netifd to trigger a restart of the network, so recovering gracefully from a netifd kill is a usecase here
<jow>
*rarely
<jow>
aleksander: uhm, ubus call network reload or /etc/init.d/network reload is the proper way
<stintel>
f00b4r0: will try another one
<aleksander>
jow, I know, I suggested doing a reload :/
awgh has quit [Ping timeout: 480 seconds]
<stintel>
I believe I bought some new recenty
<aleksander>
jow, I've fixed a related corner case with the same outcome during a normal restart (so with the proper ifdown in the process), but that was a race condition in the protocol handler, need to push the patch for review
<stintel>
hmm, these new ones might actually be in the m300's already
<stintel>
I hope not
<aleksander>
jow, now I'm trying to solve the usecase of the netifd killing; which is definitely rare in a normal openwrt
<jow>
aleksander: well the logical solution would be move all cleanup to the start and not relying on stop at all
<jow>
so basically on ifup kill what needs to be killed, then (re)setup
<jow>
a monitor process would be the natural choice because it'll die along with netifd
<jow>
is nmcli/modemmanager offering any facility to somehow attach information to a connection?
<aleksander>
jow, not really, no
<jow>
so your main issue is to differenciate between "was setup before netifd died" and "just another ifup" on ifup?
<jow>
the racing nmcli calls are easily solved with a mutex (e.g. flock around the modem device or some lock file)
<aleksander>
I'm realizing that my main issue is that there's an external process controlling when to ifup and ifdown the netifd interface, based on the *modem status* reported by ModemManager. I want to make both states (netifd and MM) in sync, but maybe the solution here is to modify the external control process so that ifstatus of the netifd interface is explicity checked in addition to the connection status reported by MM
<aleksander>
I'm trying to find "the proper upstream openwrt fix" in addition to the best solution in this setup, ideally both being the same
srslypascal has quit [Remote host closed the connection]
<aleksander>
but I'm realizing that having the external process control when to ifup/ifdown means it needs to be aware of the ifstatus as well
<aleksander>
the suggestion to ignore the stop sequence and do everything on start doesn't help my usecase, and it's anyway something we're already doing. On a start, we explicitly disconnect before reconnecting, so kind of doing it already
GNUmoon has quit [Remote host closed the connection]
<aleksander>
the additional monitor process is really only required to cover the usecase of netifd being killed or crashing; I wonder if there should be any effort put in handling that
srslypascal has joined #openwrt-devel
<aleksander>
maybe a simple monitor process launched along with MM so that MM is restarted if netifd pid changes would be enough or something like that
<jow>
yes
<jow>
it boils down to tracking the pid of boths
<jow>
*both services
<jow>
and if either changes, restart the other
<f00b4r0>
stintel: do you use squashfs or ext4 image?
mzvd has joined #openwrt-devel
<stintel>
f00b4r0: squash
<f00b4r0>
ok
<f00b4r0>
i just started the build, got distracted ;P
<stintel>
f00b4r0: my image would be way too big with ext4 due to lack of compression
Battista has quit [Read error: Connection reset by peer]
<f00b4r0>
i prefer squashfs for failsafe and ease of sysupgrade anyway :)
mzvd has quit [Remote host closed the connection]
<stintel>
sysupgrade works fine on ext4
<f00b4r0>
does it? ISTR reading it wasn't supposed to work there
<stintel>
so the SD in the main m300 is one of the ones I bought recently :/
<f00b4r0>
ugh
<f00b4r0>
fakes? :P
<stintel>
if sysupgrade doesn't work on ext4, we shouldn't be offering ext4 images
<stintel>
openwrt without sysupgrade is mostly useless
GNUmoon has joined #openwrt-devel
<f00b4r0>
true. I might be confused. I remember having issues with x86 EFI images where sysupgrade wouldn't preserve settings, but maybe that was just PEBKAC
mzvd has joined #openwrt-devel
<stintel>
it could be that at some point it was broken
<stintel>
I've had issues when changing partition layout for example
<stintel>
but that's years ago
<stintel>
either way if it's broken that's a bug and should be reported and fixed
<stintel>
sure glad I invested in a cordless screwdriver, very handy for this bloody main m300 that I have to remove/reinstall from rack every other week or so
<dwfreed>
istr at one point the wiki for running openwrt on commodity x86 said that the ext4 image did not have sysupgrade support, because it did not use overlayfs
<aleksander>
jow, there's no way to have procd do that for me right?
<dwfreed>
this was probably in the 19.x era, though
<dwfreed>
or possibly 18.x
<stintel>
I really doubt that
<stintel>
I've been using x86 ext4 in a qemu VM since forever
<stintel>
if sysupgrade wouldn't work on ext4 I would have never used it
<dwfreed>
it was forever ago that I set that system up, so I don't have any idea if my recollection is even correct
<stintel>
also possible that the wiki was wrong :)
<dwfreed>
yeah
<dwfreed>
I should update that system some day
<dwfreed>
it's still on 19.07.2
<stintel>
I think you can probably even sysupgrade from ext4 to squashfs
<dwfreed>
would not surprise me, since the approach is always the same
<stintel>
f00b4r0: I'll be trying the original SD
<stintel>
any folks here with Raspberry Pi Zero 2 W ?
mzvd has quit [Remote host closed the connection]
<f00b4r0>
stintel: image built. I'm about to set this up :)
<stintel>
Command failed: Not found
<stintel>
why the heck do I keep seeing these completely useless log messages
<stintel>
I thought I fixed that
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
<stintel>
and it's always a difference that's rather big
<f00b4r0>
same ambient i assume?
<stintel>
they're on top of each other in same rack
<f00b4r0>
ah
<f00b4r0>
that could play
<f00b4r0>
top one hotter?
<stintel>
yes, but I would be surprised it causes 25C difference
<stintel>
unfortunately I don't have the data in prometheus or so
<stintel>
so I can't check if the temperature was lower with the bottom one removed
<f00b4r0>
it does seem like a lot, for sure. But thermals are tricky. Might combine with dusty intake or similar
<stintel>
for the other temps the bottom on has higher temps
<stintel>
but difference is 1-4C
<f00b4r0>
ok it seems to have stabilized here: it went from 59 back to 58.5
<karlp>
heh, we have temperature sensors in din rails in electriccal cabinets as part of our current monitoring, and we can see gradients up teh cabinet :)
<f00b4r0>
that's laying on a wooden table
<stintel>
I also removed heatsink, cleaned and reapplied thermal paste on the one that gets hotter
<f00b4r0>
ambient is 23
<f00b4r0>
stintel: didn't you mention replacing PSU?
<stintel>
I replaced PSU in both my m3090 with brand new
<stintel>
m300*
<stintel>
one of them was dead, decided to replace both, using the spare for an esp32-c3 and 6 PWM fans in the rack :)
<f00b4r0>
lol. Sounds quite overkill for the job ;)
<Ansuel>
wait they have double psu ?
<stintel>
well the size was just right
<stintel>
no, I have 2 m300
<f00b4r0>
ok i think it's fair to say it's now stable at 59. Fans still at audible minimum
<stintel>
also, one of them has cpu1_vid, the other doesn't (in /sys/devices/platform/ffe000000.soc/ffe118000.i2c/i2c-0/0-002d/)
<f00b4r0>
i only see cpu0_vid there
<f00b4r0>
sounds like different hw revisions
<stintel>
the one with cpu_vid1 is running cooler
Battista has quit [Read error: Connection reset by peer]
<stintel>
and your ~59 is closter to my 69 than to my 45, ambient here is ~27
<stintel>
so different CPU revision - still big temp difference
<f00b4r0>
i would have suggested different node for the newer one, which could then explain lower temp, but wikipedia says the whole family is on 28nm
<f00b4r0>
since you see an extra cpu vid, it's possible they redesigned the power supply to the CPU (using e.g. two "phases" instead of just one) and that improved dissipation
<f00b4r0>
other than that, I'm out of ideas :)
mzvd has joined #openwrt-devel
srslypascal has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
<stintel>
the ones I have were originally sold in a pair
<stintel>
maybe it's a strategy :P
<f00b4r0>
well if they have similar manufacturing dates, the plot thickens ;P
<stintel>
one of them being cheaper to produce, but more prone to hardware failure
<stintel>
but since they're usually setup as a "cluster" that's not a big issue
<f00b4r0>
close inspection of the motherboard would probably hint at differences
Battista has joined #openwrt-devel
<stintel>
not finding any photos :/
<f00b4r0>
i'm up to 60 now :)
<f00b4r0>
too bad i don't have a wattmeter to check the plug load
<rmilecki>
f00b4r0: did I discuss anything related to that patch?
<rmilecki>
my memory fails me ;)
<f00b4r0>
rmilecki: you specifically asked me to send that patch, hence you being CC'd :)
<rmilecki>
let me re-read it later with more focus ;)
<f00b4r0>
np :)
cbeznea1 has quit [Quit: Leaving.]
<f00b4r0>
stintel: completely stable, oscillating between 59 and 60. I'll turn it back off, it's too noisy ;)
<stintel>
thanks
<f00b4r0>
yw
<mrnuke>
robimarko, Ansuel: I'm thinking of proposing that the &switch { node for ipq807x be moved into a <device>-switch.dtsi. Reason are (1) one can more easily diff the switch nodes to understand the deltas, and (2) The <device>.dts files look cleaner and focus onw hat's important
<Ansuel>
does that differe that much across the different devices?
<mrnuke>
I haven't checked -- I've just been bothered with the excessively convoluted dts desctiptors
ekathva has quit [Remote host closed the connection]
ekathva has joined #openwrt-devel
cmonroe_ has joined #openwrt-devel
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
zekica has joined #openwrt-devel
<zekica>
Hi, whom can I ask about making a change to a DTS (or creating a new one) for ATH79 target ar9342_ubnt_nanostation-loco-m-xw device? It appears that ethernet MDIO definition is not correct for my HW version 1950K. Thank you.
<Slimey>
you can get the source and change it for your own needs then submit a PR
<zekica>
ok, but I'm just wondering what is the easiest way to extract the correct configuration from vendor's firmware that is not using device trees (at least I don't think it is using) and using kernel 2.6.xxx
<zekica>
I can try booting with other variants' device trees (bullet-m-xw, nanostation-m-xw...), which I was planing to do, but I was just wondering is there a way not to guess...
<Ansuel>
having the source code and check whatever shit the oem did
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]