danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Strykar has quit [Ping timeout: 480 seconds]
philipp64 is now known as Guest1567
philipp64 has joined #openwrt-devel
Guest1567 has quit [Ping timeout: 480 seconds]
Grommish_ has joined #openwrt-devel
Grommish__ has joined #openwrt-devel
minimal has quit [Quit: Leaving]
Grommish has quit [Ping timeout: 480 seconds]
Grommish_ has quit [Ping timeout: 480 seconds]
<Grommish__>
stintel: Well.. I booted the 5.10 kernel, leak happens, remove the driver, leak stops.. Load the driver, and the Watchdog kicks the chip over with [15661.767989] Warning: Enabling FPA when FPA already enabled.
<Grommish__>
But, with the driver unloaded, the leak is gone. I seem to be able to reproduce it at least
<Grommish__>
but, that sounds like it isn't exiting gracefully when I remove the driver, and I'd guess cleanup would be part of that? Any opinion neggles?
<slh>
the module startup falling over an already enabled FPA is probably more of an issue than unloading the module not disabling it
<slh>
(depends a bit of what effect leaving the FPA enabled has, e.g. power-/ RAM consumption or doing undefined stuff with incoming packets - if neither of those occur, leaving it enabled shouldn't be an issue)
<Grommish__>
slh: It just seems to be broken, for sure. Not surprising though. The maintainer says it isn't the driver
Grommish__ is now known as Grommish
<slh>
well, that's the easy answer for him ;)
<slh>
and maybe it isn't broken on his hardware/ software environment, maaaybe (or maybe he didn't even notice yet)
<Grommish>
Yeah :) So far, it's been a lot of false positives and stuff it isn't. His answer was plausible for what I was reporting, so I can't fault the NMP
<Grommish>
kmemleak was reporting the memory shift to the FPA and reporting it as bad because the FPA wasn't releasing it or something until it was done
<Grommish>
So it was "that's intended, try elsewhere"
<Grommish>
except rmmod octeon-ethernet stops the leak and re-enabling immedately triggers the watchdog
<slh>
that isn't really wrong (well, it is, but hard to argue), if it wouldn't grow out of control
<Grommish>
Right, I can't fault the response given what I gave him. I just don't know how else to quantify the leak in a way it can't just be hand-waved
<slh>
hmm, lovely (albeit not OpenWrt related, i686 kernel build with gcc 11.2.0), CC [M] kernel/kheaders.o\nvirtual memory exhausted: Cannot allocate memory
mattytap__ has quit [Read error: Connection reset by peer]
mattytap__ has joined #openwrt-devel
c0sm1cSlug has joined #openwrt-devel
mattytap_ has quit [Ping timeout: 480 seconds]
Grommish_ has joined #openwrt-devel
mattytap_ has joined #openwrt-devel
mattytap__ has quit [Read error: Connection reset by peer]
Grommish has quit [Ping timeout: 480 seconds]
rua has quit [Quit: Leaving.]
svanheule has quit [Ping timeout: 480 seconds]
svanheule has joined #openwrt-devel
rua has joined #openwrt-devel
mattytap__ has joined #openwrt-devel
mattytap_ has quit [Read error: Connection reset by peer]
mattytap_ has joined #openwrt-devel
mattytap__ has quit [Ping timeout: 480 seconds]
<rsalvaterra>
Just a heads up, this breaks make oldconfig: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=795e7155cbe3e78669f6821bf7aecb7c4e1e1afb
<rsalvaterra>
Found out the hard way.
<stintel>
how so?
<rsalvaterra>
Simple. The CONFIG_PACKAGE_iptables ceases to exist, it's removed and CONFIG_PACKAGE_iptables-legacy isn't selected.
<rsalvaterra>
Which means the firewall3 dependencies need to be updeted.
<rsalvaterra>
*updated
<rsalvaterra>
(Or whateved depended on iptables.)
ekathva has joined #openwrt-devel
lelux has joined #openwrt-devel
wvdakker has quit []
<stintel>
but I don't see how that "breaks" make oldconfig, I can run it just fine
wvdakker has joined #openwrt-devel
<ekathva>
I am trying to build the image for toradex verdin (and I see already there is the support for Appalis board). As a newbie, it is very difficult to get the idea of adding new devices (can any one give me the pointers?) or shall I ask in #openwrt channel?
<ekathva>
thank you :)
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<rsalvaterra>
stintel: Ok, sure, make oldconfig runs fine, but the resulting configuration is broken. ;)
<jow>
rsalvaterra: firewall3 does not require iptables
<jow>
just libiptc and libxtables
<rsalvaterra>
jow: You're quite right. It's just that I have custom rules in firewall.user, invoking iptables directly, so my config got broken. :)
<rsalvaterra>
I don't see an obvious fix for this, since in my case nothing else depends on iptables, so I'll just file it as "it's master, it happens". ;)
<rsalvaterra>
ynezz: I think I'm going to drop that 5.4 pull request. I completely forgot it even existed and I'm not really looking into it… :/ Would that be alright?
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
Borromini has joined #openwrt-devel
<ynezz>
rsalvaterra: I didn't read it, I've just noticed it's by you so I've assigned it so it doesn't show up in my filter = not wasting time on it :)
Grommish_ is now known as Grommish
<rsalvaterra>
Right… I'm not really into 5.4 at all, but I understand it's important for the 21.x branch.
cmonroe has joined #openwrt-devel
cmonroe_ has quit [Ping timeout: 480 seconds]
hanetzer has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
<Borromini>
rsalvaterra: i'll be switching everything to 22.xx come the branch so you won't here me complain :P
danitool has joined #openwrt-devel
danitool has quit []
danitool has joined #openwrt-devel
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
hanetzer2 has joined #openwrt-devel
hanetzer1 has quit [Read error: Connection reset by peer]
minimal has quit [Quit: Leaving]
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
Borromini has quit [Quit: leaving]
gladiac has quit [Quit: k thx bye]
<hurricos>
ekathva: toradex has the right idea generally about how to add board support; it's actually extremely similar to adding Linux support in general.
<hurricos>
The biggest difference is organizing the Makefile definition for the board itself using the Makefile gimmicks supplied for your board's target
<hurricos>
I'm going to guess that something made by toradex is mvebu, without looking up the board itself.
<hurricos>
You'll want to build a device tree, and then find one of the board image Makefile definitions under target/linux/mvebu/.
<hurricos>
(and add a new definition for your board)
<hurricos>
You'll have a lot of luck doing e.g. a git log through files under that tree to see how other board support happens.
<hurricos>
Once you've got a device tree (or for mvebu, probably? a .patch file that adds support by adding a new device tree to the Linux kernel tree), and you've got an image definition, all that's left is making sure that your specific board has the openwrty bits all set.
<hurricos>
that is, things like 02_network definitions if they're peculiar on your board. Toradex, probably not going to be.
dedeckeh has joined #openwrt-devel
mattytap__ has joined #openwrt-devel
mattytap_ has quit [Remote host closed the connection]