Matthias Hentges wrote:
Am Freitag, den 01.09.2006, 22:41 -0400 schrieb shogunx:
Has this not been fixed in the 2.6.18 git?
Good question. I'll try 2.6.18-rc4-mm3 and report back.
I am having no problems with 2.6.18-rc5, which I just built and tested.
The NIC is up and running for about 9hrs now w/ -rc4-mm3, thanks for the
heads up!
My theory still unproven, is that there is a problem with transmit flow
control and alignment. I have
no direct relation to Marvell, and they tell me nothing about the
hardware bugs. But it took two
weeks to find a problem where receive flow control was busted when the
receive buffer was not
aligned on 8 byte boundary. The receiver would stop and not resume. To
workaround, the driver
ensures alignment of receive buffers. The only clue was that the receive
DMA FIFO always
had a partial count left in it.
There may well be a similar problem on transmit; since driver has no
control over transmit buffer
alignment, fixing it would require copying most transmit data, or a hack
all the way up in protocols.
Maybe if the driver lied about the hard header length, it could fool the
protocols.
Probably better just to always negotiate no transmit flow control.
--
VGER BF report: H 0.232987
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
