Stefan,
I am having a long weekend and am supposed to be doing
something other than this :) However, when I get back in the office
on Tuesday I will see if I can repro this, so just to make sure, tell
me what the PCI ID of the two cards are when it fails with Intel
on both sides, that
On 5/27/07, Stefan Lambrev [EMAIL PROTECTED] wrote:
Hi Jack,
Jack Vogel wrote:
Stefan,
I am having a long weekend and am supposed to be doing
something other than this :) However, when I get back in the office
on Tuesday I will see if I can repro this, so just to make sure, tell
On 5/27/07, Jack Vogel [EMAIL PROTECTED] wrote:
On 5/27/07, Stefan Lambrev [EMAIL PROTECTED] wrote:
Hi Jack,
Jack Vogel wrote:
Stefan,
I am having a long weekend and am supposed to be doing
something other than this :) However, when I get back in the office
on Tuesday I
On 5/29/07, Jack Vogel [EMAIL PROTECTED] wrote:
On 5/27/07, Jack Vogel [EMAIL PROTECTED] wrote:
On 5/27/07, Stefan Lambrev [EMAIL PROTECTED] wrote:
Hi Jack,
Jack Vogel wrote:
Stefan,
I am having a long weekend and am supposed to be doing
something other than
Does any driver do this now? And if a driver were to coalesce
packets and send something up the stack that violates mss
will it barf?
Jack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe,
On 5/30/07, Julian Elischer [EMAIL PROTECTED] wrote:
Andrew Thompson wrote:
On Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:
Does any driver do this now? And if a driver were to coalesce
packets and send something up the stack that violates mss
will it barf?
It would barf
I wanted to let everyone know that I will soon have a
new 10G driver to add to the tree. It is a PCI Express
MSI/X adapter, I would like to call this driver 'ix' rather
than follow Linux who are calling it 'ixgbe'. It is not
backwardly compatible with ixgb. Any objections
to the name? It would
On 5/31/07, Stefan Lambrev [EMAIL PROTECTED] wrote:
Thank you very much for the help Jack :))
Unfortunately I'm off next four days and probably will not be able to
test it before Monday.
Btw any chances to have patch for releng_6 or the difference in the
drivers is too big ? :)
Welcome, turns
On 5/31/07, Wilkinson, Alex [EMAIL PROTECTED] wrote:
0n Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:
Does any driver do this now? And if a driver were to coalesce
packets and send something up the stack that violates mss
will it barf?
erm, what is meant
On 5/31/07, Christian Brueffer [EMAIL PROTECTED] wrote:
On Wed, May 30, 2007 at 05:51:35PM -0700, Jack Vogel wrote:
I wanted to let everyone know that I will soon have a
new 10G driver to add to the tree. It is a PCI Express
MSI/X adapter, I would like to call this driver 'ix' rather
than
I have a version of code ready to MFC, the big difference with CURRENT
is that TSO is #ifdef'd off until Andre is able to get that back.
I wanted a chance for any concerns to be aired before I did it, issues
that anyone has had with the driver in CURRENT?
Regards,
Jack
On 6/6/07, Jack Vogel [EMAIL PROTECTED] wrote:
I have a version of code ready to MFC, the big difference with CURRENT
is that TSO is #ifdef'd off until Andre is able to get that back.
I wanted a chance for any concerns to be aired before I did it, issues
that anyone has had with the driver
On 6/22/07, Andrew Snow [EMAIL PROTECTED] wrote:
Hi, I have a problem with Pro/1000 cards in Freebsd, as follows:
System: Supermicro 1RU server
CPU: Intel(R) Core(TM)2 CPU 4400 @ 2.00GHz
OS: FreeBSD 6.2-STABLE (Tue May 29 03:19:28 EST 2007)
amd64 (64 bit mode, SMP kernel)
On 6/24/07, Andrew Snow [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
After medium-heavy traffic, the NIC locks up completely and no traffic
passes for a long time, perhaps longer than half an hour.
Then, it recovers and prints this to syslog:
em0: watchdog timeout -- resetting
em0: link
The 82571 device has been supported for a long time, the trick
comes when you have a gang of them how the thing is all wired
up, we have had issues even with our quad port adapters and
some vendor BIOS's. This is a custom so I'm only going to be
able to guess that its interrupts.
You say no
(missed packets counter incrementing)
- frame transmission is not possible (driver watchdog fires)
bug exists also on 6.2-RELENG - em(4) driver version 6.2.9
bug does *not* exist on 6.1-RELENG - em(4) driver version 3.2.18
jack vogel told me that the i82571 can be tricky when having a bunch
of them
On 7/19/07, Andre Oppermann [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
While testing out the ixgbe driver we've observed this failure in the stack
code, here is the info:
The test engineer is using iperf, typically with 16 threads. If the
driver is using
either legacy or MSI interrupts we
;
int i;
+
+ return;
/* Pointer to the receive descriptor being examined. */
struct em_rx_desc *current_desc;
On Tue, Jul 17, 2007 at 09:17:36AM -0700, Jack Vogel wrote:
As an experiment, search in if_em.c for 'msix' look at the logic
in this
logic, and all versions have picked up that error since.
There will be changes coming for both 6 and 7.
Jack
On 7/24/07, Jack Vogel [EMAIL PROTECTED] wrote:
Hmmm, this looks like a bug, I will look more closely today.
Sorry I have not been able to be more active with your problem,
but things
The next driver I that I release via Intel channels is going to
merge the code for 6 and 7. I was thinking that I could check that
into the tip and it would make the most current version buildable
on either RELEASE, was wondering if that is looked upon favorably
or not? I have code ready to do
I have some behavior I don't understand, perhaps someone can enlighten me.
There is a difference in behavior between the em driver and ixgbe, but I can
not figure out what it is, here is the behavior.
With em driver, you can give the interface an ipv6 address, and set mtu
to 9000, then when you
On 8/2/07, Jack Vogel [EMAIL PROTECTED] wrote:
I have some behavior I don't understand, perhaps someone can enlighten me.
There is a difference in behavior between the em driver and ixgbe, but I can
not figure out what it is, here is the behavior.
With em driver, you can give the interface
I was just working on a bug in the Oplin driver that had me look
a bit more at VLAN code than I had previously.
FreeBSD has apparently never used the hardware vlan filtering
that our hardware can do, is there a systemic reason for this,
or has the code lagged in its use of the system?
I at least
On 8/31/07, Tom Judge [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
I was just working on a bug in the Oplin driver that had me look
a bit more at VLAN code than I had previously.
FreeBSD has apparently never used the hardware vlan filtering
that our hardware can do, is there a systemic
I had an idea, I was debugging a problem on my new 10G driver a week back,
and found I had the hardware vlan filter enabled by accident, this led me to
wonder about supporting this hardware feature in the driver...
I have done some experimentation, and find that when the vlan device is
On 9/5/07, Scott Long [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
I had an idea, I was debugging a problem on my new 10G driver a week back,
and found I had the hardware vlan filter enabled by accident, this led me to
wonder about supporting this hardware feature in the driver...
I have
Our newest E1000 nic, the 82575, and the Oplin 10G hardware are capable of
multiple queues both on the receive and the send side. On the receive end for
the Oplin driver the queues actually help distribute interrupts and improve
performance without any special support in the stack.
I have been
On 9/23/07, Kip Macy [EMAIL PROTECTED] wrote:
On 9/23/07, Darren Reed [EMAIL PROTECTED] wrote:
Kip Macy wrote:
My ethng branch supports multiple rx and tx queues.
-Kip
What are your plans for how we use/manage/interact with the mutiple
rx/tx queues?
The rx hardware queue is
This is not an issue in my current driver base, I am having our test
group do some checking since I am not aware of the specific change
that fixed this, I am not sure if the CURRENT code has the problem
or not, also being tested.
Jack
On 9/26/07, Jon Otterholm [EMAIL PROTECTED] wrote:
Hi.
I
multiqueue/rss and the lock
splitting that is in that driver, and putting them back into
the Gig driver, but that should go into CURRENT first.
My recomendation is to move your work to CURRENT.
Regards,
Jack
On 10/2/07, Vladimir Ivanov [EMAIL PROTECTED] wrote:
Hi,
Jack Vogel wrote:
On 8/1/07
On 10/2/07, Vladimir Ivanov [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
I'm sorry I have not been able to get to this yet, but putting
food on the table comes first so the FreeBSD work that
Intel pays me for has to come first. Also your driver work
is based on a version that is too old
I am adding support into the em driver for PTP, what I would prefer doing is
to add interface capability support: IFCAP_TSYNC or something like that.
The driver will then enable/disable the feature.
Are there other vendor's hardware providing this support such that a
net/if.h capability would be
On 10/3/07, Poul-Henning Kamp [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Jack Vogel writes
:
I am adding support into the em driver for PTP, what I would prefer doing is
to add interface capability support: IFCAP_TSYNC or something like that.
The driver will then enable/disable
On 10/3/07, Poul-Henning Kamp [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Jack Vogel writes
:
When I talked to HP's licensing department, there were a $1k licensefee
for anything IEEE1588 related and their message was that even if
the FreeBSD foundation got such a license
Mike,
This is a patch against my 6.6.6 driver that adds a new value to the
debug sysctl, you would give the command 'sysctl dev.em.0.debug=2'
and it will dump out the first 32 16-bit words of the prom.
Mike, go to e1000.sourceforge.net/wiki and look under issues, you
will find one talking
I realize now that I need to explain doing this.
I just did a checkin that will allow the latest em code
to work on 6.2, BUT, it will NOT work integrated into
the RELEASE kernel tree, and I am not going to
support that :) To do that would mean changing
conf/files and so forth.
Therefore, if you
On 10/12/07, Jack Vogel [EMAIL PROTECTED] wrote:
You should a couple different adapters below, are you saying that
its just one of them, can you try different ones to see if its specific.
Also, would you be able to test my latest driver to see if it still
happens?
Cheers,
Jack
LOL
I have an important decision to make and I thought rather than just make
it and spring it on you I'd present the issues and see what opinions were.
Our newer hardware uses new features that, more and more, require
parallel code paths in the driver. For instance, the 82575 (Zoar) uses
what are
On 10/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
At Mon, 29 Oct 2007 10:45:17 -0700,
Jack Vogel wrote:
I have an important decision to make and I thought rather than just make
it and spring it on you I'd present the issues and see what opinions were.
Our newer hardware uses new
This morning I had an idea about what the source of the watchdog
problem is. Also, we have repro'd at least one type of watchdog
inhouse.
One question, is this problem only happening for those running
STABLE with the 6.6.6 merged driver?
We found the problem does not seem to happen on 7.0.
Things just keep getting stranger... its no wonder I didn't see this...
I had been trying to repro the watchdog on a machine in my cube at work
without success, but in the test Lab they were successful. I scratched my
head for a while wondering why...
But then I realized I had the Sept snapshot
On 10/31/07, Peter Jeremy [EMAIL PROTECTED] wrote:
On Wed, Oct 31, 2007 at 01:16:39AM -0700, Jeremy Chadwick wrote:
For what it's worth, I agree with Scott. I'd rather see a new and
separate driver (presumably igb(4)) than a hacked up em(4) driver
trying to handle tons of IC revisions. A
I have found that the FAST interrupt handling is implicated
in the watchdog resets that I have seen.
What I plan to do is revert to the way 6.2 had things, meaning
that FAST interrupts will be available but defined off by default.
I wanted to know if anyone has an issue with this. And more
, is related to it.
Regards,
Jack
On 10/31/07, Vladimir Ivanov [EMAIL PROTECTED] wrote:
Scott Long wrote:
Jack Vogel wrote:
I have found that the FAST interrupt handling is implicated
in the watchdog resets that I have seen.
It's not true. I have seen watchdogs much earlier then FASTINTR
Eh, what I see is if_em.h and if_em.c, does the version
that came thru not have both??
Jack
On 11/1/07, Pete French [EMAIL PROTECTED] wrote:
You just replace the two files in your STABLE tree. Its big
enough that this seemed easier than a patch.
Did you miss a file ? I nly see a new
This is a substantial change to the EM driver that I would
appreciate some testing and feedback on.
You just replace the two files in your STABLE tree. Its big
enough that this seemed easier than a patch.
Whats in this:
A change Mike Silbersack came up with, it makes the
watchdog period twice
Although I see it at least one person claims the message
came thru with only the header file, so I am going
to send if_em.c thru again.
Jack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe,
So at this point I'm unclear, with my reposting of if_em.c last
night has everyone seen both parts or do I have to try something
else?
Jack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe,
It seems that some mailer is stripping source attachments,
so I'm sending this in an archive.
NOTE: the attachment is a bz2, rename to extract it.
Jack
test-em
Description: Binary data
___
freebsd-net@freebsd.org mailing list
On Nov 14, 2007 5:01 PM, Wilkinson, Alex
[EMAIL PROTECTED] wrote:
Hi all,
Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon
?
LOL, I did a driver for the first version of I/OAT more than a year
ago, submitted
it and interest was half hearted.
The driver needs updating
On Nov 14, 2007 5:52 PM, Julian Elischer [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
On Nov 14, 2007 5:01 PM, Wilkinson, Alex
[EMAIL PROTECTED] wrote:
Hi all,
Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon
?
LOL, I did a driver for the first version of I
On Nov 15, 2007 9:52 AM, Scott Ullrich [EMAIL PROTECTED] wrote:
On 11/15/07, Doug Ambrisko [EMAIL PROTECTED] wrote:
Hmm, I forgot about the 2970 which are AMD based. Can you check the
BIOS to see if there is an option to turn it on? I think this is an
Intel feature. AMD might have
On Nov 15, 2007 4:04 PM, Andre Oppermann [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
On Nov 14, 2007 5:01 PM, Wilkinson, Alex
[EMAIL PROTECTED] wrote:
Hi all,
Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon
?
LOL, I did a driver for the first version of I
On Nov 15, 2007 4:25 PM, Jack Vogel [EMAIL PROTECTED] wrote:
On Nov 15, 2007 4:22 PM, Andre Oppermann [EMAIL PROTECTED] wrote:
Scott Ullrich wrote:
On 11/15/07, Doug Ambrisko [EMAIL PROTECTED] wrote:
Hmm, I forgot about the 2970 which are AMD based. Can you check the
BIOS to see
On Nov 15, 2007 4:22 PM, Andre Oppermann [EMAIL PROTECTED] wrote:
Scott Ullrich wrote:
On 11/15/07, Doug Ambrisko [EMAIL PROTECTED] wrote:
Hmm, I forgot about the 2970 which are AMD based. Can you check the
BIOS to see if there is an option to turn it on? I think this is an
Intel
On Dec 25, 2007 4:21 AM, Jordi Espasa Clofent [EMAIL PROTECTED] wrote:
Hi all,
I know how to monitoring the NIC IRQ's consume, with tools as vmstat (-i
flag), systat (-vm 1) or netstat (-m, -i), but I don't know how to
determine the maximum interrupts that these NICs can give.
I've several
On Dec 26, 2007 8:10 AM, Nash Nipples [EMAIL PROTECTED] wrote:
Dear Jordi,
In theory, on a Gigabit link you get 1 000 000 000 bits * second.
By default you have the MTU set to 1500 bytes which makes ~12 000 bits.
1 000 000 000 / 12 000 = ~ 83 333 packets per second.
83 333 packets per second
On Jan 6, 2008 5:47 AM, Robert Watson [EMAIL PROTECTED] wrote:
...
My proposal, and this is really a proposal to drive discussion as much as a
proposal for a policy, is that the internal TCP data structures exported via
the TOE interfaces and accessed by TOE device drivers *not* be considered
Hi Andrew,
Someone else has already reported this to me and in fact he is testing
a shared code
fix to see if it resolves it. I will be updating the driver if it does.
Jack
On Jan 20, 2008 12:32 AM, Andrew Snow [EMAIL PROTECTED] wrote:
Hi,
I have a recent Supermicro board (Super X7DWT
On Jan 22, 2008 9:40 AM, Patrick Oeschger [EMAIL PROTECTED] wrote:
maybe i found two issues which are em(4) related...
i tested the 6.3-RELEASE on a appliance which has two on-board SFP slots
chipset: i82571eb (serdes with tbi-interface)
[EMAIL PROTECTED]:0:0: class=0x02 card=0x10761903
On Jan 26, 2008 7:21 AM, Steven Hartland [EMAIL PROTECTED] wrote:
Also seeing this here, if we can help debug this please shout.
Regards
Steve
Kris was seeing this problem, and he has been testing with our latest
shared code which had what I thought was a fix for the problem.
It
The fix to this problem is in the new shared code that got checked into
CURRENT on Friday. I will be MFCing the changes eventually but
if you want to test now you'll need to go with CURRENT.
On Mon, Mar 3, 2008 at 11:00 AM, Oznon [EMAIL PROTECTED] wrote:
I am experiencing the exact same issue
I should be able to get the shared code part into 6.3 once problems
are wrung out.
Jack
On Fri, Mar 7, 2008 at 8:17 AM, George V. Neville-Neil
[EMAIL PROTECTED] wrote:
At Mon, 3 Mar 2008 13:43:45 -0800,
Jack Vogel wrote:
The fix to this problem is in the new shared code that got checked
On Wed, Apr 30, 2008 at 7:39 PM, Andrew Snow [EMAIL PROTECTED] wrote:
I bought a new PCIe NIC a few months ago and was working with Jack Vogel
on getting it to work but he was busy, then I got busy and things
stalled.
Does anyone else have any idea what might be wrong here? The card
Try the driver in HEAD, it might even just build and work on 7, if
not let me know.
Jack
On Wed, Apr 30, 2008 at 7:11 PM, [EMAIL PROTECTED] wrote:
(Please CC as I'm not subscribed to net@)
I bought a new PCIe NIC a few months ago and was working with Jack Vogel
on getting it to work
On Wed, Apr 30, 2008 at 9:49 PM, [EMAIL PROTECTED] wrote:
On Thu, May 1, 2008 00:09, Jack Vogel wrote:
I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful
to me, and to everyone, if as many get out and test that driver as
possible.
Can we just csup -i src/sys/dev
On Thu, May 1, 2008 at 1:17 AM, [EMAIL PROTECTED] wrote:
On Thu, May 1, 2008 00:55, Jack Vogel wrote:
On Wed, Apr 30, 2008 at 9:49 PM, [EMAIL PROTECTED] wrote:
On Thu, May 1, 2008 00:09, Jack Vogel wrote:
I am hoping to MFC the em/igb drivers in HEAD soon, it would be
helpful
On Wed, Apr 30, 2008 at 10:10 PM, Andrew Snow [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
You won't know if its still a problem if you don't take them off the
shelf and try it :)
Good point. I wasn't trying to point the finger at you, I think you are
doing a fantastic job overall
I got the new drivers in Friday afternoon for those that don't see CVS
messages.
The igb driver is for 82575 and 82576 adapters, it has multiqueue support and
MSIX, there will be more server type enhancements in that driver as I get the
time.
The em driver now will be client oriented, the latest
On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov [EMAIL PROTECTED] wrote:
On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote:
I got the new drivers in Friday afternoon for those that don't see CVS
messages.
The igb driver is for 82575 and 82576 adapters, it has multiqueue
On Sat, May 3, 2008 at 10:24 AM, Scott Long [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov [EMAIL PROTECTED]
wrote:
On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote:
I got the new drivers in Friday afternoon for those
I wanted to introduce myself to the list. I am now the primary contact
at Intel for our drivers. There was some earlier email I saw in the archive
about 82571/2 support, and I want to confirm that that code is coming.
I hope to be adding some new feature support as well. I have been
eyeing TSO
On 12/13/05, Kris Kennaway [EMAIL PROTECTED] wrote:
On Tue, Dec 13, 2005 at 01:37:31PM -0800, Doug Barton wrote:
Mihail Balikov wrote:
Hello,
In FreeBSD 4.x in ip_output.c in part for ipfw local forwarding there's
typo
that will cause kernel panic:
If you haven't already,
On 2/20/06, Chris Howells [EMAIL PROTECTED] wrote:
hmm, well these arent anything bleeding edge, so isnt any hardware
issues that occur to me
OK. I have reported this problem in the past and a few people like Gleb
Smirnoff and Christian Peron have helped in diagnosing and providing
On 2/20/06, Chris Howells [EMAIL PROTECTED] wrote:
After about 9 months of messing around with two servers with em(4) gigabit
cards and having continual problems with them randomly stopping working,
particularly under reasonably heavy load, I think I have finally come to
the conclusion that
On 3/14/06, Matt [EMAIL PROTECTED] wrote:
Hello,
I've tried to be fairly thorough in researching the problem before posting
to the list, however, there doesn't seem to be a great multitude of
information out there regarding IPMI configuration on FreeBSD.
Here's the setup: I have a
On 3/15/06, Julian Elischer [EMAIL PROTECTED] wrote:
Working with intel (TM) motherboards using the Intel Gb chips,
and talking to the intel reps last year (for my previous employer) I was
led to believe that
these chips supported IPMI by giving the BMC a back door into the same
NIC that the
On 3/15/06, Jack Vogel [EMAIL PROTECTED] wrote:
On 3/15/06, Julian Elischer [EMAIL PROTECTED] wrote:
Working with intel (TM) motherboards using the Intel Gb chips,
and talking to the intel reps last year (for my previous employer) I was
led to believe that
these chips supported IPMI
On 3/16/06, Yuriy N. Shkandybin [EMAIL PROTECTED] wrote:
Hello
I have 2 freebsd servers connected by dedicated wire via em interfaces.
systems = 6.1-PRERELEASE #0: Tue Mar 14 11:58:23 MSK 2006
1st)
man em says
MTU size for Jumbo Frames is 16114 and i'm sure i've setup this on freebsd-5
At the moment I am making Packet Split work for the em driver, but
in a quick look around I cant see how the uipc_jumbo code gets
compiled. I realize its been wedded to the ti driver, but I want to
build and link against the kernel code without that driver.
Anyone who understands all the inner
On 4/6/06, Julian Elischer [EMAIL PROTECTED] wrote:
John-Mark Gurney wrote:
Jack Vogel wrote this message on Thu, Apr 06, 2006 at 16:48 -0700:
At the moment I am making Packet Split work for the em driver, but
in a quick look around I cant see how the uipc_jumbo code gets
compiled. I
Our internal test group has run into a problem, I have witnessed it,
but not had time to pursue it. I was wondering if this has been
previously observed, and if anyone has any thoughts.
What they do is run a script that runs 100 passes at loading,
bringing up and configuring the driver, then
On 7/21/06, Dmitry Pryanishnikov [EMAIL PROTECTED] wrote:
Hello!
On Thu, 20 Jul 2006, Jack Vogel wrote:
We, myself and Prafulla Deuskar at Intel LAD, have a driver and stack
changes that support Intel's new I/OAT DMA hardware. This is a
DMA engine in the chipset. There is potential to use
On 7/21/06, Dmitry Pryanishnikov [EMAIL PROTECTED] wrote:
Hello!
On Thu, 20 Jul 2006, Jack Vogel wrote:
We, myself and Prafulla Deuskar at Intel LAD, have a driver and stack
changes that support Intel's new I/OAT DMA hardware. This is a
DMA engine in the chipset. There is potential to use
On 8/11/06, Gleb Smirnoff [EMAIL PROTECTED] wrote:
Daniel,
On Fri, Aug 11, 2006 at 01:42:32PM +0200, Daniel Ryslink wrote:
D We have started to use the em driver only recently, after the upgrade to
D gigabit connectivity (100 MBit NICs from Intel used the fxp driver).
D
D As for the frequency
On 8/11/06, Landon Fuller [EMAIL PROTECTED] wrote:
We saw this issue here on SMP systems running 6.1; I've been meaning
to set up a reproduction case in the lab and dig into the issue further.
Disabling the mpsafe network stack (debug.mpsafenet=0) is our
temporary work-around; rwatson mentioned
We are making our development driver for the I/OAT engine available for
download, experimentation, and comment available at:
http://sourceforge.net/project/showfiles.php?group_id=42302package_id=202220
This includes a core driver for the dma hardware and a set of stack changes
to allow
On 8/30/06, Andrew Gallatin [EMAIL PROTECTED] wrote:
Excellent! Can you share some of these results? I would love to try
it, but I don't have FreeBSD on any machine with I/OAT hardware.
Prafulla had the results nudges Prafulla
I've taken a very quick look at it. Maybe I'm just being
There have been a couple requests for more info about I/OAT in general.
While I think the hardware specs are still only available with NDA, there
are some public papers and descriptions at the URL:
http://www.intel.com/technology/ioacceleration/
Cheers,
Jack
On 8/30/06, Danny Braniss [EMAIL PROTECTED] wrote:
ever since 6.1 I've seen fluctuations in the performance of
the em (Intel(R) PRO/1000 Gigabit Ethernet).
motherboard OBN (On Board NIC)
--
1- Intel
On 8/31/06, Rob Watt [EMAIL PROTECTED] wrote:
After poking around in various group/pr postings the most similar problem
that we found was PR #72970.
http://www.freebsd.org/cgi/query-pr.cgi?pr=72970
Does it seem that we are encountering that bug? Is that bug fixed in
6.1-RELEASE, or is there
On 8/31/06, Joe Holden [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
On 8/31/06, Rob Watt [EMAIL PROTECTED] wrote:
After poking around in various group/pr postings the most similar problem
that we found was PR #72970.
http://www.freebsd.org/cgi/query-pr.cgi?pr=72970
Does it seem that we
On 9/1/06, Rob Watt [EMAIL PROTECTED] wrote:
On Thu, 31 Aug 2006, Joe Holden wrote:
Sounds like its at least possible this is your problem, worth setting up a
system to test with I would say.
There's also another possibility these days -- we support errata fixes
going
into release
This is a patch for the stack and the em driver to enable TSO
on CURRENT. Previously I had problems getting it to work, but
this is functional.
I should note that CURRENT is being a pain right now, when
I comment out em in the config the kernel panics coming up,
so I had to substitute this code
On 9/2/06, Andre Oppermann [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
This is a patch for the stack and the em driver to enable TSO
on CURRENT. Previously I had problems getting it to work, but
this is functional.
I should note that CURRENT is being a pain right now, when
I comment out em
On 9/2/06, Andre Oppermann [EMAIL PROTECTED] wrote:
I can't comment on the em part but the tcp_output.c stuff looks
very much like a straight port from NetBSD. If we take code from
the other BSDs we have to remark this in the emails we send with
patches and the commit message (otherwise we get
On 9/4/06, Andre Oppermann [EMAIL PROTECTED] wrote:
Robert Watson wrote:
On Fri, 1 Sep 2006, Jack Vogel wrote:
This is a patch for the stack and the em driver to enable TSO on
CURRENT. Previously I had problems getting it to work, but this is
functional.
I should note that CURRENT
On 9/5/06, Prafulla Deuskar [EMAIL PROTECTED] wrote:
Jack Vogel [EMAIL PROTECTED] wrote:
On 9/2/06, Andre Oppermann [EMAIL PROTECTED] wrote:
I can't comment on the em part but the tcp_output.c stuff looks
very much like a straight port from NetBSD. If we take code from
the other BSDs we
On 9/5/06, Andre Oppermann [EMAIL PROTECTED] wrote:
Prafulla Deuskar wrote:
Andre Oppermann [EMAIL PROTECTED] wrote:
Prafulla Deuskar wrote:
Jack Vogel [EMAIL PROTECTED] wrote:
On 9/2/06, Andre Oppermann [EMAIL PROTECTED] wrote:
I can't comment on the em part but the tcp_output.c stuff
On 9/5/06, Andre Oppermann [EMAIL PROTECTED] wrote:
Jack Vogel wrote:
On 9/5/06, Andre Oppermann [EMAIL PROTECTED] wrote:
Prafulla Deuskar wrote:
Your patch looks good and is the way to go.
So after Jack confirms that your patch works with the em driver
would you commit to to -current
401 - 500 of 603 matches
Mail list logo
