ale(4) cannot negotiate as GigE
pyunyh at gmail.com
Wed Feb 20 04:37:49 UTC 2013
On Tue, Feb 19, 2013 at 08:23:02AM +0000, Alexey Dokuchaev wrote:
> Hi there,
> I've recently put back online one of my home servers, updated to the latest
> -CURRENT code. All went fine, but one thing bothers me. This box bears
> Asus P5Q Pro mobo, with the following onboard NIC:
> ale0 at pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969
> rev=0xb0 hdr=0x00
> vendor = 'Atheros Communications Inc.'
> device = 'AR8121/AR8113/AR8114 Gigabit or Fast Ethernet'
> class = network
> subclass = ethernet
> According the the specs, it should be GigE. In fact, when plugged into a
> capable switch, it displays "green" (gig) status (same on the switch), but
> once being initialized by the kernel, it downgrades to yellowish 100mbps
> (real speeds agree).
There is a fast etherenet version(L2E) so I'm not sure what you
have. Could you show me dmesg output(ale(4) & atphy(4) only) and
"devinfo -rv| grep atphy"?
> I'm not sure why it happens; maybe it's somehow related to a handful of
> those "ale0: link state changed to DOWN/UP" flip-flops I see in dmesg(8),
> before it can finally obtain DHCP lease?
That's normal when you initiates auto-negotiation with dhclient.
> I remember these adapters had problems in the past, like infamous "Corrupted
> MAC on input" disconnect messages, but I don't recall that I could not use
> it in GigE mode. Anything I can do about it? Googling did not help much:
> most reports date back to ca. 2009, and apparently were ironed out in later
> revisions (e.g. selectively disabling checksum offloading). Thanks,
If you still see the "Corrupted MAC on input" message, let me know.
More information about the freebsd-current