On Tue, Aug 01, 2000 at 11:02:30PM +0200, Martin Husemann wrote:
> I'll need a little ethernet-driver-guru advise, please.
> 
> I filed a PR (kern/10707) a few days ago (which may be a dup of a slightly
> different PR, kern/7948). There were speculations of this all being a
> hardware bug. So I tried to find out, but now I'm not sure...
> 
> I augmented sys/dev/pci/if_vr.c with debug output on the following theory:
> 
> The driver logs this error message, when the interrupt status register
> indicates a transmit abort error.
> 
> IMHO there should be at least one TX descriptor, that has the coresponding
> VR_TXSTAT_ABRT bit set. So I added code to print another error when this
> descriptor is found (which should happen right after printing the first
> error in vr_txeof). There are checks for other error conditions at that
> place already, guarded by the appropriate if (txstat & VR_TXSTAT_ERRSUM),
> and I simply added a few lines there:
> 
> 			if (txstat & VR_TXSTAT_LATECOLL)
> 				ifp->if_collisions++;
> +			if (txstat & VR_TXSTAT_ABRT)
> +				printf("%s: TSR1 has TXSTAT_ABRT\n",
> +					sc->vr_dev.dv_xname);
> 
> With this additional code, I do still get the "vr0: transmit aborted" messages,
> but I never got the "TSR1 has TXSTAT_ABRT" message.
> 
> This either indicates my fundamental misunderstanding of the chip, or a
> flaw in the chip (unsolicited setting of the error bit). In the later case
> we should move the diagnostic message to the place where I added my test
> printf and ignore the interrupt status bit completely (or make vr_txeof return
> a value indicating whether we need to retransmit that packet or not).

To my knowledge it's useless to retransmit the packet - it'll trigger the
bug again.

--
Manuel Bouyer <bouyer@antioche.eu.org>
--