trying to set txqueulen of nic during startup fails, it remains at the default value setting it manually after boot works fine Reproducible: Always Steps to Reproduce: 1.place non-default txqueuelen value in /etc/conf.d/net 2.txqueuelen_eth0="30000" 3.boot Actual Results: txqueuelen is not changed - remains at default value Expected Results: the nics txqueuelen should have been changed to the requested value from a terminal after boot "ip link set eth0 txqueuelen 30000" works fine modules="iproute2" config_eth0="192.168.107.4/24" routes_eth0="default via 192.168.107.1" mtu_eth0="9000" txqueuelen_eth0="30000"
My guess is that you're using busybox's ip during boot since it appears to not support "txqueuelen". However qlen is supported by both (but undocumented in iproute2).
Created attachment 149946 [details, diff] txqueuelen -> qlen Applying this to the openrc-0.2.2 ebuild should fix the issue for you
(In reply to comment #2) > Applying this to the openrc-0.2.2 ebuild should fix the issue for you Sorry, did not help at all.
/etc/init.d/net.eth0 stop /etc/init.d/net.eth0 --debug start &>/tmp/start-net.eth0 then post /tmp/start-net.eth0 here
(In reply to comment #4) > /etc/init.d/net.eth0 stop > /etc/init.d/net.eth0 --debug start &>/tmp/start-net.eth0 > > then post /tmp/start-net.eth0 here > Attached. Briefly looks like the qlen is set before the device is added.
Created attachment 149960 [details] /tmp/start-net.eth0
(In reply to comment #5) > Briefly looks like the qlen is set before the device is added. Actually it appears that that shouldn't matter.
Adding that this bug exhibits on both x86 and x86_64 platforms.
Also exists with the following git version: # rc --version rc (OpenRC) git-82ea5713 (Gentoo Linux)
I cannot replicate this at all - txqueuelen is correctly set provided you're not using busybox as the shell. Please report the version of iproute2 you have installed. Also, edit /lib/rc/net/iproute2.sh and goto line 189 Then put this before and after the txqueuelen block so we can see if it's being set or not ip link show $IFACE Then post the output of the script starting.
I've also provided a patch to Mike (that I need to send upstream) that fixes it for busybox. It's implemented in busy box but someone forgot to connect the command line option to the right variable.
(In reply to comment #10) > Please report the version of iproute2 you have installed. iproute2-2.6.24.20080108 but the problem exists if I use modules="ifconfig" as well, it's not just with iproute2 > Also, edit /lib/rc/net/iproute2.sh and goto line 189 > Then put this before and after the txqueuelen block so we can see if it's being > set or not > > ip link show $IFACE > > Then post the output of the script starting. Did this and during boot it does show that qlen gets set. However, after I log in (text based, no X), qlen is back to 1000. Something is resetting qlen after it gets set. Also I longer get /var/log/boot.msg since moving to openrc. Anyway to fix this?
(In reply to comment #10) > I cannot replicate this at all - txqueuelen is correctly set provided you're > not using busybox as the shell. Standard ~ setups here no particular shell changes.
(In reply to comment #12) > but the problem exists if I use modules="ifconfig" as well, it's not just with > iproute2 > Did this and during boot it does show that qlen gets set. However, after I log > in (text based, no X), qlen is back to 1000. Something is resetting qlen after > it gets set. Which also means it's not an OpenRC bug. If you restart the interface does it stay set, even if for a few seconds. > > Also I longer get /var/log/boot.msg since moving to openrc. Anyway to fix this? > Enable rc_logger in /etc/rc.conf and you'll find /var/log/rc.log instead.
(In reply to comment #14) > Which also means it's not an OpenRC bug. > If you restart the interface does it stay set, even if for a few seconds. First I set to a non-default value not equal to conf.d/net value: # ip link set eth0 qlen 2000 && ip link show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast qlen 2000 link/ether 00:16:76:aa:bf:70 brd ff:ff:ff:ff:ff:ff Then restart the interface followed immediately by the show: # /etc/init.d/net.eth0 restart && ip link show eth0 * Bringing down interface eth0 * Caching network module dependencies * Stopping dhcpcd on eth0 ... [ ok ] * Bringing up interface eth0 * Caching network module dependencies 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc pfifo_fast qlen 1000 link/ether 00:16:76:aa:bf:70 brd ff:ff:ff:ff:ff:ff 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc pfifo_fast qlen 30000 link/ether 00:16:76:aa:bf:70 brd ff:ff:ff:ff:ff:ff * dhcp ... * Running dhcpcd ... [ ok ] * received address 192.168.107.6/24 [ ok ] * Waiting for IPv6 addresses ... [ ok ] 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast qlen 1000 link/ether 00:16:76:aa:bf:70 brd ff:ff:ff:ff:ff:ff Just to add that my x86 system that has the same problem uses a fixed IP address and not dhcp. > Enable rc_logger in /etc/rc.conf and you'll find /var/log/rc.log instead. Thanks.
Is this still an issue for you?
(In reply to comment #16) > Is this still an issue for you? Yes. And now running openrc-0.3.0. Additional info: If I don't set the MTU, then txqueulen gets set. If I set the MTU then txqueulen resets to default. This works: ============================= config_eth0="192.168.107.4/24" routes_eth0="default via 192.168.107.1" txqueuelen_eth0="10000" ============================= qlen ends up at 10000, and MTU is default of 1500 ============================= This doesn't work: ============================= config_eth0="192.168.107.4/24" routes_eth0="default via 192.168.107.1" txqueuelen_eth0="10000" mtu_eth0="9000" ============================= The MTU properly gets set to 9000, but qlen resets to the default of 1000. Although I can manually bump the qlen after booting. ============================= Chris
(In reply to comment #17) > (In reply to comment #16) > > Is this still an issue for you? > > Yes. And now running openrc-0.3.0. > > Additional info: > > If I don't set the MTU, then txqueulen gets set. If I set the MTU then > txqueulen resets to default. > This works: > ============================= > config_eth0="192.168.107.4/24" > routes_eth0="default via 192.168.107.1" > txqueuelen_eth0="10000" > ============================= > qlen ends up at 10000, and MTU is default of 1500 > ============================= Actually the above doesn't always work. Sometimes it works but usually it doesn't.
Same problem here. I am on openrc Version: 0.3.0.20081113-r2 (with baselayout 2.0.0-r1). and when I reboot my machine my Network card does not come up. I have to start it manually with /etc/init.d/net.eth0 start then I also need to start my ntp-client again. A bit annoying because it would be nice if this would just work. Networking is something very important out there. Best Zeno
Created attachment 195468 [details] debug of net start This still doesn't work! /etc/conf.d/net = modules="iproute2" config_eth0="dhcp 192.168.107.66/24" txqueuelen_eth0="10000" versions: sys-apps/net-tools-1.60_p20071202044231-r1 sys-apps/iproute2-2.6.29.1 sys-apps/openrc-0.4.3-r3
With current versions: sys-apps/net-tools-1.60_p20090728014017-r1 sys-apps/iproute2-2.6.29.1 sys-apps/openrc-0.6.0-r1 txqueuelen is correctly set. I made my /etc/conf.d/net exactly the same (modulo ip address) modules="iproute2" config_eth0="dhcp 192.168.0.66/24" txqueuelen_eth0="10000" I also tested using ifconfig instead of iproute2, and that also correctly sets txqueuelen.
Chris, can you verify that this works for you as well? Thanks, William
(In reply to comment #22) > Chris, > > can you verify that this works for you as well? Last couple of boots on my x86 server (static address) it has worked although previously I have seen it fail on occasion. Still does not work on my x86_64 desktop! Server loads the e1000 modules, desktop loads the e1000e module.
Forgot to mention: I tested on x86. > (In reply to comment #22) > > Chris, > > > > can you verify that this works for you as well? > > Last couple of boots on my x86 server (static address) it has worked although > previously I have seen it fail on occasion. > > Still does not work on my x86_64 desktop! > > Server loads the e1000 modules, desktop loads the e1000e module. >
And to reiterate, even on x86, if I set the MTU then the txqueuelen does not get set. See my comment #17 which holds for x86 - on x86_64 txqueuelen does not get set regardless of whether I attempt to set the MTU or not.
This bug is now about 9 months old. What else can I do to assist? Standard hardware here - genuine Intel branded mainboards and genuine Intel branded NICs - does it get any more generic?
(In reply to comment #26) I tested with the following configuration: config_eth0="192.168.107.4/24" routes_eth0="default via 192.168.107.1" txqueuelen_eth0="10000" mtu_eth0="9000" I tried restarting it five times, because Chris seemed to suggest in comment #17 that it seemed a little racy. Each time I got the same result: MTU got correctly set, but txqueulen got set to "100" (strange...). I tried various other combinations for MTU and txqueuelen and also saw the same result. Will do some digging during the next couple of days. > This bug is now about 9 months old. What else can I do to assist? Standard > hardware here - genuine Intel branded mainboards and genuine Intel branded NICs > - does it get any more generic? >
Here's some odd findings. Here's the default state: # ip link show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 I'll change the qlen: # ip link set eth0 qlen 10000 # ip link show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 10000 Now I'll change the mtu: # ip link set eth0 mtu 9000 # ip link show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 Note that the qlen has been reset. # ip link set eth0 mtu 1500 # ip link show eth0 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 Notice the state of the link is now DOWN (and I also lost my secondary address as 'ip addr' would show). # ip link set eth0 up mtu 9000 qlen 10000 # ip link show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 Sometimes the above works (the qlen and mtu get set properly), this time it didn't, the mtu was set, the link is up, but the qlen didn't survive. Seems like the qlen must be specified after the mtu is set and that the mtu must be specified along with an up to insure the link remains up.
(In reply to comment #28) > Seems like the qlen must be specified after the mtu is set and that the mtu > must be specified along with an up to insure the link remains up. What I mean by this is that the order may need to be something like: 1) ip link set eth0 up mtu 9000 2) ip link set eth0 up qlen 10000 Not sure if (1) needs the "up" or not - but changing the mtu without it will (or so it seems) at times take the interface down.
> (In reply to comment #28) > 1) ip link set eth0 up mtu 9000 > > Not sure if (1) needs the "up" or not - but changing the mtu without it will > (or so it seems) at times take the interface down. Actually the "up" seems to be worthless here as multiple trials of changing the mtu seem to randomly take the interface down. So maybe an order more like: 1) ip link set eth0 mtu 9000 2) ip link set eth0 up qlen 10000 Or: 1) ip link set eth0 mtu 9000 2) ip link set eth0 qlen 10000 3) ip link set eth0 up
More testing on x86 reveals: Using both ip and ifconfig I find that setting (on command line) the MTU to any value takes a second or two to take, and (automatically) sets the txqueuelen to 100 (which some quick searching appears to suggest is a kernel/NIC default... need to confirm). Which means that on x86 I cannot find any bug that has to do with OpenRC. I do not have access to x86_64. Chris, can you confirm the behavior that I describe, but on x86_64? Or does it still appear to only occur on boot? Also (obviously a pain) have you tried reproducing this with baselayout 1?
(In reply to comment #31) > Which means that on x86 I cannot find any bug that has to do with OpenRC. > > I do not have access to x86_64. Chris, can you confirm the behavior that I > describe, but on x86_64? Or does it still appear to only occur on boot? Also > (obviously a pain) have you tried reproducing this with baselayout 1? See my comments #'s 28, 29 & 30. Sorry, don't know exactly what part of the OS it has to do with (maybe it's baselayout and not openrc, or even some other subsystem or sys app) but one is supposed to be able (according to current documentation) to set the MTU and the QLEN on net start via statements in /etc/conf.d/net - I can only suggest to either make it possible (fix the timing, order, or whatever) or document that Gentoo can not accomplish this. If it has nothing to do with OpenRC than please properly reassign the bug. Sorry, I will not be testing this with baselayout-1.
I think this bug got lost in the shuffel somewhere. Chris, is it still happening? Trevor, is there any more information from your side? Also, I am re-assigning to openrc for now. Thanks, William
(In reply to comment #33) > I think this bug got lost in the shuffel somewhere. > > Chris, is it still happening? Just tested this and it is now working on my end. Thank you.
Thanks Chris, I am going to go ahead and close this bug since you are saying this is resolved. William
