On 05/11/15 10:23, Stuart Henderson wrote:
On 2015/05/09 17:10, Brad Smith wrote:
On Sun, May 03, 2015 at 12:16:21PM +0200, Mark Kettenis wrote:
Date: Sun, 3 May 2015 02:38:12 -0700
From: Bryan Linton <b...@shoshoni.info>
The key difference is the following two lines. The first wedged,
the second unwedged:
em0 2048 2 2 256 2
em0 2048 4 2 256 4
It seems like the em0 line always shows the latter line, so I'm hoping
this indicates something useful.
I believe em(4) needs at least 4 descriptors on its rx ring. If you
fall below that limit (which can happen if the CPU is busy), the card
stops receiving packets. I believe em(4) is supposed to get an
interrupt for dropped packets and will attempt to refill the ring if
it receives such an interrupt. It seems that mechanism isn't working
for your card. Perhaps the usual workaround of using a timeout should
be added to the driver.
Good hint, rev 1.280 broke the chips not capable of jumbo frames. Correcting
the low watermark for the affected chips resolves the issue Christian and
Bryan were experiencing.
If all em(4) need 4 descriptors, would it make more sense to just enforce
lwm >= 4? Both from a self-documentation point of view, and to avoid a
potential trap if some nic was discovered to support <2k baby jumbos
i.e. give the same result for the if_hardmtu/MCLBYTES sum.
That is the whole point of the diff.
That doesn't involve chaining so it doesn't make any sense.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
