Again, for the archives, this problem is sadly still here. Although
it appears to happen a little less frequently with the driver from
HEAD. It seems it might be some issue specific to power savings, as
LINUX users seem to have the same issues
Just for the archives, the version of
http://lists.freebsd.org/pipermail/svn-src-head/2010-November/022058.htmlhttp://lists.freebsd.org/pipermail/svn-src-head/2010-November/022058.html
fixes this particular problem on this particular version of the em
nic for me on RELENG_8. The motherboard
Hi Jack,
Two quick notes about the new driver.
On the server that was having nic lockups, so far so good. Saturday
AM, the box would take a lot of level0 dumps as well as do about
70Mb/s of outbound rsync traffic. By now, the nic would have wedged
at least once So far so good!
At 08:00 PM 9/26/2010, Jack Vogel wrote:
The system I've had stress tests running on has 82574 LOMs, so I hope it
will solve the problem, will see tomorrow morning at how things have held
up...
I pulled a copy of sys/dev/e1000 from HEAD and copied onto my
RELENG_8 box. I had another nic lock
At 06:36 PM 9/24/2010, Jack Vogel wrote:
There is a new revision of the em driver coming next week, its going thru some
stress pounding over the weekend, if no issues show up I'll put it into HEAD.
Yongari's changes in TX context handling which effects checksum and tso
are added. I've also
The NIC has 5 MSIX vectors and can have 2 queues, I have been trying to
release code with both queues active, but its been unstable, I finally
concluded
its not worth the aggrevation :)
Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
not sure whats broken from what you
At 06:19 PM 9/26/2010, Jack Vogel wrote:
Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
not sure whats broken from what you show here. I will try to get the new
driver out shortly for you to try.
With this particular NIC, it will wedge under high load. I tried 2
The system I've had stress tests running on has 82574 LOMs, so I hope it
will solve the problem, will see tomorrow morning at how things have held
up...
Jack
On Sun, Sep 26, 2010 at 4:43 PM, Mike Tancsa m...@sentex.net wrote:
At 06:19 PM 9/26/2010, Jack Vogel wrote:
Your em1 is using MSI
There is a new revision of the em driver coming next week, its going thru
some
stress pounding over the weekend, if no issues show up I'll put it into
HEAD.
Yongari's changes in TX context handling which effects checksum and tso
are added. I've also decided that multiple queues in 82574 just are
Hi Jack,
Any plans to commit the patch below ? I have been running it
on a number of boxes and it works as expected with no side effects.
---Mike
At 04:00 PM 8/17/2010, Pyun YongHyeon wrote:
On Tue, Aug 17, 2010 at 03:55:12PM -0400, Mike Tancsa wrote:
At 02:52 PM 8/17/2010,
On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
Hi Jack,
FYI, I am still seeing this same problem on RELENG_8 (code
as of today). Unfortunately I cant try Pyun's patch since the
underlying code has changed since then.
e...@pci0:3:0:0: class=0x02 card=0x34ec8086
Hmmm, interesting, I'll have to have some testing done, maybe for the 574 it
should automagically disable CSUM?
Jack
On Tue, Aug 17, 2010 at 11:52 AM, Pyun YongHyeon pyu...@gmail.com wrote:
On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
Hi Jack,
FYI, I am still
On Tue, Aug 17, 2010 at 11:52:08AM -0700, Pyun YongHyeon wrote:
On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
Hi Jack,
FYI, I am still seeing this same problem on RELENG_8 (code
as of today). Unfortunately I cant try Pyun's patch since the
underlying code has
I believe the requirement of a context descriptor for most frames in the igb
driver
is just the way the hardware works, I've looked over the Linux driver again
and it
looks like they require the same. I don't believe its a big deal, just the
added
descriptor for the frame.
Jack
On Tue, Aug 17,
On Tue, Aug 17, 2010 at 12:05:56PM -0700, Jack Vogel wrote:
Hmmm, interesting, I'll have to have some testing done, maybe for the 574 it
should automagically disable CSUM?
I don't have 82574 controller to test but it may depend on how
pipelined Tx data DMA works. If 82574 can still pipeline
Well we do of course, i'll have my test engineer try it both ways and see
what
looks better. Let you know...
Jack
On Tue, Aug 17, 2010 at 12:35 PM, Pyun YongHyeon pyu...@gmail.com wrote:
On Tue, Aug 17, 2010 at 12:05:56PM -0700, Jack Vogel wrote:
Hmmm, interesting, I'll have to have some
On Tue, Aug 17, 2010 at 12:34:31PM -0700, Jack Vogel wrote:
I believe the requirement of a context descriptor for most frames in the igb
driver
is just the way the hardware works, I've looked over the Linux driver again
and it
looks like they require the same. I don't believe its a big deal,
The guy who worries about the Linux driver's performance is in my team, and
he's
a very good engineer, and we're talking about the hardware's DMA, so its not
an OS issue, thus I'm not saying I'm sure, but I'm dubious about this, at
least
when we're talking about igb. But hey, I'm willing to be
At 02:52 PM 8/17/2010, Pyun YongHyeon wrote:
Here is updated patch for HEAD and stable/8.
http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
It seems to work as expected under my limited environments. If
Thanks! The patch applies cleanly and all works as expected now! I am
no
On Tue, Aug 17, 2010 at 03:55:12PM -0400, Mike Tancsa wrote:
At 02:52 PM 8/17/2010, Pyun YongHyeon wrote:
Here is updated patch for HEAD and stable/8.
http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
It seems to work as expected under my limited environments. If
Thanks! The
Hi Jack,
FYI, I am still seeing this same problem on RELENG_8 (code
as of today). Unfortunately I cant try Pyun's patch since the
underlying code has changed since then.
e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086
rev=0x00 hdr=0x00
vendor = 'Intel
Hi Jack,
Just a followup to the email below. I now saw what appears
to be the same problem on RELENG_8, but on a different nic and with
VLANs. So not sure if this is a general em problem, a problem
specific to some em NICs, or a TSO problem in general. The issue
seemed to be
I got the email, there are server outages around here today and people
leaving
for a long weekend, so not much getting done. I'll take some time and look
into
this after the weekend, ok?
Jack
On Fri, Jul 2, 2010 at 10:39 AM, Mike Tancsa m...@sentex.net wrote:
Hi Jack,
Just a followup
On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
Hi Jack,
Just a followup to the email below. I now saw what appears
to be the same problem on RELENG_8, but on a different nic and with
VLANs. So not sure if this is a general em problem, a problem
specific to some em
At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
http://www.freebsd.org/cgi/query-pr.cgi?pr=141843
I'm not sure whether you're seeing the same issue though.
I didn't have chance to try latest em(4) on stable/7.
Wow, what a detailed PR! That sure sounds like the issue I am seeing
as well. I am
25 matches
Mail list logo
