Re: ixgbe and ixgbevf drivers are not working in virtualization environment
Le 26 oct. 2012 à 23:40, Sami Halabi a écrit : > Hi, > did you try explicit "ifconfig ix0 up" instead of rebooting? In fact, down, then up commands are necessary : ifconfig ix0 down ifconfig ix0 up Regards, Rémi > > Sami > > On Thu, Oct 25, 2012 at 4:29 PM, Rémi Pauchet wrote: > more informations about the SR-IOV issue. > > The problem is that the link is not updated in the virtual machine (VF > driver). > > ie: I start the VM with my fiber unplugged, the vf link is "no carrier". > I plug the fiber, the link stays in state "no carrier". > If I reboot the vm, I get the active link. > I reproduce the issue with esxi 5.1 and xenserver 6 > > > On other hand, I still haven't managed to get an active link with VMWare > DirectPath. > > Regards, > Rémi > > > Le 17 oct. 2012 à 09:42, Rémi Pauchet a écrit : > > > Hi > > > > My interface is configured, UP and running and I still can't get a link > > > > Can you help me with this issue ? > > > > Regards, > > Rémi > > > > > > Le 12 oct. 2012 à 09:38, Rémi Pauchet a écrit : > > > >> Hi, > >> > >> Unfortunately not: > >> > >> ix0: flags=8843 metric 0 mtu 1500 > >> > >> options=401bb > >> ether 00:e0:ed:1c:99:4e > >> inet 172.16.255.254 netmask 0x broadcast 172.16.255.255 > >> inet6 fe80::2e0:edff:fe1c:994e%ix0 prefixlen 64 scopeid 0x2 > >> nd6 options=29 > >> media: Ethernet autoselect > >> status: no carrier > >> ix1: flags=8843 metric 0 mtu 1500 > >> > >> options=401bb > >> ether 00:e0:ed:1c:99:4f > >> inet 172.17.255.254 netmask 0x broadcast 172.17.255.255 > >> inet6 fe80::2e0:edff:fe1c:994f%ix1 prefixlen 64 scopeid 0x3 > >> nd6 options=29 > >> media: Ethernet autoselect > >> status: no carrier > >> > >> Regards, > >> Rémi > >> > >> Le 11 oct. 2012 à 18:25, Jack Vogel a écrit : > >> > >>> The ixgbe device will not get link until you have run init, so assign it > >>> an address or just do an ifconfig up. > >>> > >>> I have never used the driver using a passthru type setup but I believe > >>> its been done successfully if > >>> memory serves. > >>> > >>> Jack > >>> > >>> > >>> On Thu, Oct 11, 2012 at 8:39 AM, Rémi Pauchet > >>> wrote: > >>> Hi, > >>> > >>> I'm trying to use the ixgbe (10Gb) driver in a FreeBSD virtual machine on > >>> an esxi 5 using DirectPath (PCI Passthrough) and the card is detected, > >>> but I can't get a link (status: no carrier) > >>> > >>> ix0: > >>> mem 0xd242-0xd243,0xd240-0xd2403fff irq 18 at device 0.0 on > >>> pci3 > >>> > >>> ix0: flags=8802 metric 0 mtu 1500 > >>> > >>> options=401bb > >>> ether 00:e0:ed:1c:99:4e > >>> nd6 options=29 > >>> media: Ethernet autoselect > >>> status: no carrier > >>> > >>> I have also tested with XenServer 6, using SR-IOV (ixgbevf driver) with > >>> the same result: the driver is loading, but no link detected. > >>> > >>> In both case (VMWare DirectPath and XenServer SR-IOV), I tested Linux > >>> with success. > >>> > >>> > >>> The card is an Intel 82599EB, the motherboard is an Intel X58 (supermicro > >>> X8ST3) with a Xeon W3680 and I've tested FreeBSD 8.3 and 9.0 > >>> > >>> I've found a forum thread with the same issue: > >>> http://forums.freebsd.org/showthread.php?t=29855 and no answer :) > >>> > >>> > >>> Please find in attachment the dmesg (boot -v) with the ix driver compiled > >>> with DEBUG flags using vmware. > >>> > >>> > >>> Can anyone provide feedback about this issue ? > >>> > >>> Regards, > >>> Rémi Pauchet > >>> > >>> > >>> > >> > > > > > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert >
Re: request for help: 'fixing' the 802.11 TX path
On 29.10.2012 04:53, Adrian Chadd wrote: On 28 October 2012 20:43, PseudoCylon wrote: Cannot we just add custom hand off function to ieee80211_start()? Yes. That's the general idea. But what I don't want to do is have it just wake up the driver TX taskqueue - well, unless we have to. That means we'll have two context switches for each frame being transmitted and that as a concept just sucks. See my (very recent) email to -wireless - I broke TCP throughput quite substantially by moving ath(4) TX into the taskqueue. I thought the problem was _just_ going to be how overlapping, direct dispatch TX could be preempted by the RX tasklet and TX completion, but there's obviously more going on. I can't believe that TCP is getting broken by just introducing some additional delay in the TX path. That can't add more than 300ms, can it? There must be something else going on. Most likely either severe packet loss (the m_nextpkt leak you mentioned earlier) or severe packet re-ordering. So don't rule out the TX taskqueue concept quite yet. -- Andre ___ 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: VIMAGE crashes on 9.x with hotplug net80211 devices
On Sunday 28 October 2012 19:47:20 Adrian Chadd wrote: > ping? > > Marko - would you be willing to add the if_free() vnet context setup into > -HEAD? Feel free to do it - though I'd suggest to use the CURVNET_SET_QUIET() variant there, to reduce the console spam with VNET_DEBUG. Marko Index: if.c === --- if.c(revision 242304) +++ if.c(working copy) @@ -513,7 +513,9 @@ if (!refcount_release(&ifp->if_refcount)) return; + CURVNET_SET_QUIET(ifp->if_vnet); if_free_internal(ifp); + CURVNET_RESTORE(); } /* ___ 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"
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/173137 net[em] em(4) unable to run at gigabit with 9.1-RC2 o kern/172985 net[patch] [ip6] lltable leak when adding and removing IP o kern/172895 net[ixgb] [ixgbe] do not properly determine link-state o kern/172683 net[ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net[netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net[panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net[ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net[oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net[bce] [panic] bce related kernel panic o kern/171728 net[arp] arp issue o kern/171711 net[dummynet] [panic] Kernel panic in dummynet o kern/171697 net[ip6] [ndp] panic when changing routes o kern/171532 net[ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net[ndis] undocumented dependency for ndis(4) o kern/171524 net[ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net[epair] [request] Add the ability to name epair device o kern/171228 net[re] [patch] if_re - eeprom write issues o kern/170701 net[ppp] killl ppp or reboot with active ppp connection c o kern/170267 net[ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net[fxp] pf/nat/jails not working if checksum offloading o kern/169898 netifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net[bge] [hang] system hangs, fully or partially after re o kern/169664 net[bgp] Wrongful replacement of interface connected net o kern/169620 net[ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net[ppp] umodem/ppp/3g stopped working after update from o kern/169438 net[ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net[ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net[em] Multiple em(4) not working with qemu o kern/168245 net[arp] [regression] Permanent ARP entry not deleted on o kern/168244 net[arp] [regression] Unable to manually remove permanent o kern/168183 net[bce] bce driver hang system o kern/167947 net[setfib] [patch] arpresolve checks only the default FI o kern/167603 net[ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net[em] [panic] Kernel panics in em driver o kern/167325 net[netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net[igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net[tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net[ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net[gre] gre(4) when using a tunnel source address from c o kern/166372 net[patch] ipfilter drops UDP packets with zero checksum o kern/166285 net[arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net[net] [patch] It should be possible to disable "promis o kern/165963 net[panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 netmbuf leak o kern/165643 net[net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net[ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net[request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net[bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net[ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net[ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net[vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net[igb] igb freezes after about 2 weeks of uptime o kern/165174 net[patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net[ip6] Does not work through the issue of ipv6 addresse o kern/164495 net[igb] connect double head igb to switch cause system t o kern/164490 net[pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net[gre] gre misses RUNNING flag after a reboot o kern/164265 net[netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net[igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 netfreebsd do not add itself to ping route packet o kern/162927 net
Re: request for help: 'fixing' the 802.11 TX path
On Mon, Oct 29, 2012 at 3:47 AM, Andre Oppermann wrote:
> On 29.10.2012 04:53, Adrian Chadd wrote:
>>
>> On 28 October 2012 20:43, PseudoCylon wrote:
>>
>>> Cannot we just add custom hand off function to ieee80211_start()?
>>
>>
>> Yes. That's the general idea. But what I don't want to do is have it
>> just wake up the driver TX taskqueue - well, unless we have to.
>>
>> That means we'll have two context switches for each frame being
>> transmitted and that as a concept just sucks.
Plan B
vap->iv_ifp->if_transmit = ieee80211_transmit;
ieee80211_transmit() /* new */
{
/* Alternatively, we can make a list of param and attach mbuf to it. */
HANDOFF(parent->if_snd, m);
ieee80211_new_tx(vap, m);
}
/* enque packet, but keep working on the same mbuf */
ieee80211_new_tx(vap, m)
{
encap;
if (fragment)
insert_fragmented_packet_to_queue;
/* don't forget about a fragmented packet */
for (; m->m_nextpkt != NULL; m = m->m_nextpkt)
parent->if_new_tx(vap, m);
}
/* keep working on the same mbuf */
driver_new_tx(vap, m)
{
do_descriptor_stuff;
m->m_flags |= ALL_SET;
/*
* If, for instance, processing of queue #5 packet finished
before queue #1,
* #5 packet will stay in queue until all of preceding packets
get processed.
*/
if (parent->if_sc->sc_tx == NOT_RUNNING &&
ifq_head->m_flags & ALL_SET)
driver_pass2hw(parent);
}
/* finally, process mbuf from the head of queue */
driver_pass2hw()
{
/* only one thread to dequeue */
if (atomic_compset(&sc->sc_tx, NOT_RUNNING, RUNNING) == 0)
return;
for (;;) {
DEQUEUE(ifq, m);
if (!(m->m_flags & ALL_SET)) {
PREPEND();
break;
}
/*
* want to do seq stuff somewhere in ieee80211_*(),
* but I guess this is the only place could do.
*/
do_seqnum_stuff;
/* simply put a packet onto dma-able memory area */
pass2hw;
}
sc->sc_tx = NOT_RUNNING;
}
No additional context switching, no long-held lock, but first queue first tx.
AK
>>
>> See my (very recent) email to -wireless - I broke TCP throughput quite
>> substantially by moving ath(4) TX into the taskqueue. I thought the
>> problem was _just_ going to be how overlapping, direct dispatch TX
>> could be preempted by the RX tasklet and TX completion, but there's
>> obviously more going on.
>
>
> I can't believe that TCP is getting broken by just introducing some
> additional delay in the TX path. That can't add more than 300ms,
> can it? There must be something else going on. Most likely either
> severe packet loss (the m_nextpkt leak you mentioned earlier) or
> severe packet re-ordering.
>
> So don't rule out the TX taskqueue concept quite yet.
>
> --
> Andre
>
___
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: request for help: 'fixing' the 802.11 TX path
The problem with this is that fragments need to be handed as an entire list to the driver. ath(4) looks ahead to the next fragment, calculates the rate, and then adds that to the NAV of the previous frame. So yeah what I'm thinking about for now is something like the following: * say that wifi drivers have to move to if_transmit(); * "abuse" if_transmit() semantics to assume a m_nextpkt chain of mbufs is a fragment list for a single frame; * for now, figure out why the hell the ath(4) TX taskqueue setup is providing crappy throughput and fix _that_; * then migrate the net80211 TX to a taskqueue; * .. and then just undo the ath(4) TX taskqueue since now TX is serialised by if_transmit() inside the net80211 TX taskqueue. There are other things to do, mostly surrounding fixing up the power save queue handling to repopulate the queue packet-by-packet, rather than doing if_snd gymnastics. Once that's done, we can look at ways to implement serialisation besides just using a taskqueue - eg, using the running/not-running flag idea you've suggested. The big problem here is that once TX completion occurs, drivers kick off new TX. Now, if all TX is triggered by a frame TX, the TX will stall until the next frame is attempted. What we'd have to do is tell the drivers how to 'kick' the net80211 stack TX again. Adrian ___ 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"
Missing / broken ixgbe sysctl's and tunables PR kern/173201 (patch included)
I've been having issues getting a ixgbe (ix) device to link reliably in a decent amount of time at boot to 1Gbps switch connected on cat 5, even netwait was timing out. Having a dig in the code there's advertise_speed which seemed like it was just what I was looking for but unfortunately sysctl.conf is too late in the boot process to have any effect. Looking for the syscyl for ixgbe I found none so dug around and noticed all the tunables where missing sysctl's hence not displaying. In addition noticed enable_aim was using a common var instead of device independent which is what its config dev.ix.0.enable_aim indicated to me. I've created a patch to fix all of the above which can be found here in PR here when its been processed:- http://www.freebsd.org/cgi/query-pr.cgi?pr=173201 Hope it helps. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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"
