GNU/Linux

Eventually this will be a useful page, I hope. For now it's just some notes on a network driver I fought.

Linux

I'm a bit of a Linux evangelist, though I try to put my money where my mouth is. That means free tech support for anyone I convert. I would like to have space on these pages dedicated to Linux idioms, problems, confusions, and solutions that I find myself repeating frequently, but that will have to wait. Wait for what, I'm not sure. But it's clearly not here yet.

April 28, 2001

Netgear FA311TX problems with kernel 2.4.x and natsemi.o driver

If you are running kernel 2.4.x, have a Netgear FA311TX network interface card, use the natsemi.o driver, and are experiencing somewhat random failures to receive packets, you may want to try my driver patch below. In particular, the problem occurs when an APM call, set_power_state(), is made in order to unblank a virtual terminal. I've seen this occur when awakening your monitor from a text console, or when exiting from an X server ( at least with X 4.x.x).

Finding a workaround isn't too hard. One is to disable APM screen blanking in the General Options when compiling a kernel. Another is to cycle the FA311's network with ifdown followed by ifup. A third is this patch to natsemi.c as included in kernel 2.4.4-pre3. This patch may work with other 2.4.x kernels, and even if not there are only three lines of code to add manually.

More difficult is figuring out why things are breaking. I've observed that the a particular call to apm.c:set_power_state() makes the PMEEN (Power Management Enable) bit of the CCSR register flip to 1. The card then seems to enter a power management state during which it transmits and recieves packets, but doesn't handle the received packets in the normal manner. This makes the conditional "intr_status & (IntrRxDone | IntrRxIntr)" in natsemi.c:intr_handler() fail, and hence natsemi.c:netdev_rx() is never called. My patch blindly sets the PMEEN bit to 0 just before this conditional is tested.

I don't know why the PMEEN bit is being set. One friend suggested that this may be related to a problem that occurs on some models of IBM Thinkpads, where closing the lid triggers a power management event that ends up messing with the PCI bus. He tells me there is an option in the kernel configuration to protect the PCI bus from this situation, but I haven't tried this yet. If you have any questions or suggestions, my email is at the bottom of this page.

I'm especially interested in positive or negative confirmations of this problem in various hardware configurations. So far, I have one other person affected by this who has, like me, a VIA KT133A-based motherboard. I also know of a person with a VIA KT133-based motherboard that cannot reproduce this problem. If you are trying to induce this problem, you might find my killnet.c program helpful. It simply makes the calls that, if you have APM console blanking enabled in your kernel, indirectly and mysteriously cause the PMEEN bit to become set. Instructions for compiling the program are at the top of the source file.

To directly observe whether PMEEN is set or not, I recommend Donald Becker's natsemi-diag.c program. Run it with the "-aa" option, and locate the output for register 0x3c. This 32 bit register is normally 0x00000000, and with the PMEEN bit (the 8th bit counting from zero) set it looks like 0x00000100. Instructions for compiling the program are at the bottom of the source file. Note that there is a lot of good networking diagnostic tools at Scyld's diagnostic page. If you want to know how to read the PMEEN bit from the apm.c:set_power_state() function, for debugging purposes, send me email.

If someone has an FA311 and the appropriate Windows tools, I'd be very intersted to find out if Netgear's Windows driver occasionaly makes writes to the CCSR register at offset 0x3c. While Netgear has a linux driver for kernels 2.0.x and 2.2.x, they don't have one (yet) for kernel 2.4.x. Overall this card looks to be okay, though it seems to peform somewhat worse than my Netgear FA310TX cards. This performance difference might simply be driver issues, since the generic Tulip drivers used for the FA310TX are very mature.