| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
ok brad@
|
|
|
|
activity instead of letting it sit and return 'no buffer available'
errors.
|
|
- support setting the MTU
|
|
We have to enable the connection to the MII first. Doing so fixes the
problem cards without breaking the older, working cards.
From FreeBSD
|
|
- sync dc_mii_readreg()
From FreeBSD
|
|
From NetBSD
NetBSD PR 27678 for details
ok mcbride@
|
|
Avoid an unnecessary copy of a packet if it is already in a single mbuf.
Introduce an additional device flag for those NICs which require the
transmit buffers to be aligned to 32-bit boundaries.
From FreeBSD
|
|
Don't read the MAC address from a copy of the EEPROM in the softc
that has been recorded earlier and overwrite it again later by
reading it directly from the EEPROM again.
Read the MAC address from the PAR0/PAR1 registers instead, which
are autoloaded on reboot.
From FreeBSD
Thanks to David Snyder <dasnyderx at yahoo dot com> for testing on
a AN983 based card which used to come up with a MAC address of
ff:ff:ff:ff:ff:ff.
|
|
From FreeBSD
|
|
Ignore CSR13, CSR14, CSR15 'Media Specific Data' registers
for 21143 based cards which use SIA mode.
This fixes 10mbit mode for ZNYX ZX346Q cards and other
21143 based cards.
rev 1.108
Only use a SIA/SYM media info block if no MII block is detected.
The submitter of PR 32118 told me that this patch also fixes autoselecting
for znyx 4 port cards (10baseT, 100baseTX did work already).
From FreeBSD
ok deraadt@
|
|
Fix if_timer logic to make sure that there is always a timeout
pending if there are packets queued for transmission.
From FreeBSD
ok deraadt@
|
|
Do not call mii_pollstat() from within device tick routines; the status
information is updated by mii_tick().
dcphy.c rev 1.13
Work around an Intel 21143 chip bug.
Rev 1.56 of if_dc.c removed calls to mii_pollstat() from the dc_tick()
routine. dc_tick() is called regularly to detect link up and link down
status, especially when autonegotiating.
The expectation was that mii_tick() (which is still called from dc_tick())
would update status information automatically in all cases where it would
be sensible to do so.
Unfortunately, with authentic 21143 chips this is not the case, and
the driver never successfully autonegotiates. This is because (despite
what it says in the 21143 manual) the chip always claims that link is not
present while the autonegotiation enable bit is set. Autonegotation takes
place and succeeds, but the driver tests the link bits before it switches
off the autonegotiation enable bit, and success is not recognised.
The simplest solution is to call dcphy_status() more often for MII_TICK
calls by dropping out of the switch statement instead of exiting when
we are autonegotiating and link appears to not be present. When
autonegotiation succeeds, dcphy_status() will note the speed and fdx/hdx
state and turn off the autonegotiation enable bit. The next call to
dcphy_status() will notice that link is present, and the dc driver code
will be notified.
Macronix chips also use this code, but implement link detection as
described in the manual, and hence don't need this patch. However, tests
on a Macronix 98715AEC-C show that it does not adversely affect them.
From FreeBSD
ok deraadt@
|
|
Enable the automatic TX underrun recovery for the ADMtek chips.
This solves cvsup update on my laptop which aborts after a while
without this patch.
rev 1.79
Fix the support for the AN985/983 chips, which do not set the
RXSTATE to STOPPED, but to WAIT. This should fix hangs which
could only be solved by replugging the cable.
From FreeBSD
Thanks to C. Bensend <benny at bennyvision dot com> for testing.
|
|
Add a check in the interrupt service routine to return quickly in
case there is nothing to do. This happens normally when the card shares
the interrupt line with other devices.
This code saves a couple of microseconds per interrupt even on a
fast CPU. You normally would not care, except under heavy tinygram
traffic where you can have some 50-100.000 interrupts per second...
rev 1.51
Patch to allow TX underrun handling without issuing a complete
chip reset. Just temporarily turn off the transmitter instead.
From FreeBSD
ok mcbride@
tested by mcbride@, jaredy@, marco@, grange@, <harding at motd dot ca>
|
|
|
|
in the 21143, instead of giving priority to the receive unit.
This gives a 10-15% performance improvement in the forwarding rate
under heavy load.
From FreeBSD
ok mcbride@ nick@ deraadt@
|
|
|
|
{ether,atm,fddi}_ifattach already does this.
ok mcbride@ markus@ henning@
|
|
- get rid of hand rolled crc32 logic, use ether_crc32_{le,be}
- accept all multicast if a range is encountered
|
|
|
|
Tom: I did not commit a couple of your changes.
i did not include some punctuation fixes (full stops, etc.)
mnemorable -> mnemonic: i decided memorable was probably better
instrunctions -> instruction: i kept the plural
|
|
syncing; jason@ testing
|
|
|
|
|
|
and give be archs a better chance at getting the correct mac address as tested on the mac and hppa where mac has an additional bug w/ the phy bit still remaining and hppa seems fine; jason@ ok
|
|
ok jason@
|
|
bug in the Momenco firmware on the Leopard-V, which now has one port
working.
|
|
|
|
- remove a bunch of #if 0 stuff (most of which referred to dc_unit, grr)
- delay a bzero until necessary
|
|
|
|
ok henning@
|
|
|
|
many many many thanks to nick@, who booted no less then 8 kernels for me today
while hacking on that (and this includes going downstairs to the basement
and up again 8 times...)
ok jason@
|
|
This chip is some strange abnormal 21143 variant. It really only works with
10 MBit/s halfduplex only and autonegotiation is totally broken in hardware.
Should also have a HomePNA phy, but we don't support that.
for now requires and explicit "media 10BaseT".
if anybody has such a chip please mail me.
nick@ is the only one who has the hardware and did an incredible amount of
testing. Thanks for all the help, Nick!
some hints and ok jason@
|
|
|
|
'struct arpcom foo' -> 'struct arpcom sc_arpcom'
ok itojun@
|
|
|
|
Nonnekes <maurice@amaze.nl> based on FreeBSD (only minor surgery necessary)
|
|
|
|
|
|
|
|
|
|
(untested, but it's pretty similiar to the tested 21143 case).
|
|
dc_setfilt_21143() case at least.
XXX I'm looking at the other filter setups and they appear to need work for BE too.
|
