22:25:42 2008
RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno
0, flags:
locks: inits:
sockaddrs:
default
Is there a way to try and track down what is generating those messages
? Its eating up a fair bit of cpu with quagga (the zebra process
specifically)
---Mike
__
Rcvd = 0
em1: XON Xmtd = 0
em1: XOFF Rcvd = 0
em1: XOFF Xmtd = 0
em1: Good Packets Rcvd = 71949
em1: Good Packets Xmtd = 2507
em1: TSO Contexts Xmtd = 369
em1: TSO Contexts Failed = 0
And are you using gigabit or fastE. If fastE, try disabling TSO as
some people have said they
rt 6112 -j
SNAT --to-source 216.238.130.251:63012
***
What I'm hoping is that someone will be able to tell me a way to do this
same thing using natd or ipfwd or something like that. Any hints or help
would be much appreciated
Thanks, I'll see what I can find out from there:)
Mike
> On Fri, Mar 16, 2001 at 01:53:25AM -0500, Mike wrote:
> > What I'm hoping is that someone will be able to tell me a way to do
this
> > same thing using natd or ipfwd or something like that. Any hints
mike-karels.net added a subscriber: mike-karels.net.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1965
To: erj, adrian, jfvogel, gnn
Cc: mike-karels.net, glebius, freebsd-net
___
freebsd-net@freebsd.org mailing list
http
mike-karels.net added a comment.
>>! In D1965#11, @gnn wrote:
> BTW Mike Karels was in favor of this in an email thread. He's not yet on
> phabricator but I'll ask him here as well.
Agreed, with minor exceptions. Given the ixl changes, I don't think the vtnet
exam
mike-karels.net added a comment.
I believe that the original code is wrong, and the change is not sufficient
to fix it. The retransmit timer should be running if and only if we have
sent data into the receive window and are awaiting an ACK. The persist
timer should be running if and
mike-karels.net added a comment.
Setting a retransmission timer on an ACK makes no sense; I don't think
tcp_output will send an ACK on a retransmission timeout.
Setting timers in the ENOBUFS case is at best a partial fix. If the ACK is
lost locally, we know; if it is lost elsewher
mike-karels.net added a comment.
btw, I think the line to set the snd_cwnd should remain for now, until
something replaces it. ENOBUFS signals local congestion.
REVISION DETAIL
https://reviews.freebsd.org/D5872
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel
mike-karels.net added a comment.
I disagree; congestion is congestion, not "congestion for everyone but me".
I'd prefer to leave the cwnd change until it is replaced by something more
modern.
REVISION DETAIL
https://reviews.freebsd.org/D5872
EMAIL PREF
.77 Gbits/sec 244 sender
[ 5] 0.00-30.00 sec 30.6 GBytes 8.77 Gbits/sec receiver
More data can be found @
https://forums.freebsd.org/threads/poor-performance-with-stable-13-and-mellanox-connectx-6-mlx5.85460/
Mike Jakubik
https://www.swiftsmsgateway.
0.00-30.00 sec 31.1 GBytes 8.91 Gbits/sec 1330 sender
[ 5] 0.00-30.00 sec 31.1 GBytes 8.91 Gbits/sec receiver
Thanks.
On Mon, 13 Jun 2022 14:41:05 -0400 Santiago Martinez
<mailto:s...@codenetworks.net> wrote ----
Mik
Yes, it is the default of 1500. If I set it to 9000 I get some bizarre network
behavior.
On Tue, 14 Jun 2022 09:45:10 -0400 Andrey V. Elsukov
<mailto:bu7c...@yandex.ru> wrote
Hi,
Do you have the same MTU size on linux machine?
Mike Jakubik
e the problem is, if it's
PCI backpressure or something else.
sysctl -a | grep diag_pci_enable
sysctl -a | grep diag_general_enable
Set these two to 1, then run some traffic and dump all mce sysctls:
sysctl -a | grep mce > dump.txt
--HPS
Mike Jakubik
https://www.swiftsmsg
] 0.00-30.00 sec 29.4 GBytes 8.42 Gbits/sec 3863 sender
[ 5] 0.00-30.00 sec 29.4 GBytes 8.42 Gbits/sec receiver
On Tue, 14 Jun 2022 10:21:51 -0400 Mike Jakubik
wrote
Disabling rx/tx pause seems to produce higher peaks.
[root@db-02
After multiple tests and tweaks i believe the issue is not with the HW or Numa
related (Infinity fabric should do around 32GB) but rather with FreeBSD TCP/IP
stack. It's like it cant figure itself out properly for the speed that the HW
can do, i keep getting widely varying results when testing.
receiver
iperf Done.
Thank You!
On Thu, 16 Jun 2022 17:00:25 -0400 Alexander V. Chernikov
wrote
> On 16 Jun 2022, at 21:48, Mike Jakubik
> <mailto:mike.jaku...@swiftsmsgateway.com> wrote:
>
> After multiple tests and tweaks i believe the issue is not with
Responding to parts of two emails:
On 27 Jun 2022, at 7:41, Marek Zarychta wrote:
W dniu 27.06.2022 o 13:44, Dave Cottlehuber pisze:
I've found a workaround for this issue, but don't understand why this
occurs. Reading RFC1122 has left me none the wiser. What am I
missing?
Is this a Linuxism
e any significant impact,
sometimes they even reduce performance. So I m hoping when this goes into
production the scheduler will be sane enough to do the same, but we shall see.
Thanks.
On Fri, 17 Jun 2022 11:03:04 -0400 Dave Cottlehuber
wrote ---
On Fri, 17 Jun 2022, at 02:38,
in /etc/csh.cshrc
---Mike
On 1 Jul 2022, at 4:11, Ronald Klop wrote:
Van: George Michaelson
Datum: vrijdag, 1 juli 2022 00:50
Aan: "Rodney W. Grimes"
CC: mike tancsa , Chris Ross
, freebsd-net@freebsd.org
Onderwerp: Re: Netstat -i 5-character interface name length?
Is there a reason (avoid bikeshedding)
On 2 Jul 2022, at 10:11, Mike Karels wrote:
On 1 Jul 2022, at 4:11, Ronald Klop wrote:
Van: George Michaelson
Datum: vrijdag, 1 juli 2022 00:50
Aan: "Rodney W. Grimes"
CC: mike tancsa , Chris Ross
, freebsd-net@freebsd.org
Onderwerp: Re: Netstat -i 5-character interface name le
sion first.
Changes are also being made in Linux, although I don't know their state.
Note that there is a related proposal and change to allow use of the
lowest host on a network/subnet [4]. This change was essentially a bug
fix for FreeBSD, and is already in -current and 13.1-RELEASE.
from internally and then translates. But it will benefit
from greater accuracy in other cases as well (e.g. "out of memory"
rather than "Name does not resolve").
Comments? I have a change in progress, but wanted to float the idea
before I finish it and put it into review.
Mike
On 27 Sep 2022, at 17:41, Viktor Dukhovni wrote:
> On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote:
>
>> The first error message is misleading, because the name *does* resolve,
>> but has no record, and it is the same error message as for a name
>> t
On Wed, 28 Sep 2022, Konstantin Belousov wrote:
> On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote:
> > I recently noticed the following behavior:
> >
> > % ping6 redrock
> > ping6: Name does not resolve
> > % host redrock
> >
On Oct 17, I wrote:
> On Wed, 28 Sep 2022, Konstantin Belousov wrote:
> > On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote:
> > > I recently noticed the following behavior:
> > >
> > > % ping6 redrock
> > > ping6: Name does not resolve
justification
> to me.
I have used trpt, but not for many years. It was done before tcpdump
as well. Its time has long since gone.
Mike
> --
> Gleb Smirnoff
tion
and causes a reset, and the session gets cleaned up. I use a longer keepidle
value for other reasons.
Mike
3a8 at amd64_syscall+0x138
#16 0x8101da7b at fast_syscall_common+0xf8
Mike
the same.
Just curious, how does iperf3 perform in comparison ?
---Mike
g the code and reading the history of changes
between stable/13 and stable/14 to see if there are something obvious,
but more insights from others would be appreciated :)
[/me takes a in the dark]
maybe something like net.inet.ipsec.filtertunnel=1 is needed now ?
---Mike
I need more approval and if yes, how can I get that?
>
> Regards,
> Ronald.
The change looks good to me now. I think it would be good if someone who
works on USB looked at it too. I am willing to approve the change; I think
you can commit it with approval.
Mike
The kernel has a driver name for each interface, which looks like it
doesn't change currently in most cases. There is a kernel accessor
function, but I don't think it is exported to user space now. It could
be, though. Would this be sufficient for your purposes? There is also
a unit number, which could also be exported.
Mike
On 19 Nov 2023, at 13:13, Mina Galić wrote:
> Hi Mike,
>
>> The kernel has a driver name for each interface, which looks like it
>> doesn't change currently in most cases. There is a kernel accessor
>> function, but I don't think it is exported to user space
ibly as two words using the same
option. It should probably be an option rather than a keyword,
so something like this:
# ifconfig -N interface-name
igb 1
#
Or the unit number could be on a separate option.
Comments?
Mike
> Unrelatedly, I don't see anything in ure(4) mentioning that if_ure
> devices will be named "ue".
> Don't we usually document such deviation from the norm?
>
>
> Kind regards,
>
> Mina
On 20 Nov 2023, at 14:56, Kristof Provost wrote:
> On 20 Nov 2023, at 21:29, Mike Karels wrote:
>> On 19 Nov 2023, at 15:35, Mina Galić wrote:
>>> Hi Zhenlei,
>>>
>>>
>>>> Since it is just for physical devices, may I propose to have the driver
&g
ial to add; I just tested it. It also has problems with
epair. Maybe that isn't an issue for this purpose. I hate to invent
something new when there is something already existing that solves
most of the problem.
Mike
> Cheers,
> Franco
On 21 Nov 2023, at 0:43, Franco Fichtner wrote:
>> On 20. Nov 2023, at 23:06, Mike Karels wrote:
>>
>> On 20 Nov 2023, at 15:16, Franco Fichtner wrote:
>>
>>> All that is really missing is a way to print it via ifconfig command.
>>
>> That is t
On 21 Nov 2023, at 12:16, Mina Galić wrote:
> Hi Mike,
>
>> Mina, do you care about epair, or is the behavior I described sufficient
>> for your purposes?
>
> I do deeply care about epair, but for me, ifinfo does the
> right thing for me:
>
> root@irc:~ # ifinfo |
On 21 Nov 2023, at 19:35, Jamie Landeg-Jones wrote:
> Mike Karels wrote:
>
>> I have a proof of concept that makes the presumed original name
>> (driver name + unit number) available to ifconfig, which prints
>> the string with everything else in the standard output forma
On 21 Nov 2023, at 19:57, Mike Karels wrote:
> ... My newer code prints "drivername: igb1" at the end of
> the list of values for "ifconfig $interface-name" or "ifconfig -a"
> if the -D option is given. I decided that it was better to be able
> to ge
ression.
Ideally, tcphpts could enable this automatically when it starts to be
used (enough?), but a sysctl could select auto/on/off.
Mike
> Best regards
> Michael
>>
>> Thanks all!
>> Really happy here :)
>>
>> Cheers,
>>
>> Nuno Teix
I run into this problem in layered networks where the next hop
is often RFC 1918 addrs. I bind applications to internal NICs that have
addresses that have routing to/from.
---Mike
oobar ... does not fail. (12.4 got the interface wrong
when the alias was on the loopback.)
Anyone know why -ifa is ineffective in 14.0 and -current? It could
be fallout from netlink.
The documentation is weak at best; route(8) says only "the -ifp or -ifa
modifiers may be used to determi
addr, but it allows other members
of the structure, so I don't see a problem with exposing them all even
in a POSIX environment.
I would have no objection to exposing all four definitions, especially
if Linux apps use them.
Mike
On 26 Apr 2024, at 15:49, Mike Karels wrote:
> On 26 Apr 2024, at 15:01, Warner Losh wrote:
>
>> This has to be a FAQ
>>
>> I'm porting a program from Linux, I often see an error like:
>> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_
On 26 Apr 2024, at 18:06, Warner Losh wrote:
> On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote:
>
>> On 26 Apr 2024, at 15:49, Mike Karels wrote:
>>
>>> On 26 Apr 2024, at 15:01, Warner Losh wrote:
>>>
>>>> This has to be a FAQ
>>>>
On 26 Apr 2024, at 23:02, Bakul Shah wrote:
> On Apr 26, 2024, at 8:41 PM, Warner Losh wrote:
>>
>>
>>
>> On Fri, Apr 26, 2024, 9:33 PM Bakul Shah wrote:
>>
>>
>>> On Apr 26, 2024, at 5:02 PM, Mike Karels wrote:
>>>
>>> On 26 Ap
I have no networking changes at all in the 14.1 release notes. Is there
anything that should be mentioned? Feel free to reply to me individually.
Thanks,
Mike
On 5/18/2024 10:49 AM, Mike Karels wrote:
I have no networking changes at all in the 14.1 release notes. Is there
anything that should be mentioned? Feel free to reply to me individually.
Not sure if appropriate or not, but when going to 13.x to 14.x, not all
vlan configs work now in rc.conf
On 19 May 2024, at 18:29, mike tancsa wrote:
> On 5/18/2024 10:49 AM, Mike Karels wrote:
>> I have no networking changes at all in the 14.1 release notes. Is there
>> anything that should be mentioned? Feel free to reply to me individually.
>>
> Not sure if appropriate o
On 5/19/2024 8:59 PM, Mike Karels wrote:
On 19 May 2024, at 18:29, mike tancsa wrote:
On 5/18/2024 10:49 AM, Mike Karels wrote:
I have no networking changes at all in the 14.1 release notes. Is there
anything that should be mentioned? Feel free to reply to me individually.
Not sure if
On 20 May 2024, at 10:15, mike tancsa wrote:
> On 5/19/2024 8:59 PM, Mike Karels wrote:
>> On 19 May 2024, at 18:29, mike tancsa wrote:
>>
>>> On 5/18/2024 10:49 AM, Mike Karels wrote:
>>>> I have no networking changes at all in the 14.1 release notes. I
On 5/20/2024 11:54 AM, Mike Karels wrote:
That sounds like an outright bug. Looks like it was true in 14.0 as well.
Is there a bug report? I couldn't find one.
I didnt open one. Wasnt sure if it the change was a deliberate one or on the
wrong side of POLA. To me it feels unnecessary to
to get around that and only drop packets with a certain port in the
first fragment ?
---Mike
On 8/29/2024 3:45 PM, Olivier Cochard-Labbé wrote:
On Thu, Aug 29, 2024 at 8:52 PM mike tancsa wrote:
But this would kill all UDP fragments. If the host has some other
UDP
application that needs to deal with fragmented packets, is there a
way
to get around that and only
The following device tree specifies a shared mdio.
The ffec driver uses miibus.
When there is a shared mdio, one of the device instances will not be able to
properly configure the PHY, as it needs to use the other devices resource to
read/write the PHY.
&fec1 {
pinctrl-names = "d
a fit.
I do not have the hardware. I am trying to help somebody else with this. I
have seen the dtb.
It’s a Variscite DAR-MX8M-PLUS.
Regards,
Mike.
From: owner-freebsd-...@freebsd.org on behalf
of Milan Obuch
Date: Friday, September 13, 2024 at 3:08 AM
To: freebsd-net@freebsd.org
Subject
but you really
don't need all multicasts in this case.
Mike
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On 4/24/2013 6:45 AM, Olivier Cochard-Labbé wrote:
> # Why all these benchs ? #
>
> I've found performance regression regarding packet forwarding/ipfw/pf
> speed on -current comparing to 9.1 on my old server.
BTW, how much of a drop in performance as compared to 9.1 ?
(Student's t, pooled s = 935.915)
Is that because pf is slower on a single flow, or packet forwarding in
general is slower on HEAD ? How different is 9.1 and HEAD in just
forwarding performance?
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communica
s here
in Canada do that. It would not be manageable otherwise by the carrier.
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.t
think the message should say "from my MAC address" (vs IP).
> 2c,
2c more,
Mike
On 27 July 2013 13:49, Zaphod Beeblebrox wrote:
> I'd like to advocate implementing
> http://www.freebsd.org/cgi/query-pr.cgi?pr=180893
>
> Quoting the PR:
>
>
omething is not quite being re-enabled properly ? But its different
than the other two cases ?!?
tgt is FreeNAS-9.1.1-RELEASE-x64 (a752d35) and initiator is r254328 9.2
AMD64
The FreeNAS box has 16G of RAM, so the file is being served out of cache
as gstat shows no activity when sending out the fil
On 9/10/2013 6:42 PM, Barney Cordoba wrote:
> NFS has been broken since Day 1, so lets not come to conclusions about
> anything
> as it relates to NFS.
iSCSI is NFS ?
---Mike
>
> BC
>
> ----
On 9/10/2013 7:04 PM, Rick Macklem wrote:
> Mike Tancsa wrote:
>> On 9/10/2013 6:42 PM, Barney Cordoba wrote:
>>> NFS has been broken since Day 1, so lets not come to conclusions
>>> about
>>> anything
>>> as it relates to NFS.
>>
>> iSC
Wow! I just had a look at the TOC and it looks like a great addition to
the spare resources that are out there. I will certainly have a look
through it in the coming days. Thanks for sharing with the community!
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex
On 3/9/2014 7:33 AM, Przemyslaw Frasunek wrote:
I've seen that Mike reported similar issues in October
(http://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075552.html).
Did you managed to resolve it?
I worked around the crash by removing ipv6 from the kernel. The box has
users
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-net@freebsd.org ma
abled ?
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-net@freebs
On 12/21/2011 1:46 AM, Jack Vogel wrote:
> I was fighting with UDP issues before the latest checkin, so you should
> look at THAT version, 2.3.1 in HEAD please.
Hi Jack,
Is there a stand alone version of 2.3.1 that we can try on RELENG_9 and
RELENG_8 ?
-
add 1 allow ip from any to any
> 1.1 mpps routing utilizes E5645 by more that 80%. (with IGP routes in
> rtable only). YMMV, but 2x10G is too much at the moment even without ipfw.
Dont some of the modern 10G adapters support filtering in the card
itself ? eg cxgbe.
---Mike
--
-
Has anyone had any success using the bxe driver with FreeBSD 9.0 or
pre-releases? If so, are you using BCM57710 or BCM57711[E]? We are
trying to use the 57710 without any success; it does not receive
unicast packets, just broadcast or multicast.
Thanks,
Mike
o dealing with congestion, there
are many params you can tune in pf. Take a look at the man pages for
pf.conf for details as you can control how this situation is dealt with
to some degree.
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@s
. Hopefully it will be MFC'd soon :)
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
On 1/29/2012 1:21 PM, Jack Vogel wrote:
> No, I told Mike I'd get it into 8.x, have just been busy, but will try
> and get it pushed up in the queue.
Thanks Jack, I see its now MFC'd into RELENG_8!
em1: port 0x2000-0x201f mem
0xb410-0xb411,0xb412-0xb4123fff irq 16
I dont think the driver changes from HEAD were ever MFC'd to 9.x. Only
to 8.x
---Mike
On 2/22/2012 1:23 PM, Darren Baginski wrote:
> Same problem on
> FreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #2: Wed Feb 22
> 18:10:53 UTC 2012 r...@srv-4-2.lab.local:/u
f "making your NIC and network stack not angry."
The 82574L is not that common on NICs and tends to be on server
motherboards. igb is easy enough to source.
---Mike
>
>
>
> Adrian
> ___
> freebsd-net@freebsd.org mailin
carp4.html#carp-4.2.2)?
Does FreeBSD yet have IP load balacing on CARP? Are there plans to do this
on FreeBSD?
--
Mike
Of course, you might discount this possibility, but remember that one in a
million chances happen 99% of the
supports 1 message, 64 bit
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 001517ed68a4
--
---
Mike Tancsa, t
Hi,
Try the driver from HEAD. It has a number of fixes in it to both the
igb and em drivers that is not yet in RELENG_9 nor 8
http://lists.freebsd.org/pipermail/svn-src-head/2012-March/035888.html
---Mike
On 4/3/2012 10:19 AM, Darren Baginski wrote:
> Still getting same err
v6 on an LNS was not stable.
http://lists.freebsd.org/pipermail/svn-src-stable-8/2012-June/007555.html
---Mike
>
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.se
some was recently fixed by bz@, but definitely not merged to stable/8.
>
> Thanks a lot guys. For now, I disabled IPv6 on this BRAS. Let's see if it's
> going to help.
Hi,
Any changes in stability ?
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sen
been able to trigger the panic after a few days of
use with IPv6 enabled. Should have it up and running in a week or so.
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambri
37 in via ng21
panic: bufwrite: buffer is not busy???
cpuid = 1
Uptime: 151d12h10m10s
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge,
errors
when you rebooted a system with bxe NICs if you had not UP'd all of the
bxe NICs before the shutdown.
Thanks,
Mike "Silby" Silbersack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To un
On 9/5/12 3:56 PM, YongHyeon PYUN wrote:
On Tue, Sep 04, 2012 at 11:35:13PM -0500, Mike Silbersack wrote:
Does anyone want to review this patch before I check it in? The change
has been reviewed and tested by coworkers, but not yet reviewed by any
other FreeBSD committers.
http
the vlan
level. You can then run all sorts of fine grained reports this way. We
use it on a system with about 900 ng interfaces.
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex
essant... as in very
> "often."
>
Are you using pf ? Also, did you confirm it is the igb nic and not
something more general ? e.g. if you put in a different nic, does the
problem go away ?
If you are using pf, lets see the rules.
---Mike
--
---
Mike T
ported." It might further
say "This specific error value may not be accurate, but is specified
by POSIX.1-2008."
Mike
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
discard subsequent packets when link was down. No
special change is needed to restart: the next time a packet is transmitted
after link comes up, that packet is sent. Our change is not necessarily
done the way I'd do it for FreeBSD, but it minimizes changes. Patch
available on request.
nks for the tip. But I see I forgot to mention this was FreeBSD 8.0.
> The em(4) driver is actually the one found in FreeBSD 8.1 as we needed
> the AltQ fixes.
>
Try grabbing the em drivers from HEAD. They fixed a few bugs for me.
You should be able to
acker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449
>
>
Interesting, this is the same nic that has been giving me grief! Mine is
on an Intel server board (S3420GPX). The symptoms are VERY similar to
what the LINUX user sees as well with RX errors and the traffic pat
On 11/23/2010 8:16 AM, Ivan Voras wrote:
> On 11/23/10 14:03, Mike Tancsa wrote:
>> On 11/23/2010 7:47 AM, Ivan Voras wrote:
>>> It looks like I'm unfortunate enough to have to deploy on a machine
>>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F
1: Using an MSI interrupt
em1: [FILTER]
em1: Ethernet address: 00:15:17:ed:68:a4
---Mike
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
27;s speed and duplex are manual, change the media
options on the NIC to something like 10 half. The switch should see the
port "down" then.
---Mike
>
> Eugene Grosbein
> ___
> freebsd-net@freebsd.org mailing list
> htt
8's em driver a week ago.
Perhaps update to that first. But what sort of em nics do you have ?
pciconf -lvc will show it. I have a number of boxes with 20 or more
ifconfig | grep ^vlan | wc
20 1201562
Most of which are pcie based, or onboard 82574L types.
--
On 12/7/2010 6:45 PM, Mihai-Catalin Salgau wrote:
> Hello Mike,
>
> Tuesday, December 7, 2010, 8:13:26 PM, you wrote:
>
>> Hi,
>> There were a bunch of changes to RELENG_8's em driver a week ago.
>> Perhaps update to that first. But what sort of em
On 12/24/2010 5:44 PM, Jan Koum wrote:
> hi Ivan and Mike,
>
> wanted to follow up and see if you found a solid long-term solution to this
> bug. we are still seeing this problem in our 8.2 environment with ASPM
> already disabled. here is what we have:
Hmmm,
With the la
1 - 100 of 1030 matches
Mail list logo
