IFF_UP and IFF_RUNNING before running the 'disable' step, instead
of after. Soon I will handle the 'disable' step by calling into
PMF, which may call if_stop(, 0). Ordinarily, that is harmless.
This change lets the if_stop() routines exit early when they find
on entry that IFF_RUNNING is not set.
handling, ether_mediastatus() and ether_mediachange(). Check for
a non-ENXIO error return from mii_mediachg(). (ENXIO indicates
that a PHY is suspended.)
This patch shrinks the source code size by 979 lines. There was
a 5100-byte savings on the NetBSD/i386 kernel configuration, ALL.
I have made a few miscellaneous changes, too:
gem(4): use LIST_EMPTY(), LIST_FOREACH().
mtd(4): handle media ioctls, for a change!
axe(4): do not track link status in sc->axe_link any longer
nfe(4), aue(4), axe(4), udav(4), url(4): do not reset all PHYs
on a change of media
Except for the change to mtd(4), no functional changes are intended.
XXX This patch affects more architectures than I can feasibly
XXX compile and run. I have compiled macppc, sparc64, i386. I
XXX have run the patches on i386 boxen with bnx(4) and sip(4).
XXX Compiling and running on evbmips (MERAKI, ADM5120) is in
XXX progress.
from FreeBSD's if_vr.c rev 1.52:
- check more error status in TX descriptor and restart TX module
appropriately in vr_txeof()
- check more error interrupt status in vr_intr()
I can't confirm whether these changes actually fix TX stalls because
I can't reproduce the problem I had about seven years ago (I guess
it might be caused by excessive collisions on a dumb hub), but at least
they don't seem to have bad side effects on normal operations on my macppc.
The commit log in FreeBSD's if_vr.c rev 1.43 says
"This is really only for the VT6102, but it doesn't hurt the older chips,"
but at least it hurts my VT86C100A (which returns a product ID of VT3043)
on macppc and causes kernel MCHK trap while the same board on i386
and VT6102 on macppc have no problem with it.
- in vr_rxeoc() (i.e. on RX error interrupts), disable RX before
calling vr_rxeof() and check it actually stopped
- no recovery is needed for VR_ISR_DROPPED, so just account ierrors
- also account ierrors in vr_rxeoc()
support this feature. This avoids multiple crashes that I've had in the
past. Also ensure that packets are not empty when DIAGNOSTIC is set.
However, this is just another sanity check of the received packets, but
does not address the real problem. The issue seems to be the following:
if the card receives data while doing a reset (vr_init), it later finds
a bunch of empty packets in the receive ring.
This explains the crashes I've hit: running a program which needs
promiscuous mode (dhclient) while the card was already running in
that mode (tcpdump). In this situation, it's easy that the second
reset receives stuff from the network.
Unfortunately, I don't know why the card is producing these packets...
While here, fix a typo in a comment.
This reloads the entire EEPROM, not just the MAC address, which can
cause problems for the host PCI bus under certain circumstances. The
chip already loads the EEPROM at powerup/reset anyway.
XXX: This probably applies to the other Rhine variants too, but I don't
have a data sheet to confirm this behaviour.
only single segment.
- No need to set VR_CMD_TX_ON in vr_start().
- Initialize BCR0 and BCR1 registers.
- Change RX DMA threshold 128bytes.
Mostly from FreeBSD via OpenBSD.
- Windows put the chip in suspended mode, make sure we unsuspend
it. 1.43, by Takefumi SAYO <stake@po.shiojiri.ne.jp>
- Detect the revision of the Rhine chip we're using, and force reset
when the chip supports it. 1.65, by silby@freebsd.org
joerg