Bugfix for annoying messages from the Natsemi network driver

I'm sure that almost everybody dealing with Compaq Evo T20 thin clients experienced the bug with the Natsemi driver. After the network adapter is initialized, it spits the following messages to the console every few seconds:
eth0: DSPCFG accepted after 0 usec.
eth0: Wake-up event 0x200000b
eth0: Setting full-duplex based on negotiated link capability.

I asked many people about how to solve this and nobody knew. Dag Sverre gave me the tip to simply comment out the log instruction in the source of the Natsemi driver. However I didn't like the idea too much since these messages appear for a reason. And the reason is quite simple: it's a bug. Smile

In the natsemi.c source file in the definition of the netdev_timer() function there's the following condition:
  if (!netif_queue_stopped(dev)) {
    ...
  } else {
    ...
  }

The condition is evaluated exactly in the opposite way as it should be. So change it to this:
  if (netif_queue_stopped(dev)) {
    ...
  } else {
    ...
  }

I've made a kernel patch for kernel v2.6.16.1 (right now this is highest 2.6.x kernel that I could make running on the Evo), see below.

AttachmentSize
natsemi-2.6.16.1.patch554 bytes

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

linux on T20

Hi,
I was wondering would you please mind sharing some info on getting Linux 2.6 on the T20? The 'how to' pages don't appear to be online any more and I would like to have a newer linux running on my T20 please.

thank you.

answer in email

I've sent the answer in email to the address you gave in your comment. Generally people looking for EvoT20 related information should subscribe to the open-evot20-discuss mailing list or just go through the archives.

natsemi not fixed

Some time ago I've discovered that with the 2.6.20.2 kernel these messages from the Natsemi driver did not appear on the console of the thinclient (or at least I thought it was because of the new kernel). Today I've found out the real reason: the error messages are going to the syslog host. :-> I've found a 80MB kern.log for one of the thinclients on the syslog host and a 90MB kern.log for another client (the 3 lines are sent by the client to the syslog host every 5 seconds).

Now taking a look at the natsemi.c source again, I've found that the first and the third line in the repeated error message go to kern log facility with info log level, and the second line in the error message goes to the kern log facility with notice log level. Thus if you set up your syslog config not to log messages from these two sources, then you'll be just fine.

Or you can try my patch which indeed supresses the messages, but since I was just hacking around in the source of natsemi.c without much knowledge of what I was doing ... I might have even messed up something. Smile

Anyone who wants to be on

Anyone who wants to be on the save side should simply disable the corresponding printk commands in the driver. This wil supress all messages of these types but if your network once works correctly why should you need them Smile

Markus
        if (np->SavedClkRun & PMEStatus && netif_msg_wol(np)) {
/*              printk(KERN_NOTICE "%s: Wake-up event %#08x\n",
                        dev->name, readl(ioaddr + WOLCmd)); */
        }

                } else {
/*                      printk(KERN_INFO
                                "%s: DSPCFG accepted after %d usec.\n",
                                dev->name, i*10); */
                }

                if (netif_msg_link(np))
/*                        printk(KERN_INFO
                                "%s: Setting %s-duplex based on negotiated "
                                "link capability.\n", dev->name,
                                duplex ? "full" : "half"); */
                if (duplex) {

ethtool

Instead of patching the driver, it is possible to use ethtool ( http://sourceforge.net/projects/gkernel/ ) to shut up the natsemi driver: ethtool -s <interface> msglvl 0 does the trick here.

Re: ethtool

Thanks for the tip! I did not know about that tool til now.

natsemi.dspcfg_workaround=0

you won`t need to hack the driver or use ethtool - simply add natsemi.dspcfg_workaround=0 to your kernel commandline and you´re done