Main problem is solved I guess. Thanks!
I've followed your instructions but persistent rules were not automatically created at boot and syslog messages are still appearing...
Main problem is solved I guess. Thanks!
I've followed your instructions but persistent rules were not automatically created at boot and syslog messages are still appearing...
Last edited by Jason Pierce; November 23rd, 2012 at 02:50 PM. Reason: More concise
I've had to reinstall udev and libudev because I've accidentally deleted the persistent-rules (is my fault).
New created rules are empty. System is running fine but the syslog pollution is there.
I've recovered previous rules from a Clonezilla backup soooo, this is not a problem anymore.
Apart from this, my syslog it's about 15 MB right now hahaha.
I've found an older thread with a similar problem after installing the propietary drivers.
Hope it helps.
http://ubuntuforums.org/showthread.php?t=1612271&page=6
EDIT 1
I've tried reinstalling the drivers step by step but it's not the solution.
Last edited by Jason Pierce; November 24th, 2012 at 04:25 AM. Reason: More info
lol !
Wasn't necessary though, since you had already posted the previous one's contents which we could just copy-paste
However, as the comments in the file says, we can edit it as long as it is changing values only. So assuming the contents of the 'persistent rules' file are same as those in post #9, let's try it -
Open the file in gedit with root privileges-
Now change its values so its contents become (changes highlighted in "red") -Code:gksu gedit /etc/udev/rules.d/70-persistent-net.rules
Proofread, save and close. Reboot and see if the syslog is still flooded with the same messages (or different ones, or not at all).Code:# This file was automatically generated by the /lib/udev/write_net_rules # program, run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single # line, and change only the value of the NAME= key. # PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1c.5/0000:05:00.0 (r8169) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # PCI device 0x1814:/sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:00.0 (rt3562sta) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="ra*", NAME="ra0"
Also, have you checked the .conf files in /etc/conky/ to see if something appears suspicious there ?
PS:
By the way, since the messages indeed seem to be related with something trying to get stats from the older driver, while the overall system seems to be comfortable with the new driver, I still doubt if it is related to conky somehow. Accordingly, why don't you try to back up the conkyscript and the /etc/conky directory, then do a full removal of it (sudo apt-get purge conky) to see if the messages stop ? If not, you can easily reinstall it and restore your backed-up files.
Also, you seem to be comfortable with scripts. While we try different things, would you like to keep a script running in the background to keep the syslog clean from those messages ? We can even make it a permanent workaround if needed . Please let me know if sounds interesting to you.
Yeah, but I deleted other persistent rules which I didn't copied
Sadly, nothing seems to change, although this version seems more accurate.Open the file in gedit with root privileges-
Now change its values so its contents become (changes highlighted in "red") -Code:gksu gedit /etc/udev/rules.d/70-persistent-net.rules
Proofread, save and close. Reboot and see if the syslog is still flooded with the same messages (or different ones, or not at all).Code:# This file was automatically generated by the /lib/udev/write_net_rules # program, run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single # line, and change only the value of the NAME= key. # PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1c.5/0000:05:00.0 (r8169) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # PCI device 0x1814:/sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:00.0 (rt3562sta) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="ra*", NAME="ra0"
Nothing to blame on it.Also, have you checked the .conf files in /etc/conky/ to see if something appears suspicious there ?
I wouldn't mind doing it, but do you think it's necessary?? Remember we deactivated conky script at boot up without results.PS:
By the way, since the messages indeed seem to be related with something trying to get stats from the older driver, while the overall system seems to be comfortable with the new driver, I still doubt if it is related to conky somehow. Accordingly, why don't you try to back up the conkyscript and the /etc/conky directory, then do a full removal of it (sudo apt-get purge conky) to see if the messages stop ? If not, you can easily reinstall it and restore your backed-up files.
Maybe later if we aren't capable of finding a good solution. It's good to know there are more optionsAlso, you seem to be comfortable with scripts. While we try different things, would you like to keep a script running in the background to keep the syslog clean from those messages ? We can even make it a permanent workaround if needed . Please let me know if sounds interesting to you.
Hi!
I'm posting again because I've started noticing some inestability in the connection. Maybe because there are more wifi clients today...
Moreover, using a P2P application I couldn't get the usual download rate and after this the system was kind of slow.
Would you mind start again with basic tests like lsmod and so on?
Last edited by Jason Pierce; November 24th, 2012 at 02:34 PM. Reason: Last line added
Like I admitted already, I'm not familiar with conky nor with how it works. What I suspect is, maybe it made changes in some system files to be able to grab live system stats effectively (obviously, a wild-wild guess). If so, then hopefully purging it may revert those changes.
For example - there is a file /usr/share/apport/package-hooks/conky.py which is a python script (tiny, but way above my head !). It certainly grabs settings from ~/conkyrc file and God only knows (or a python programmer) where it 'adds' it. Now unless it repeats its job at every boot, it may have made changes in something which is now spewing those messages. If so, removing it may revert the changes. Even if not, then re-installing it may once again trigger those changes, this time with correct driver - thus making happy 'whoever is angry' with the absence of rt28xx at the moment.
Obviously, all this is based on pure suspicion and no proofs. But if the .conf files and the conkyrc files are all that is needed for customization, then trying a purge-reinstall cycle shouldn't hurt.
With 6 messages a second, the culprit process should be consuming a significant amount of processing power. Of course the script can't compensate that, but can only save the space. But this just gave me an idea. Do you notice some unusual process continuously using the CPU ? Even if it is just 2-4%, but continuous.... it may lead us to the culprit. Check it in System Monitor. If you hover the pointer over a process, it shows the program name, and sometimes the path as well..
Done!
Code:sudo apt-get purge conky-all
Unfortunately, nothing has changed. As I said, we could try to double check lsmod and stuff like that.
Hi, please try:
that should turn the debug messages off.Code:iwpriv ra0 set Debug=0
Thanks
Bookmarks