Arch Linux

kayrune

Member

Registered: 2007-12-15

Posts: 43

kernel log growing fast (over 300mb in 2 days!!) [SOLVED (via hack)]

with the following message

Jan 21 22:43:01 Serenity atl1 0000:01:00.0: tx busy
Jan 21 22:43:01 Serenity atl1 0000:01:00.0: tx busy
Jan 21 22:43:01 Serenity atl1 0000:01:00.0: tx busy
Jan 21 22:43:01 Serenity atl1 0000:01:00.0: tx busy
Jan 21 22:43:01 Serenity atl1 0000:01:00.0: tx busy
Jan 21 22:43:01 Serenity atl1 0000:01:00.0: tx busy
Jan 21 22:43:01 Serenity atl1 0000:01:00.0: tx busy

Any idea what this is ?

Is seems it has something to do with network, could it be a faulty driver, dos attack ?

Last edited by kayrune (2008-01-27 12:30:43)

kayrune

Member

Registered: 2007-12-15

Posts: 43

Re: kernel log growing fast (over 300mb in 2 days!!) [SOLVED (via hack)]

can't say for sure, but I think I've isolated this error message to come from NFS traffic. Whenever transfering files via nfs the errors start. Transfering via FTP doesn't make this error.

Also I found this is messages.log regarding NFS, maybe it's related.

17:52:12 Serenity exportfs[7930]: /etc/exports [2]: Neither 'subtree_check' or 'no_subtree_check' specified for export "10.0.0.12:/mnt/share".   Assuming default behaviour ('no_subtree_check').   NOTE: this default has changed since nfs-utils version 1.0.x

kayrune

Member

Registered: 2007-12-15

Posts: 43

Re: kernel log growing fast (over 300mb in 2 days!!) [SOLVED (via hack)]

The NFS errors are unrelated.

I've found some more info on the problem here:
https://bugs.launchpad.net/ubuntu/+sour … bug/133575

The odd thing is, this supposedly is fixed with 2.6.23, although I still have this problem with 2.6.23-ARCH, though I don't run 64bit arch and I only have 1GB of memory. I've tried to disable the memory remapping, but as pointed out, this only fix the crash, the errors in the log are still there.

kayrune

Member

Registered: 2007-12-15

Posts: 43

Re: kernel log growing fast (over 300mb in 2 days!!) [SOLVED (via hack)]

I got in contact with the developer of the driver, this is what he said:

You're running out of transmit descriptors.  You can do a couple of
things.  First, you can increase the number of descriptors (to a maximum
of 1024) by:

ethtool -G eth0 1024

The default is 256.

Also, the tx busy and hw csum messages are debug messages.  You can
eliminate them completely by turning off kernel debug messaging.

Unfortunatly the ethtool command did not help.

Regarding the kernel debug messaging, would turning this off be a bad thing? I assume this can only be done by recompiling the kernel?

kayrune

Member

Registered: 2007-12-15

Posts: 43

Re: kernel log growing fast (over 300mb in 2 days!!) [SOLVED (via hack)]

I've tried recompiling the kernel without logging debug messages, I've tried the boot option loglevel = 3, and I've tried every possible setting in /proc/sys/kernel/printk. Nothing worked the kernel.log still got flooded, when there was traffic via NFS.

So the only solution I found was to remove the following line in atl1_mail.c

dev_printk(KERN_DEBUG; &adapter->pdev->dev, "tx busy\n");

and recompile the kernel/NIC driver. This way the message does not get printet to kernel.log

Thanks to the driver developer for pointing me in the right direction.

Last edited by kayrune (2008-01-27 12:29:48)