NEWS: There are now three variants of the Atheros L1 chip in circulation, each using a different Linux driver. Make sure you know which variant is installed in your system. See "Which L1 do YOU have?" below.
NEWS: The atl1 driver was released as part of kernel version 2.6.21 on April 27, 2007.
NEWS: On Feb 9, 2007 the atl1 driver was merged into the mainline kernel with kernel version 2.6.20-git5.
NEWS: We've established an atl1 project at Sourceforge. See this link.
NEWS: Attansic has been acquired by Atheros. See this press release for details.
This page is devoted to the Attansic L1 Gigabit Ethernet driver for Linux. The Attansic L1 is included as the onboard network device for the following Asus hardware. (If you know of other mainboards/systems that include this device, please email me.)
|A7SV (laptop)||F3E (laptop)||F3SC (laptop)||F3SV (laptop)|
|P5L-MX||P5LD2-VM||P5L-VM 1394||P51Sn (laptop)|
Thanks to Xiong Huang of Attansic for writing the original vendor version of the driver and for granting permission to make the driver available for inclusion in the kernel. After obtaining permission from Attansic, I made the initial submittal of the driver to the Linux Kernel Mailing List (LKML) on September 27, 2006.
Thanks also to Chris Snook for joining up to co-maintain the driver.
Here are some L1 drivers released by Attansic, now Atheros.
IMPORTANT NOTE: These are vendor versions of the L1 driver. They were written by Attansic. We do not support these drivers. They're offered here merely as a courtesy to make your life easier. If you have a problem with the driver, contact Attansic/Atheros directly.
IMPORTANT NOTE: The Attansic vendor version of the drivers prior to 22.214.171.124 have a problem: TSO is broken, and that results in horrible transmit performance. The good news is that it's fixed in 1.2.40.x and higher. For the older versions, the workaround is simple: turn off TSO. You can do this two ways. First, you can run this command as root, but it won't survive a reboot: ethtool -K eth0 tso off.
A more permanent solution is to disable the TSO feature in the driver source itself. You do this by commenting out a line in one of the driver source files. Let's say you install the driver files at $HOME/atl1. You need to edit $HOME/atl1/src/at_main.c and comment out the line that contains netdev->features |= NETIF_F_TSO, then (re)build the driver.
|0.1.40.6||Initial vendor version found on the Asus M2V mainboard CD|
|126.96.36.199||Vendor version released by Attansic on Sept 29, 2006 for kernel <=2.6.18|
|188.8.131.52||Vendor version released by Atheros on June 17, 2007 for kernel <=2.6.21.x|
|184.108.40.206||Vendor version released by Atheros on July 5, 2007 for kernel <=2.6.22.x|
|220.127.116.11||Vendor version released by Atheros in May 2008 for kernel <=2.6.22.x|
Here are some drivers for the L1 adapted for inclusion in the mainline kernel. For the standalone driver, just untar the tarball, cd into the resulting directory, and execute "sudo make install". The driver should build and install itself.
The kernel patch version requires that you build a new kernel. To apply the patch, take a look at these instructions.
|18.104.22.168||L1 standalone driver compatible with kernel 2.6.19 -- EXPERIMENTAL|
|22.214.171.124||L1 standalone driver compatible with kernel 2.6.20 -- EXPERIMENTAL|
|126.96.36.199||L1 kernel patch compatible with kernel 2.6.20 -- EXPERIMENTAL|
|2.0.7||L1 standalone driver compatible with kernel 2.6.19 -- EXPERIMENTAL|
|2.0.7||L1 standalone driver compatible with kernel 2.6.20 -- EXPERIMENTAL|
|2.1.3||L1 prebuilt rpm compatible with Centos 5.2 (kernel 2.6.18)|
|2.1.3||L1 standalone driver compatible with kernel 2.6.23|
|2.1.3||L1 standalone driver compatible with kernel 2.6.24|
|2.1.3||L1 standalone driver compatible with kernel 2.6.25|
1. Some Via chipsets don't play well with message signalled interrupts (MSI), and will generate a flood of APIC errors in dmesg or system logs when the atl1 driver starts sending and receiving packets. If this happens, modify your kernel's boot line and add this kernel parameter: pci=nomsi. A fix was added to 188.8.131.52 and later kernels.
2. There is a bug in the atl1 driver that results in a kernel hang or crash (oops) under heavy network load IF AND ONLY IF you have 4GB or more RAM in your system. The L1 network chip can DMA to 64-bit addresses, but multiple descriptor rings share a single register for the high 32 bits of their address, so only a single, aligned, 4 GB physical address range can be used at a time. If you encounter this problem, modify your kernel's boot line and add this kernel parameter: mem=3900M. A fix was added to the 184.108.40.206 and 2.6.23 (and later) kernels.
3. Another atl1 bug affects older real-time (RT) kernels. The symptom is very sluggish network performance, accompanied by a log entry that looks like this:
date:time hostname kernel: network driver disabled raw interrupts: atl1_xmit_frame+0x0/0x7c0 [atl1]
This problem was fixed in 2.6.23, and is fixed in all later kernels.
4. There is a bug in the driver that causes memory corruption during the shutdown of the interface if and only if you have 4GB or more RAM in your system (and your system utilizes all that memory). The bug has been solved and was incorporated into kernel 2.6.25 and beyond.
5. If you see this message (or lots of them) in your system log:
atl1 0000:02:00.0: hw csum wrong, pkt_flag:1600, err_flag:80
it generally means you're encountering a bug in the L1 hardware that isn't handled well by the atl1 driver. Basically, the L1 hardware treats a fragmented IP packet as an error, when, in fact, it may not be erroneous at all. Fragmented packets can occur, for example, if your MTU size is set too large. In my own case, my DSL modem/router has its MTU size set to 1500 bytes, but it needs 8 of those bytes for its own use. If my Linux box also has its MTU size set to 1500, then inbound and outbound packets will be fragmented at the DSL router so it can add (or remove) its 8 bits. Here's where the hardware bug comes into play. When the L1 hardware receives a fragmented packet, it sets an error flag in one of its registers, and the driver, upon seeing the error bit, spews the "hw csum wrong" message. This has been fixed in the 2.6.27 kernel and beyond. The fragmentation will still occur, but the atl1 driver won't spew the error message that contributes to network slowdown.
You can avoid this condition and significantly improve network performance by adjusting the MTU size downward on your atl1 box. I use an MTU size of 1492 bytes on all my systems that sit behind the DSL modem/router. This MTU size leaves room for the DSL modem/router to add its 8 bits and avoid fragmentation altogether.
6. If you try and build vendor version 220.127.116.11 or 18.104.22.168 under Centos 5 or 5.2, you'll encounter this error:
/home/jcliburn/atl1/vendor_drivers/l1-linux-v22.214.171.124/src/kcompat.h:1116: error: redefinition of typedef ‘irq_handler_t’
include/linux/interrupt.h:67: error: previous declaration of ‘irq_handler_t’ was here
make: *** [/home/jcliburn/atl1/vendor_drivers/l1-linux-v126.96.36.199/src/at_main.o] Error 1
make: *** [_module_/home/jcliburn/atl1/vendor_drivers/l1-linux-v188.8.131.52/src] Error 2
make: Leaving directory `/usr/src/kernels/2.6.18-92.1.18.el5-x86_64'
make: *** [default] Error 2
Atheros now has three different variants of the L1 gigabit ethernet chip in circulation. All three report themselves as the "L1 Gigabit Ethernet Adapter" or similar in your logs. Unfortunately, each of them also uses a different driver. Make sure you know which L1 chip your system contains. You can tell by inspecting the output of this command:
lspci -n | grep 1969
Here are the three L1 chip variants, their PCI IDs, and their associated driver names.
The atl1c driver is the newest. It was released on 20090323 in kernel version 2.6.29.
If you don't see what you're looking for, just browse the ftp server.