Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 May 2008 13:00:12 +0900
From:      Pyun YongHyeon <pyunyh@gmail.com>
To:        Boris Samorodov <bsam@ipt.ru>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: Call for testers : age(4), Attansic/Atheros L1 gigabit ethernet controller
Message-ID:  <20080519040012.GE22924@cdnetworks.co.kr>
In-Reply-To: <40672761@bb.ipt.ru>
References:  <20080310043412.GA4425@cdnetworks.co.kr> <20080310073150.GC4425@cdnetworks.co.kr> <20080313034321.GG16972@cdnetworks.co.kr> <05004621@bb.ipt.ru> <20080409065513.GB46412@cdnetworks.co.kr> <40672761@bb.ipt.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 09, 2008 at 04:40:22PM +0400, Boris Samorodov wrote:
 > On Wed, 9 Apr 2008 15:55:13 +0900 Pyun YongHyeon wrote:
 > > On Tue, Apr 08, 2008 at 11:29:22PM +0400, Boris Samorodov wrote:
 > >  > On Thu, 13 Mar 2008 12:43:21 +0900 Pyun YongHyeon wrote:
 > >  > > On Mon, Mar 10, 2008 at 04:31:50PM +0900, To freebsd-current@FreeBSD.org wrote:
 > >  > >  > On Mon, Mar 10, 2008 at 01:34:12PM +0900, To freebsd-current@FreeBSD.org wrote:
 > >  > >  >  > Hi,
 > >  > >  >  > 
 > >  > >  >  > Due to high pressure from FreeBSD user community to get a working
 > >  > >  >  > driver for Attansic/Atheros L1 giagabit ethernet I had changed
 > >  > >  >  > priorities in my TODO list. I had spent several weeks to write
 > >  > >  >  > this driver and I managed to get a working driver. From my very
 > >  > >  >  > limited testing the driver seems to work as expected.
 > >  > >  >  > 
 > >  > >  >  > ATM the performance is horrible so there must be mis-programmed
 > >  > >  >  > registers or incorrectly configured parameters. Due to the
 > >  > >  >  > existence several variants of L1 hardware and lack of publicly
 > >  > >  >  > available documentation I'd like to know how many variants are
 > >  > >  >  > supported by this driver. L1 gigabit ethernet controller is
 > >  > >  >  > frequently found in ASUS motherboard. Note, it seems that there are
 > >  > >  >  > other variants of hardware as known as L2(Fast ethernet) and newer
 > >  > >  >  > gigabit ethernet(AR81xx) from Atheros. These are not supported by
 > >  > >  >  > this driver and they require a seperate driver. The following
 > >  > >  >  > hardware features are supported by age(4).
 > >  > >  >  > 
 > >  > >  >  >   - TCP Segmentation Offload.
 > >  > >  >  >   - Hardware VLAN tag insertion/stripping.
 > >  > >  >  >   - TCP/UDP checksum offload.
 > >  > >  >  >   - Interrupt moderation.
 > >  > >  >  >   - Hardware statistics counter support.
 > >  > >  >  >   - Jumbo frame support.
 > >  > >  >  >   - WOL support.
 > >  > >  >  > 
 > >  > >  >  > As I said, I already know poor performance issue of age(4) but I'm
 > >  > >  >  > more interested in getting a stable driver. If you're owner of L1
 > >  > >  >  > gigabit ethernet controller please give it spin and let me know
 > >  > >  >  > how it goes on your system.
 > >  > >  >  > 
 > >  > >  >  > Install:
 > >  > >  >  > o Get age(4) jumbo diff at the following URL. The diff was
 > >  > >  >  >   generated against HEAD but I guess it would also apply to RELENG_7
 > >  > >  >  >   and 7.0-RELEASE.
 > >  > >  >  >   http://people.freebsd.org/~yongari/age/age.HEAD.diff
 > >  > >  > 
 > >  > >  > For 7.0-RELEASE, use the following URL.
 > >  > >  > http://people.freebsd.org/~yongari/age/age.7.0R.diff
 > >  > 
 > >  > > It seems that previous version have a bug in getting ethernet
 > >  > > hardware address. To diagnose it I've updated age(4) again and
 > >  > > put updated files to the same URL.
 > >  > 
 > >  > > For CURRENT:
 > >  > > http://people.freebsd.org/~yongari/age/age.HEAD.diff
 > >  > > For RELENG_7/7.0-RELEASE:
 > >  > > http://people.freebsd.org/~yongari/age/age.7.0R.diff
 > >  > 
 > >  > >  >  > o Patch kernel srouce and rebuild/reboot your kernel.
 > >  > >  >  >   #cd /usr/src
 > >  > >  >  >   #patch -p0 < /path/to/age.HEAD.diff 
 > >  > >  >  > 
 > >  > >  >  > Test:
 > >  > >  >  > Use age(4) for your normal network activities and report success or
 > >  > >  >  > any issues you've encountered. The driver may be chatty to ease of
 > >  > >  >  > debugging.
 > >  > 
 > >  > At last I have some spare time to test your patches. I use RELENG_7.
 > >  > Patches applied cleanly exept one simple case with
 > >  > sys/modules/mii/Makefile. And now all works fine! Thank you!
 > >  > I dreamed about using this on-board lan adapter...
 > >  > 
 > >  > Here is some info (Asus P5K m/b):
 > >  > -----
 > >  > host% dmesg | grep ^age
 > >  > age0: <Attansic Technology Corp, L1 Gigabit Ethernet> mem 0xfe8c0000-0xfe8fffff irq 17 at device 0.0 on pci2
 > >  > age0: PCI device revision : 0x00b0
 > >  > age0: Chip id/revision : 0x9006
 > >  > age0: 1280 Tx FIFO, 2364 Rx FIFO
 > >  > age0: MSIX count : 0
 > >  > age0: MSI count : 1
 > >  > age0: Using 1 MSI messages.
 > >  > age0: Read request size : 512 bytes.
 > >  > age0: TLP payload size : 128 bytes.
 > >  > age0: PCI VPD capability not found!
 > >  > age0: Ethernet address: 00:1d:60:XX:XX:XX
 > >  > age0: [FILTER]
 > >  > age0: interrupt moderation is 100 us.
 > >  > age0: interrupt moderation is 100 us.
 > >  > age0: link state changed to UP
 > 
 > > atphy(4) should pick up PHY hardware.
 > > Would you check whether ukphy(4) is attached to the PHY hardware? 
 > > Or would you show me 'devinfo -r' output?
 > 
 > host% dmesg | grep phy
 > atphy0: <Atheros F1 10/100/1000 media interface> PHY 0 on miibus0
 > atphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
 > 
 > Output of 'devinfo -r' is here:
 > ftp://ftp.ipt.ru/pub/download/tmp/devinfo
 > 
 > >  > host% pciconf -vl | grep -A4 age0
 > >  > age0@pci0:2:0:0:	class=0x020000 card=0x82261043 chip=0x10481969 rev=0xb0 hdr=0x00
 > >  >     vendor     = 'Attansic (Now owned by Atheros)'
 > >  >     device     = 'L1 Gigabit Ethernet 10/100/1000Base-T Ethernet Controller'
 > >  >     class      = network
 > >  >     subclass   = ethernet
 > >  > 
 > >  > host% ifconfig age0
 > >  > age0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 > >  > 	options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
 > >  > 	ether 00:1d:60:XX:XX:XX
 > >  > 	inet 192.168.12.89 netmask 0xffffff00 broadcast 192.168.12.255
 > >  > 	media: Ethernet autoselect (1000baseTX <full-duplex>)
 > >  > 	status: active
 > >  > 
 > >  > host% vmstat -i
 > >  > interrupt                          total       rate
 > >  > irq1: atkbd0                       76453          2
 > >  > irq16: nvidia0+++*               3110144        121
 > >  > irq17: atapci1                    235335          9
 > >  > irq18: uhci2 ehci*                     1          0
 > >  > irq21: uhci1                      109423          4
 > >  > irq22: pcm0                           16          0
 > >  > cpu0: timer                     51011849       1999
 > >  > irq256: age0                       72478          2
 > >  > cpu3: timer                     49962753       1958
 > >  > cpu1: timer                     51002577       1999
 > >  > cpu2: timer                     49962704       1958
 > >  > Total                          205543733       8058
 > >  > -----
 > >  > 
 > 
 > > Apart form its poor performance, I think age(4) works well for
 > > normal desktop usage pattern. Three issues not resolved yet are
 > 
 > > 1. Poor performance. No idea how to improve performance without
 > >    documentation. 
 > 
 > > 2. For L1 hardwares that have SPI flash interface, age(4) relys on
 > >    reading station address register which is supposed to be
 > >    initialized during hardware reset. This may not work under
 > >    certain circumtances. Linux seems to have SPI flash interface
 > >    code from vendor with lots of magic code. Because SPI flash
 > >    memory device of different vendors vary in their instruction
 > >    codes for read ID instruction, it's very hard to get instruction
 > >    codes without detailed information for the flash memory device
 > >    used on ethernet controller. Also I guess this SPI flash memory
 > >    device should be maintained in other parts of kernel, not in
 > >    each driver.
 > 
 > > 3. Sometimes chip id/revision returns 0xFFFF and hardware does not
 > >    work at all. I guess this could be related with controller/PHY
 > >    initialziation. Plugging in network cable before system boot
 > >    seems to fix the issue.
 > 
 > > The third issue should be resolved before committing age(4) to
 > > HEAD. Since I can't reprocude it no ETA for the third issue, sorry.
 > 
 > Neither can I.
 > 

FYI: I committed age(4) to HEAD.

-- 
Regards,
Pyun YongHyeon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080519040012.GE22924>