[tulip] tulip_interrupt() bug? (again)

[Bhavesh P. Davda]

The 21143 documentation says:

CSR5<2>:
TU—Transmit Buffer Unavailable
Indicates that the next descriptor on the transmit list is owned by the
host and cannot be acquired by the 21143. The transmission process is
suspended. Table 4-14 explains the transmit process state transitions.
To resume processing transmit descriptors, the host should change the
ownership bit of
the descriptor and then issue a transmit poll demand command, unless
transmit automatic polling (Table 3-43) is enabled.

This maps to csr5&TxNoBuf

In that case, how can you trust the status bits in TDES0, if the device
couldn't grab ownership of the TxRing buffer entry?

In tulip_interrupt():
if (csr5 & (TxNoBuf | TxDied | TxIntr)) {
	...
	if (status & 0x8000) {
		/* There was an major error, log it. */
		...
	} else {
		...
	}
	/* Free the original skb. */
	dev_free_skb(tp->tx_skbuff[entry]);
	tp->tx_skbuff[entry] = 0;
}

I would have thought that if (csr5 & TxNoBuf), then you just want to ACK
the interrupt, and go on, so that once the driver gives up ownership of
TDES0 for the TxRing buffer entry that the device complained about, the
device can transmit that TxRing buffer entry.

Ofcourse, how the device got into such a state that it thought it had to
transmit that TxRing buffer entry, when the driver still hadn't given up
"ownership" of the entry, is another mystery.

- Bhavesh
-- 
Bhavesh P. Davda
Avaya Inc
Room B3-B16                     E-mail : bhavesh@avaya.com
1300 West 120th Avenue          Phone  : (303) 538-4438
Westminster, CO 80234           Fax    : (303) 538-3155