It seems that RealTek 8129/8139 chip reports invalid length of

received frame under certain conditions. wpaul said the length
0xfff0 is special meaning that indicates hardware is in the
process of copying a packet into host memory. But it seems
there are other cases that hardware is busy or stuck in bad
situation even if the received frame length is not 0xfff0.
To work-around this condition, add a check that verifys that
recevied frame length is in valid range. If received length is out
of range reinitialize hardware to recover from stuck condition.

Reported by:	Mike Tancsa ( mike AT sentex DOT net )
Tested by:	Mike Tancsa
Obtained from:	OpenBSD
MFC after:	1 week
This commit is contained in:
Pyun YongHyeon 2008-04-10 01:06:05 +00:00
parent 82e45205c8
commit 1375f576a9
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=178054

View file

@ -1117,17 +1117,19 @@ rl_rxeof(struct rl_softc *sc)
* datasheet makes absolutely no mention of this and
* RealTek should be shot for this.
*/
if ((uint16_t)(rxstat >> 16) == RL_RXSTAT_UNFINISHED)
total_len = rxstat >> 16;
if (total_len == RL_RXSTAT_UNFINISHED)
break;
if (!(rxstat & RL_RXSTAT_RXOK)) {
if (!(rxstat & RL_RXSTAT_RXOK) ||
total_len < ETHER_MIN_LEN ||
total_len > ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) {
ifp->if_ierrors++;
rl_init_locked(sc);
return;
}
/* No errors; receive the packet. */
total_len = rxstat >> 16;
rx_bytes += total_len + 4;
/*