Re: Question about GPIO bitbang MII
On Mon, Oct 10, 2011 at 12:58 AM, Marius Strobl wrote: > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: >> Hi, >> >> Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using >> gpio-bitbang mii that I can refer to? Thanks. >> It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang >> mii, >> and it's useful for porting embedded devices. >> > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > which (im)ports these and converts drivers to take advantage of it here: > http://people.freebsd.org/~marius/mii_bitbang.diff > You can also hook up that generic MII bitbang'ing code up to GPIO. Awesome! This is what I want, thank you very much, Marius. > Marius Best regards, Dave. ___ 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/161381 net[re] RTL8169SC - re0: PHY write failed o kern/161277 net[em] [patch] BMC cannot receive IPMI traffic after loa o kern/161123 net[carp] [patch] when preemption is enabled carp interfa 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/159602 net[netinet] [patch] arp_ifscrub() is called even if IFF_ 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][ipfw] unable to correctly re-injec o kern/156226 net[lagg]: failover does not announce the failover to swi o kern/156030 net[ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 netifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net[multicast] problems with multicast s kern/155642 net[request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net[flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net[panic] Kernel panics with "sbdrop" message o kern/155585 net[tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155420 net[vlan] adding vlan break existent vlan o bin/155365 net[patch] routed(8): if.c in routed fails to compile if o kern/155177 net[route] [panic] Panic when inject routes in kernel o kern/155030 net[igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net[msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net[bce] [panic] kernel panic in bce0 driver o kern/154943 net[gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net[request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net[netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net[em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net[tcp] [panic] Random kernel panics on tcp_output o kern/154557 net[tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net[if_bridge] K
Re: bce(4) with IPMI
On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote: > > Could you try attached patch? Yeah, this does work on the r410 ... however, I can't test the "negative" case here where the bce(4) driver runs across a chipset where sc->bce_flags & BCE_MFW_ENABLE_FLAG == 0 I tried disabling the Dell IPMI controller, but the h/w is still there doing "things". So, this may not be the flag you want to use. Sean ___ 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"
panic in tcp_drop (and fix for it)
While stress testing a few systems, I encountered a panic in tcp_drop
due to NULL tp->t_inpcb. tcp_drop had been called by tcp_timer_rexmt.
The problem is that timer_rexmt lets go of the pcbinfo and inp locks and
the inp could be dropped by the time it re-acquires the locks.
The attached patch fixes the problem. I've observed the counter in the
patch go up by 2-3 in 48 hours or so. If someone can review the patch
I can push it (without the counter) to head.
Regards,
Navdeep
--- a/sys/netinet/tcp_timer.c
+++ b/sys/netinet/tcp_timer.c
@@ -439,6 +439,8 @@
CURVNET_RESTORE();
}
+static int tcp_rexmt_inpdrop_race = 0;
+
void
tcp_timer_rexmt(void * xtp)
{
@@ -495,6 +497,14 @@
CURVNET_RESTORE();
return;
}
+ if (inp->inp_flags & INP_DROPPED) {
+ tcp_rexmt_inpdrop_race++;
+ INP_WUNLOCK(inp);
+ INP_INFO_WUNLOCK(&V_tcbinfo);
+ CURVNET_RESTORE();
+ return;
+ }
+
tp = tcp_drop(tp, tp->t_softerror ?
tp->t_softerror : ETIMEDOUT);
headlocked = 1;
___
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: bce(4) with IPMI
On Mon, Oct 10, 2011 at 09:42:22AM -0700, Sean Bruno wrote:
> On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote:
> >
> > Could you try attached patch?
>
> Yeah, this does work on the r410 ... however, I can't test the
> "negative" case here where the bce(4) driver runs across a chipset where
> sc->bce_flags & BCE_MFW_ENABLE_FLAG == 0
>
> I tried disabling the Dell IPMI controller, but the h/w is still there
> doing "things". So, this may not be the flag you want to use.
>
Hmm, then could you try attached patch again?
> Sean
>
Index: sys/dev/bce/if_bce.c
===
--- sys/dev/bce/if_bce.c(revision 226123)
+++ sys/dev/bce/if_bce.c(working copy)
@@ -761,7 +761,7 @@ bce_print_adapter_info(struct bce_softc *sc)
printf("2.5G"); i++;
}
- if (sc->bce_flags & BCE_MFW_ENABLE_FLAG) {
+ if (sc->bce_flags & BCE_MFW_PRESENT_FLAG) {
if (i > 0) printf("|");
printf("MFW); MFW (%s)\n", sc->bce_mfw_ver);
} else {
@@ -1221,7 +1221,7 @@ bce_attach(device_t dev)
/* Check if any management firwmare is enabled. */
val = bce_shmem_rd(sc, BCE_PORT_FEATURE);
if (val & BCE_PORT_FEATURE_ASF_ENABLED) {
- sc->bce_flags |= BCE_MFW_ENABLE_FLAG;
+ sc->bce_flags |= BCE_MFW_PRESENT_FLAG;
/* Allow time for firmware to enter the running state. */
for (int i = 0; i < 30; i++) {
@@ -1246,6 +1246,7 @@ bce_attach(device_t dev)
memcpy(&sc->bce_mfw_ver[i], &val, 4);
i += 4;
}
+ sc->bce_flags |= BCE_MFW_ENABLE_FLAG;
} else {
/* May cause firmware synchronization timeouts. */
BCE_PRINTF("%s(%d): Management firmware enabled "
@@ -6158,7 +6159,8 @@ bce_ifmedia_sts(struct ifnet *ifp, struct ifmediar
BCE_LOCK(sc);
- if ((ifp->if_flags & IFF_UP) == 0) {
+ if ((ifp->if_flags & IFF_UP) == 0 &&
+ (sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0) {
BCE_UNLOCK(sc);
return;
}
Index: sys/dev/bce/if_bcereg.h
===
--- sys/dev/bce/if_bcereg.h (revision 226123)
+++ sys/dev/bce/if_bcereg.h (working copy)
@@ -6431,11 +6431,12 @@ struct bce_softc
#define BCE_NO_WOL_FLAG0x0008
#define BCE_USING_DAC_FLAG 0x0010
#define BCE_USING_MSI_FLAG 0x0020
-#define BCE_MFW_ENABLE_FLAG0x0040
-#define BCE_ONE_SHOT_MSI_FLAG 0x0080
-#define BCE_USING_MSIX_FLAG0x0100
-#define BCE_PCIE_FLAG 0x0200
-#define BCE_USING_TX_FLOW_CONTROL 0x0400
+#define BCE_MFW_PRESENT_FLAG 0x0040
+#define BCE_MFW_ENABLE_FLAG0x0080
+#define BCE_ONE_SHOT_MSI_FLAG 0x0100
+#define BCE_USING_MSIX_FLAG0x0200
+#define BCE_PCIE_FLAG 0x0400
+#define BCE_USING_TX_FLOW_CONTROL 0x0800
/* Controller capability flags. */
u32 bce_cap_flags;
___
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: panic in tcp_drop (and fix for it)
On 10.10.2011 19:36, Navdeep Parhar wrote:
While stress testing a few systems, I encountered a panic in tcp_drop
due to NULL tp->t_inpcb. tcp_drop had been called by tcp_timer_rexmt.
The problem is that timer_rexmt lets go of the pcbinfo and inp locks and
the inp could be dropped by the time it re-acquires the locks.
The attached patch fixes the problem. I've observed the counter in the
patch go up by 2-3 in 48 hours or so. If someone can review the patch
I can push it (without the counter) to head.
Looks good w/o the counter.
Regards,
Navdeep
--- a/sys/netinet/tcp_timer.c
+++ b/sys/netinet/tcp_timer.c
@@ -439,6 +439,8 @@
CURVNET_RESTORE();
}
+static int tcp_rexmt_inpdrop_race = 0;
+
void
tcp_timer_rexmt(void * xtp)
{
@@ -495,6 +497,14 @@
CURVNET_RESTORE();
return;
}
+ if (inp->inp_flags& INP_DROPPED) {
+ tcp_rexmt_inpdrop_race++;
+ INP_WUNLOCK(inp);
+ INP_INFO_WUNLOCK(&V_tcbinfo);
+ CURVNET_RESTORE();
+ return;
+ }
+
tp = tcp_drop(tp, tp->t_softerror ?
tp->t_softerror : ETIMEDOUT);
headlocked = 1;
___
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"
___
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: bce(4) with IPMI
On Mon, 2011-10-10 at 10:47 -0700, YongHyeon PYUN wrote: > On Mon, Oct 10, 2011 at 09:42:22AM -0700, Sean Bruno wrote: > > On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote: > > > > > > Could you try attached patch? > > > > Yeah, this does work on the r410 ... however, I can't test the > > "negative" case here where the bce(4) driver runs across a chipset where > > sc->bce_flags & BCE_MFW_ENABLE_FLAG == 0 > > > > I tried disabling the Dell IPMI controller, but the h/w is still there > > doing "things". So, this may not be the flag you want to use. > > > > Hmm, then could you try attached patch again? > > > Sean > > hrm indeed. I don't know that the Dell DRAC thing actually does anythign to the running IPMI controller on the host. Disabling the IPMI/DRAC completely in the BIOS of the DRAC does seem to have any effect on this flag. -bash-4.2$ dmesg |grep -i bce bce0: mem 0xd800-0xd9ff irq 36 at device 0.0 on pci1 bce0: Reserved 0x200 bytes for rid 0x10 type 3 at 0xd800 bce0: attempting to allocate 1 MSI vectors (16 supported) bce0: using IRQ 256 for MSI miibus0: on bce0 bce0: bpf attached bce0: Ethernet address: a4:ba:db:2b:6d:58 bce0: [MPSAFE] bce0: [ITHREAD] bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); Flags (MSI|MFW); MFW (NCSI 2.0.8) bce1: mem 0xdc00-0xddff irq 48 at device 0.1 on pci1 bce1: Reserved 0x200 bytes for rid 0x10 type 3 at 0xdc00 bce1: attempting to allocate 1 MSI vectors (16 supported) bce1: using IRQ 257 for MSI miibus1: on bce1 bce1: bpf attached bce1: Ethernet address: a4:ba:db:2b:6d:59 bce1: [MPSAFE] bce1: [ITHREAD] bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); Flags (MSI|MFW); MFW (NCSI 2.0.8) bce1: link state changed to UP ___ 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: bce(4) with IPMI
On Mon, Oct 10, 2011 at 11:24:06AM -0700, Sean Bruno wrote: > On Mon, 2011-10-10 at 10:47 -0700, YongHyeon PYUN wrote: > > On Mon, Oct 10, 2011 at 09:42:22AM -0700, Sean Bruno wrote: > > > On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote: > > > > > > > > Could you try attached patch? > > > > > > Yeah, this does work on the r410 ... however, I can't test the > > > "negative" case here where the bce(4) driver runs across a chipset where > > > sc->bce_flags & BCE_MFW_ENABLE_FLAG == 0 > > > > > > I tried disabling the Dell IPMI controller, but the h/w is still there > > > doing "things". So, this may not be the flag you want to use. > > > > > > > Hmm, then could you try attached patch again? > > > > > Sean > > > > > hrm indeed. I don't know that the Dell DRAC thing actually does > anythign to the running IPMI controller on the host. Disabling the > IPMI/DRAC completely in the BIOS of the DRAC does seem to have any > effect on this flag. > > -bash-4.2$ dmesg |grep -i bce > bce0: mem > 0xd800-0xd9ff irq 36 at device 0.0 on pci1 > bce0: Reserved 0x200 bytes for rid 0x10 type 3 at 0xd800 > bce0: attempting to allocate 1 MSI vectors (16 supported) > bce0: using IRQ 256 for MSI > miibus0: on bce0 > bce0: bpf attached > bce0: Ethernet address: a4:ba:db:2b:6d:58 > bce0: [MPSAFE] > bce0: [ITHREAD] > bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); > Flags (MSI|MFW); MFW (NCSI 2.0.8) > bce1: mem > 0xdc00-0xddff irq 48 at device 0.1 on pci1 > bce1: Reserved 0x200 bytes for rid 0x10 type 3 at 0xdc00 > bce1: attempting to allocate 1 MSI vectors (16 supported) > bce1: using IRQ 257 for MSI > miibus1: on bce1 > bce1: bpf attached > bce1: Ethernet address: a4:ba:db:2b:6d:59 > bce1: [MPSAFE] > bce1: [ITHREAD] > bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); > Flags (MSI|MFW); MFW (NCSI 2.0.8) > bce1: link state changed to UP > Did you capture this message generated after disabling IPMI/DRAC in BIOS? I thought you had to use Broadcom's separate program to disable management firmware. Does the last patch solve the problem? It's still not clear to me. The last patch allows accessing PHY status when there is a management firmware regardless of its running state. > ___ 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: Question about GPIO bitbang MII
On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > Hi, > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > gpio-bitbang mii that I can refer to? Thanks. > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang > > mii, > > and it's useful for porting embedded devices. > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > which (im)ports these and converts drivers to take advantage of it here: > http://people.freebsd.org/~marius/mii_bitbang.diff Patch looks good to me. What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) and xe(4))? > You can also hook up that generic MII bitbang'ing code up to GPIO. > > Marius ___ 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: Error - mysql_connect: Operation not permitted.
> > > > Appreciate any advice offered. > > Thanks. Dear "gi", Please do not cross post to different mailing lists. You ask something about PF and not specifically about networking things at the moment. I didn't read the pf.conf and such, but if something tricks on pf you can mostly see that either in your logs (tcpdump pflog0, read the documentation to see the advised settings here!) and see whether that might cause things to fail. As I can read this from your current feedback, you didn't test that yet and it would be great if you can see whether there are issues there. If you can look into this yourself this will help you in your later queste. Thanks! Remko p.s Remove the -net mailing list when you reply! -- /"\ With kind regards,| re...@elvandar.org \ / Remko Lodder | re...@freebsd.org XFreeBSD| http://www.evilcoder.org / \ The Power to Serve| Quis custodiet ipsos custodes ___ 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: bce(4) with IPMI
On Mon, 2011-10-10 at 12:06 -0700, YongHyeon PYUN wrote:
> Did you capture this message generated after disabling IPMI/DRAC in
> BIOS? I thought you had to use Broadcom's separate program to
> disable management firmware.
>
> Does the last patch solve the problem?
> It's still not clear to me. The last patch allows accessing PHY
> status when there is a management firmware regardless of its
> running state.
The latest patchset you sent me does indeed allow IPMI to function. So,
awesome!
I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I couldn't
see any driver detection of this status. So, when I add this:
> if ((ifp->if_flags & IFF_UP) == 0 &&
>(sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0){
> printf("%s: BCE detected MFW not present\n", __func__);
I don't see any change in behavior with IPMI enabled or disabled via the
Dell "DRAC" ROM Menu.
Sean
___
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: bce(4) with IPMI
On Mon, Oct 10, 2011 at 01:35:05PM -0700, Sean Bruno wrote:
> On Mon, 2011-10-10 at 12:06 -0700, YongHyeon PYUN wrote:
> > Did you capture this message generated after disabling IPMI/DRAC in
> > BIOS? I thought you had to use Broadcom's separate program to
> > disable management firmware.
> >
> > Does the last patch solve the problem?
> > It's still not clear to me. The last patch allows accessing PHY
> > status when there is a management firmware regardless of its
> > running state.
>
> The latest patchset you sent me does indeed allow IPMI to function. So,
> awesome!
>
Thanks for testing! :-)
> I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I couldn't
> see any driver detection of this status. So, when I add this:
>
> > if ((ifp->if_flags & IFF_UP) == 0 &&
> >(sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0){
> > printf("%s: BCE detected MFW not present\n", __func__);
>
>
> I don't see any change in behavior with IPMI enabled or disabled via the
> Dell "DRAC" ROM Menu.
>
I thought you may have seen "MFW(NOT RUNNING)" if management
firmware is present and you disabled IPMI in device attach time.
You may have to enable bootverbose to see it.
If management firmware is present and running you may have seen
actual management firmware version string.
> Sean
>
___
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: kern/159601: commit references a PR
The following reply was made to PR kern/159601; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/159601: commit references a PR
Date: Mon, 10 Oct 2011 21:41:43 + (UTC)
Author: qingli
Date: Mon Oct 10 21:41:34 2011
New Revision: 226237
URL: http://svn.freebsd.org/changeset/base/226237
Log:
MFC 226114
Remove the reference held on the loopback route when the interface
address is being deleted. Only the last reference holder deletes the
loopback route. All other delete operations just clear the IFA_RTSELF
flag.
PR: kern/159601
Submitted by:pluknet
Reviewed by: discussed on net@
Modified:
stable/8/sys/netinet/in.c
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/amd64/include/xen/ (props changed)
stable/8/sys/cddl/contrib/opensolaris/ (props changed)
stable/8/sys/contrib/dev/acpica/ (props changed)
stable/8/sys/contrib/pf/ (props changed)
Modified: stable/8/sys/netinet/in.c
==
--- stable/8/sys/netinet/in.c Mon Oct 10 21:38:19 2011(r226236)
+++ stable/8/sys/netinet/in.c Mon Oct 10 21:41:34 2011(r226237)
@@ -1126,8 +1126,10 @@ in_scrubprefix(struct in_ifaddr *target,
RT_LOCK(ia_ro.ro_rt);
if (ia_ro.ro_rt->rt_refcnt <= 1)
freeit = 1;
- else
+ else if (flags & LLE_STATIC) {
RT_REMREF(ia_ro.ro_rt);
+ target->ia_flags &= ~IFA_RTSELF;
+ }
RTFREE_LOCKED(ia_ro.ro_rt);
}
if (freeit && (flags & LLE_STATIC)) {
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
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: kern/159602: commit references a PR
The following reply was made to PR kern/159602; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: kern/159602: commit references a PR Date: Mon, 10 Oct 2011 21:44:10 + (UTC) Author: qingli Date: Mon Oct 10 21:43:53 2011 New Revision: 226238 URL: http://svn.freebsd.org/changeset/base/226238 Log: MFC 226120 Do not try removing an ARP entry associated with a given interface address if that interface does not support ARP. Otherwise the system will generate error messages unnecessarily due to the missing entry. PR: kern/159602 Submitted by:pluknet Modified: stable/8/sys/netinet/in.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/netinet/in.c == --- stable/8/sys/netinet/in.c Mon Oct 10 21:41:34 2011(r226237) +++ stable/8/sys/netinet/in.c Mon Oct 10 21:43:53 2011(r226238) @@ -1138,7 +1138,8 @@ in_scrubprefix(struct in_ifaddr *target, if (error == 0) target->ia_flags &= ~IFA_RTSELF; } - if (flags & LLE_STATIC) + if ((flags & LLE_STATIC) && + !(target->ia_ifp->if_flags & IFF_NOARP)) /* remove arp cache */ arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr); } ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" ___ 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: kern/159603: commit references a PR
The following reply was made to PR kern/159603; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: kern/159603: commit references a PR Date: Mon, 10 Oct 2011 21:46:49 + (UTC) Author: qingli Date: Mon Oct 10 21:46:37 2011 New Revision: 226239 URL: http://svn.freebsd.org/changeset/base/226239 Log: MFC 225223 When an interface address route is removed from the system, another route with the same prefix is searched for as a replacement. The current code did not bypass routes that have non-operational interfaces. This patch fixes that bug and will find a replacement route with an active interface. PR: kern/159603 Submitted by:pluknet, ambrisko at ambrisko dot com Reviewed by: discussed on net@ Modified: stable/8/sys/netinet/in.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/netinet/in.c == --- stable/8/sys/netinet/in.c Mon Oct 10 21:43:53 2011(r226238) +++ stable/8/sys/netinet/in.c Mon Oct 10 21:46:37 2011(r226239) @@ -1166,7 +1166,8 @@ in_scrubprefix(struct in_ifaddr *target, p.s_addr &= ia->ia_sockmask.sin_addr.s_addr; } - if (prefix.s_addr != p.s_addr) + if ((prefix.s_addr != p.s_addr) || + !(ia->ia_ifp->if_flags & IFF_UP)) continue; /* ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" ___ 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: bce(4) with IPMI
> > I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I
> couldn't
> > see any driver detection of this status. So, when I add this:
> >
> > > if ((ifp->if_flags & IFF_UP) == 0 &&
> > >(sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0){
> > > printf("%s: BCE detected MFW not present\n",
> __func__);
> >
> >
> > I don't see any change in behavior with IPMI enabled or disabled via
> the
> > Dell "DRAC" ROM Menu.
> >
>
> I thought you may have seen "MFW(NOT RUNNING)" if management
> firmware is present and you disabled IPMI in device attach time.
> You may have to enable bootverbose to see it.
> If management firmware is present and running you may have seen
> actual management firmware version string.
The Broadcom MFW is configured to load/not load through an NVRAM
option that is likely not affected by the iDRAC BIOS settings.
To disable MFW you'd need to run the user diagnostic utility
(UXDIAG.EXE) with the following command line:
C:\>uxdiag -mfw 0
To turn it back on run the following:
C:\>uxdiag -mfw 1
You can find a bootable CD with the user diagnostic here:
http://www.broadcom.com/support/license.php?file=NXII/Xdiag-5.2.2.iso
Dave
___
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] Wifi link dying randomly. reboot required to reconnect.
> Date: Thu, 6 Oct 2011 19:02:15 -0500 > From: Chuck Burns > Subject: Re: [urtw] Wifi link dying randomly. reboot required to > reconnect. > To: Gary Palmer > Cc: freebsd-net@freebsd.org > Message-ID: <201110061902.15838.brea...@gmail.com> > Content-Type: Text/Plain; charset="iso-8859-1" > > > options KDB # Kernel debugger related code > options KDB_TRACE # Print a stack trace for a panic > #options KDB_UNATTENDED # Reboot on panic > options WITNESS # add me With run(4) (another usb dangle), there is a LOR between node lock and driver lock in if_raw_xmit(). Maybe, stuck on sending mgmt frames -> hang/disconnected from AP? With run(4), the LOR hasn't caused dead lock in 11abg mode, but in 11n mode, it causes dead lock every time. You run it in 11g mode, but it might be having bad hair day occasionally. Next time, rather than unplugging the device to induce a panic, wait and see if the computer will completely be locked up. AK ___ 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: RADIX_MPATH Documentation Feedback Request
I am hoping to get the documentation, along with more enhancements completed within a month. The main reason for this delay is because I am suspending RADIX_MPATH related work at the moment, and focusing on fixing IPv6 code instead. The FreeBSD IPv6 implementation in -CURRENT, stable/8 and stable/9 are all failing the IPv6-Ready logo certification tests. I have been asked to get these failures fixed as soon as possible. --Qing On Mon, Oct 10, 2011 at 10:20 PM, Jason Hellenthal wrote: > > Qing, > > Just checking in as I have been reading more lately about RADIX_MPATH > and have seen some commits come accross my bow to the inet and inet6 > areas of the kernel mentioning it. > > Are these commits prerequisits to the incoming docs ? > > Do you have a timeframe when these might be expected ? > > Should a PR be filed so this can be tracked ? > > > Thank in Advance. > ___ 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: RADIX_MPATH Documentation Feedback Request
Makes perfect sense. Thank you for the followup and if there is anyway that I could assist on direct tasks then feel free to give me a hollar and Ill do what I can to assist. On Mon, Oct 10, 2011 at 11:21:39PM -0700, Qing Li wrote: > I am hoping to get the documentation, along with more enhancements completed > within a month. > > The main reason for this delay is because I am suspending RADIX_MPATH related > work at the moment, and focusing on fixing IPv6 code instead. > > The FreeBSD IPv6 implementation in -CURRENT, stable/8 and stable/9 are > all failing > the IPv6-Ready logo certification tests. I have been asked to get these > failures > fixed as soon as possible. > > --Qing > > > On Mon, Oct 10, 2011 at 10:20 PM, Jason Hellenthal wrote: > > > > Qing, > > > > Just checking in as I have been reading more lately about RADIX_MPATH > > and have seen some commits come accross my bow to the inet and inet6 > > areas of the kernel mentioning it. > > > > Are these commits prerequisits to the incoming docs ? > > > > Do you have a timeframe when these might be expected ? > > > > Should a PR be filed so this can be tracked ? > > > > > > Thank in Advance. > > ___ 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"
