Re: vlan with modified MAC fails to communicate

ath isn't Ethernet. :) ___ 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

Re: drbr_enqueue - OCE driver - Freebsd 9.1

On Mon, Apr 8, 2013 at 1:14 PM, Duvvuru,Venkat Kumar venkatkumar.duvv...@emulex.com wrote: Hi, In the transmit path, if enqueue mechanism is used instead of blocking on the lock, the throughput is not good in some scenarios (especially single queue, multiple connections). For example: if

Re: pf performance?

On Fri, Apr 26, 2013 at 10:49 AM, Erich Weiler wei...@soe.ucsc.edu wrote: The pf isn't a process, so you can't see it in top. pf has some helper threads however, but packet processing isn't performed by any of them. But the work pf does would show up in 'system' on top right? So if I see

Re: surprise surprise (VM related) [lu...@freebsd.org: svn commit: r250911 - head/sys/kern]

On Wed, May 22, 2013 at 12:42 PM, Luigi Rizzo ri...@iet.unipi.it wrote: all that work on paravirtualization (as presented at bsdcan) http://info.iet.unipi.it/~luigi/netmap/talk-bsdcan-2013.html just to discover that simply enabling DEVICE_POLLING (10-years old technology) gives the same

Re: Create pkey on FreeBSD 9.1

On Thu, May 23, 2013 at 4:32 AM, Alex Liptsin al...@mellanox.com wrote: Hello. I have FreeBSD 9.1 installed. There is mellanox adapter inside. OFED support is already installed. I try to add pkeys on ib0 port. Usually in Linux I did: echo 0x800c /sys/class/net/ib0/create_child

Re: Intel 4-port ethernet adaptor link aggregation issue

On Thu, Aug 1, 2013 at 2:07 PM, Joe Moog joem...@ebureau.com wrote: We have an iXsystems 1U server (E5) with an Intel 4-port ethernet NIC installed, model I350-T4 (manufactured May of 2013). We're trying to bind the 4 ports on this NIC together into a single lagg port, connected LACP to a

Re: The reason of ping: sendto: No buffer space available and link_irq variable

On Thu, Oct 3, 2013 at 11:42 AM, Tugrul Erdogan h.tugrul.erdo...@gmail.com wrote: Hi, I am using FreeBSD alpha2 amd64 on my router and after packet loaded test attack I am taking ping: sendto: No buffer space available error when running ping from router to victim directoion. The nic is

Re: netmap: understanding pkg-gen.c

On Thu, Oct 3, 2013 at 2:51 AM, hiren panchasara hiren.panchas...@gmail.com wrote: What/where is the exact logic/code of how card determines what traffic goes to what queue? Is it based on DST-MAC always? RSS is based off of a hash of the 4-tuple (src/dst ip, src/dst port). Note that this is

Re: Non-interrupt packet sending and receiving

You might want to take a look at the projects/sv branch, which implement kernel core dumps over the network. We had to solve a similar problem there (in lem, em, igb and ixgbe) and ended up piggybacking on most of the DEVICE_POLLING code to do it. The work ended up stalling over objections over

Re: ixgbe and igb - how many queues?

The oldest hardware supported by the ixgbe driver is the 82598, which supports up to 16 RSS queues (see Table 3-48 in the 82598 datasheet). I believe that the 82599 and X520 are more capable. I have no idea what the situation is on igb, as there seems to be a lot more hardware supported by that

Re: Sending data via MAC address

On Mon, Aug 18, 2014 at 8:58 AM, Piotr Kubaj p.ku...@pp.com.pl wrote: Hi. Please see http://forums.freebsd.org/viewtopic.php?f=15t=45303#p264204 and http://forums.freebsd.org/viewtopic.php?f=15t=45303#p264249 . I know I can use web interface or ssh but WinBox is required. In short, using

Re: How can sshuttle be used properly with FreeBSD (and with DNS) ?

I'm unable to get sshuttle to redirect DNS traffic even on a machine that doesn't have any other ipfw rules running, so I don't think that it's a conflict with your divert rules causing the problem. Unfortunately I don't have a solution to your problem. When I need to use sshuttle I run it from a

[PATCH] Fix integer truncation in systat -ifstat

systat -ifstat currently truncates byte counters down to 32-bit integers. The following fixes the issue, but I'm not very happy with it. u_long is what the rest of our code uses for network counters, but that ends up meaning that our counters are 32-bits wide on 32-bit platforms. I could make

Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD

On Wed, Sep 17, 2014 at 4:27 AM, Stefano Garzarella stefanogarzare...@gmail.com wrote: Much of the advantage of TSO comes from crossing the network stack only once per (large) segment instead of once per 1500-byte frame. GSO does the same both for segmentation (TCP) and fragmentation (UDP) by

[PATCH] Convert ixl(4) and ixlv(4) to ifcounters, and fix some counter bugs

The patch below converts the ixl(4) and ixlv(4) drivers to use the new ifcounter interface. I've hidden the interface behind some macros to ensure that the driver continues to compile for FreeBSD 10 and earlier. The result of the macros is that the ifcounter implementation is somewhat clunkier

Re: vlan problem

What netmasks are you using on the FreeBSD machine? I have seen very strange behaviour (like packets not being able to be routed) in the FreeBSD network stack if I assign two addresses on the same subnet to different interfaces. On Thu, Sep 25, 2014 at 2:53 PM, Tony Moseby tsmos...@yahoo.no

Re: netisr defered - active only one thread

2012/2/2 Alexander V. Chernikov melif...@freebsd.org: P.S. it is also reasonable to set net.isr.bindthreads to 1 I really don't recommend setting this in any release. There is currently a bug with binding kernel threads that causes unrelated threads to be unnecessarily bound to CPUs. In the

Re: netisr defered - active only one thread

On Thu, Feb 2, 2012 at 2:09 PM, Alexander V. Chernikov melif...@freebsd.org wrote: As far as I understand, the only effect of setting bindthreads to 1 causes intr_event_bind() to bind soft netisr to appropriate CPU. Can you point me to ML discussion or some other info clarifying this bug?

Re: netisr defered - active only one thread

On Thu, Feb 2, 2012 at 2:51 PM, Ryan Stone ryst...@gmail.com wrote: of the last netisr through to be bound to a CPU. *sigh*, that should read netisr thread of course. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo

Re: kern/165863

On Fri, Mar 9, 2012 at 4:30 AM, Gleb Smirnoff gleb...@freebsd.org wrote: The following reply was made to PR kern/165863; it has been noted by GNATS. From: Gleb Smirnoff gleb...@freebsd.org To: Eric van Gyzen eric_van_gy...@dell.com,        Eric van Gyzen e...@vangyzen.net, ema...@freebsd.org

Re: kern/165863

The following reply was made to PR kern/165863; it has been noted by GNATS. From: Ryan Stone ryst...@gmail.com To: Eric van Gyzen e...@vangyzen.net Cc: Gleb Smirnoff gleb...@freebsd.org, Eric van Gyzen eric_van_gy...@dell.com, ema...@freebsd.org, bug-follo...@freebsd.org Subject: Re

Removing an IPv6 address does not remove NDP entries on that subnet

Currently, if you remove an IPv4 address from an interface, all ARP cache entries on its subnet are invalidated. However, the same thing is not done for NDP cache entries when an IPv6 address is removed*. Is this correct behaviour? It seems weird to have IPv4 and IPv6 behave differently. * In

Re: kern/165863

Ok, I think that I have an approach that will work. This is heavily based off of glebius' proposal. The big difference is that instead of initializing the arptimer callout with the ll_entry's lock, I initialize it with the if_afdata_lock. This eliminates the LOR problem in arptimer. It also

Re: Removing an IPv6 address does not remove NDP entries on that subnet

On Fri, Mar 30, 2012 at 12:28 AM, Li, Qing qing...@bluecoat.com wrote: * In a way this is a good thing as in6_lltable_prefix_free() is guaranteed to crash your kernel in two different ways, and that's not counting the race conditions that it's subject to.        Could you please elaborate

Re: Removing an IPv6 address does not remove NDP entries on that subnet

On Mon, Apr 9, 2012 at 5:46 PM, Li, Qing qing...@bluecoat.com wrote: Could you please share with me a call path that you believe is problematic, or a simple test case that uncovers the issue ? I cannot because it is literally impossible for in6_lltable_prefix_free() to ever be called.

Re: Removing an IPv6 address does not remove NDP entries on that subnet

On Mon, Apr 9, 2012 at 9:08 PM, Li, Qing qing...@bluecoat.com wrote: I have not followed this thread closely from the beginning, so let me confirm. Are you reporting multiple bugs: 1) ndp entries remain after the removal of an address (according to the thread title), and 2) you believe there

Re: kern/165863

2012/4/10 Gleb Smirnoff gleb...@freebsd.org:  Thanks, Ryan! (snip) Looks okay from my viewpoint. Have you stress tested it? My snap patch definitely had problems, AFAIR. If this patch fixes panics observed by kern/165863 and passes stress testing, then it should be committed ASAP, and

Re: 82574L hangs (with r233708 e1000 driver).

On Thu, Apr 12, 2012 at 2:38 PM, Konstantin Belousov kostik...@gmail.com wrote: And, on receive, the atom board does receive interrupts, em0:rx 0 counter in vmstat -i increases. Even more fun, the sysctl dev.em.0.debug shows increasing hw rdh (as I understand, this is hardware 'last received'

Re: Removing an IPv6 address does not remove NDP entries on that subnet

On Wed, Apr 25, 2012 at 3:59 AM, Li, Qing qing...@bluecoat.com wrote: The patch is located at   http://people.freebsd.org/~qingli/nd6_prefix.diff Please give it a try. I did only basic testing as of now and will do more tomorrow. --Qing I tested this last night. Unfortunately this seems

Re: mpd5/Netgraph issues after upgrading to 7.4

On Mon, Jul 9, 2012 at 4:12 AM, Gleb Smirnoff gleb...@freebsd.org wrote: This looks very much related to a known race in ARP code. See this email and related thread: http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031865.html Ryan didn't check in any patches since, and I failed to

Re: check pending callouts

On Sat, Jul 28, 2012 at 2:15 AM, Jason Hellenthal jhellent...@dataix.net wrote: You should be able to dtrace that out and uncover whats going on with a little intellect. The D language itself might take a little learning but it would be worth your while to pick it up now instead of later.

What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc?

I know that there have been a lot of discussions about fixing how packets are handed off to ifnets due to the current methods being extremely race-prone. Has there been any consensus on how the problem is going to be solved? In my particular case, I've seen an if_bridge interface whose if_snd

Re: ixgbe rx tx locks

On Wed, Sep 26, 2012 at 9:55 AM, John Baldwin j...@freebsd.org wrote: You only have to drop the RX lock around if_input() if you use the same lock for both TX and RX (as if_transmit() / if_start() can be invoked while locks in the network stack are held). Last time I checked(FreeBSD 8.2), this

Re: ixgbe rx tx locks

On Wed, Sep 26, 2012 at 3:38 PM, John Baldwin j...@freebsd.org wrote: ix:rx - udp - udpinp - in_multi_mtx - ix:core - ix:rx Hmm, I'm not sure where the 'in_multi_mtx - ix:core' bit comes from. I think that is the broken part of this. The SIOCADDMULTI and SIOCDELMULTI ioctls are invoked

Re: ixgbe if_igb RX ring locking

On Mon, Oct 15, 2012 at 12:29 PM, Gleb Smirnoff gleb...@freebsd.org wrote: To me this unlock/lock looks like a legacy from times, when the driver had a single mutex for both TX and RX parts. And removing this re-locking in foo_rxeof() was one of the aims for separate TX/RX locking. Really,

Re: ixgbe if_igb RX ring locking

On Tue, Oct 16, 2012 at 8:47 AM, Gleb Smirnoff gleb...@freebsd.org wrote: Can you please provide hints how can SIOCADDMULTI lead to obtaining RX lock in the stock driver? It doesn't. But it does acquire the core lock, and the core lock is acquired before the RX lock (in ixgbe_init, for

Re: ixgbe if_igb RX ring locking

On Sun, Oct 21, 2012 at 2:21 PM, Alexander V. Chernikov melif...@freebsd.org wrote: ix:rx - udp is also fairly obvious (here's one backtrace): The same question, where udp - ix:rx can happen ? It can't happen directly as far as I can tell. But to trigger a deadlock, all that has to happen is

Re: 'no buffer space available' after switch goes down on freeBSD 7.3

On Fri, Dec 21, 2012 at 7:13 AM, Tsaregorodtsev Denis tele...@extrim.itwrote: Hello, I maintenance ISP's DNS server which works under FreeBSD 7.3 and BIND 9.9.1-P4. The network adapter is Intel(R) PRO/1000 Network Connection, driver - em. The server is connected to a Cisco 6500 switch.

Re: 'no buffer space available' after switch goes down on freeBSD 7.3

I don't believe that this is fixed in later versions of the driver. The problem is that when the interface loses link the transmit queue can fill up. Once that happens the driver never gets any more calls from the network stack to make it send packets. Pinging the interface fixes it because the

Re: e1000 serdes link flap

On Wed, Jan 23, 2013 at 2:13 AM, Neel Natu neeln...@gmail.com wrote: Hi, I am running into a problem in head with the e1000 link state detection logic attached to a 82571EB serdes controller. The symptom is that the link state keeps flapping between up and down. After I enabled the debug

Re: mbuf tuning on 9.1

On Tue, Mar 12, 2013 at 5:31 PM, Boris Kochergin sp...@acm.poly.edu wrote: Additionally, can someone clarify the meaning of total vs. max for these values? -Boris It measures the amount of memory being used as that type of data structure. This is the total of the number of allocated items

Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST

What's the benefit in having a both an interrupt thread and task that performs the same function? It seems to me that having two threads that do the same job is what is making this so complicated. ___ freebsd-net@freebsd.org mailing list

Re: [PATCH] Netdump for review and testing -- preliminary version

On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson rwat...@freebsd.org wrote: + /* +* get and fill a header mbuf, then chain data as an extended +* mbuf. +*/ + MGETHDR(m, M_DONTWAIT, MT_DATA); The idea of calling into

Re: Debugging em(4) driver

It looks to me that you're getting a ton of input drops. That's presumably the cause of your issue. You can get the em driver to print debug information to the console by running: # sysctl dev.em.3.stats=1 # sysctl.dev.em.3.debug=1 The output should be available in dmesg and /var/log/messages

Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)?

This one bit me hard several months ago. Your analysis is correct. It's a hardware bug. The solution is to track in the driver whether the VME bit is set for the given queue, and if it isn't, ignore the VP bit. I meant to report this one to Jack but forgot, evidently. Ryan Stone

Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)?

will see that the VP bit is set and set the M_VLANTAG on the mbuf, and put 0 in m_pkthdr.ether_vtag. This means that the stack will treat the packet as if it was double vlan tagged, with outer tag being 0. Ryan Stone ___ freebsd-net@freebsd.org mailing list

Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)?

On Fri, Nov 26, 2010 at 3:46 PM, Jack Vogel jfvo...@gmail.com wrote: Ahh, OK, so how would this solution work: In rxeof, in addition to requiring VP to be set, also check that adapter-num_vlans is non-zero, in order to store the tag. Jack Yes, I believe that will work. Ryan Stone

Re: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)?

2010/11/26 Jack Vogel jfvo...@gmail.com: Just for the record, I was not aware of a hardware bug, and for right now no one is around :) I will ask around next week to see if something was known that I missed. I doubt that anybody at Intel will know about this one. To my knowledge, it's not in

Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR

As near as I can tell, the SR version of the X520 is going to be the same card, only with an SR SFP+ installed. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to

Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR

If it has an SFP+, won't the it be LR or SR depending on the type of SFP+ installed? ___ 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

Re: New device_polling algorithm

A couple of things that I forgot: - Note that DEVICE_POLLING is not included in GENERIC. You'll have to add the following to your kernel config to get polling support: options DEVICE_POLLING - you can enable polling on a interface with ifconfig(provided the driver supports polling) ifconfig

New device_polling algorithm

I've put together a patch against HEAD that replaces the device_polling algorithm(it should apply cleanly to stable/8 as well -- nothing has changed with polling in some time). The patch can be found here: http://people.freebsd.org/~rstone/kern_poll.diff The new algorithm makes use of the

Re: Polling with multiqueue support

Ah, you've anticipated me. This is just the kind of thing that I had in mind. I have some comments: - Why allocate the poll_if_t in ether_poll_register_? If you let the driver allocate it you don't have to worry about failure. And the driver can embed it in its rx_ring so it doesn't have to

Re: Intel ix (X520) disconnects when manipulating ips?

On Wed, Apr 20, 2011 at 9:37 AM, Steven Hartland kill...@multiplay.co.uk wrote: Seems there's an issue with the intel ix driver which causes it to bin connections when you manipulate ip aliases. This causes issues on boot when jails start as it bins other active sessions. Is this a know

Re: FreeBSD I/OAT (QuickData now?) driver

On Sat, Jun 11, 2011 at 2:55 PM, Luigi Rizzo ri...@iet.unipi.it wrote: I am also looking at other options, eg. a mixed mode where certain packets (e.g. depending on the MAC address) retain the usual path, whereas others stay in the netmap ring. Of course when you need to replicate packets

Re: m_pkthdr.rcvif dangling pointer problem

On Sun, Jul 17, 2011 at 7:59 AM, Vadim Goncharov vadim_nucli...@mail.ru wrote: Ways to improve are to be found from this starting point. However, are that +2 atomic ops per packet really so expensive? How many of atomic ops are already on that path? Any measures? On high-performance multiqueue

Re: Ethernet link status on i82576

I notice that the interface not up in your test. If you ifconfig it up does it detect that it has lost link? The driver isn't really running anymore when you bring the link down -- interrupts are disabled, for example, so it will never get a link down interrupt.

Re: m_pkthdr.rcvif dangling pointer problem

I ran headlong into this issue today when trying to test some network stack changes. It's depressingly easy to crash HEAD by periodically destroying vlan interfaces while you are sending traffic over those interfaces -- I get a panic within minutes.

pxeboot hangs if link bounces

as to what could have changed that triggers this BIOS bug. I've tried building with -DOLD_NFSv2 but that didn't resolve the problem. Ryan Stone ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe

Re: pxeboot hangs if link bounces

On Wed, Jul 27, 2011 at 12:45 PM, Ryan Stone ryst...@gmail.com wrote: I'm going to try a binary search to narrow down what set of changes introduced the problem, On that note, is there an faster way to cleanly build the boot code than a full buildworld? I can just make in sys/boot

Re: igb/ixgbe RSS/RX queues for non-IP traffic

On Wed, Sep 7, 2011 at 10:52 AM, Alexander V. Chernikov melif...@yandex-team.ru wrote: Particularly I'm trying to figure out how can I use all this variety of filters to get MPLS traffic split to different RX queues. I've got bad news for you on this. From Section 7.1.2.7 of the 82599

Re: FreeBSD 7-STABLE mbuf corruption

On Tue, Sep 13, 2011 at 2:36 PM, Arnaud Lacombe lacom...@gmail.com wrote: It did not crash, yet. The only downside is that after 3h30 and ~4h, igb(4) queues' handler started spinning infinitely, breaking network connectivity. I saw a similar issue on HEAD last week. The attached patch fix the

Re: FreeBSD 7-STABLE mbuf corruption

On Wed, Sep 14, 2011 at 7:40 AM, John Baldwin j...@freebsd.org wrote: You should probably commit that. I've been meaning to post it to -current to see if somebody could come up with a better approach to solving the problem, but if you're happy with it, I'll submit it to re@. I wonder if it

Re: FreeBSD 7-STABLE mbuf corruption

On Wed, Sep 14, 2011 at 7:40 AM, John Baldwin j...@freebsd.org wrote: You should probably commit that. I've been meaning to post it to -current to see if somebody could come up with a better approach to solving the problem, but if you're happy with it, I'll submit it to re@. I wonder if it

Re: which 10GE cards are supported by FreeBSD ?

On Sat, Sep 24, 2011 at 4:56 PM, Juli Mallett jmall...@freebsd.org wrote: It's actually not as trivial to grep for 10G NICs as implied, since some drivers have silly bugs, like ixgbe which sets if_baudrate to '10' (i.e. 1 000 000 000). I'm pretty sure that the bug is FreeBSD's.

[PATCH] Don't have ICMP Echo Replies copy fragmentation flags from Echo Request

Currently when FreeBSD responds to a ICMP Echo Request, it takes the original mbuf, rewrites a couple of fields (like the src/dst IP and the ICMP type), and then sends that mbuf back. As things are currently implemented, the Don't Fragment bit is kept in the ICMP replay. This can cause problems

ether_demux does not handle frames with embedded vlan tags

ether_demux currently assumes that all vlan-tagged packets that it sees have had the vlan stripped out and the M_VLAN tag is set, so it never checks the ether type for a vlan. However ng_ether_rcv_upper currently does not guarantee that this is the case(and there may be other code paths where

Re: ether_demux does not handle frames with embedded vlan tags

2011/10/18 rozhuk...@gmail.com: In what cases vlan-tagged packet can be received by ng_ether_rcv_upper ? If another node attaches to an ng_ether node's upper hook and sends a vlan tagged packet to the hook. ___ freebsd-net@freebsd.org mailing list

Re: ether_demux does not handle frames with embedded vlan tags

2011/10/19 rozhuk...@gmail.com: This may be a wrong configuration or QinQ: packet may have M_VLAN tag is set and still vlan-tagged (ether_type = VLAN) It is not QinQ in my case. The interface that the upper hook exports is that you send it a valid ethernet frame and it passes that frame up

Re: ether_demux does not handle frames with embedded vlan tags

On Wed, Oct 19, 2011 at 3:30 PM, Juli Mallett jmall...@freebsd.org wrote: Why should the requirements for the Netgraph path be any different to the non-Netgraph path?  If drivers must ensure that frames that reach ether_demux have had their VLAN tags stripped, so should Netgraph things that

Re: IPFW shows me Strangeness in fresh 8.2-RELEASE system

On Sun, Oct 23, 2011 at 5:31 PM, David DeSimone f...@verio.net wrote: Ethernet cards filter their traffic based on MAC address, not based on IP address. Use tcpdump -e to examine the destination MAC of the packets you are receiving, in order to determine whether you should receive them.

Re: Too much interrupts on ixgbe

On Mon, Oct 24, 2011 at 3:08 PM, Sergey Saley sergeysa...@gmail.com wrote: Nothing has changed after increasing mbufs count increasing: irq256: ix0:que 0                3013004       2431 irq257: ix0:que 1                 970295        783 irq258: ix0:que 2                 574782        463

Re: Too much interrupts on ixgbe

On Mon, Oct 24, 2011 at 3:51 PM, Sergey Saley sergeysa...@gmail.com wrote: MPD5, netgraph, pppoe.Types of traffic - any (customer traffic). Bying this card I counted on a 3-4G traffic at 3-4K pppoe sessions. It turned to 600-700Mbit/s, about 50K pps at 700-800 pppoe sessions. PPPoE is your

Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled

On Sun, Oct 30, 2011 at 4:57 AM, Hooman Fazaeli hoomanfaza...@gmail.com wrote: IMHO, this is not a driver issue and the real fix would be to change IFQ_HANDOFF to call if_start when the queue is full. I'm not sure that's the right approach. 99% of the time, calling if_start when the queue is

Re: net.isr.maxthreads tunable?

Currently you have to disable DEVICE_POLLING in your kernel config in order to use multiple netisr threads. Back in the spring I was working on a patch to fix this limitation, but at the time I was having trouble getting access to equipment to test it out on. I should be able to get some systems

Re: LOR in FreeBSD 8.1 w/ IPv6

This was fixed on HEAD in r207337. I believe that it was MFC'ed some time ago. http://svnweb.freebsd.org/base?view=revisionrevision=207337 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe,

em: Hardware Initialization Failed on 8.0-RELEASE

...@pci0:2:0:0: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 hdr=0x00 e...@pci0:2:0:1: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 hdr=0x00 Please let me know if there's anything else that you need. I'm willing to try patches or get more debug output. Thanks, Ryan Stone

Re: em: Hardware Initialization Failed on 8.0-RELEASE

The em driver version 6.2.9(that's the Intel version number) worked just fine, but it stopped working on multiple machines as soon as I upgraded, so I doubt that it's the hardware. ___ freebsd-net@freebsd.org mailing list

Re: em: Hardware Initialization Failed on 8.0-RELEASE

So it seems the problem is buggy hardware that incorrectly reports that is has a copper PHY instead of an internal serdes. For whatever reason this didn't matter to the old driver, but the new driver is tripping over the problem. *sigh* ___

Any work being done on ath9k/athn WiFi support?

I just bought a laptop with a Atheros AR9XXX and as far as I can tell there is no driver support yet in FreeBSD. Some googling has seemed to indicate that there is a driver in OpenBSD(athn) that supports this family of cards. I was wondering if there was any work underway to port this to

Re: Intel 82574L Gigabit Ethernet Controller

Hm, I see that you're using the ticks variable. To the best of my knowledge, changing the current time should not cause ticks to change. A lot of things, like the callout wheel, would be pretty broken if that were happening. My knowledge of this stuff is several major versions out of date,

Re: Intel 82574L Gigabit Ethernet Controller

No, defining EM_WATCHDOG as 10 * hz should mean that the watchdog expires after 10 seconds no matter what your kern.hz is. hz is set to the number of ticks in a second. ___ freebsd-net@freebsd.org mailing list

Re: no carrier by using 82599 10 Gigabit Ethernet

You have ifconfig'ed the interfaces up, right? ___ 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

Re: igb statistics error

If you look at the datasheet you will see that the statistics do not measure the same thing(why would Intel implement two hardware counters that measure the same thing?). The Good Packets Received Count measures the number of valid packets that passed one of the receive filters. In other words,

Re: Re: igb statistics error

The extra packets counted in tpr are packets received by the interface that were not addressed to that interface. The fact that your machine with a 82571 has not seen any such packets is just a coincidence. Whatever switch that machine is connected to has happened not to have flooded unicast

Re: support for L3/L4-filters in ixgbe

Currently there's interface for giving access to queues to userspace. One problem that you're going to run into is that the registers for all of the queues are mapped consecutively. There wouldn't be any way of preventing the application from messing around with queues that don't belong to it.

Re: support for L3/L4-filters in ixgbe

On Tue, Jul 20, 2010 at 5:55 PM, Ryan Stone ryst...@gmail.com wrote: Currently there's interface for giving access to queues to userspace. That should of course read Currently there's *no* interface... ___ freebsd-net@freebsd.org mailing list http

Re: mbuf changes

It's not a big thing but it would be nice to replace the m_next and m_nextpkt fields with queue.h macros. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to

Re: Cannot attribute both IPv4 and IPv6 to a VLAN interface

It seems to me that the mistake that you are making is that you are setting the vlan portion (e.g. vlan 18 vlandev em0) twice. The second time that the configuration is applied it fails. I believe that you want instead to put the following in rc.conf: ipv6_ifconfig_vlan18=xxx:xxx:xxx:460::

Re: EM(4) - Link flap when bridged and adding members (em bridge flap)

From a quick look at the code, whenever an interface is added to a bridge, if that interface does not support a feature currently enabled on the bridge then it has to disable that feature on all member interfaces of that bridge. That would re-init the em interface, which would cause a link flap.

HEADS UP: PCI SR-IOV infrastructure has been committed to head

I've just finished committing support for PCI Single Root I/O Virtualization in the pci subsystem to head. This should be a no-op for everyone right now, but there were some minor refactorings in the pci code that could have a lingering bug. I did make sure to test that it boots on a variety of

Re: netmap support for the Intel 40G card in head

This is great! Thanks to both you and Intel. I'm planning on getting SR-IOV support into head this week, which would allow you to create ixlv instances (on the same hardware). Any chance that you'd have the time to look into supporting SR-IOV for that driver too?

Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second port not present?

I think that you might be a bit confused about the behaviour. An ix port will only be missing if a) You have a non-Intel SFP+ installed b) hw.ix.unsupported_sfp=1 is not set in loader.conf ix ports that have no SFP+ installed do show up in ifconfig

Re: Reg Intel Fortville IXL driver on 11-CURRENT

On Wed, Jun 17, 2015 at 7:00 AM, Lakshmi Narasimhan Sundararajan lakshm...@msystechnologies.com wrote: [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ diff -c5pt ixl_txrx.c ixl_txrx.c.mod *** ixl_txrx.c Fri Jun 12 06:56:51 2015 --- ixl_txrx.c.mod Fri Jun 12 06:56:33 2015 ***

Re: [RFC] ifconfig description

On Jul 28, 2015 11:07 AM, Sergey Kandaurov pluk...@freebsd.org wrote: On 28 July 2015 at 20:55, Alexander V. Chernikov melif...@freebsd.org wrote: 28.07.2015, 15:32, Arseny Nasokin eir...@gmail.com: Separate ifconfig_IF_description will be simpler to use. I was also insisting on this..

Re: Intel XL710 broken link down detection?

On Wed, Nov 11, 2015 at 11:18 AM, Steven Hartland wrote: > Comparing this to the Linux driver which does detect the link down I've > discovered it actually polls the link status by default in its watchdog. > > Disabling this with "ethtool --set-priv-flags eth1 LinkPolling

route command will perform DNS lookup of invalid interface name

At $WORK, we have observed that if you attempt to add a route with the -iface flag, but you specify an incorrect interface name, the route command will perform a DNS lookup of the interface name. It appears that if the DNS lookup succeeds that it will treat the parameter to -iface as if it were a

Re: Outgoing packets being sent via wrong interface

An easier way to block ICMP redirects would be to set the sysctl: sysctl net.inet.icmp.drop_redirect=1 ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to

Re: Is netmap jumbo frames broken in STABLE?

The use of mbuf clusters larger than a single page really doesn't work. The problem is that over time physical memory becomes fragmented and eventually 9K of contiguous memory can't be allocated anymore. This is why many drivers now limit themselves to page-sized clusters. On Mon, Jun 6, 2016 at

Re: Regression? VLAN packet drop after upgrading from r281235

From a quick look at the vlan code, I can identify a few cases that might cause that counter to increment: 1) Error from the underlying ixgbe device. Does "netstat -dI ix0" show that the driver has been dropping packets? 2) Link down events on the underlying NIC. I believe that link flaps will

  1   2   3   >