Rick Macklem
2014-Sep-13 21:06 UTC
svn commit: r267935 - head/sys/dev/e1000 (with work around?)
Mike Tansca wrote:> On 9/12/2014 7:33 PM, Rick Macklem wrote: > > I wrote: > >> The patches are in 10.1. I thought his report said 10.0 in the message. > >> > >> If Mike is running a recent stable/10 or releng/10.1, then it has been > >> patched for this and NFS should work with TSO enabled. If it doesn't, > >> then something else is broken. > > Oops, I looked and I see Mike was testing r270560 (which would have both > > the patches). I don't have an explanation why TSO and 64K rsize, wsize > > would cause a hang, but does appear it will exist in 10.1 unless it > > gets resolved. > > > > Mike, one difference is that, even with the patches the driver will be > > copying the transmit mbuf list via m_defrag() to 32 MCLBYTE clusters > > when using 64K rsize, wsize. > > If you can reproduce the hang, you might want to look at how many mbuf > > clusters are allocated. If you've hit the limit, then I think that > > would explain it. > > I have been running the test for a few hrs now and no lockups of the > nic, so doing the nfs mount with -orsize=32768,wsize=32768 certainly? seems to work around the lockup. How do I check the mbuf clusters ? Btw, in the past when reducing the rsize,wsize has fixed a problem that isn't fixed by disabling TSO, it has been a problem w.r.t. receiving a burst of ethernet packets. I believe this may be a problem with either the receive ring size or interrupt latency (testers have reported cases where changing the way the device driver uses interrupts have fixed the problem so that it worked with 64K rsize, wsize). I have no familiarity with this hardware/driver so I can't suggest anything specific to try except maybe how interrupts are handled, if the driver has a sysctl for that. rick
Mike Tancsa
2014-Sep-14 00:17 UTC
svn commit: r267935 - head/sys/dev/e1000 (with work around?)
Hi Eric, Any chance you can look at this em driver bug in Jack's absence ? ---Mike On 9/13/2014 5:06 PM, Rick Macklem wrote:> Mike Tansca wrote: >> On 9/12/2014 7:33 PM, Rick Macklem wrote: >>> I wrote: >>>> The patches are in 10.1. I thought his report said 10.0 in the message. >>>> >>>> If Mike is running a recent stable/10 or releng/10.1, then it has been >>>> patched for this and NFS should work with TSO enabled. If it doesn't, >>>> then something else is broken. >>> Oops, I looked and I see Mike was testing r270560 (which would have both >>> the patches). I don't have an explanation why TSO and 64K rsize, wsize >>> would cause a hang, but does appear it will exist in 10.1 unless it >>> gets resolved. >>> >>> Mike, one difference is that, even with the patches the driver will be >>> copying the transmit mbuf list via m_defrag() to 32 MCLBYTE clusters >>> when using 64K rsize, wsize. >>> If you can reproduce the hang, you might want to look at how many mbuf >>> clusters are allocated. If you've hit the limit, then I think that >>> would explain it. >> >> I have been running the test for a few hrs now and no lockups of the >> nic, so doing the nfs mount with -orsize=32768,wsize=32768 certainly > ? seems to work around the lockup. How do I check the mbuf clusters ? > > Btw, in the past when reducing the rsize,wsize has fixed a problem that > isn't fixed by disabling TSO, it has been a problem w.r.t. receiving a > burst of ethernet packets. > I believe this may be a problem with either the receive ring size or > interrupt latency (testers have reported cases where changing the way > the device driver uses interrupts have fixed the problem so that it > worked with 64K rsize, wsize). > > I have no familiarity with this hardware/driver so I can't suggest > anything specific to try except maybe how interrupts are handled, > if the driver has a sysctl for that. > > rick > > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" > >-- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/