You are not logged in.
I'm trying out kernel 3.10 (up to 3.10.3 so far) and find that conky isn't playing too well. Both these lines worked up to kernel 3.99 but now only show a blank:
${color black}${downspeedgraph eth0 32,300 ff0000 4876ff}
${color black}${upspeedgraph eth0 32,300 bdb76b ff0000}
Any ideas or do I just wait till it gets past the testing repo?
Last edited by kinleyd (2014-04-10 05:27:32)
Offline
Does it output anything when starting conky in a terminal?
Offline
Both these lines worked up to kernel 3.99...
You are 89 minor version into the FUTURE!!! How is it in the future?
What does the output of the command show not if anything at all?
Offline
Is your ethernet card still named "eth0"?
Offline
Thank you all for your responses:
@Army: same thing in a terminal. Most conky variables show, except downspeedgraph, upspeedgraph AND (which I should have mentioned earlier) downspeed eth0, upspeed eth0, both of which remain at 0.
@WonderWoofy: Hello there. Yup, sadly not a time traveler here - I meant kernel 3.9.9-1. It just outputs the outline of two empty boxes where the graphs should be.
@Nierro: eth0 seems to be up. conky's ${if_up eth0} gets me a Connected output and ip route show gets me:
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.14
To add to the background, I am using an Atheros AR8161 NIC for which I had to use the dkms-alx package from AUR up to the last kernel. I'm guessing its integration into the kernel still has a few kinks to be worked out? Any further suggestions will be appreciated.
Add: Apart from the conky issues, the internet connection itself is working.
Last edited by kinleyd (2013-07-12 07:55:42)
Offline
I've now also tried out aur/conky-cli. ${downspeed eth0} ${upspeed eth0} still don't work, while ${if_up eth0} gets me a Connected as before. I'm guessing it has to do with kernel 3.10.1. Let's see. On the positive side, I'm happy to have moved to conky-cli, mainly because I'm getting the transparency and tintColor settings to work with conky on my urxvt terminals.
Offline
I'm suspecting it's some kind of regression in the nic driver: I am using an Atheros AR8161 nic. I had to use the dkms-alx package from AUR up to kernel 3.9.9 (that worked perfectly) and I'm guessing its integration into the kernel has let in the regression.
Feedback from anyone using kernel 3.10.x and conky, and who also previously used the dkms-alx driver will be most welcome.
Last edited by kinleyd (2013-07-27 07:33:37)
Offline
Moved topic and merged threads.
In the future, please use the 'report' link and leave a note to the moderators asking us to move the thread to another forum.
Thank You.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Thanks ewaller. I've edited my post to better reflect the merge status and please ignore my recent report/request - for some reason I thought the thread was still in the [testing] Repo Forum. /facepalm/
Offline
I'm having to exact same issue. Until upgrading to kernel 3.10 from 3.9 I was using dkms-alx and since the upgrade the conky downspeed and upspeed stays at 0.
Networking works fine, though.
Offline
Thanks for responding aiBo. Sorry you are having the same problem but glad to know that it isn't something weird specific to my system. As they say, misery loves company. :)
Offline
I can tell you that it works with 3.10 with a Intel gigabit chip (e1000e driver). So it's probably something related with you card's driver.
Offline
Yes, @r3pek, it almost certainly is the nic driver. It used to work when the drivers came off AUR/dkms-alx but has stopped being fully functional (on the conky side, luckily internet connectivity is fine) after it was integrated into the kernel.
Offline
Hi all,
I'm having the same problem. Before kernel 3.10 I had to compile the driver from source. Networking and the following conkyrc lines worked:
Down ${downspeed enp5s0}/s ${alignr}Up ${upspeed enp5s0}/s
${downspeedgraph enp5s0 25,107} ${alignr}${upspeedgraph enp5s0 25,107}
Total ${totaldown enp5s0} ${alignr}Total ${totalup enp5s0}
The output of ip link command:
[username@hostname ~]$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 90:2b:34:d1:d5:64 brd ff:ff:ff:ff:ff:ff
My conkyrc has the correct interface's name but still not working.
Has anyone progressed on this issue?
Thanks all!
Offline
Unfortunately no progress since kernel 3.10.1 and up to 3.10.4 so far. I'm not sure if any one has filed a bug report yet. Any one know who's maintaining the kernel section dealing with the Atheros family of NICs?
Edit: At this time, kernel 3.10.5 carries the same problem. I've filed a bug report with the maintainers. Hopefully it won't take too long to fix this.
Last edited by kinleyd (2013-08-06 06:48:05)
Offline
The reason appears to be that Johannes Berg, who cleaned up and simplified the alx driver that's now in the kernel, also killed the relevant functions that update the interface stats (check /proc/net/dev or /sys/class/net/enp2s0/statistics/rx_* — it's all 0) in that process.
Compare main.c from the kernel commit with alx_main.c as it was in the dkms driver; no more update_hw_stats etc.
edit:Ah, after looking at the mailing list with your bug report I see that he's already aware of the issue.
Last edited by misc (2013-08-07 14:25:58)
Offline
Yeah, @misc, that was basically it. I was really surprised by his casual approach to the code and functionality that he threw out, as suggested in the bug report link you posted, as well as on the Linux kernel page on G+. I'm not sure which is more desirable - a working set of drivers in AUR that you have to build manually every time you upgrade your kernel, or a functionally hobbled driver but one that is built into the kernel. I'd have personally settled for the former. :(
Last edited by kinleyd (2013-08-08 16:34:52)
Offline
@kinleyd, I have the same probem with alx driver too. Bummer.
I did notice that, since I use network bridging with kvm, the bridge interface registers stats in /proc/net/dev. My guess would be that the bridge module is handling this and not the alx driver. I also don't know how accurate the data is.
I know this doesn't line up with exactly what you want but maybe it might help.
Offline
@narb: Eric Dumazet, one of the maintainers, has reviewed the original code in the alx driver and asked Johannes Berg to copy/paste it back in. I'm not sure how long it will take to get it back into the kernel but I'm hoping not too long. For the sake of conky and alx driver users everywhere. :)
Last edited by kinleyd (2013-08-10 04:32:32)
Offline
The relevant alx stat functions have finally been added to (what will become) 3.14-rc1.
Offline
Ah, finally. I will be waiting for 3.14 eagerly.
Thanks for the update, misc.
Offline
3.14 has landed from testing, and as misc said, this has finally been fixed. My conky connection speeds are once again something other than 0.
It's been a while since the release of 3.10 (around June 2013) when one bloke needlessly broke the driver (yeah, damn you!), and all hail the developer who finally fixed it (all hail, all hail!!).
Marking this thread as solved.
Offline