swalker has quit [Remote host closed the connection]
swalker has joined #openwrt-devel
Grommish has joined #openwrt-devel
JohnA has left #openwrt-devel [Leaving]
_lore_- has joined #openwrt-devel
_lore_ has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
<digitalcircuit>
plntyk: Thank you for your advice! After much poking about, I'm now running a debug-enabled 21.02 branch build for the ZyXEL NBG6817 for https://bugs.openwrt.org/index.php?do=details&task_id=3099#comment9712 , and I think I have a reasonable level of debugging enabled. I've also packaged in everything I was using before, plus stress-ng, avoiding opkg.
<digitalcircuit>
(I enabled package debug, disabled sstrip, then enabled kernel KALLSYMS, DETECT_HUNG_TASK, DYNAMIC_DEBUG, LOCKUP_DETECTOR, WQ_WATCHDOG.)
<digitalcircuit>
I figure if I can recreate the crashes on this (ideally with stress-ng, but using Deja Dup SFTP upload if not), then I'll try backporting the ipq806x CPU governor patch ( https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6e411b8416388a9c8be1b2291be9b5adeeb07784 ) and see if that fixes matters.
<plntyk>
as bisecting / testing kernel configs sometimes fixes things too
<digitalcircuit>
plntyk: Much appreciated! I did stumble across that article, but I wasn't sure about going as far as GDB right now. That is a good follow-up step after testing the CPU governor patch and after comparing kernel configs, though. I hadn't even considered bisecting/testing kernel configs either, thank you for pointing that out.
<jow>
nbd: it seems there's suddenly a new `option band` in the wireless configuration and `option hwmode 11a` is not set anymore at least for AC radio defualt configs
<jow>
when was this `option band` introduced and is it documented anywhere? It breaks LuCI channel selection
<jow>
and of course it is backwards incompatible so if I fix LuCI now it will break on older systems
felix has quit [Read error: Connection reset by peer]
<jow>
can we please stop silently changing configuration, in an undocumentend manner, in the middle of a release process?
felix has joined #openwrt-devel
goliath has joined #openwrt-devel
Zaba2 has quit [Quit: Leaving.]
f00b4r__ has quit [Remote host closed the connection]
<nbd>
jow: i thought i had mentioned this to you before i added the option. the band option is needed for 6ghz support and the old hwmode option is still supported for old configs
<nbd>
jow: since 21.02 has the netifd update, it will accept the band option as well
<jow>
nbd: maybe I missed it. I added some forward/backward compatible code to LuCI now that should resolve it. Awaiting some user test feedback
<nbd>
so migrating the config in luci is an option
<jow>
if option hwmode is in the config, it'll be mapped to 2g/5g internally and written back as 11a/11g respectively
<jow>
if option band is present, it is used instead
<nbd>
okay
<jow>
but maybe it would be a good idea to do the same in mac80211.sh in case someone restores an older wireless config backup
<nbd>
netifd already handles it
<jow>
ah okay
<nbd>
it's fully backwards compatible
<jow>
great
<rmilecki>
nbd: mwlwifi (we all love it) didn't see much development in 2019 or later
<jow>
unless generic mac80211 updates somehow influence the way the driver works I don't see how it would improve or degrade with newer versions, it's the same firmware blob with the same driver wrapper after all
<rmilecki>
jow: if you mean change of RF env before and after sysuprade it's probably not sth that happes often
<jow>
ah
<rmilecki>
most people don't move during sysupgrade ;)
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jow>
true, but some people at least tend to change quite a lot of stuff along with the sysupgrade
<jow>
or start changing configs once they look at the device again
<rmilecki>
ok, i'll suggest that
<jow>
rmilecki: well I stop guessing before spreading false facts. Maybe an hostapd update broke something
<jow>
the way the post describes it (in the usual dramatic way) it sounds as if the wifi signal changed form solid/okay to completely unusable
<nbd>
i think we should probably remove broadcom-wl from master
<jow>
openwrt will get all the blame (it is a supported opensource router! and now you broke it!)
<nbd>
so we can get rid of the iwinfo support code as well
<rsalvaterra>
jow: It's really sad. I feel so sorry for everyone who bought those Linksys devices (a friend of mine included)… :(
<jow>
and linksys the hype for bringing such great devices to the community
<jow>
nbd: yes, I think it makes sense to drop anything non-nl80211 from now on
<jow>
nbd: which also raises the question about a libiwinfo redesign or replacement
<jow>
it doesn't add much value if all that's left is nl80211
<rsalvaterra>
jow: Linksys gets the credits, the open source community gets the blame.
<jow>
the ubus info backends could be migrated to netifd
nlowe has joined #openwrt-devel
<jow>
the cli tool does not add much value over iw, could be replaced by a script wrapper
<nbd>
actually, i think the cli tools is more useful than iw
<nbd>
for getting the status info of the wifi devices
<jow>
maybe libiwinfo should remain as a convenience library for scanning and stuff. But it really needs a rework of the internal design
<nbd>
right, the ops abstraction can be removed
<jow>
the fixed buffer approach does not scale well with nl80211 evolution
<jow>
imaybe it should use blob buffers internally for non-scalar return values such as scan results, frequency lists, encryption structures etc.
<nbd>
i think blobmsg as output of the api makes a lot of sense
<nbd>
easy to convert for lua/ucode, cli can easily convert it too
<nbd>
and it makes the whole thing extensible
<jow>
that should be a libiwinfo2 then though and libiwinfo a thing compat wrapper around it
<jow>
*thin
<nbd>
right
<jow>
until we can completely drop it
<nbd>
btw. i've written most of the code for the iwinfo phy path stuff
<nbd>
should hopefully finish it today
<nitroshift>
jow, nbd mat i chime in regarding mwlwifi?
<nbd>
sure
<nbd>
rmilecki: btw. it appears that the mwlwifi firmware was updated between 19.07 and 21.02
<nbd>
so maybe they fixed a bug and added two more
<rmilecki>
nbd: ok, i'll point that out
<rmilecki>
thanks
<nbd>
it was pointed out in one of the forum threads
<nitroshift>
i'm using 2 wrt3200acm's for over 2 years now, never encountered any major issues with mwlwifi
<rmilecki>
nitroshift: did you upgrade to 21.02-rc2?
<nitroshift>
as for the issues posted in the forum, i've dealt in the past with similar situations, turned out to be bad configs, physically moving the router around in the house, etc
<nitroshift>
don't get me wrong, i am NOT a linksys advocate
<nitroshift>
rmilecki, i'm building my own images based off master
<jow>
nbd: ah cool. drop me a line if you have a patch
<nitroshift>
nbd, shouldn't the firmware update be present in kaloz's git?
<nbd>
nitroshift: i think it is. the update is not very recent, i think it was from feb 2020
<nitroshift>
nbd, thanks, unless someone is using a *very* old version of openwrt, we're all using that firmware
<nitroshift>
rmilecki, at the moment i'm running OpenWrt SNAPSHOT, r16738-4508b12b08
<nitroshift>
however, should it be of any use for you guys, i can flash rc2
<rmilecki>
nitroshift: probably no need to
_lore_- is now known as _lore_
rejoicetreat has joined #openwrt-devel
<jow>
rmilecki: did we reach any conclusion about the migration failure reports? I just fixed one issue which triggered an endless loop but apart from that I wasn't able to reproduce connectivity loss after migration so far
<rmilecki>
jow: i've reviewed all posts in the rc2 announcement forum post
<rmilecki>
there is on report that I asked for more details
<rmilecki>
jow: unless you see sth buggy in that config
<rmilecki>
jow: i'm going to search for more reports now in case we have any other failures
<rmilecki>
jow: i also want to test wireguard protocol setup just in case
<rmilecki>
jow: i'm planning to do that toda
<jow>
nope, but when clicking around in luci, creating, deleting vlan devices toggling back and forth between explicit and implicit vlans I managed to bring netifd into an undefined state where it wasn't able to bring up the interface up or down anymore until it was completely restarted
<jow>
maybe something similar can happen in other sceanrios
<jow>
afair we're currently reloading the config after migration. A complete service restart might be needed
<rmilecki>
nbd: ?
<jow>
also I recall that some people specifically comlained about wireless reattachment not working to the migrated bridges
<rmilecki>
jow: uh, i'm quite sure I tested it, you actually explicitly asked me if I tried that at all
<jow>
but that could also have been some kind of ui confusion
<rmilecki>
jow: i'll give it 1 more try
<jow>
because until a recent fix an hour ago or so we didn't display bridge port icons after the migration anymore
<jow>
they were only shown for legacy bridge configs, not for referenced bridge devices
<jow>
and the vlan filtering matrix only displays wired ports
<jow>
so on a cursory look that could look as if wifi was not attached to the bridge
<rmilecki>
oh
<rmilecki>
i could miss that indeed
<jow>
also the one reporter of the luci ticket was quite enraged, not sure if he spent much time gathering details
<rmilecki>
jow: but of course we have to be very careful with reports we get
<rmilecki>
jow: one user has already blamed switch to the kernel 5.3 which isn't very likely to cause regression if I were to guess
<russell-->
5.4, surely ;)
<rmilecki>
oh, so much about detailed reports
<Tusker>
OK, so, now seeing a JFFS2 "old erase block" error... is there a standard way to wipe the mtd on first sysupgrade? Or should I include a wipe from uboot in the instructions ?
<Tusker>
jffs2reset manually solved it, is that something that should be automated ? or just put an installation note on it ?
<nbd>
hauke: ping
<nbd>
hauke: your gdb python commit does this if python support is disabled: HOST_CONFIGURE_ARGS:= --without-python
<nbd>
(removes all previous host configure args)
<nbd>
i'll fix it
<rmilecki>
jow: i looked at two reports:
<rmilecki>
https://github.com/openwrt/luci/issues/5068 - that one is closed for good reason - i reviewed it and original issue is fixed now (old netifd + new LuCI + migration)
<rmilecki>
("luci-proto-qmi fail to setup via luci web")
dr|z3d__ has quit [Remote host closed the connection]
<jow>
rmilecki: I know, I plan to do a large backport round later this week
<rmilecki>
ok
dorf_ has joined #openwrt-devel
Tapper has joined #openwrt-devel
<nbd>
jow: got iwinfo path stuff working, sent the patches to you via email
<nbd>
at least the basic bits
<nbd>
still need to add lookup by path
<nbd>
instead of by config section
<nbd>
i tested it on a mt7915 DBDC device
decke has quit [Quit: Leaving.]
feriman has quit [Ping timeout: 480 seconds]
<jow>
nbd: did you consider using realpath(buf, NULL) ? This way libc will allocate a buffer for the canonical path and you don't need to reserve PATH_MAX bytes on the stack
<nbd>
jow: it's not stack
<nbd>
it's static
<nbd>
and i'm returning a pointer to that buffer
<nbd>
that way the caller doesn't need to free the buffer
<jow>
okay
<nbd>
i have 'iwinfo nl80211 phyname path=...' and mac=... working as well
<nbd>
do you want me to push it, or do you want to review it again?
<rsalvaterra>
rmilecki: The new L2 configuration only applies do DSA switches, right?
<rmilecki>
rsalvaterra: no
<rsalvaterra>
Oh, swconfig too?
<rmilecki>
rsalvaterra: we use "config device" for "lan" bridge interface on swconfig devices too
<rmilecki>
rsalvaterra: yes, for "lan" logical interface we always use bridge as often wireless interfaces need to be bridged
<jow>
nbd: feel free to push it
<rsalvaterra>
rmilecki: So, in the case of a one-armed router, I'd have to use the VLAN interfaces (ethx.y) as ports, is that it?
<nbd>
jow: we don't need lua code for looking up the device path of a phy, right?
<rmilecki>
rsalvaterra: does your device has a switch?
danitool has joined #openwrt-devel
<rsalvaterra>
rmilecki: Yes. Specifically, it's a TL-WDR3600.
<rmilecki>
rsalvaterra: i believe swconfig requires using VLANs
<rmilecki>
rsalvaterra: so yes, you'll need ethx.y
<rmilecki>
so you should have "config device" with "option type bridge" and "list ports ethx.y"
<rsalvaterra>
rmilecki: Right, that's what I was asking, thanks. :)
<rmilecki>
np :)
* rsalvaterra
goes to reconfigure the thingy…
<jow>
nbd: no, I don't think so
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<tmn505>
russell--: jow: sorry for the noise and blaming prematurely, current config for all subtarget in x86 set properly the CPU family and type. So this was not an issue. Mine issue may be different to Russell's.
<jow>
tmn505: no probem, I blame prematurely all the time
<jow>
it works once in a while
<tmn505>
russell--: can You give me an output of /sys/devices/system/clocksource/clocksource0/{available_clocksource,current_clocksource} when kernel 5.10 is booted?
<kabel>
nbd: hey felix, one question: the mt76 driver supports mt7663s SDIO chip. Is is possible to buy a device with this chip? I cannot find anything anywhere
<nbd>
in general, i don't have any experience with buying mt76 cards
feriman has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
JohnA has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
<hauke>
nbd: thanks
<hauke>
that should be an +=
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<nick[m]4>
jow: i'm allowed to change copyright header to spdx or?
Tapper has joined #openwrt-devel
feriman has quit [Quit: WeeChat 3.1]
feriman has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Tusker has quit [Quit: Time wasted on IRC: 15 hours 29 minutes 21 seconds]
<tmn505>
russell--: jow: found the cause of bootloops on WRAP with kernel 5.10. It's some sort of timing issue where timekeeping watchdog is not able to mark TSC clocksource as unstable fast enough and probably some other watchdog kicks in and reboots the device. If I overclock the CPU with jumpers to 266 MHz it boots without problems (marks TSC as unstable and uses scx200_hrt), but only with Microdrive, if
<tmn505>
I use CF card it hangs regardless.
<tmn505>
So the fix, in WRAP case, is to add to kernel command line tsc=unstable or clocksource=scx200_hrt.
feriman has quit [Quit: WeeChat 3.1]
feriman has joined #openwrt-devel
feriman has quit []
feriman has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
JohnA has quit [Ping timeout: 480 seconds]
JohnA has joined #openwrt-devel
JohnA_ has joined #openwrt-devel
JohnA has quit [Ping timeout: 480 seconds]
JohnA has joined #openwrt-devel
JohnA_ has quit [Ping timeout: 480 seconds]
<rmilecki>
jow: how do you update just LuCI in running firmware?
<rmilecki>
jow: i do scp ./bin/packages/arm_cortex-a9/luci/*ipk root@192.168.1.1:/tmp/
<rmilecki>
and then opkg install
<rmilecki>
is there anything better / smarter?
feriman has quit [Ping timeout: 480 seconds]
JohnA has quit [Ping timeout: 480 seconds]
JohnA has joined #openwrt-devel
<jow>
nick[m]4: yes of course, changing spdx etc. is no problem
<jow>
nick[m]4: you should just leave the old "copyright (c) openwrt.org" statements alone
<jow>
rmilecki: I usually mount the target rootfs using sshfs and then I copy files directly fro mthe luci repo back & forth
<rmilecki>
oh, interesting
<rmilecki>
i'll try that, thanks
<jow>
there's no fast workflow I'm aware of yet (except maybe somehow mounting the repo to the target device and setting up symlink trees
<rmilecki>
FS#3864 - Regression: LuCI displays DHCP Server tab for wireguard
JohnA has quit [Ping timeout: 480 seconds]
<jow>
rmilecki: this is intentional
<rmilecki>
oh
<jow>
rmilecki: it is needed to mark interfaces as master
<jow>
note that the dhcp server tab won't offer most options, only ignore for dhcpv4 (marked default) and master mode + ra, dhcpv6 and ndp relay for dhcpv6
<rmilecki>
I'm ignorant then, I didn't think DHCP may make any sense for wireguard
<jow>
in general dhcp tab only makes sense on static (downstream) interfaces and wan
<jow>
but "wan" could be anything
<jow>
anything providing a default route at least
<jow>
so the current approach is to show the dhcp tab for any interface, but restrict it to a very small subset of options for non-static interfaces
<jow>
on non-static interfaces (e.g. your wireguard one) you can't actually enable a DHCPv4 or DHCPv6 server
<rmilecki>
ok, i admit i didn't check what options appear there
<rmilecki>
i assumed it's for enabling dhcp server
<jow>
tl;dr - you need to be able to add a "config dhcp; option interface wan; option master 1" through LuCI for your upstream interface in order to be able to setup DHCPv6/RA relay mode and NDP proxy mode
<jow>
which is needed if an IPv6-enabled ISP does not offer prefix delegation or only leases out single /128 IPv6 ips
<jow>
to have IPv6 working for lan clients then you need to proxy NDP and DHCPv6 traffic to the upstream server
<jow>
to the upstream ISP one, that is
<rmilecki>
ok, it's not bug, it's a feature
<jow>
;)
<PaulFertser>
Talking about that feature, would be nice if someone in the know clarified in the docs what exactly "hybrid" implies, and when it should be used.
<jow>
PaulFertser: I actually spent quite some time reading odhcpd sources
* PaulFertser
too
<jow>
hybrid is a bit of a misnomer for "auto mode"
<PaulFertser>
Yes, that's what I figured but I wasn't sure I got it all proper...
<PaulFertser>
From what I "understood" it didn't look useful for anything.
<jow>
on master 1 (upstream) interfaces hybrid means "try relay mode if a prefix is available, else disable"
<jow>
on master 0 (downstream) interfaces hybrid means "try relay mode if a master iface exists, else fall back to server mode"
<jow>
on on downstream ndp hybrid means "enable proxy mode if a master iface exists, else disable ndp proxy"
<jow>
"master iface exists" means a master interface has been selected in the configuration, a suitable upstream prefix is available and odhcpd has marked that master interface as active internally
<jow>
or rather is serving it, has set up listeners etc.
<jow>
I guess the main purpose is to be able to setup a relay config that is only activated if upstream IPv6 connectivity is present
<jow>
intuitively I would've expected hybrid mode to switch to server mode if DHCPv6-PD is available
<jow>
but my understanding of the code was that it does not work this way
<nick[m]4>
jow: okay thanks.
<jow>
PaulFertser: ah wait, it *does* work this way
<jow>
ubus_has_prefix() checks that the interface marked master (e.g. wan) has at least one "ipv6-prefix" entry in ifstatus, if it does, upstream offers DHCPv6-PD and relay mode is disabled master side which causes the realy slaves to switch into server mode
<PaulFertser>
jow: sounds nifty! What would be the downside of enabling it by default?
<jow>
so if you ship a config with upstream and downstream ra/ndp/dhcpv6 services set to "hybrid" then openwrt will do DHCPv6-PD if available upstream side and fall back to proxy/relay mode if not
<jow>
probably not much of a downside
<jow>
maybe less reliable DHCPv6 service if upstream is slow to respond and odhcpd decides to switch into relay mode
<jow>
while there actually is DHCPv6-PD upstream available
<PaulFertser>
Ah, so it's racy
<jow>
maybe, I can't really test due to lack of proper IPv6
<PaulFertser>
Many people especially in JP have to use this relaying, and it's quite counter-intuitive to have to add option master 1 etc. to a "disabled" dhcp section.
<jow>
yeah
<jow>
I wouldn't be opposed to change the default in master and see how it plays out
<jow>
would probably also expand the IPv6 coverage considerably for people having weird ISPs
<jow>
assuming that there is no race issues, but that can only be tested in the field
<jow>
nbd: found a little bug here: https://git.openwrt.org/?p=project/iwinfo.git;a=blob;f=iwinfo_nl80211.c;h=84d69e8c32953ad1f224a7993aa5c96ab0bda077;hb=268bb26d2e2a729c890899ab2d20efb98dec4117#l395
<jow>
nbd: I think it should be nl80211_phy_idx_from_phy(opt)
<aparcar[m]>
jow: do you have an opinion on replacing flyspray with github issues?
<zorun>
-1 for github issues, what happened to the gitlab idea?
<aparcar[m]>
zorun: we need somebody != gitlab.com to host an instance for us since nobody is keen to do so
Zaba2 has joined #openwrt-devel
<aparcar[m]>
I wanted to suggest fosshost.org but they seem to have a downtime since early yesterday.
<aparcar[m]>
oh fastly seems to be down, hah good we postponed the CDN migration
<aparcar[m]>
nothing ever really works
<zorun>
I don't think fosshost is suitable for critical infrastructure (as gitlab would be)
<aparcar[m]>
zorun: who is?
<zorun>
difficult question :)
<aparcar[m]>
zorun: I'm not able (nor willing) to maintain a "production" gitlab instance. I think neither is lynxis and those were the only people who initially suggested such move. We could look into a slim replacement like sourcehut, but that's another discussion. We could ask people like alpine or debian if we could sneak on their servers, but that might be vetoed by others
Zaba2 has quit [Ping timeout: 480 seconds]
Zaba2 has joined #openwrt-devel
Zaba2 has quit [Ping timeout: 480 seconds]
Luke-Jr has quit []
f5 has quit [Remote host closed the connection]
f5 has joined #openwrt-devel
<lynxis>
aparcar[m]: it depends. my instance is a small one with a couple of regular people and lots of repositories. as long you stay on the supported path it's really not much work at all. just an apt-get dist-upgrade as soon there is a cve. sure gitlab is quite huge. but also has lots of usuful features
Zaba2 has joined #openwrt-devel
rejoicetreat has quit [Ping timeout: 480 seconds]
<zorun>
it's still some amount of work (proper backups, monitoring, following security issues, etc)
<zorun>
but in any case gitlab is a good match in terms of features
dorf_ has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<nbd>
jow: you're right
<xdarklight>
hauke: are you familiar with NAPI (or performance tuning in general)? with RX traffic of ~50 Mbit/s on dsl0 (package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_vdsl.c) NAPI (ksoftirqd) consumes one xRX200 CPU core. haven't noticed this earlier since I was limited to 50Mbit/s downstream anyways. since yesterday I have 100Mbit/s downstream (my line synced at ~95Mbit/s) but I can't reach that speed because ~50Mbit/s downstream maxes out one CPU
<xdarklight>
core already
<hauke>
xdarklight: no not really
<xdarklight>
hauke: ok, thanks anyways. maybe someone else in here has a hint for me (even if it's just a "go read this fine manual: <link>")
<stintel>
I'm actually interested in that too, maxing out one core on octeon limiting me to ~2Gbps
<aparcar[m]>
lynxis: so, you'd be down to manage the gitlab instance for OpenWrt?
<stintel>
it shouldn't be just one person maintaining it, there should at least be one backup, preferably more than one
<lynxis>
stintel: ack. i don't want to be the bus factory.
<stintel>
or your plane could get shot out of the air by russian rebels etc :)
<lynxis>
xdarklight: just in case if you need a testsetup. I've a zyxel vdsl 30a dslam up to 100mbit rx/tx around and some lantiq boards.
<xdarklight>
lynxis: that seems like a great toy :-). I'll keep that in mind in case I need some extra testing - thanks for offering this :)
<hauke>
xdarklight: accessing DMA mapped memory is very expensive
<zorun>
aparcar[m]: I've just replied to your thread about github
<zorun>
if we switch everything to gitlab, let's make sure it's rock solid and durable
<hauke>
when I removed one 32 bit access into a DMA mapped area it improved sped by 20%
<xdarklight>
hauke: hmm, so that might be the DMA cache invalidation in alloc_skb_rx and the descriptor handling in ptm_poll
goliath has quit [Quit: SIGSEGV]
<aparcar[m]>
zorun: ty
goliath has joined #openwrt-devel
figgyc_ has joined #openwrt-devel
danitool has joined #openwrt-devel
PaulFertser has quit [Ping timeout: 480 seconds]
PaulFertser has joined #openwrt-devel
Borromini has quit [Quit: leaving]
<xdarklight>
hauke: I think you're right with this. right after rebooting the device I get ~10MB/s download speed but shortly after it drops to half of that again. I assume it's because the RX queue is pre-allocated during startup in init_tables()
dorf has quit [Remote host closed the connection]
<mangix>
aparcar[m]: +1 for GitHub. Nobody seems to be able to figure out this girlab thing.
<russell-->
tmn505: trying on my net4826 ...
<russell-->
tmn505: apparently not the same problem for me. wouldn't your clock theory imply you'd get the same hang whether it was a warm or cold boot? I am only seeing the hang on warm boots. a full power cycle lets it boot normally.