;automatically load the (em) module.
>
>On Thu, Jan 31, 2019 at 07:04 Robert Blayzor wrote:
>
>> Reading the release notes, the igb driver has been merged into the Intel
>> em driver so that should be added to custom kernels. No problem.
>>
>> Question is, when the sy
ged into the Intel
> em driver so that should be added to custom kernels. No problem.
>
> Question is, when the system reboots, are the NIC devices going to come
> up with "emX" now or will they remain "igbX" ?
>
> Kind of important to know on remote upgrading a
Reading the release notes, the igb driver has been merged into the Intel
em driver so that should be added to custom kernels. No problem.
Question is, when the system reboots, are the NIC devices going to come
up with "emX" now or will they remain "igbX" ?
Kind of importa
Hi,
just for a short note: I have several servers running FreeBSD 9-STABLE.
However, the test of the latest STABLE revisions (machines received no
OS updates for over a year, no relevant security updates for my case)
brought up stability issues.
After giving traffic (over 2 VLANs) to the machi
Hi,
Switch: HP ProCurve 2910al
The switch does passive LACP
Motherboard: Supermicro X8DTN+-F
NIC: Quad Port Card, i.e. em1:
em1@pci0:6:0:1: class=0x02 card=0x125e15d9 chip=0x105e8086 rev=0x06
hdr=0x00
vendor = 'Intel Corporation'
device = 'HP NC360T PC
On Thu, May 5, 2011 at 4:44 PM, Jack Vogel wrote:
> So, this happens EVERY time after an install of 8.2 ??
>
> Give me details about the hardware please.
Having had more time to experiment, it seems it happens whenever
ifconfig_em0="DHCP" is in rc.conf --- which happens after using the
PC-BSD ins
On Thursday, May 05, 2011 2:11:39 pm Zaphod Beeblebrox wrote:
> The motherboard in question is made by Intel and contains a Xeon 3440
> (4 core x 2 HT per core). 16 Gig of RAM is installed and we are
> installing the 64 bit FreeBSD 8.2 using the PC-BSD installer (to
> install zfs root faster). Th
So, this happens EVERY time after an install of 8.2 ??
Give me details about the hardware please.
Jack
On Thu, May 5, 2011 at 11:11 AM, Zaphod Beeblebrox wrote:
> The motherboard in question is made by Intel and contains a Xeon 3440
> (4 core x 2 HT per core). 16 Gig of RAM is installed and w
The motherboard in question is made by Intel and contains a Xeon 3440
(4 core x 2 HT per core). 16 Gig of RAM is installed and we are
installing the 64 bit FreeBSD 8.2 using the PC-BSD installer (to
install zfs root faster). The motherboard has 4 "igb" ethernet and
one "em" ethernet. The "em" et
w/o packet header
Panic string: sbsndptr: sockbuf 0xff007cca8c20 and mbuf
0xff00490a6400 clashing
In case someone is interested or has an idea - on this machine I have
multiple crashed cores with similarily strange problems all connected
with networking and/or the em driver:
...
It
-- Stanislav Sedov wrote :
On Wed, 5 Aug 2009 00:30:20 -0700 (PDT)
alexpalias-bsdsta...@yaho... mentioned:
>> dev.em.0.rx_processing_limit=300
>> dev.em.1.rx_processing_limit=300
>> dev.em.2.rx_processing_limit=300
>> dev.em.3.rx_processing_limit=300
> This tunables only affects polling mode. D
On Wed, 14 Apr 2010 09:28:33 -0700 Jack Vogel wrote:
> Oh, didn't realize you were running the lem code :) Will make the changes
> shortly,
r206614 works for me. Thanks :-)
> thanks for your debugging efforts.
>
> Jack
--
Mikolaj Golub
___
freebsd-s
Oh, didn't realize you were running the lem code :) Will make the changes
shortly,
thanks for your debugging efforts.
Jack
On Wed, Apr 14, 2010 at 2:29 AM, Mikolaj Golub wrote:
>
> On Sun, 11 Apr 2010 23:40:03 +0300 Mikolaj Golub wrote:
>
> MG> Hi,
>
> MG> Today I have upgraded the kernel in
On Sun, 11 Apr 2010 23:40:03 +0300 Mikolaj Golub wrote:
MG> Hi,
MG> Today I have upgraded the kernel in my VirtualBox (3.1.51.r27187) to the
MG> latest current and have "em0: Watchdog timeout -- resetting" issue. My
MG> previous kernel was for Mar 12.
MG> Tracking the revision where the pr
Hi,
On Thu, 8 Apr 2010 14:52:07 -0500 Brandon Gooch wrote:
> On Thu, Apr 8, 2010 at 2:17 PM, Jack Vogel wrote:
>> Try the code I just checked in, it puts in the CRC stripping, but also
>> tweaks the
>> TX code, this may resolve the watchdogs. Let me know.
>>
>> Cheers,
>>
>> Jack
>>
>
> Yes, thi
On Fri, Apr 9, 2010 at 9:41 AM, Pyun YongHyeon wrote:
> On Fri, Apr 09, 2010 at 09:17:07AM -0400, Mike Tancsa wrote:
> > At 07:07 PM 4/8/2010, Pyun YongHyeon wrote:
> > >On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> > >> Only one device support by em does multiqueue right now, and
On Fri, Apr 09, 2010 at 09:17:07AM -0400, Mike Tancsa wrote:
> At 07:07 PM 4/8/2010, Pyun YongHyeon wrote:
> >On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> >> Only one device support by em does multiqueue right now, and that is
> >> Hartwell, 82574.
> >>
> >
> >Thanks for the info.
At 07:07 PM 4/8/2010, Pyun YongHyeon wrote:
On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> Only one device support by em does multiqueue right now, and that is
> Hartwell, 82574.
>
Thanks for the info.
Mike, here is updated patch. Now UDP bulk TX transfer performance
recovered a
Ah, ok, let me play around with it a bit, perhaps I'll make it definable,
of course if there is no positive benefit from using it it would seem silly
to leave it around :)
Will look at your patch changes and that issue tomorrow. Thanks
for your efforts!
Jack
On Thu, Apr 8, 2010 at 4:07 PM, Pyun
On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> Only one device support by em does multiqueue right now, and that is
> Hartwell, 82574.
>
Thanks for the info.
Mike, here is updated patch. Now UDP bulk TX transfer performance
recovered a lot(about 890Mbps) but it still shows bad num
Only one device support by em does multiqueue right now, and that is
Hartwell, 82574.
Jack
On Thu, Apr 8, 2010 at 2:05 PM, Mike Tancsa wrote:
> At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
>
>> On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
>> > At 02:17 PM 4/8/2010, Pyun YongHyeo
At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
> At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
>
> >Try this patch. It should fix the issue. It seems Jack forgot to
> >strip CRC bytes as old em(4) didn't strip it, probably to
> >workaround s
On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
> At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
>
> >Try this patch. It should fix the issue. It seems Jack forgot to
> >strip CRC bytes as old em(4) didn't strip it, probably to
> >workaround silicon bug of old em(4) controllers.
>
> Tha
On Thu, Apr 8, 2010 at 2:17 PM, Jack Vogel wrote:
> Try the code I just checked in, it puts in the CRC stripping, but also
> tweaks the
> TX code, this may resolve the watchdogs. Let me know.
>
> Cheers,
>
> Jack
>
Yes, this is indeed the fix for both the dhclient and VirtualBox issue
(at least w
Try the code I just checked in, it puts in the CRC stripping, but also
tweaks the
TX code, this may resolve the watchdogs. Let me know.
Cheers,
Jack
On Thu, Apr 8, 2010 at 11:39 AM, Pyun YongHyeon wrote:
> On Thu, Apr 08, 2010 at 11:27:10AM -0700, Jack Vogel wrote:
> > You know, I'm wondering
On Thu, Apr 08, 2010 at 11:27:10AM -0700, Jack Vogel wrote:
> You know, I'm wondering if the so-called ALTQ fix, which makes the TX
> start always queue is causing the problem on that side?
>
I'm not sure because I didn't configure ALTQ so it might be NOP for
non-ALTQ case.
> Jack
>
>
> On Thu
Bigger question is will it fix Brandon's VirtualBox issue??
Jack
On Thu, Apr 8, 2010 at 11:31 AM, Mike Tancsa wrote:
> At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
>
> Try this patch. It should fix the issue. It seems Jack forgot to
>> strip CRC bytes as old em(4) didn't strip it, probably to
At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
Try this patch. It should fix the issue. It seems Jack forgot to
strip CRC bytes as old em(4) didn't strip it, probably to
workaround silicon bug of old em(4) controllers.
Thanks! The attached patch does indeed fix the dhclient issue.
It seems the
You know, I'm wondering if the so-called ALTQ fix, which makes the TX
start always queue is causing the problem on that side?
Jack
On Thu, Apr 8, 2010 at 11:22 AM, Jack Vogel wrote:
>
>
> On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon wrote:
>
>> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mik
On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon wrote:
> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
> >
> > OK, some more data... It seems dhclient is getting upset as well
> > since the updated driver
> >
> > Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
> > 255.
LOL, what timing :)
On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon wrote:
> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
> >
> > OK, some more data... It seems dhclient is getting upset as well
> > since the updated driver
> >
> > Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCO
Both of you try something for me:
Assuming you are using the latest code in HEAD, at line 4042 please make
this insert:
/* Strip the CRC */
rctl |= E1000_RCTL_SECRC;
And try things again, I think this will solve at least the DHCP thing. I
hope.
Jack
On Thu, Apr
On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
>
> OK, some more data... It seems dhclient is getting upset as well
> since the updated driver
>
> Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
> 255.255.255.255 port 67 interval 6
> Apr 8 10:28:38 ich10 dhclient[138
At 12:52 PM 4/8/2010, Jack Vogel wrote:
Mike, I noticed this connection is only 100Mb, that isn't
accidental? And, is it possible for
you to check a connection at 1Gb and see if the watchdogs don't happen.
My test engineer is running this code, and we are having trouble
repro'ing the issue, so
On Thu, Apr 8, 2010 at 10:18 AM, Brandon Gooch
wrote:
> On Thu, Apr 8, 2010 at 12:06 PM, Jack Vogel wrote:
> >
> >
> > On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch <
> jamesbrandongo...@gmail.com>
> > wrote:
> >>
> >> On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel wrote:
> >> > Mike, I noticed th
On Thu, Apr 8, 2010 at 12:06 PM, Jack Vogel wrote:
>
>
> On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch
> wrote:
>>
>> On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel wrote:
>> > Mike, I noticed this connection is only 100Mb, that isn't accidental?
>> > And,
>> > is it possible for
>> > you to check
On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch
wrote:
> On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel wrote:
> > Mike, I noticed this connection is only 100Mb, that isn't accidental?
> And,
> > is it possible for
> > you to check a connection at 1Gb and see if the watchdogs don't happen.
> >
> > My
On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel wrote:
> Mike, I noticed this connection is only 100Mb, that isn't accidental? And,
> is it possible for
> you to check a connection at 1Gb and see if the watchdogs don't happen.
>
> My test engineer is running this code, and we are having trouble repro'
he kernel 64 or 32 bit?
Jack
On Thu, Apr 8, 2010 at 6:20 AM, Mike Tancsa wrote:
> At 09:12 AM 4/8/2010, Mike Tancsa wrote:
>
>> Hi Jack,
>>I looks like the latest MFC to RELENG_8 for the em driver has
>> caused a regression. The box is not doing much as its a de
On Thu, Apr 8, 2010 at 11:04 AM, Jack Vogel wrote:
> Brandon,
>
> Did the checkin of yesterday afternoon resolve the problem of the win7
> systems in
> VirtualBox? I will continue to look at this today.
>
> Jack
>
Sorry, I was a little unclear on that :(
No, the issue wasn't resolved even after
Brandon,
Did the checkin of yesterday afternoon resolve the problem of the win7
systems in
VirtualBox? I will continue to look at this today.
Jack
On Thu, Apr 8, 2010 at 8:29 AM, Brandon Gooch
wrote:
> On Thu, Apr 8, 2010 at 9:46 AM, Mike Tancsa wrote:
> >
> > OK, some more data... It seems d
On Thu, Apr 8, 2010 at 9:46 AM, Mike Tancsa wrote:
>
> OK, some more data... It seems dhclient is getting upset as well since the
> updated driver
>
> Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to 255.255.255.255
> port 67 interval 6
> Apr 8 10:28:38 ich10 dhclient[1383]: ip length
OK, some more data... It seems dhclient is getting upset as well
since the updated driver
Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
255.255.255.255 port 67 interval 6
Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with
bytes received 332.
Apr 8 10:28:38 ich
At 09:12 AM 4/8/2010, Mike Tancsa wrote:
Hi Jack,
I looks like the latest MFC to RELENG_8 for the em driver
has caused a regression. The box is not doing much as its a
development server in the lab. This is an Intel MB (DX58SO). dmesg
and pciconf -lvc attached.
Here are the stats
Hi Jack,
I looks like the latest MFC to RELENG_8 for the em driver
has caused a regression. The box is not doing much as its a
development server in the lab. This is an Intel MB (DX58SO). dmesg
and pciconf -lvc attached.
Apr 6 14:27:13 ich10 kernel: em0: Watchdog timeout
have
> multiple crashed cores with similarily strange problems all connected
> with networking and/or the em driver:
>
> 1)
> em0: watchdog timeout -- resetting
> Fatal trap 12: page fault while in kernel mode
> current process = 0 (em0 taskq)
>
> 2)
> em0
ff00490a6400 clashing
>>
>> In case someone is interested or has an idea - on this machine I have
>> multiple crashed cores with similarily strange problems all connected with
>> networking and/or the em driver:
>>
>> 1)
>> em0: watchdog timeout -- resetting
0xff00490a6400 clashing
>>
>
> In case someone is interested or has an idea - on this machine I have
> multiple crashed cores with similarily strange problems all connected with
> networking and/or the em driver:
>
> 1)
> em0: watchdog timeout -- resetting
> Fatal trap
: sbsndptr: sockbuf 0xff007cca8c20 and mbuf
0xff00490a6400 clashing
In case someone is interested or has an idea - on this machine I have
multiple crashed cores with similarily strange problems all connected
with networking and/or the em driver:
1)
em0: watchdog timeout -- resetting
Fatal
I have a fairly recent 8-stable machine running under VMWare ESXi 3.5
(amd64 guest), which apparently crashes every few days from the same causes:
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
Panic string: sbsndptr: sockbuf 0x
On Thu, Aug 06, 2009 at 08:45:39AM +0200, Vitezslav Novy wrote:
> I used net-snmpd before, but I was not able to use HC_* counters. If
> I understand situation, bsnmpd creates 64bit counters from system 32
> bit counters, but net-snmpd does not. (Maybe I'm wrong).
This used to be the case, but mor
On Wed, 5 Aug 2009 00:30:20 -0700 (PDT)
alexpalias-bsdsta...@yahoo.com mentioned:
> dev.em.0.rx_processing_limit=300
> dev.em.1.rx_processing_limit=300
> dev.em.2.rx_processing_limit=300
> dev.em.3.rx_processing_limit=300
>
This tunables only affects polling mode. Do you use polling with this
ad
alexpalias-bsdsta...@yahoo.com wrote:
--- On Wed, 8/5/09, Vitezslav Novy wrote:
I had similar problem with bsnmpd +
mibII module running.
Thanks for the pointer. Did you find a solution to this problem?
No. Just stopped bsnmpd.
Maybe I should try switching to net-snmpd or some other sn
--- On Wed, 8/5/09, Vitezslav Novy wrote:
> From: Vitezslav Novy
> Subject: Re: em driver input errors
> To: freebsd-stable@freebsd.org
> Date: Wednesday, August 5, 2009, 10:48 PM
> I had similar problem with bsnmpd +
> mibII module running.
>
> v.
Thanks for the
--- On Wed, 8/5/09, Marat N.Afanasyev wrote:
> From: Marat N.Afanasyev
> Subject: Re: em driver input errors
> To: alexpalias-bsdsta...@yahoo.com, "freebsd-stable@freebsd.org >>
> FreeBSD-STABLE Mailing List"
> Date: Wednesday, August 5, 2009, 11:47 PM
&
alexpalias-bsdsta...@yahoo.com wrote:
Good day
I'm looking for suggestions for tuning my setup in order to get rid of the
input errors I'm seeing on em0, em1 and em2 when using vlans.
[This message (excluding the description of the second machine at the end) has
also been sent to the freebsd-
I had similar problem with bsnmpd + mibII module running.
v.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Good day
I'm looking for suggestions for tuning my setup in order to get rid of the
input errors I'm seeing on em0, em1 and em2 when using vlans.
[This message (excluding the description of the second machine at the end) has
also been sent to the freebsd-net mailing list, a few days ago]
I'm r
> > > "2007.10.10.23.59.59" and have noticed lags while playing mp3 and
> > > browsing.
> > > I have suspected new em driver, because there was no lags if wifi iwi0
> > > was used instead of em0 for network. So I had downgraded the em driver
&g
gt; > "2007.10.10.23.59.59" and have noticed lags while playing mp3 and
> > > browsing.
> > > I have suspected new em driver, because there was no lags if wifi iwi0
> > > was used instead of em0 for network. So I had downgraded the em driver
> > &g
rowsing.
> > I have suspected new em driver, because there was no lags if wifi iwi0
> > was used instead of em0 for network. So I had downgraded the em driver
> > separately to 6.2.9 version, have build a kernel loadable module, and have
> > loaded it instead of the 6.6.6
On Fri, Oct 12, 2007 at 04:15:46PM +0400, Igor Sysoev wrote:
> Yesterday I have cvsup'ed FreeBSD on ThinkPad T42 to RELENG_6
> "2007.10.10.23.59.59" and have noticed lags while playing mp3 and browsing.
> I have suspected new em driver, because there was no lags if wifi iw
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 revisio
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 good example of the insanity
>the latter causes is nve
On Tue, Oct 30, 2007 at 09:06:39PM -0600, Scott Long wrote:
> There are too many examples to name in every OS of drivers that have
> tried in vain to support diverging hardware evolutionary paths. if_dc
> and if_bge are great (or horrible, depending on your perspective)
> examples of this in FreeB
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 called 'advanced descriptors', this means different TX path.
The 7.0 em driver has this support in it, it just uses a function pointer
to hand
at 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 called 'advanced descriptors', this means different TX path.
> > The 7.0 em driv
uire
> parallel code paths in the driver. For instance, the 82575 (Zoar) uses
> what are called 'advanced descriptors', this means different TX path.
> The 7.0 em driver has this support in it, it just uses a function pointer
> to handle it.
>
> When I add in multique
an 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 called 'advanced descriptors&#x
nd 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 called 'advanced descriptors', this means differen
t are called 'advanced descriptors', this means different TX path.
The 7.0 em driver has this support in it, it just uses a function pointer
to handle it.
When I add in multiqueue/RSS support it will add even more code
that functions this way.
What the Linux team did was to split the ne
On Fri, Oct 12, 2007 at 04:15:46PM +0400, Igor Sysoev wrote:
> Yesterday I have cvsup'ed FreeBSD on ThinkPad T42 to RELENG_6
> "2007.10.10.23.59.59" and have noticed lags while playing mp3 and browsing.
> I have suspected new em driver, because there was no lags if wifi iw
Yesterday I have cvsup'ed FreeBSD on ThinkPad T42 to RELENG_6
"2007.10.10.23.59.59" and have noticed lags while playing mp3 and browsing.
I have suspected new em driver, because there was no lags if wifi iwi0
was used instead of em0 for network. So I had downgraded the em drive
Jack Vogel wrote:
> 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?
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 tha
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 in
> 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.
Is something broken with TSO? I just added TSO support to bce on
CURRENT
and was planning on MFC'ing to RELENG_6 within the next week.
Dave
__
On 6/6/07, David Christensen <[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.
Is something broken with TSO? I just added TSO support to bce on
CURRENT
and was planning on MFC'i
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 4/6/07, Tai-hwa Liang <[EMAIL PROTECTED]> wrote:
On Thu, 5 Apr 2007, Jack Vogel wrote:
> Our test group uses a script that does 100 iterations of
> a module load, then bring up all interfaces, and then
> unload driver.
>
> Depending on the system in anything from just a few
> iterations to 20
On Thu, 5 Apr 2007, Jack Vogel wrote:
Our test group uses a script that does 100 iterations of
a module load, then bring up all interfaces, and then
unload driver.
Depending on the system in anything from just a few
iterations to 20 or more, the system will panic.
Just a "me too" here. :p
Our test group uses a script that does 100 iterations of
a module load, then bring up all interfaces, and then
unload driver.
Depending on the system in anything from just a few
iterations to 20 or more, the system will panic.
Its doing an em_detach() which calls ether_ifdetach()
which goes to i
On Mon, Mar 05, 2007 at 02:13:36PM -0800, Jack Vogel wrote:
[...snip...]
> >>
> >> Don't bother installing CURRENT, just got out of my meeting and I found
> >> out what the problem is. There is indeed an issue with management, and
> >> its something our test group isnt set up to test. I will send a
On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
On Mon, Mar 05, 2007 at 10:02:26AM -0800, Jack Vogel wrote:
> On 3/5/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> >On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
> >> On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >> > >
> >> >
On Mon, Mar 05, 2007 at 10:02:26AM -0800, Jack Vogel wrote:
> On 3/5/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> >On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
> >> On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >> > >
> >> > >Maybe more of your dmesg might help as it could show
On 3/5/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> > >
> > >Maybe more of your dmesg might help as it could show interrrupt issues
> > >that perhaps others could help diagnose
> >
> >
On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >
> >Maybe more of your dmesg might help as it could show interrrupt issues
> >that perhaps others could help diagnose
>
> Yes, agreed, this might be revealing.
Here's the full dmesg.
On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >
> >Maybe more of your dmesg might help as it could show interrrupt issues
> >that perhaps others could help diagnose
>
> Yes, agreed, this might be revealing.
Here's the full dmesg. Thanks for looking at this.
-
On Sun, Mar 04, 2007 at 11:37:01PM -0800, Jack Vogel wrote:
>
> These are one of our latest NICs, I have had no trouble with these
> but I'm used to using them on an Intel design, not SuperMicro.
>
> First question, do you get the same behavior on both ports?
> My first guess is that this is a BI
saw 225 who-has/reply packets in the same
> 1-minute period.
>
> I've tried different cables, and a different switch. I started with
> 6.2-RELEASE, and then went to 6.2-STABLE on 3/3/07 to get the latest
> em driver fixes. I've used SMP and GENERIC kernels. I get the sam
same
> 1-minute period.
>
> I've tried different cables, and a different switch. I started with
> 6.2-RELEASE, and then went to 6.2-STABLE on 3/3/07 to get the latest
> em driver fixes. I've used SMP and GENERIC kernels. I get the same
> results in all cases.
>
&
riod, I saw 3 ARP who-has/reply packets. On a different machine on
the same ethernet switch, I saw 225 who-has/reply packets in the same
1-minute period.
I've tried different cables, and a different switch. I started with
6.2-RELEASE, and then went to 6.2-STABLE on 3/3/07 to get the latest
em driv
hine on
the same ethernet switch, I saw 225 who-has/reply packets in the same
1-minute period.
I've tried different cables, and a different switch. I started with
6.2-RELEASE, and then went to 6.2-STABLE on 3/3/07 to get the latest
em driver fixes. I've used SMP and GENERIC kernels.
Scott Long wrote:
> My personally opinion is that the changes needed are too risky to rush
> into 6.2 for all of the different drivers. For the vast majority of
> people, what is in 6.2 works quite well, and there is no need to
> introduce new bugs. We are pushing forward with if_em because the
Steven Hartland wrote:
Scott Long wrote:
I don't doubt that there are users with other problems. We spent some
time collecting as much user data as we could in order to find
patterns and weed out the uncommon cases. But this timer/watchdog
thing looks to be a strong candidate for being the ro
Scott Long wrote:
I don't doubt that there are users with other problems. We spent some
time collecting as much user data as we could in order to find
patterns and weed out the uncommon cases. But this timer/watchdog
thing looks to be a strong candidate for being the root cause of many
of the p
UP/DOWN events.
> >
> >Are you sure this is the same problem as what's being discussed
> >here? If you revert to a previous kernel or em driver, does the
> >problem (link up/down) go away? Are you sure you don't actually
> >have a flaky cable or RJ45 conn
you sure this is the same problem as what's being discussed
> here? If you revert to a previous kernel or em driver, does the
> problem (link up/down) go away? Are you sure you don't actually
> have a flaky cable or RJ45 connector? What does the switch your
> NIC is connec
evert to a previous kernel or em driver, does the
problem (link up/down) go away? Are you sure you don't actually
have a flaky cable or RJ45 connector? What does the switch your
NIC is connected to say? (does it show link going up and down)
I feel horrible for both Scott and Jack -- I think th
s kernel or em driver, does the
problem (link up/down) go away? Are you sure you don't actually
have a flaky cable or RJ45 connector? What does the switch your
NIC is connected to say? (does it show link going up and down)
I feel horrible for both Scott and Jack -- I think there's tons
1 - 100 of 163 matches
Mail list logo
