<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/sys/dev/ale, branch releng/8.0</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>Disable Rx checksum offload until I find more clue why it breaks</title>
<updated>2009-06-29T05:12:21+00:00</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2009-06-29T05:12:21+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=ca406a44ded4fac34beff45ebcad4afaa72a0804'/>
<id>ca406a44ded4fac34beff45ebcad4afaa72a0804</id>
<content type='text'>
under certain environments. However give users chance to override
it when he/she surely knows his/her hardware works with Rx checksum
offload.

Reported by:	Ulrich Spoerlein ( uqs &lt;&gt; spoerlein dot net )
MFC after:	1 week
Approved by:	re (kensmith)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
under certain environments. However give users chance to override
it when he/she surely knows his/her hardware works with Rx checksum
offload.

Reported by:	Ulrich Spoerlein ( uqs &lt;&gt; spoerlein dot net )
MFC after:	1 week
Approved by:	re (kensmith)
</pre>
</div>
</content>
</entry>
<entry>
<title>Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/</title>
<updated>2009-06-26T11:45:06+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2009-06-26T11:45:06+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=eb956cd041f956275522092d6ba66671356ff84f'/>
<id>eb956cd041f956275522092d6ba66671356ff84f</id>
<content type='text'>
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs.  This will
allow us to change the locking strategy without affecting our driver
programming interface or binary interface.

For two wireless drivers, remove unnecessary locking, since they
don't actually access the multicast address list.

Approved by:	re (kib)
MFC after:	6 weeks
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs.  This will
allow us to change the locking strategy without affecting our driver
programming interface or binary interface.

For two wireless drivers, remove unnecessary locking, since they
don't actually access the multicast address list.

Approved by:	re (kib)
MFC after:	6 weeks
</pre>
</div>
</content>
</entry>
<entry>
<title>Now pci(4) handles PCIM_CMD_INTxDIS so there is no need to poke</title>
<updated>2009-03-05T00:04:32+00:00</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2009-03-05T00:04:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=59f72548f6f99ff9019e0654f01b733f15b8924b'/>
<id>59f72548f6f99ff9019e0654f01b733f15b8924b</id>
<content type='text'>
this bit in driver.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
this bit in driver.
</pre>
</div>
</content>
</entry>
<entry>
<title>AR8113 also need to set DMA read burst value. This should fix</title>
<updated>2008-12-03T09:01:12+00:00</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2008-12-03T09:01:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=1ce1618851021f429dbc6ffb76122f2f2323d160'/>
<id>1ce1618851021f429dbc6ffb76122f2f2323d160</id>
<content type='text'>
occasional DMA read error seen on AR8113.

Submitted by:	Jie Yang &lt; Jie.Yang &lt;&gt; Atheros com &gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
occasional DMA read error seen on AR8113.

Submitted by:	Jie Yang &lt; Jie.Yang &lt;&gt; Atheros com &gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add some PHY magic to enable PHY hibernation and 1000baseT/10baseT</title>
<updated>2008-12-03T08:56:01+00:00</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2008-12-03T08:56:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=19042fb8c79792f52b05738781b09b955a529976'/>
<id>19042fb8c79792f52b05738781b09b955a529976</id>
<content type='text'>
power adjustment. This change is required to guarantee correct
operation on certain switches.

Submitted by:	Jie Yang &lt; Jie.Yang &lt;&gt; Atheros com &gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
power adjustment. This change is required to guarantee correct
operation on certain switches.

Submitted by:	Jie Yang &lt; Jie.Yang &lt;&gt; Atheros com &gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add ale(4), a driver for Atheros AR8121/AR8113/AR8114 PCIe ethernet</title>
<updated>2008-11-12T09:52:06+00:00</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2008-11-12T09:52:06+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=3c6e15bceeab4470243c60c9a4b5b9cafca9abaa'/>
<id>3c6e15bceeab4470243c60c9a4b5b9cafca9abaa</id>
<content type='text'>
controller. The controller is also known as L1E(AR8121) and
L2E(AR8113/AR8114). Unlike its predecessor Attansic L1,
AR8121/AR8113/AR8114 uses completely different Rx logic such that
it requires separate driver. Datasheet for AR81xx is not available
to open source driver writers but it shares large part of Tx and
PHY logic of L1. I still don't understand some part of register
meaning and some MAC statistics counters but the driver seems to
have no critical issues for performance and stability.

The AR81xx requires copy operation to pass received frames to upper
stack such that ale(4) consumes a lot of CPU cycles than that of
other controller. A couple of silicon bugs also adds more CPU
cycles to address the known hardware bug. However, if you have fast
CPU you can still saturate the link.
Currently ale(4) supports the following hardware features.
  - MSI.
  - TCP Segmentation offload.
  - Hardware VLAN tag insertion/stripping with checksum offload.
  - Tx TCP/UDP checksum offload and Rx IP/TCP/UDP checksum offload.
  - Tx/Rx interrupt moderation.
  - Hardware statistics counters.
  - Jumbo frame.
  - WOL.

AR81xx PCIe ethernet controllers are mainly found on ASUS EeePC or
P5Q series of ASUS motherboards. Special thanks to Jeremy Chadwick
who sent the hardware to me. Without his donation writing a driver
for AR81xx would never have been possible. Big thanks to all people
who reported feedback or tested patches.

HW donated by:	koitsu
Tested by:	bsam, Joao Barros &lt;joao.barros &lt;&gt; gmail DOT com &gt;
		Jan Henrik Sylvester &lt;me &lt;&gt; janh DOT de &gt;
		Ivan Brawley &lt; ivan &lt;&gt; brawley DOT id DOT au &gt;,
		CURRENT ML
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
controller. The controller is also known as L1E(AR8121) and
L2E(AR8113/AR8114). Unlike its predecessor Attansic L1,
AR8121/AR8113/AR8114 uses completely different Rx logic such that
it requires separate driver. Datasheet for AR81xx is not available
to open source driver writers but it shares large part of Tx and
PHY logic of L1. I still don't understand some part of register
meaning and some MAC statistics counters but the driver seems to
have no critical issues for performance and stability.

The AR81xx requires copy operation to pass received frames to upper
stack such that ale(4) consumes a lot of CPU cycles than that of
other controller. A couple of silicon bugs also adds more CPU
cycles to address the known hardware bug. However, if you have fast
CPU you can still saturate the link.
Currently ale(4) supports the following hardware features.
  - MSI.
  - TCP Segmentation offload.
  - Hardware VLAN tag insertion/stripping with checksum offload.
  - Tx TCP/UDP checksum offload and Rx IP/TCP/UDP checksum offload.
  - Tx/Rx interrupt moderation.
  - Hardware statistics counters.
  - Jumbo frame.
  - WOL.

AR81xx PCIe ethernet controllers are mainly found on ASUS EeePC or
P5Q series of ASUS motherboards. Special thanks to Jeremy Chadwick
who sent the hardware to me. Without his donation writing a driver
for AR81xx would never have been possible. Big thanks to all people
who reported feedback or tested patches.

HW donated by:	koitsu
Tested by:	bsam, Joao Barros &lt;joao.barros &lt;&gt; gmail DOT com &gt;
		Jan Henrik Sylvester &lt;me &lt;&gt; janh DOT de &gt;
		Ivan Brawley &lt; ivan &lt;&gt; brawley DOT id DOT au &gt;,
		CURRENT ML
</pre>
</div>
</content>
</entry>
</feed>
