Subject: Re: kern/10707: "transmit aborted" errors from vr driver
To: Martin Husemann <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 08/01/2000 23:43:05
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)
> + 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
Manuel Bouyer <email@example.com>