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/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/165032 net[mii] [patch] brgphy(4) is not used for BCM57780 o kern/164901 net[regression] [patch] [lagg] igb/lagg poor traffic dist o kern/164569 net[msk] [hang] msk network driver cause freeze in FreeBS 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/164400 net[ipsec] immediate crash after the start of ipsec proce 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[tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net[ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net[dummynet] [panic] seldom dummynet panics o kern/162509 net[re] [panic] Kernel panic may be related to if_re.c (r o kern/162352 net[patch] Enhancement: add SO_PROTO to socket.h o kern/162153 net[em] intel em driver 7.2.4 don't compile o kern/162110 net[igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net[ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net[re] RTL8169SC - re0: PHY write failed o kern/161277 net[em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net[igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 netIntel PRO/1000 connection breaks under load until rebo o kern/160693 net[gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net[msk] phy write timeout on HP 5310m o kern/160293 net[ieee80211] ppanic] kernel panic during network setup o kern/160206 net[gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net[udp] write UDPv4: No buffer space available (code=55) o kern/159795 net[tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net[ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net[tcp] [panic] panic: soabort: so_count o kern/159603 net[netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net[netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net[em] em watchdog timeouts o kern/159203 net[wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net[bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net[ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net[ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net[ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net[em] TSO breaks BPF packet captures with em driver f kern/157802 net[dummynet] [panic] kernel panic in dummynet o kern/157785 netamd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net[re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net[em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net[ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net[re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net[ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net[network.subr] [patch] stf(4) can not communicate betw o kern/157182 net[lagg] lagg interface not working together with epair o kern/156877 net[dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net[em] em0 fails to init on CURRENT after March 17 o kern/156408 net[vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net[icmp]: host can ping other subnet but no have IP from o kern/156317 net[ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net[ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net[if_bridge][divert][i
Re: [urtw] Random wireless crash / kernel panic
I do still have the kernel and the crash dump. I'll try that fix tonight
to see how it goes. Unfortunately, the kernel doesn't usually crash, more
likely the wifi stops working and I am forced to reboot the machine to get
it working again.
On Feb 20, 2012 2:56 AM, "Adrian Chadd" wrote:
>
> Hi,
>
> Do you still have the kernel?
>
>
> On 19 February 2012 18:23, Adam Twardowski
wrote:
> > Hello, I submitted a bug report the other day regarding a kernel panic
> > related to the urtw driver. If anyone needs any additional
> > infromation, please let me know.
>
> It looks like there's no node associated with that particular TX.
>
> Change:
>
>if (m->m_flags & M_TXCB) {
>
>
> to
>
>if ((m->m_flags & M_TXCB) && (data->ni != NULL)) {
>
> .. that may fix the crash but it doesn't explain how an mbuf marked
> M_TXCB has no node..
>
>
>
> 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"
Re: [urtw] Random wireless crash / kernel panic
On Monday 20 February 2012 18:03:45 Adam Twardowski wrote: > I do still have the kernel and the crash dump. I'll try that fix tonight > to see how it goes. Unfortunately, the kernel doesn't usually crash, more > likely the wifi stops working and I am forced to reboot the machine to get > it working again. Building urtw(4) as module here helps a lot, kldunload/kldload is just so much faster than a reboot. :) I have a bunch of asorted fixes [1] for urtw(4) which needs some further testing, though I still wasn't able to fix the issue which made me look into this in the first place.. As a test case I force a disconnection from the AP side a few times, which will eventually result in a device timeout and the requirement to reload the module. I believe that one of those might actually address the panic you're seeing, though, it doesn't fix the device timeout. [1] http://techwires.net/~bschmidt/urtw/ -- Bernhard ___ 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: Abstracting struct ifnet
On Thu, Feb 16, 2012 at 08:16:22PM -0800, Marcel Moolenaar wrote:
> All,
>
> Juniper is in the final phases of creating a clean separation
> between FreeBSD and Junos, so as to make upgrades of FreeBSD
> easier. This also allows Juniper to track -current and be more
> active FreeBSD contributors.
>
> To that end, we have a short-term and hopefully short-lived
> problem to solve, which is the ability to use FreeBSD's network
> drivers against the Junos network stack. As some may know, the
> Junos network stack has split up struct ifnet into a physical
> and logical component, called ifdev and iflogical.
>
> We've tried a few approaches to bridge the gap between ifnet
> on the one hand and ifdev and iflogical on the other and found
> that abstracting ifnet and using accessor functions is the
> best way to allow us to use FreeBSD drivers with the Junos
> network stack, while retaining the ability to use them with
> the FreeBSD stack.
>
> FreeBSD is also looking at breaking up ifnet and with that in
> mind, I was wondering if there would be any resistance to
> changing network drivers to use accessor functions or macros
> instead of direct pointer dereferences?
>
> For example, do something like:
>
> Index: if_fxp.c
> ===
> --- if_fxp.c (revision 231178)
> +++ if_fxp.c (working copy)
> @@ -823,13 +823,14 @@
> }
>
> if_initname(ifp, device_get_name(dev), device_get_unit(dev));
> - ifp->if_init = fxp_init;
> - ifp->if_softc = sc;
> - ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
> - ifp->if_ioctl = fxp_ioctl;
> - ifp->if_start = fxp_start;
> + if_set_init(ifp, fxp_init);
> + if_set_softc(ifp, sc);
> + if_set_flags(ifp, IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST, 0);
> + if_set_ioctl(ifp, fxp_ioctl);
> + if_set_start(ifp, fxp_start);
>
> - ifp->if_capabilities = ifp->if_capenable = 0;
> + if_set_capabilities(ifp, 0);
> + if_set_capenable(ifp, 0);
>
> /* Enable checksum offload/TSO for 82550 or better chips */
> if (sc->flags & FXP_FLAG_EXT_RFA) {
>
> Such a scheme, while initially touching a lot of driver,
> would make it easier to break up ifnet *and* also make it
> easier to hide ABI/API changes from driver vendors (esp.
> when the accessor functions are non-inlined functions and
> not macros or inlines). This is particularly useful for
> Juniper, where we have worked towards network stacks as
> (pre-)loadable modules so as to help with migration and
> validation.
>
> Thoughts, feedback and suggestion are welcome,
The concept seems fine to me and I like that it might simplify future
API changes. Have you verified that if_get_*() accessors don't add
significant overhead?
I agree with the concern raised by Luigi about intra-branch
compatability. My prefered solution to that would be to MFC the adition
of the accessors pretty much instantly and to commit the changes to
individual drivers seperately to allow them to be merged as needed by
driver maintainers.
-- Brooks
pgpSv3ZgguMK4.pgp
Description: PGP signature
Re: Abstracting struct ifnet
On Mon, Feb 20, 2012 at 05:16:02PM -0600, Brooks Davis wrote: > > The concept seems fine to me and I like that it might simplify future > API changes. Have you verified that if_get_*() accessors don't add > significant overhead? the vast majority of these fields are only accessed in the control path, not on each packet, so there isn't really a performance issue. Besides they can be trivially implemted as macros or inline functions. cheers luigi ___ 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: Abstracting struct ifnet
On 20 February 2012 16:15, Luigi Rizzo wrote: >> The concept seems fine to me and I like that it might simplify future >> API changes. Have you verified that if_get_*() accessors don't add >> significant overhead? > > the vast majority of these fields are only accessed in the control path, > not on each packet, so there isn't really a performance issue. Besides > they can be trivially implemted as macros or inline functions. I doubt Juniper need _binary_ level compatibility. So we could get away with inline methods. This sort of thing just makes source level compatibility a lot easier. 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"
Re: Abstracting struct ifnet
On 20 February 2012 18:21, Juli Mallett wrote: > > It's not just about Juniper, though, it's about us, and how much this > buys us. Using inlines buys us some source compatibility and the > ability to add some invariants, but is no different to macros in terms > of KBI within a version of FreeBSD, or between versions. We can't > make ifnet opaque with inlines. Adding a member to ifnet which is > opaque[*] and which has the fields most likely to change in size, > order, existence, etc., and leaving a few that are needed in the fast > path and will be used by macros/inlines is probably where we should > end up. > > *: Obviously ifnet should be a value member of the opaque type, and > the ifnet should include a pointer to the opaque type, or something > like that, since you can't make an opaque struct a value member, which > is probably obvious, but I wanted to be clearish. Is the target though _binary_ compatibility? Just having a blessed method of doing accessor method things will buy more source flexibility. The KBI can stay the same in the default case and IMHO this kind of thing gives developers more power to do smart invariant and debugging things. Being able to say "inform me every time an interface flag changes" would actually be kind of nice when debugging some of the issues i've been facing with ath. I've been half tempted to do this -inside- the ath driver, partially to restore the OS portability it once tried to achieve. 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"
Re: Abstracting struct ifnet
On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote: > Is the target though _binary_ compatibility? Just having a blessed > method of doing accessor method things will buy more source > flexibility. The KBI can stay the same in the default case and IMHO > this kind of thing gives developers more power to do smart invariant > and debugging things. KBI compatibility requires very little discipline and makes loadable modules for network drivers much less hellish. Inlines, macros and full visibility of ifnet in -current may be useful, but unless there's a performance reason for doing so, retaining KBI compatibility *and* the ability to merge ifnet changes to -stable sounds pretty nice to me. > Being able to say "inform me every time an interface flag changes" > would actually be kind of nice when debugging some of the issues i've > been facing with ath. I've been half tempted to do this -inside- the > ath driver, partially to restore the OS portability it once tried to > achieve. I think that it is rare that this is useful in debugging, and something of a red herring. Even invariants are almost a red herring: really, we shouldn't be using these individual methods to tweak structure fields, either, we should have a way of describing a network driver more semantically, such that the invariants are richer and also not as complicated, and also more comprehensive. Source compatibility is the biggest win, but a little self-discipline to win what measure of binary compatibility we can seems perfectly sensible. (And at some point, we could even replace ifnet with something that's less of a strange grab bag assortment that's awkward to explain to new driver writers, and keep both source and binary compatibility for a reasonable period in doing so. Unlikely to happen in the near term, but wouldn't it be nice? ___ 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: [urtw] Random wireless crash / kernel panic
On Mon, Feb 20, 2012 at 12:32 PM, Bernhard Schmidt wrote: > On Monday 20 February 2012 18:03:45 Adam Twardowski wrote: >> I do still have the kernel and the crash dump. I'll try that fix tonight >> to see how it goes. Unfortunately, the kernel doesn't usually crash, more >> likely the wifi stops working and I am forced to reboot the machine to get >> it working again. > > Building urtw(4) as module here helps a lot, kldunload/kldload is just so > much faster than a reboot. :) > > I have a bunch of asorted fixes [1] for urtw(4) which needs some further > testing, though I still wasn't able to fix the issue which made me look into > this in the first place.. As a test case I force a disconnection from the AP > side a few times, which will eventually result in a device timeout and the > requirement to reload the module. I believe that one of those might actually > address the panic you're seeing, though, it doesn't fix the device timeout. > > [1] http://techwires.net/~bschmidt/urtw/ > > -- > Bernhard Bernhard, I just applied your four patches and rebooted. I also went with a module like you suggested. We will see how it goes. I did not apply Adrians change above, not sure if it was necessary. ___ 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: Abstracting struct ifnet
On Mon, Feb 20, 2012 at 16:37, Adrian Chadd wrote: > On 20 February 2012 16:15, Luigi Rizzo wrote: > >>> The concept seems fine to me and I like that it might simplify future >>> API changes. Have you verified that if_get_*() accessors don't add >>> significant overhead? >> >> the vast majority of these fields are only accessed in the control path, >> not on each packet, so there isn't really a performance issue. Besides >> they can be trivially implemted as macros or inline functions. > > I doubt Juniper need _binary_ level compatibility. So we could get > away with inline methods. > > This sort of thing just makes source level compatibility a lot easier. It's not just about Juniper, though, it's about us, and how much this buys us. Using inlines buys us some source compatibility and the ability to add some invariants, but is no different to macros in terms of KBI within a version of FreeBSD, or between versions. We can't make ifnet opaque with inlines. Adding a member to ifnet which is opaque[*] and which has the fields most likely to change in size, order, existence, etc., and leaving a few that are needed in the fast path and will be used by macros/inlines is probably where we should end up. *: Obviously ifnet should be a value member of the opaque type, and the ifnet should include a pointer to the opaque type, or something like that, since you can't make an opaque struct a value member, which is probably obvious, but I wanted to be clearish. ___ 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"
