Subject: Re: kern/10707: "transmit aborted" errors from vr driver
To: None <martin@rumolt.teuto.de>
From: Martin Husemann <martin@rumolt.teuto.de>
List: current-users
Date: 08/02/2000 11:55:48
> I'm not sure this is the same bug as your bug and as far as I understand
> the source the packet currently *is* retransmitted.

Ok, looked again: seems the packet is dropped.

> This would be explainable if it isn't a hardware bug but "normal flow control",
> as cgd suggested. Which would suggest to not log it at all (but just increase
> the collision error count).

I had a look at the FreeBSD driver: it does nearly the same thing as ours, but
does not log UNDERRUN nor TRANSMIT ABORTED. If I understood it correctly, that
would be the attached change to our if_vr.c. I'm not sure about the dotx = 1
move, though, but the old position seemed bogus to me. The FreeBSD driver does
detect this differently.

Is this the right thing to do?


Martin


Index: if_vr.c
===================================================================
RCS file: /cvsroot/syssrc/sys/dev/pci/if_vr.c,v
retrieving revision 1.35
diff -c -r1.35 if_vr.c
*** if_vr.c	2000/06/28 16:08:46	1.35
--- if_vr.c	2000/08/02 09:55:34
***************
*** 895,910 ****
  		}
  
  		if (status & (VR_ISR_TX_UNDERRUN | VR_ISR_TX_ABRT)) {
- 			if (status & VR_ISR_TX_UNDERRUN)
- 				printf("%s: transmit underrun\n",
- 				    sc->vr_dev.dv_xname);
- 			if (status & VR_ISR_TX_ABRT)
- 				printf("%s: transmit aborted\n",
- 				    sc->vr_dev.dv_xname);
  			ifp->if_oerrors++;
- 			dotx = 1;
  			vr_txeof(sc);
  			if (sc->vr_txpending) {
  				VR_SETBIT16(sc, VR_COMMAND, VR_CMD_TX_ON);
  				VR_SETBIT16(sc, VR_COMMAND, VR_CMD_TX_GO);
  			}
--- 895,904 ----
  		}
  
  		if (status & (VR_ISR_TX_UNDERRUN | VR_ISR_TX_ABRT)) {
  			ifp->if_oerrors++;
  			vr_txeof(sc);
  			if (sc->vr_txpending) {
+ 				dotx = 1;
  				VR_SETBIT16(sc, VR_COMMAND, VR_CMD_TX_ON);
  				VR_SETBIT16(sc, VR_COMMAND, VR_CMD_TX_GO);
  			}