FreeBSD 8: ipfw fwd and pf route-to broken?

2009-12-04 Thread Lytochkin Boris 
Hi!

It seems that FreeBSD 8 has ipfw fwd and pf's route-to malfunctioning:
1) ipfw fwd
a) net.inet.ip.forwarding = 0
  Packets altered by fwd rule are silently dropped somewhere
between ip_output() checking forward tag and bpf (tcpdump does not
show these packets)
b) net.inet.ip.forwarding = 1
  Packets altered by fwd rule are forwarded according to normal
routing table (in my case they were forwarded to default gateway), not
fwd statement

2) pf route-to
Both values of net.inet.ip.forwarding replicates 1b case.


Sample configs

1) ipfw
add 60 fwd 10.60.128.254 ip from 10.60.128.0/24 to any out
add 65534 allow ip from any to any

2) pf
scrub in all fragment reassemble
pass in all flags S/SA keep state
pass out quick route-to (em0 10.60.128.254) inet from 10.60.128.0/24
to any flags S/SA keep state

~>uname -a
FreeBSD thost 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #5: Wed Dec  2
13:43:48 MSK 2009 r...@thost:/usr/obj/usr/src/sys/CSUP  amd64


--
Regards,
Boris Lytochkin
___
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 8: ipfw fwd and pf's route-to (reply-to) broken?

2009-12-04 Thread Lytochkin Boris 
Hi!

It seems that FreeBSD 8 has ipfw fwd and pf's route-to malfunctioning:
1) ipfw fwd
a) net.inet.ip.forwarding = 0
   Then packets altered by fwd rule are silently dropped somewhere
between ip_output() checking forward tag and bpf (tcpdump does not
show these packets)
b) net.inet.ip.forwarding = 1
   Packets altered by fwd rule are forwarded according to normal
routing table (in my case they were forwarded to default gateway), not
fwd statement

2) pf route-to
Both values of net.inet.ip.forwarding replicates 1b case.


Sample configs

1) ipfw
add 60 fwd 10.60.128.254 ip from 10.60.128.0/24 to any out
add 65534 allow ip from any to any

2) pf
scrub in all fragment reassemble
pass in all flags S/SA keep state
pass out quick route-to (em0 10.60.128.254) inet from 10.60.128.0/24
to any flags S/SA keep state

~>uname -a
FreeBSD thost 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #5: Wed Dec  2
13:43:48 MSK 2009 r...@thost:/usr/obj/usr/src/sys/CSUP  amd64


-- 
Regards,
Boris Lytochkin
___
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: hw.bge.forced_collapse

2009-12-04 Thread Pyun YongHyeon 
On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote:
> I saw commit introducing hw.bge.forced_collapse loader tunable.
> Just intresting, why it can not be a sysctl ?
> 

I didn't think the sysctl variable would be frequently changed
in runtime except debugging driver so I took simple path.

> 
> -- 
> Igor Sysoev
> http://sysoev.ru/en/
___
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/141134: [ppp] "ioctl (SIOCAIFADDR): File exists" error when configuring ppp interfaces

2009-12-04 Thread qingli 
Synopsis: [ppp] "ioctl (SIOCAIFADDR): File exists" error when configuring ppp 
interfaces

Responsible-Changed-From-To: freebsd-net->qingli
Responsible-Changed-By: qingli
Responsible-Changed-When: Fri Dec 4 18:05:10 UTC 2009
Responsible-Changed-Why: 
Take ownership of this bug.

http://www.freebsd.org/cgi/query-pr.cgi?pr=141134
___
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/139145: [ip6] IPv6 blackhole / reject routes broken

2009-12-04 Thread qingli 
Synopsis: [ip6] IPv6 blackhole / reject routes broken

State-Changed-From-To: open->closed
State-Changed-By: qingli
State-Changed-When: Fri Dec 4 18:53:31 UTC 2009
State-Changed-Why: 
The fix had been committed and verified by the submitter.



Responsible-Changed-From-To: freebsd-net->qingli
Responsible-Changed-By: qingli
Responsible-Changed-When: Fri Dec 4 18:53:31 UTC 2009
Responsible-Changed-Why: 
The fix had been committed and verified by the submitter.


http://www.freebsd.org/cgi/query-pr.cgi?pr=139145
___
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/139113: [arp] removing IP alias doesn't delete permanent arp entry

2009-12-04 Thread qingli 
Synopsis: [arp] removing IP alias doesn't delete permanent arp entry

State-Changed-From-To: open->closed
State-Changed-By: qingli
State-Changed-When: Fri Dec 4 18:55:40 UTC 2009
State-Changed-Why: 
The patch has been committed and the fix has been verified.



Responsible-Changed-From-To: freebsd-net->qingli
Responsible-Changed-By: qingli
Responsible-Changed-When: Fri Dec 4 18:55:40 UTC 2009
Responsible-Changed-Why: 


http://www.freebsd.org/cgi/query-pr.cgi?pr=139113
___
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/138676: [route] after buildworld not work local routes [regression]

2009-12-04 Thread qingli 
Synopsis: [route] after buildworld not work local routes [regression]

Responsible-Changed-From-To: freebsd-net->qingli
Responsible-Changed-By: qingli
Responsible-Changed-When: Fri Dec 4 18:58:35 UTC 2009
Responsible-Changed-Why: 
Take ownership of this bug.


http://www.freebsd.org/cgi/query-pr.cgi?pr=138676
___
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: hw.bge.forced_collapse

2009-12-04 Thread Igor Sysoev 
On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote:

> On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote:
> > I saw commit introducing hw.bge.forced_collapse loader tunable.
> > Just intresting, why it can not be a sysctl ?
> 
> I didn't think the sysctl variable would be frequently changed
> in runtime except debugging driver so I took simple path.

I do not think it's worth to reboot server just to look how various
values affect on bandwidth and CPU usage, expecially in production.

As I understand the change is trivial:

-  CTLFLAG_RD
+  CTLFLAG_RW

since bge_forced_collapse is used atomically.


-- 
Igor Sysoev
http://sysoev.ru/en/
___
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/139559: [tun] several tun(4) interfaces can be created with same dst addr

2009-12-04 Thread qingli 
Synopsis: [tun] several tun(4) interfaces can be created with same dst addr

Responsible-Changed-From-To: freebsd-net->qingli
Responsible-Changed-By: qingli
Responsible-Changed-When: Fri Dec 4 19:44:12 UTC 2009
Responsible-Changed-Why: 
Take ownership of this bug.


http://www.freebsd.org/cgi/query-pr.cgi?pr=139559
___
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/134369: [route] [ip6] IPV6 in Head broken for routing table updates

2009-12-04 Thread qingli 
Synopsis: [route] [ip6] IPV6 in Head broken for routing table updates

State-Changed-From-To: open->closed
State-Changed-By: qingli
State-Changed-When: Fri Dec 4 19:46:08 UTC 2009
State-Changed-Why: 
The patch had been committed and verified by the submitted in May 2009.



Responsible-Changed-From-To: freebsd-net->qingli
Responsible-Changed-By: qingli
Responsible-Changed-When: Fri Dec 4 19:46:08 UTC 2009
Responsible-Changed-Why: 


http://www.freebsd.org/cgi/query-pr.cgi?pr=134369
___
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: hw.bge.forced_collapse

2009-12-04 Thread Pyun YongHyeon 
On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote:
> On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote:
> 
> > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote:
> > > I saw commit introducing hw.bge.forced_collapse loader tunable.
> > > Just intresting, why it can not be a sysctl ?
> > 
> > I didn't think the sysctl variable would be frequently changed
> > in runtime except debugging driver so I took simple path.
> 
> I do not think it's worth to reboot server just to look how various
> values affect on bandwidth and CPU usage, expecially in production.
> 
> As I understand the change is trivial:
> 
> -  CTLFLAG_RD
> +  CTLFLAG_RW
> 
> since bge_forced_collapse is used atomically.
> 

I have no problem changing it to RW but that case I may have to
create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead
of hw.bge.forced_collapse which may affect all bge(4) controllers
on system. Attached patch may be what you want. You can change the
value at any time.
Index: sys/dev/bge/if_bgereg.h
===
--- sys/dev/bge/if_bgereg.h	(revision 200104)
+++ sys/dev/bge/if_bgereg.h	(working copy)
@@ -2647,6 +2647,7 @@
 	int			bge_link;	/* link state */
 	int			bge_link_evt;	/* pending link event */
 	int			bge_timer;
+	int			bge_forced_collapse;
 	struct callout		bge_stat_ch;
 	uint32_t		bge_rx_discards;
 	uint32_t		bge_tx_discards;
Index: sys/dev/bge/if_bge.c
===
--- sys/dev/bge/if_bge.c	(revision 200104)
+++ sys/dev/bge/if_bge.c	(working copy)
@@ -449,6 +449,7 @@
 #endif
 static void bge_add_sysctls(struct bge_softc *);
 static int bge_sysctl_stats(SYSCTL_HANDLER_ARGS);
+static int bge_sysctl_forced_collapse(SYSCTL_HANDLER_ARGS);
 
 static device_method_t bge_methods[] = {
 	/* Device interface */
@@ -483,29 +484,12 @@
 DRIVER_MODULE(miibus, bge, miibus_driver, miibus_devclass, 0, 0);
 
 static int bge_allow_asf = 1;
-/*
- * A common design characteristic for many Broadcom client controllers
- * is that they only support a single outstanding DMA read operation
- * on the PCIe bus. This means that it will take twice as long to fetch
- * a TX frame that is split into header and payload buffers as it does
- * to fetch a single, contiguous TX frame (2 reads vs. 1 read). For
- * these controllers, coalescing buffers to reduce the number of memory
- * reads is effective way to get maximum performance(about 940Mbps).
- * Without collapsing TX buffers the maximum TCP bulk transfer
- * performance is about 850Mbps. However forcing coalescing mbufs
- * consumes a lot of CPU cycles, so leave it off by default.
- */
-static int bge_forced_collapse = 0;
 
 TUNABLE_INT("hw.bge.allow_asf", &bge_allow_asf);
-TUNABLE_INT("hw.bge.forced_collapse", &bge_forced_collapse);
 
 SYSCTL_NODE(_hw, OID_AUTO, bge, CTLFLAG_RD, 0, "BGE driver parameters");
 SYSCTL_INT(_hw_bge, OID_AUTO, allow_asf, CTLFLAG_RD, &bge_allow_asf, 0,
 	"Allow ASF mode if available");
-SYSCTL_INT(_hw_bge, OID_AUTO, forced_collapse, CTLFLAG_RD, &bge_forced_collapse,
-	0, "Number of fragmented TX buffers of a frame allowed before "
-	"forced collapsing");
 
 #define	SPARC64_BLADE_1500_MODEL	"SUNW,Sun-Blade-1500"
 #define	SPARC64_BLADE_1500_PATH_BGE	"/p...@1f,70/netw...@2"
@@ -3933,17 +3917,17 @@
 	}
 
 	if ((m->m_pkthdr.csum_flags & CSUM_TSO) == 0 &&
-	bge_forced_collapse > 0 && (sc->bge_flags & BGE_FLAG_PCIE) != 0 &&
-	m->m_next != NULL) {
+	sc->bge_forced_collapse > 0 &&
+	(sc->bge_flags & BGE_FLAG_PCIE) != 0 && m->m_next != NULL) {
 		/*
 		 * Forcedly collapse mbuf chains to overcome hardware
 		 * limitation which only support a single outstanding
 		 * DMA read operation.
 		 */
-		if (bge_forced_collapse == 1)
+		if (sc->bge_forced_collapse == 1)
 			m = m_defrag(m, M_DONTWAIT);
 		else
-			m = m_collapse(m, M_DONTWAIT, bge_forced_collapse);
+			m = m_collapse(m, M_DONTWAIT, sc->bge_forced_collapse);
 		if (m == NULL) {
 			m_freem(*m_head);
 			*m_head = NULL;
@@ -4879,6 +4863,7 @@
 	struct sysctl_ctx_list *ctx;
 	struct sysctl_oid_list *children, *schildren;
 	struct sysctl_oid *tree;
+	int error;
 
 	ctx = device_get_sysctl_ctx(sc->bge_dev);
 	children = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->bge_dev));
@@ -4898,6 +4883,32 @@
 
 #endif
 
+	/*
+	 * A common design characteristic for many Broadcom client controllers
+	 * is that they only support a single outstanding DMA read operation
+	 * on the PCIe bus. This means that it will take twice as long to fetch
+	 * a TX frame that is split into header and payload buffers as it does
+	 * to fetch a single, contiguous TX frame (2 reads vs. 1 read). For
+	 * these controllers, coalescing buffers to reduce the number of memory
+	 * reads is effective way to get maximum performance(about 940Mbps).
+	 * Without collapsing TX buffers the maximum TCP bulk transfer
+	 * performance is about 850Mbps. However forcing coalescing m

Re: hw.bge.forced_collapse

2009-12-04 Thread Igor Sysoev 
On Fri, Dec 04, 2009 at 11:51:40AM -0800, Pyun YongHyeon wrote:

> On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote:
> > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote:
> > 
> > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote:
> > > > I saw commit introducing hw.bge.forced_collapse loader tunable.
> > > > Just intresting, why it can not be a sysctl ?
> > > 
> > > I didn't think the sysctl variable would be frequently changed
> > > in runtime except debugging driver so I took simple path.
> > 
> > I do not think it's worth to reboot server just to look how various
> > values affect on bandwidth and CPU usage, expecially in production.
> > 
> > As I understand the change is trivial:
> > 
> > -  CTLFLAG_RD
> > +  CTLFLAG_RW
> > 
> > since bge_forced_collapse is used atomically.
> > 
> 
> I have no problem changing it to RW but that case I may have to
> create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead
> of hw.bge.forced_collapse which may affect all bge(4) controllers
> on system. Attached patch may be what you want. You can change the
> value at any time.

Thank you for the patch. Can it be installed on 8-STABLE ?


-- 
Igor Sysoev
http://sysoev.ru/en/
___
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: hw.bge.forced_collapse

2009-12-04 Thread Pyun YongHyeon 
On Fri, Dec 04, 2009 at 11:13:03PM +0300, Igor Sysoev wrote:
> On Fri, Dec 04, 2009 at 11:51:40AM -0800, Pyun YongHyeon wrote:
> 
> > On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote:
> > > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote:
> > > 
> > > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote:
> > > > > I saw commit introducing hw.bge.forced_collapse loader tunable.
> > > > > Just intresting, why it can not be a sysctl ?
> > > > 
> > > > I didn't think the sysctl variable would be frequently changed
> > > > in runtime except debugging driver so I took simple path.
> > > 
> > > I do not think it's worth to reboot server just to look how various
> > > values affect on bandwidth and CPU usage, expecially in production.
> > > 
> > > As I understand the change is trivial:
> > > 
> > > -  CTLFLAG_RD
> > > +  CTLFLAG_RW
> > > 
> > > since bge_forced_collapse is used atomically.
> > > 
> > 
> > I have no problem changing it to RW but that case I may have to
> > create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead
> > of hw.bge.forced_collapse which may affect all bge(4) controllers
> > on system. Attached patch may be what you want. You can change the
> > value at any time.
> 
> Thank you for the patch. Can it be installed on 8-STABLE ?
> 

bge(4) in HEAD has many fixes which were not MFCed to stable/8 so
I'm not sure that patch could be applied cleanly. But I guess you
can manually patch it.
I'll wait a couple of days for wider testing/review and commit the
patch.
___
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: i386/141171: when ping FreeBSD crash and reboot

2009-12-04 Thread remko 
Synopsis: when ping FreeBSD crash and reboot

State-Changed-From-To: open->feedback
State-Changed-By: remko
State-Changed-When: Fri Dec 4 21:30:07 UTC 2009
State-Changed-Why: 
The information is rather ''limited'', to say the least. Please
try to obtain a kernel crash dump so that we might be able to
investigate what is going on.


Responsible-Changed-From-To: freebsd-i386->freebsd-net
Responsible-Changed-By: remko
Responsible-Changed-When: Fri Dec 4 21:30:07 UTC 2009
Responsible-Changed-Why: 
Reassign to the networking team.

http://www.freebsd.org/cgi/query-pr.cgi?pr=141171
___
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: i386/141171: when ping FreeBSD crash and reboot

2009-12-04 Thread Prommart Saelua 
This is my core dump.
http://www.thaisolution.net/tmp/core-dump.tar.gz
Thank you

2009/12/5 

> Synopsis: when ping FreeBSD crash and reboot
>
> State-Changed-From-To: open->feedback
> State-Changed-By: remko
> State-Changed-When: Fri Dec 4 21:30:07 UTC 2009
> State-Changed-Why:
> The information is rather ''limited'', to say the least. Please
> try to obtain a kernel crash dump so that we might be able to
> investigate what is going on.
>
>
> Responsible-Changed-From-To: freebsd-i386->freebsd-net
> Responsible-Changed-By: remko
> Responsible-Changed-When: Fri Dec 4 21:30:07 UTC 2009
> Responsible-Changed-Why:
> Reassign to the networking team.
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=141171
>
___
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: i386/141171: when ping FreeBSD crash and reboot

2009-12-04 Thread Prommart Saelua 
The following reply was made to PR i386/141171; it has been noted by GNATS.

From: Prommart Saelua 
To: re...@freebsd.org
Cc: freebsd-i...@freebsd.org, freebsd-net@freebsd.org, 
bug-follo...@freebsd.org
Subject: Re: i386/141171: when ping FreeBSD crash and reboot
Date: Sat, 5 Dec 2009 04:49:52 +0700

 --0016e64bfde06af3b00479ee1656
 Content-Type: text/plain; charset=ISO-8859-1
 
 This is my core dump.
 http://www.thaisolution.net/tmp/core-dump.tar.gz
 Thank you
 
 2009/12/5 
 
 > Synopsis: when ping FreeBSD crash and reboot
 >
 > State-Changed-From-To: open->feedback
 > State-Changed-By: remko
 > State-Changed-When: Fri Dec 4 21:30:07 UTC 2009
 > State-Changed-Why:
 > The information is rather ''limited'', to say the least. Please
 > try to obtain a kernel crash dump so that we might be able to
 > investigate what is going on.
 >
 >
 > Responsible-Changed-From-To: freebsd-i386->freebsd-net
 > Responsible-Changed-By: remko
 > Responsible-Changed-When: Fri Dec 4 21:30:07 UTC 2009
 > Responsible-Changed-Why:
 > Reassign to the networking team.
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=141171
 >
 
 --0016e64bfde06af3b00479ee1656
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 This is my core dump.http://www.thaisolution.net/tmp/core-du=
 mp.tar.gz">http://www.thaisolution.net/tmp/core-dump.tar.gzThank yo=
 u2009/12/5  re...@freebsd.org>
 Synopsis: when ping FreeBSD crash and reboot
 
 State-Changed-From-To: open->feedback
 State-Changed-By: remko
 State-Changed-When: Fri Dec 4 21:30:07 UTC 2009
 State-Changed-Why:
 The information is rather ''limited'', to say the least. Pl=
 ease
 try to obtain a kernel crash dump so that we might be able to
 investigate what is going on.
 
 
 Responsible-Changed-From-To: freebsd-i386->freebsd-net
 Responsible-Changed-By: remko
 Responsible-Changed-When: Fri Dec 4 21:30:07 UTC 2009
 Responsible-Changed-Why:
 Reassign to the networking team.
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D141171"; target=3D"_=
 blank">http://www.freebsd.org/cgi/query-pr.cgi?pr=3D141171
 
 
 --0016e64bfde06af3b00479ee1656--
___
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/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock

2009-12-04 Thread Benjamin Kaduk 
The following reply was made to PR kern/140036; it has been noted by GNATS.

From: Benjamin Kaduk 
To: Bernhard Schmidt , s...@freebsd.org
Cc: bug-follo...@freebsd.org
Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock
 and iwn0 softc lock
Date: Fri, 4 Dec 2009 21:49:42 -0500 (EST)

 Okay, I've been getting these lockups fairly frequently -- in fact,
 there was this one room where I was getting them every five minutes
 or so.  I hypothesized that dissociation/association events might
 be triggers, so I set dev.iwn.0.debug=-1 and started wandering around
 this building (which is chock full of APs).
 I get:
 panic: lock (sleep mutex) iwn0_com_lock not locked @ 
 /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3254
 
 Unfortunately, it appears to have messed up my machine pretty badly,
 as only numlock blinks the LED, and I don't have a db> prompt ...
 
 Trying again without the debugging spew gets a useful debugger, though.
 "show alllocks" produces empty output (?!).
 backtrace is:
 kdb_enter
 panic
 witness_unlock
 _mtx_unlock_flags
 iwn_raw_xmit
 ieee80211_send_probereq
 beacom_miss
 taskqueue_run
 taskqueue_thread_loop
 fork_exit
 
 Looking at the coredump, I'm inclined to suspect this block of 
 ieee80211_proto.c (in beacon_miss() ):
 1.46  sam   1379:/* XXX locking */
  1380:TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) {
 1.38  sam   1381:/*
 1.46  sam   1382: * We only pass events through for sta 
vap's in RUN state;
  1383: * may be too restrictive but for now 
this saves all the
  1384: * handlers duplicating these checks.
 1.38  sam   1385: */
 1.46  sam   1386:if (vap->iv_opmode == IEEE80211_M_STA &&
 1.64  sam   1387:vap->iv_state >= IEEE80211_S_RUN &&
 1.46  sam   1388:vap->iv_bmiss != NULL)
  1389:vap->iv_bmiss(vap);
 
 
 Sam, do you have any thoughts as to why throwing a 
 IEEE80211_LOCK(ic)/IEEE80211_UNLOCK(ic) block around the TAILQ_FOREACH 
 might not be a good idea?
 I'm currently running with that, which gives me a new LOR
 (iwn_com_lock @ /usr/src/sys/net80211/ieee80211_scan.c:683 and
 iwn0 @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3289)
 but it hasn't locked up or panic()ed on me, yet.
 
 
 I am happy to pull more information from the coredump if needed.
 
 Thanks,
 
 Ben Kaduk
___
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/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock

2009-12-04 Thread Brandon Gooch 
On Sat, Dec 5, 2009 at 2:50 AM, Benjamin Kaduk  wrote:
> The following reply was made to PR kern/140036; it has been noted by GNATS.
>
> From: Benjamin Kaduk 
> To: Bernhard Schmidt , s...@freebsd.org
> Cc: bug-follo...@freebsd.org
> Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock
>  and iwn0 softc lock
> Date: Fri, 4 Dec 2009 21:49:42 -0500 (EST)
>
>  Okay, I've been getting these lockups fairly frequently -- in fact,
>  there was this one room where I was getting them every five minutes
>  or so.  I hypothesized that dissociation/association events might
>  be triggers, so I set dev.iwn.0.debug=-1 and started wandering around
>  this building (which is chock full of APs).
>  I get:
>  panic: lock (sleep mutex) iwn0_com_lock not locked @
>  /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3254
>
>  Unfortunately, it appears to have messed up my machine pretty badly,
>  as only numlock blinks the LED, and I don't have a db> prompt ...
>
>  Trying again without the debugging spew gets a useful debugger, though.
>  "show alllocks" produces empty output (?!).
>  backtrace is:
>  kdb_enter
>  panic
>  witness_unlock
>  _mtx_unlock_flags
>  iwn_raw_xmit
>  ieee80211_send_probereq
>  beacom_miss
>  taskqueue_run
>  taskqueue_thread_loop
>  fork_exit
>
>  Looking at the coredump, I'm inclined to suspect this block of
>  ieee80211_proto.c (in beacon_miss() ):
>  1.46      sam   1379:        /* XXX locking */
>                  1380:        TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) {
>  1.38      sam   1381:                /*
>  1.46      sam   1382:                 * We only pass events through for sta 
> vap's in RUN state;
>                  1383:                 * may be too restrictive but for now 
> this saves all the
>                  1384:                 * handlers duplicating these checks.
>  1.38      sam   1385:                 */
>  1.46      sam   1386:                if (vap->iv_opmode == IEEE80211_M_STA &&
>  1.64      sam   1387:                    vap->iv_state >= IEEE80211_S_RUN &&
>  1.46      sam   1388:                    vap->iv_bmiss != NULL)
>                  1389:                        vap->iv_bmiss(vap);
>
>
>  Sam, do you have any thoughts as to why throwing a
>  IEEE80211_LOCK(ic)/IEEE80211_UNLOCK(ic) block around the TAILQ_FOREACH
>  might not be a good idea?
>  I'm currently running with that, which gives me a new LOR
>  (iwn_com_lock @ /usr/src/sys/net80211/ieee80211_scan.c:683 and
>  iwn0 @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3289)
>  but it hasn't locked up or panic()ed on me, yet.
>
>
>  I am happy to pull more information from the coredump if needed.
>

Ben, have you tried Bernhard Schmidt's driver? He's recently updated
it with a reordering of locking code:

http://svn.techwires.net/viewvc/viewvc.cgi/svnrepos/projects/freebsd/sys/dev/iwn/if_iwn.c?view=log

I've been using the code from his repository for a while, and it's
much more stable than what's in the tree currently.

-Brandon
___
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/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock

2009-12-04 Thread Benjamin Kaduk 

On Sat, 5 Dec 2009, Brandon Gooch wrote:



Ben, have you tried Bernhard Schmidt's driver? He's recently updated
it with a reordering of locking code:

http://svn.techwires.net/viewvc/viewvc.cgi/svnrepos/projects/freebsd/sys/dev/iwn/if_iwn.c?view=log

I've been using the code from his repository for a while, and it's
much more stable than what's in the tree currently.


Sorry if the PR history was not clear -- this panic is with Bernhard's 
driver in place.

(And a `svn diff` in my working copy doesn't show any changes.)

-Ben Kaduk
___
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/132554: [ipl] There is no ippool start script/ipfilter magic to load them

2009-12-04 Thread Jason Loretz 
The following reply was made to PR kern/132554; it has been noted by GNATS.

From: Jason Loretz 
To: bug-follo...@freebsd.org, a...@axel.truedestiny.net
Cc:  
Subject: Re: kern/132554: [ipl] There is no ippool start script/ipfilter magic 
to load them
Date: Fri, 4 Dec 2009 23:10:12 -0500

 The ippools feature is quite useful and would be nice to have automatically 
start with the IPF startup script (as part of FreeBSD rather than a system 
administrator insert/tweek). The actual functionality already exists in the 
current 7.1 release and just needs hooks to properly startup and reload/flush 
configurations in sync with ipfilter. This functionality appears that it should 
reside in the ipfilter rc.d script since ippools will not work until "ipf -E" 
has been executed but also needs to be configure d previous to the "ipf -f" 
commands. Therefore I submit these diffs as a possible solution, which will 
provide the appropriate rc.conf options and modifications to rc.d/ipfilter to 
make it load and flush in the correct places during the ipf configuration. I 
took a stab, but needs work, at modifications to the firewall handbook page to 
include information on ippools. This no doubt will need some work if it can be 
included.
 
 Thanks, Jason
 
 --- rc.conf.diff begins here ---
 --- /usr/src/etc/defaults/rc.conf  2008-11-24 21:59:29.0 -0500
 +++ /etc/defaults/rc.conf  2009-11-30 20:43:10.0 -0500
 @@ -152,6 +152,12 @@
  ipfilter_rules="/etc/ipf.rules"   # rules definition file for ipfilter, 
see
# /usr/src/contrib/ipfilter/rules for examples
  ipfilter_flags="" # additional flags for ipfilter
 +ipfilter_ippool_enable="NO"   # Set to YES to enable ippool functionality
 +ippool_program="/sbin/ippool" # where the ippool program lives
 +ippool_rules="/etc/ippool.conf"   # rules definition file for ippool, see 

 +  # /usr/src/contrib/ipfilter/rules/pool.conf
 +  # for example
 +ippool_flags=""   # additional flags for ippool
  ipnat_enable="NO" # Set to YES to enable ipnat functionality
  ipnat_program="/sbin/ipnat"   # where the ipnat program lives
  ipnat_rules="/etc/ipnat.rules"# rules definition file for ipnat
 --- rc.conf.diff ends here ---
 
 --- ipfilter.diff begins here --- 
 --- /usr/src/etc/rc.d/ipfilter 2008-11-24 21:59:29.0 -0500
 +++ /etc/rc.d/ipfilter 2009-12-01 09:19:43.0 -0500
 @@ -33,6 +33,14 @@
if [ `sysctl -n net.inet.ipf.fr_running` -le 0 ]; then
${ipfilter_program:-/sbin/ipf} -E
fi
 +  if checkyesno ipfilter_ippool_enable; then
 +  if [ -r "${ippool_rules}" ]; then
 +  echo "Loading ippool rules."
 +  ${ippool_program:-/sbin/ippool} \
 +  -f "${ippool_rules}" ${ippool_flags}
 +  fi
 +  fi
 +  echo "Loading ipfilter rules."
${ipfilter_program:-/sbin/ipf} -Fa
if [ -r "${ipfilter_rules}" ]; then
${ipfilter_program:-/sbin/ipf} \
 @@ -58,8 +66,16 @@
  
  ipfilter_reload()
  {
 -  echo "Reloading ipfilter rules."
 +  if checkyesno ipfilter_ippool_enable; then
 +  if [ -r "${ippool_rules}" ]; then
 +  echo "Reloading ippool rules."
 +  ${ippool_program:-/sbin/ippool} -F
 +  ${ippool_program:-/sbin/ippool} \
 +  -f "${ippool_rules}" ${ippool_flags}
 +  fi
 +  fi
  
 +  echo "Reloading ipfilter rules."
${ipfilter_program:-/sbin/ipf} -I -Fa
if [ -r "${ipfilter_rules}" ]; then
${ipfilter_program:-/sbin/ipf} -I \
 --- ipfilter.diff ends here ---
 
 --- chapter.sgml.diff begins here ---
 --- /usr/doc/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml 
2009-11-27 12:11:33.0 -0500
 +++ /tmp/chapter.sgml  2009-12-04 20:19:23.0 -0500
 @@ -653,6 +653,16 @@
# v = log tcp window, ack, seq
# n = map IP & port to 
names
  
 +  If the use of ippools is desired, the following lines need to be
 +added to enable the ippool functionality:
 +
 +  ipfilter_ippool_enable="NO" # Set to YES to enable 
ippool functionality
 +ippool_program="/sbin/ippool"   # where the ippool program lives
 +ippool_rules="/etc/ippool.conf" # rules definition file for ippool, see 
 +# /usr/src/contrib/ipfilter/rules/pool.conf
 +# for example
 +ippool_flags="" # additional flags for ippool
 +
If there is a LAN behind this firewall that uses the
reserved private IP address ranges, the following lines will have to
be added to enable NAT
 @@ -701,6 +711,26 @@
  
  
  
 +  IPPOOL
 +
 +  ippool
 +
 +  The &man.i