Re: 8.0 network problem
On Tuesday 06 July 2010 22:32:22 Jeremy Chadwick wrote: > Adding Max Laier (maintainer of pf) to the CC list. He may have some > ideas as to what's causing this. Max, relevant thread details: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057586.html > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057597.html > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057602.html > > The last link above indicates the OP gets decent transfer rates with pf > disabled, and includes his pf.conf. Please check "pfctl -si" esp. "state-mismatch" This is always the first indication that something is wrong. In addition you can set a higher pf debugging level (pfctl -xm) in order to get more information on the issue - if the cause is indeed a state mismatch. > On Tue, Jul 06, 2010 at 07:41:55PM +0200, Roland Smith wrote: > > On Tue, Jul 06, 2010 at 01:06:25AM -0500, David Warren wrote: > > > pass out keep state > > > > I think keeping state is the default now. > > It is, but it's worth going over the "history" just so people > understand. I've been schooled on this in the past, but I'm still going > off of memory so if someone knows otherwise please chime in. > > In 7.2 and earlier (I could have the version numbers wrong, but > 7.3-PRERELEASE doesn't require this), you had to explicitly state "keep > state flags S/SA" on TCP traffic, and "keep state" on UDP/ICMP traffic. > This is because said version(s) use older and newer pf, respectively. > > So in the OP's case, the above rule on an older OS would cause mayhem > (excessive states being created for TCP, and improperly at that (any > outbound TCP packet, rather than ones with only SYN set when looking at > only SYN & ACK)). > > In 7.3 and later (including 8.x and onward), the "keep state" parameter > isn't needed; it's explicitly applied unless you use "no_state". pf > also intelligently figures out when to use "flags S/SA" (e.g. for TCP > rules). For example, the following pf.conf rule (notice that there's no > protocol defined): > > pass in quick on em0 inet from any to 1.2.3.4 keep state > > Gets turned into: > > pass in quick on em0 inet from any to 1.2.3.4 flags S/SA keep state > > And "does the right thing" even with UDP/ICMP traffic where there's no > stateful flags involves. Meaning, the "flags S/SA" part applies to any > inbound TCP, and isn't used for other protocols. > > Back to the problem at hand: > > I wonder if it's lack of "quick" on some rules which is causing the > problem; hard to say, and I'm not sure how to "benchmark" pf. > > Furthermore, remember that the OP can move to another NIC and the > problem goes away[1]. I know there have been issues in the past > reported with em(4) and pf ALTQ, but that isn't in use here. > > > > [1]: I assume the OP is updating pf.conf to specify the changed > interface and so on; if not, then I imagine it would be as effective as > disabling pf (thus "it's fast when I use something other than em0" would > be inaccurate). I simply don't know. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PF + BRIDGE still causes system freezing
On Monday 31 May 2010 08:03:09 Giulio Ferro wrote: > Max Laier wrote: > > On Friday 28 May 2010 07:46:07 Giulio Ferro wrote: > >> Months ago I reported a system freezing whenever bridge was used > >> with pf. This still happens now in 8.1 prerelease: after several minutes > >> to hours > >> that the bridge is active the system becomes unresponsive. > > > > as I told you last time your reported this problem: you need to simplify > > your setup in order to track down the problem. For all I know, you have > > created a routing or ethernet loop that is the cause of your problems. > > Unless you can provide a simple setup that can be reproduced, you have > > to track down the issue yourself - sorry. > > > > Max > > Ok, I've moved the vpn-bridging service to a server without pf, and now > it seems to work correctly. Glad to hear. I would, however, still like to know the *details* of your setup so I can *reproduce* the problem. Without proper configuration details, all I - or anyone - can do is guess. The information you provided so far is not very helpful in this regard. > I maintain that this issue would need to look into, anyway... Yes ... but unless the issue can be reproduced in a controlled environment, it's next to impossible to do so. > I don't think that a system freezing is acceptable, even when the > administrator > makes some configuration mistakes: the o.s. should complain about > "routing or ethernet loop", without leaving him wondering... I'm afraid in this regard we (or any other o.s. for that matter) are just rope vendors. Network configuration is complicated business. The more components you throw in the mix, the easier it gets to hang yourself in the ensuing web. Sorry I can't be of more help, but again: without details about your setup, everything is just guesswork! Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PF + BRIDGE still causes system freezing
On Friday 28 May 2010 07:46:07 Giulio Ferro wrote: > Months ago I reported a system freezing whenever bridge was used > with pf. This still happens now in 8.1 prerelease: after several minutes > to hours > that the bridge is active the system becomes unresponsive. as I told you last time your reported this problem: you need to simplify your setup in order to track down the problem. For all I know, you have created a routing or ethernet loop that is the cause of your problems. Unless you can provide a simple setup that can be reproduced, you have to track down the issue yourself - sorry. Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em(4) interface hangs under 8.0-RELEASE
On Sunday 07 March 2010 00:32:21 Jeremy Chadwick wrote: > On Sat, Mar 06, 2010 at 02:56:07PM -0800, Nick Rogers wrote: > > ALTQ + RELENG_8 + em(4) will not work at the moment. It does not matter > > what your PF ruleset looks like or how much traffic you are pushing. The > > packets that transit the em interface simply never make it to the ALTQ > > queues (not even the interface's root queue). Thus any kind of bandwidth > > rate limiting or whatever you are doing will not work. > > > > This was fixed by the following commit. I think its supposed to MFC soon? > > http://svn.freebsd.org/viewvc/base?view=revision&revision=203834 > > Nick, thanks for pointing me to this. I'll hold off on doing our > upgrade (on that one server) until said code is backported to RELENG_8. > > Max, will this be MFC'd in about a week? Usually things of this sort > MFC'd after 4 weeks, but I thought I'd get confirmation. As noted in the commit message, I do indeed plan to MFC this in about a week. There are two remaining issues in some drivers that may result in packet reordering (w/ or w/o ALTQ). I was hoping to address this before the MFC, but I didn't yet find the time. Regards, Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em(4) + ALTQ broken
Okay ... attached is a patch to fix this for em(4) (and lay the groundwork to
fix it for other drbr_* consumer as well). I have tested it in VirtualBox,
but don't have real hardware to check for non-ALTQ performance or other
regressions.
Test, comments and review appreciated.
--
Max
Index: sys/dev/e1000/if_em.c
===
--- sys/dev/e1000/if_em.c (revision 203362)
+++ sys/dev/e1000/if_em.c (working copy)
@@ -943,7 +943,7 @@
{
struct adapter *adapter = ifp->if_softc;
struct mbuf *next;
- int error = E1000_SUCCESS;
+ int ret, error = E1000_SUCCESS;
EM_TX_LOCK_ASSERT(adapter);
/* To allow being called from a tasklet */
@@ -955,28 +955,34 @@
|| (!adapter->link_active)) {
error = drbr_enqueue(ifp, adapter->br, m);
return (error);
- } else if (drbr_empty(ifp, adapter->br) &&
- (adapter->num_tx_desc_avail > EM_TX_OP_THRESHOLD)) {
- if ((error = em_xmit(adapter, &m)) != 0) {
- if (m)
-error = drbr_enqueue(ifp, adapter->br, m);
+ }
+ ret = drbr_maybe_enqueue(ifp, adapter->br, m);
+ if (ret == 0) {
+ if (adapter->num_tx_desc_avail > EM_TX_OP_THRESHOLD) {
+ if ((error = em_xmit(adapter, &m)) != 0) {
+if (m)
+ error = drbr_enqueue(ifp, adapter->br,
+ m);
+return (error);
+ } else {
+/*
+ * We've bypassed the buf ring so we need to
+ * update ifp directly
+ */
+drbr_stats_update(ifp, m->m_pkthdr.len,
+m->m_flags);
+/*
+** Send a copy of the frame to the BPF
+** listener and set the watchdog on.
+*/
+ETHER_BPF_MTAP(ifp, m);
+adapter->watchdog_check = TRUE;
+ }
+ } else if ((error = drbr_enqueue(ifp, adapter->br, m)) != 0)
return (error);
- } else {
- /*
- * We've bypassed the buf ring so we need to update
- * ifp directly
- */
- drbr_stats_update(ifp, m->m_pkthdr.len, m->m_flags);
- /*
- ** Send a copy of the frame to the BPF
- ** listener and set the watchdog on.
- */
- ETHER_BPF_MTAP(ifp, m);
- adapter->watchdog_check = TRUE;
- }
- } else if ((error = drbr_enqueue(ifp, adapter->br, m)) != 0)
- return (error);
-
+ } else if (ret < 0)
+ return (-ret);
+
process:
if (drbr_empty(ifp, adapter->br))
return(error);
@@ -989,7 +995,7 @@
break;
if ((error = em_xmit(adapter, &next)) != 0) {
if (next != NULL)
-error = drbr_enqueue(ifp, adapter->br, next);
+error = drbr_requeue(ifp, adapter->br, next);
break;
}
drbr_stats_update(ifp, next->m_pkthdr.len, next->m_flags);
Index: sys/net/if_var.h
===
--- sys/net/if_var.h (revision 203362)
+++ sys/net/if_var.h (working copy)
@@ -597,18 +597,26 @@
return (error);
}
+static __inline int
+drbr_requeue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m)
+{
+#ifdef ALTQ
+ if (ALTQ_IS_ENABLED(&ifp->if_snd)) {
+ IFQ_DRV_PREPEND(&ifp->if_snd, m);
+ return (0);
+ }
+#endif
+ return drbr_enqueue(ifp, br, m);
+}
+
static __inline void
drbr_flush(struct ifnet *ifp, struct buf_ring *br)
{
struct mbuf *m;
#ifdef ALTQ
- if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd)) {
- while (!IFQ_IS_EMPTY(&ifp->if_snd)) {
- IFQ_DRV_DEQUEUE(&ifp->if_snd, m);
- m_freem(m);
- }
- }
+ if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd))
+ IFQ_DRV_PURGE(&ifp->if_snd);
#endif
while ((m = buf_ring_dequeue_sc(br)) != NULL)
m_freem(m);
@@ -642,11 +650,12 @@
{
struct mbuf *m;
#ifdef ALTQ
- /*
- * XXX need to evaluate / requeue
- */
if (ALTQ_IS_ENABLED(&ifp->if_snd)) {
IFQ_DRV_DEQUEUE(&ifp->if_snd, m);
+ if (m != NULL && func(m, arg) == 0) {
+ IFQ_DRV_PREPEND(&ifp->if_snd, m);
+ return (NULL);
+ }
return (m);
}
#endif
@@ -668,6 +677,24 @@
}
static __inline int
+drbr_maybe_enqueue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m)
+{
+ int error;
+
+#ifdef ALTQ
+ if (ALTQ_IS_ENABLED(&ifp->if_snd)) {
+ IFQ_ENQUEUE(&ifp->if_snd, m, error);
+ return error ? -error : 1;
+ }
+#endif
+ if (drbr_empty(ifp, br))
+ return 0;
+
+ error = drbr_enqueue(ifp, br, m);
+ return error ? -error : 1;
+}
+
+static __inline int
drbr_inuse(struct ifnet *ifp, struct buf_ring *br)
{
#ifdef ALTQ
diff --git a/sys/dev/e1000/if_em.c b/sys/dev/e1000/if_em.c
index 7a2dbad..94ad229 100644
--- a/sys/dev/e1000/if_em.c
+++ b/sys/dev/e1000/if_em.c
@@ -1020,7 +1020,7 @@ em_mq_start_locked(struct ifnet *ifp, struct mbuf *m)
{
struct adapter *adapter = ifp->if_softc;
struct mbuf *next;
- int error = E1000_SUCCESS;
+ int ret, error = E1000_SUCCESS;
EM_TX_LOCK_ASSERT(adapter);
/* To allow being called from a tasklet */
@@ -1032,28 +1032,34 @@ em_mq_start_locked(struct ifnet *ifp, struct mbuf *m)
|| (!adapter->link_active)) {
error = drbr_enqueue(ifp, adapter->br, m);
return (error);
- } else if (drbr_empty(ifp, adapter->br) &&
- (adapter->num_tx_desc_avail > EM_TX_OP_THRESHOLD)) {
- if ((error = em_xm
Re: em(4) + ALTQ broken
On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > So apparently this thing needs no special knowledge in the driver, yet > something in > the new code breaks it, can someone explain tersely how the altq app > actually > "pokes" or "hooks up" to the driver? I am not clear about that and I > suspect if I was > this would all be clearer. The whole story is in man 9 altq long story short, as long as you consistently use the IFQ_* macros to manage the interface queue, things should just work. if_var.h used to conditionally define these macros to avoid ALTQ overhead when the kernel is built without ALTQ. This has changed a long time ago and should not make any difference anymore. I can't figure out who the OP is, but could you make sure that the includes that are used to built the kernel are up to date? You are building with the buildkernel target and not "the old way", right? Also, if you build just the module, the build might pick up the includes from /usr/include instead of src/sys ... > Jack > > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon wrote: > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > > I guess the problem comes from multi-queue support. The drbr > > > > interface is implemented with inline function so em(4)/igb(4) may > > > > have to define ALTQ to the header. I have not tested the patch(no > > > > time at this moment) but would you give it try? > > > > > > > > I tried the patch and it did not work. > > > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > !DSPAM:4b686584144321871135632! > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available
On Friday 22 January 2010 19:49:19 John Baldwin wrote: > On Friday 22 January 2010 12:18:20 pm Max Laier wrote: > > On Friday 22 January 2010 15:20:13 John Baldwin wrote: > > > On Friday 22 January 2010 3:08:45 am Florian Smeets wrote: > > > > ... > > > > > > If it really is IPsec traffic then there are no rewrite rules only 10 > > > > pf pass rules on the enc0 interface and a "scrub in all" rule. > > > > > > > > Perhaps it matters that i have these set: > > > > > > > > net.enc.out.ipsec_bpf_mask=0x0001 > > > > net.enc.out.ipsec_filter_mask=0x0001 > > > > net.enc.in.ipsec_bpf_mask=0x0002 > > > > net.enc.in.ipsec_filter_mask=0x0002 > > > > > > > > so that i can filter the "encapsulated" traffic. > > > > > > I have no idea, I've cc'd mlaier@ (pf) and bz@ (ipsec) to see if they > > > have any ideas. > > > > pf could be the culprit if it were present in the trace, but I don't see > > any sign of it: > > > > On Thursday 21 January 2010 11:10:20 Florian Smeets wrote: > > > #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 > > > "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > > > at /usr/src/sys/kern/uipc_mbuf.c:815 > > > #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at > > > /usr/src/sys/netinet/ip_input.c:1307 > > > #9 0xc05fa30c in ip_input (m=0xc23dc900) at > > > /usr/src/sys/netinet/ip_input.c:609 > > > #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at > > > /usr/src/sys/net/netisr.c:185 > > > #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at > > > /usr/src/sys/net/if_ethersubr.c:834 > > > #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at > > > /usr/src/sys/net/if_ethersubr.c:692 > > > #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at > > > /usr/src/sys/dev/sis/if_sis.c:1476 > > > #14 0xc04b8973 in sis_intr (arg=0xc2093800) at > > > /usr/src/sys/dev/sis/if_sis.c:1667 > > > #15 0xc050344b in ithread_loop (arg=0xc20ab410) at > > > /usr/src/sys/kern/kern_intr.c:1126 > > > #16 0xc04ffe36 in fork_exit (callout=0xc05032a0 , > > > arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811 > > > #17 0xc06d9180 in fork_trampoline () at > > > /usr/src/sys/i386/i386/exception.s:271 > > > > pf does change the byte order in the pfil hook, but changes it back on > > return to the stack either when returning from the hook or when calling > > back into the stack. There have been some issues where we missed returns > > to the stack that would result in this situation, but since pf is not in > > the trace, this is clearly not the case here. > > That isn't necessarily the case. ip_input() invokes the PFIL hooks which > then return after possibly modifying the packet. The (possibly modified) > packet is then passed to ip_forward() from ip_input(). If the PFIL hook > modified the packet and returned ip_len in network byte order then it would > cause this breakage without showing up in the stack trace. What I meant to say was: if we return from the pfil hook we either report error (and/or consume the mbuf) or switch back to network byte order: http://fxr.watson.org/fxr/source/contrib/pf/net/pf_ioctl.c?v=FREEBSD72#L3655 While I can't completely rule out that there is a double flip happening in some obscure path through pf, I very much doubt this is what is going on (or there would be more reports and it would happen straight away, not only after passing some data). A quick search through the sources also didn't turn up any red flags. All byte order operations inside pf are either temporary or performed on a properly copied packet that is send back through the stack (icmp error, tcp packet, ...). Depending on how easily this can be reproduced, my money is on modifying a shared mbuf (possibly inside enc(4)). Regards, -- Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available
On Friday 22 January 2010 15:20:13 John Baldwin wrote: > On Friday 22 January 2010 3:08:45 am Florian Smeets wrote: ... > > If it really is IPsec traffic then there are no rewrite rules only 10 pf > > pass rules on the enc0 interface and a "scrub in all" rule. > > > > Perhaps it matters that i have these set: > > > > net.enc.out.ipsec_bpf_mask=0x0001 > > net.enc.out.ipsec_filter_mask=0x0001 > > net.enc.in.ipsec_bpf_mask=0x0002 > > net.enc.in.ipsec_filter_mask=0x0002 > > > > so that i can filter the "encapsulated" traffic. > > I have no idea, I've cc'd mlaier@ (pf) and bz@ (ipsec) to see if they have > any ideas. pf could be the culprit if it were present in the trace, but I don't see any sign of it: On Thursday 21 January 2010 11:10:20 Florian Smeets wrote: > #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 > "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > at /usr/src/sys/kern/uipc_mbuf.c:815 > #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at > /usr/src/sys/netinet/ip_input.c:1307 > #9 0xc05fa30c in ip_input (m=0xc23dc900) at > /usr/src/sys/netinet/ip_input.c:609 > #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at > /usr/src/sys/net/netisr.c:185 > #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at > /usr/src/sys/net/if_ethersubr.c:834 > #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at > /usr/src/sys/net/if_ethersubr.c:692 > #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at > /usr/src/sys/dev/sis/if_sis.c:1476 > #14 0xc04b8973 in sis_intr (arg=0xc2093800) at > /usr/src/sys/dev/sis/if_sis.c:1667 > #15 0xc050344b in ithread_loop (arg=0xc20ab410) at > /usr/src/sys/kern/kern_intr.c:1126 > #16 0xc04ffe36 in fork_exit (callout=0xc05032a0 , > arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811 > #17 0xc06d9180 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:271 pf does change the byte order in the pfil hook, but changes it back on return to the stack either when returning from the hook or when calling back into the stack. There have been some issues where we missed returns to the stack that would result in this situation, but since pf is not in the trace, this is clearly not the case here. It might indeed be related to enc(4). I remember there have been some issues in IPSEC where it failed to properly copy a packet before modifying it. Maybe this is what is happening. Details escape me at the moment. Can you also make sure that your if_enc.c has revision 174978: http://svn.freebsd.org/viewvc/base/release/7.2.0/sys/net/if_enc.c?view=diff&r1=174977&r2=174978 Regards, -- Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pf: unlocked lookup
Hello Derek, On Thursday 10 December 2009 04:45:12 Derek Kulinski wrote: > My console gets flooded by "pf: unlocked lookup" message anyone knows > what circumstances cause this message, so I could figure out which pf > rule is causing it? this is a generic informational message that was put into the code to figure out if the hack that is "debug.pfugidhack" is actually required. You can get rid of the message by setting the debug level of pf to something below "misc" (e.g. pfctl -x urgent). > After searching on google I found few people asking about it, though no > real answer. The first result talks about debug.pfugidhack being set to > 1. > > It is set to 1 on my system, though I don't have anything in > /etc/syctl.conf, also when I switched it to 0, the system crashed within > an hour or so. > > Is this somehow related to rules that have rules with attached to a > specific user? The pfugidhack is automatically enabled when you use rules with user or group filters. These rules are a layering violation and the hack is required to make them work. I'd rather get rid of them altogether, but since it is a much demanded functionality we introduced the workaround instead. Just lower the debugging level (s.a.), ignore the messages, or rebuild your kernel/pf module with the respective DPRINTF lines (sys/contrib/pf/net/pf.c) commented out. I might just move them to the loud level in the main tree, though. Regards, -- Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic due to junk pointer in pf(4)
On Wednesday 12 August 2009 21:16:09 Peter Jeremy wrote:
> My firewall (7.2p3/i386) recently panic'd:
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x1065e
> fault code = supervisor read, page not present
> ...
> I have a crashdump that shows:
> #6 0xc06c9c1b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
> #7 0xc044ecd0 in pf_state_tree_lan_ext_RB_REMOVE_COLOR (head=0xc2a256a8,
> parent=0xc442c6a0, elm=0xc40aa8e0) at
> /usr/src/sys/contrib/pf/net/pf.c:391 #8 0xc044ef79 in
> pf_state_tree_lan_ext_RB_REMOVE (head=0xc2a256a8, elm=0xc404a11c) at
> /usr/src/sys/contrib/pf/net/pf.c:391
> #9 0xc045383e in pf_unlink_state (cur=0xc404a11c)
> at /usr/src/sys/contrib/pf/net/pf.c:1158
> #10 0xc0456b6e in pf_purge_expired_states (maxcheck=119)
> at /usr/src/sys/contrib/pf/net/pf.c:1242
> #11 0xc04570f9 in pf_purge_thread (v=0x0)
> at /usr/src/sys/contrib/pf/net/pf.c:998
> #12 0xc0535781 in fork_exit (callout=0xc0456f50 , arg=0x0,
> frame=0xd2d4cd38) at /usr/src/sys/kern/kern_fork.c:810
> #13 0xc06c9c90 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:264
>
> Working up, 'parent' in pf_state_tree_lan_ext_RB_REMOVE_COLOR() has
> a garbage u.s.entry_lan_ext:
> (kgdb) p parent->u
> $3 = {s = {entry_lan_ext = {rbe_left = 0x10602, rbe_right = 0x5,
> rbe_parent = 0xc40aa8e0, rbe_color = -1002258432}, entry_ext_gwy = {
> rbe_left = 0xc3c42238, rbe_right = 0x1, rbe_parent = 0x0,
> rbe_color = 0}, entry_id = {rbe_left = 0xc3c54470, rbe_right = 0x0,
> rbe_parent = 0x0, rbe_color = 0}, entry_list = {tqe_next =
> 0xc41f9e6c, tqe_prev = 0x0}, kif = 0xc442c58c},
> ifname = "\002\006\001\000\000\000\005\000à¨\nÄ\000ÀBÄ"}
>
> Does anyone have any suggestions on where to look next?
You could try the attached patch that I just set to re@ for inclusion. There
is an obvious error in how I handle the pf_consistency_lock in the purge
thread that might well be the culprit for the error you are seeing. I assume
you can't trigger the panic at will, though. In any case I'd be interested in
your feedback, thanks.
--
/"\ Best regards, | mla...@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mla...@efnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: sys/contrib/pf/net/pfvar.h
===
--- sys/contrib/pf/net/pfvar.h (revision 196216)
+++ sys/contrib/pf/net/pfvar.h (working copy)
@@ -1593,8 +1593,13 @@ extern struct pool pf_state_pl, pf_altq_pl, pf_p
extern struct pool pf_state_scrub_pl;
#endif
extern void pf_purge_thread(void *);
+#ifdef __FreeBSD__
+extern int pf_purge_expired_src_nodes(int);
+extern int pf_purge_expired_states(u_int32_t, int);
+#else
extern void pf_purge_expired_src_nodes(int);
extern void pf_purge_expired_states(u_int32_t);
+#endif
extern void pf_unlink_state(struct pf_state *);
extern void pf_free_state(struct pf_state *);
extern int pf_insert_state(struct pfi_kif *,
Index: sys/contrib/pf/net/pf.c
===
--- sys/contrib/pf/net/pf.c (revision 196216)
+++ sys/contrib/pf/net/pf.c (working copy)
@@ -971,6 +971,9 @@ void
pf_purge_thread(void *v)
{
int nloops = 0, s;
+#ifdef __FreeBSD__
+ int locked;
+#endif
for (;;) {
tsleep(pf_purge_thread, PWAIT, "pftm", 1 * hz);
@@ -978,14 +981,19 @@ pf_purge_thread(void *v)
#ifdef __FreeBSD__
sx_slock(&pf_consistency_lock);
PF_LOCK();
+ locked = 0;
if (pf_end_threads) {
- pf_purge_expired_states(pf_status.states);
+ PF_UNLOCK();
+ sx_sunlock(&pf_consistency_lock);
+ sx_xlock(&pf_consistency_lock);
+ PF_LOCK();
+ pf_purge_expired_states(pf_status.states, 1);
pf_purge_expired_fragments();
- pf_purge_expired_src_nodes(0);
+ pf_purge_expired_src_nodes(1);
pf_end_threads++;
- sx_sunlock(&pf_consistency_lock);
+ sx_xunlock(&pf_consistency_lock);
PF_UNLOCK();
wakeup(pf_purge_thread);
kproc_exit(0);
@@ -994,20 +1002,44 @@ pf_purge_thread(void *v)
s = splsoftnet();
/* process a fraction of the state table every second */
+#ifdef __FreeBSD__
+ if(!pf_purge_expired_states(1 + (pf_status.states
+ / pf_default_rule.timeout[PFTM_INTERVAL]), 0)) {
+ PF_UNLOCK();
+ sx_sunlock(&pf_consistency_lock);
+ sx_xlock(&pf_consistency_lock);
+ PF_LOCK();
+ locked = 1;
+
+ pf_purge_expired_states(1 + (pf_status.states
+ / pf_default_rule.timeout[PFTM_INTERVAL]), 1);
+ }
+#else
pf_purge_expired_states(1 + (pf_status.states
/ pf_default_rule.timeout[PFTM_INTERVAL]));
+#endif
/* purge other expired types every PFTM_INTERV
Re: Loading ng_socket at runtime?
On Thursday 30 July 2009 11:39:00 Robert Watson wrote: > On Wed, 29 Jul 2009, Matthew Fleming wrote: > > I'm doing a migration from releng/6.1 to stable/7, and one of the many > > new things is that I get a warning when doing things with ng_socket that > > didn't used to happen. > > > > WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > > I've wondered about these warnings also, and am not sure they're justified > -- any protocol loading after domainfinalize() should expect that timers > are already started, etc, and loadable protocols are clearly desirable. > > > - ignore the warning (usually a bad idea...) > > Probably remove the warning. Some more synchronization is likely required > in domain registration than is currently there -- on the other hand, it's > probably not a big issue that it's missing as write operations on the > domain list are conservative and extremely rare. > > I've CC'd Max Laier, who added the warnings -- perhaps he could lend some > insight into the types of problems he anticipated. The main one I'm aware > of is that mutating the domain list on a live system is risky because it's > not well-synchronized -- however, adding domains should be pretty safe in > practice. This originated from http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/72772 - if I remember correctly. As usual, the devil is in the details. In the case of the PR there was a race for if_afdata contents. The specific problem described in that PR is a static initialization order problem, but - as I recall - we did see a similar issue with runtime loading of domains as well. The waring was added as a compromise. We didn't want to remove the ability to add netgraph at runtime, but would want to discourage more domains with module capabilities. A full fix was way out of reach at the time as it means a lot of synchronization around otherwise very static data (e.g. if_afdata). Maybe it is time to revisit as we now have read-mostly locks and there is more locking in place for things like address-lists (which was also an area of concern). In any case and my opinion, removing a domain should never be allowed at runtime. Unless we add proper synchronization around the protosw, that is. -- /"\ Best regards, | mla...@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mla...@efnet / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: carpX: incorrect hash with IP aliases
On Wednesday 04 March 2009 13:50:09 Eirik Øverby wrote: > On Mar 3, 2009, at 19:23, Scott Ullrich wrote: > > On Tue, Mar 3, 2009 at 12:52 PM, Max Laier wrote: > > [snip] > > > >> Make sure that you are configuring the same aliases with the same > >> netmasks on > >> all members of the carp group - preferably before bringing the > >> interface up > >> for the first time (though it should properly recalculate the > >> hashes as you > >> add aliases). As you seem to be using pfsense you might want to > >> check with > >> them to make sure they have the fix in their build - though I > >> recall it was a > >> joined effort back then. > > > > 1.2.3 is based on 7.1 so this patch should be in the base system now. > > Just tested, and this seems to work. > Now I just need to figure out how to make sure both carp nodes have > the IPs added/removed at ~exactly the same time.. Just ifconfig down the BACKUP, change the config on both and bring the BACKUP back up ;) -- /"\ Best regards, | mla...@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mla...@efnet / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: carpX: incorrect hash with IP aliases
On Tuesday 03 March 2009 15:57:50 Eirik Øverby wrote: > Hi, > > whenever I configure an extra IP on one of my CARP interfaces, traffic > on that particular subnet slows to a crawl (the primary IP of the > interface is the gateway IP), and I get lots of > carp4: incorrect hash > in dmesg. > > I see this issue referenced also in >http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017160.html > and there are suggestions this is a known issue - however I still see > it in FreeBSD 7.1 (pfSense 1.2.3-prerelease). I cannot find a PR on > this, but my searching skills may be inadequate.. You might be referring to http://www.freebsd.org/cgi/query-pr.cgi?pr=121574 which should have been fixed with rev 1.54 (MFC'ed in 1.52.2.1 to RELENG_7) of ip_carp.c > Am I doing something wrong? I tried assigning the alias with both /32 > and /24 netmasks. Make sure that you are configuring the same aliases with the same netmasks on all members of the carp group - preferably before bringing the interface up for the first time (though it should properly recalculate the hashes as you add aliases). As you seem to be using pfsense you might want to check with them to make sure they have the fix in their build - though I recall it was a joined effort back then. -- /"\ Best regards, | mla...@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mla...@efnet / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IPC Sys5 for amd64?
On Monday 02 March 2009 23:07:30 nico...@boiteameuh.org wrote: > Hi all, > > I'm trying to install a PostgreSQL db on FreeBSD 7.1-RELEASE amd64. > It's seems I can't allocate a shared memory segment more than 2GB. > I tune sysctl ipc.shm* values but without effects. > > IPC Sys5 isn't "64bit-aware" or the problem is elsewhere? It looks like shm_segsz in struct shmid_ds is of type int, so that will limit your segment. Also there are the kernel config options SHMMAX and SHMMAXPGS. -- /"\ Best regards, | mla...@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mla...@efnet / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: synproxy state does not work on FreeBSD 7.1-PRERELEASE
On Thursday 04 December 2008 16:47:13 Max Laier wrote: > On Thursday 04 December 2008 16:24:23 Vladimir Ermakov wrote: > > problem is fixed in OpenBSD 4.4 > > http://www.openbsd.org/plus44.html > > The bug this note refers to was introduced after OpenBSD 4.1 (our last > import) and should not be present in the FreeBSD code. I'll double check > in a bit to make sure synproxy is working, but I don't think it was broken > after my last import ... do you have a particular test case that I could > reproduce? Okay ... here is the story: First off, "synproxy state" is *NOT* broken! But you need to be careful how you use it. If you - like the OP - intend to use it to protect a service running on the same box as your pf, you must make sure to "set skip on lo0" or it will not work. If you are protecting a box behind the pf box, there is no need for that. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: synproxy state does not work on FreeBSD 7.1-PRERELEASE
On Thursday 04 December 2008 16:24:23 Vladimir Ermakov wrote: > problem is fixed in OpenBSD 4.4 > http://www.openbsd.org/plus44.html The bug this note refers to was introduced after OpenBSD 4.1 (our last import) and should not be present in the FreeBSD code. I'll double check in a bit to make sure synproxy is working, but I don't think it was broken after my last import ... do you have a particular test case that I could reproduce? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LORs in RELENG_7
On Friday 21 November 2008 18:39:33 Ulrich Spoerlein wrote: > On Thu, 20.11.2008 at 17:56:07 -0500, Michael Proto wrote: > > On Thu, Nov 20, 2008 at 4:11 PM, Ulrich Spoerlein <[EMAIL PROTECTED]>wrote: > > > Hi, > > > > > > I'm running my RELENG_7 kernel with WITNESS and there's always a LOR > > > when pf(4) is enabled: > > > > > > lock order reversal: > > > 1st 0xc09ca828 ifnet (ifnet) @ /usr/src/sys/net/if.c:849 > > > 2nd 0xc45d604c pf task mtx (pf task mtx) @ > > > /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:916 > > > KDB: stack backtrace: > > > db_trace_self_wrapper(c08df797,fb671764,c0630e8e,c08e1c96,c45d604c,...) > > > at db_trace_self_wrapper+0x26 > > > kdb_backtrace(c08e1c96,c45d604c,c45d3b1c,c45d3b1c,c45d379e,...) at > > > kdb_backtrace+0x29 > > > witness_checkorder(c45d604c,9,c45d379e,394,c08e9058,...) at > > > witness_checkorder+0x6de > > > _mtx_lock_flags(c45d604c,0,c45d379e,394,fb6717dc,...) at > > > _mtx_lock_flags+0xbc > > > pfi_attach_group_event(0,c445,c08e9058,374,c44a920c,...) at > > > pfi_attach_group_event+0x4e > > > if_addgroup(c441c000,c08f70d6,4,0,0,...) at if_addgroup+0x2c7 > > > if_clone_createif(0,0,c08e9563,87,0,...) at if_clone_createif+0x81 > > > if_clone_create(fb671943,4,0,44,180,...) at if_clone_create+0x8c > > > tunclone(0,c461e400,fb671943,4,fb67195c,...) at tunclone+0x17a > > > devfs_lookup(fb6719d0,fb6719d0,fb671b7c,c418de04,2,...) at > > > devfs_lookup+0x50e > > > VOP_LOOKUP_APV(c0928f40,fb6719d0,c412f230,c08e77ef,2a9,...) at > > > VOP_LOOKUP_APV+0xa5 > > > lookup(fb671b7c,c08e77ef,c6,bf,c461e92c,...) at lookup+0x58e > > > namei(fb671b7c,c412f230,fb671a74,246,c0983774,...) at namei+0x34b > > > vn_open_cred(fb671b7c,fb671c78,ce8,c461e400,c4460558,...) at > > > vn_open_cred+0x2c9 > > > vn_open(fb671b7c,fb671c78,ce8,c4460558,c05e807d,...) at vn_open+0x33 > > > kern_open(c412f230,80a0f18,0,3,808ecfa,...) at kern_open+0xe7 > > > open(c412f230,fb671cfc,c,c08e28c3,c092c0b8,...) at open+0x30 > > > syscall(fb671d38) at syscall+0x2b3 > > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > > --- syscall (5, FreeBSD ELF32, open), eip = 0x2835a65b, esp = > > > 0xbfbfeafc, ebp = 0xbfbfeb38 --- > > > > Are you using user or group rules in your pf.conf? IIRC there is still a > > known LOR in the socket layer with rules using the user or group filters. > > No, I'm aware of the problems with pf(4) and user/group rules. This LOR > is in combination with rules on tun(4) devices, as you can see from the > backtrace. I wonder what tunclone() is doing in there, though. This LOR is believed to be harmless. There should be an easy fix, even. I'll have to take a look over the weekend. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Block device
On Tuesday 04 November 2008 15:32:01 d_elbracht wrote: > Hi list, > > can someone please explain, why > stat -x /dev/da1 > > show the SCSI-Drive as a character-device ? > > Also, on the same device > > S_ISREG(st.st_mode) is false > > S_ISCHR(st.st_mode) is true http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: zfs quota question
On Tuesday 07 October 2008 12:43:45 Pete French wrote: > > Yeah, ZFS offers a lot, which can create confusion, unfortunately. Do we > > limit physical space with quota or only logical (before compression)? > > Should we take space consumed by snapshots into account or not? etc. > > On a related note, is there any way to make du tell me how big files > are in actual bytes on a compressed ZFS filesystem, aas opposed to space > on the disc ? I love ZFS, but I suddenly found out last night that I > have lost the ability tto do a 'du' on a directory to work out if it will > fit onto a CD or not :-) But you can't do that on UFS either: sparse files, hardlinks, ... The GNU du(1) has a "--apparent-size" switch to get the logical size instead of what the tool's name suggests (the disk usage). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
On Tuesday 12 August 2008 13:35:33 Mathieu Arnold wrote: > +-le 12.08.2008 12:02:42 +0100, Pete French a dit : > |> Since I added IPv6 to my network, and started really using it, I'm > |> seeing some strange things happening. > |> > |> For instance, I'm on machine 2a01:678:1:443::443, and I do : > |> > |> $ traceroute6 -n 2a01:678:100:2:: > |> traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > |> 2a01:678:1:443::443, 64 hops max, 12 byte packets > |> 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > |> 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > |> > |> 2a01:678:1:443:: is it's default gateway, and is also directly connected > |> to 2a01:678:100:2::, but it does not seem to be able to contact it. > | > | What are your prefix lengths on the various interfaces, and does > | 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you > | can show us the config on the interfaces of the three machines then > | we might be able to get a better idea. I am imagining how you have these > | three boxes connected in my head, but nothing beats an explanation plus > | the config :-) > > Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both > have the "same" gateway, that is, the same box, which has : > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 > > The problem I'm seeing is that before I ping the machine from the gateway, > all ndp -a says about this machine is : > > 2a01:678:100:2:: (incomplete) em0 1sI > 3 > > when I ping it from the first host, I see : > > 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length > 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, > who has 2a01:678:100:2::, length 32 > fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, ^--^ There is your problem. You have all three hosts connected to the same broadcast domain? Disable redirects or separate the domains using VLAN or similar - otherwise the gateway will get smart and try to avoid work. > 2a01:678:100:2:: to 2a01:678:100:2::, length 104 > fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor > advertisement, tgt is 2a01:678:100:2::, length 32 > fe80::207:e9ff:fe0e:dead > ff02::1:ffe1:c05f: ICMP6, neighbor solicitation, > who has fe80::2b0:d0ff:fee1:c05f, length 32 > fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor > advertisement, tgt is fe80::2b0:d0ff:fee1:c05f, length 32 > > and when I ping it from the gateway, I see : > > 2a01:678:100:25:: > 2a01:678:100::: ICMP6, neighbor solicitation, who has > 2a01:678:100::, length 32 > 2a01:678:100:: > 2a01:678:100:25::: ICMP6, neighbor advertisement, tgt is > 2a01:678:100::, length 24 > 2a01:678:100:: > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has > 2a01:678:100:2::, length 32 > 2a01:678:100:2:: > 2a01:678:100::: ICMP6, neighbor advertisement, tgt is > 2a01:678:100:2::, length 32 > > And I don't understand why there's a difference, and why when the packets > don't come from the gateway, the neighbor solicitation goes up wrong and > does not work. > > |> Maybe I'm doing something wrong, but, well, I can't seem to find ou > |> what. > |> > |> 2a01:678:1:443::443 is a 7.0 > |> 2a01:678:1:443::is a 6.2 > |> 2a01:678:100:2::is a 6.0 > | > | I've used all of those with IPv6 and they work fine, it's most likely > | a small config problem. I had a lot of frustrations with IPv6 when I > | started using it - though now it is working I wouldn't be without it. > > Well, I'm certain it must be some stupid configuration problem, but, well, > I can't seem to find it :-) -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lagg(4) and failover
On Tuesday 12 August 2008 13:43:29 Marian Hettwer wrote: > Hi Pete, > > On Tue, 12 Aug 2008 12:30:12 +0100, Pete French > > <[EMAIL PROTECTED]> wrote: > >> However, IMO lacp doesn't solve that problem. lacp is used for link > >> aggregation, not failover. > > > > It does both - if one of the links becomes unavailable then it will > > stop using it. We use this for failover and it works fine, the only > > caveat being that your LACP device at the far end needs to look like > > a single phsyical device (the nicer Cisco switches do this quite happily) > > thanks for that info. > > >> The manpage states "In the event of changes in physical > > > > connectivity...". > > > >> Again, does that mean, the link needs to be physically unavailable? If > > > > so, > > > >> it'll be the same behaviour as in failover mode and doesn't solve my > >> problem of a misconfigured switch... > > > > lagg is to handle failover at the physical layer for when one of your > > ether ports fails, or someone unplugs a cable. If I understand you > > correctly you are looking for something at the next layer up, to handle > > a problem where the ports work fine, but are not going to their expected > > destinations. lagg won't do this. > > Thats unfortunate... > bonding in Linux is capable of doing this and solaris too. > Well then. At least everythings clear now. And in the end, clarifing things > was the reason for that mail thread :) You are looking for net/ifstated -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Max size of one swap slice
On Tuesday 05 August 2008 17:39:11 Lin Jui-Nan Eric wrote: > Recently we found that we can only allocate 32GB for one swap slice. > Does there is any sysctl oid or any kernel option to increase it? Why > we have this restriction? this is a consequence of the data structure used to manage swap space. See sys/blist.h for details. It *seems* that you *might* be able to increase the coverage by decreasing BLIST_META_RADIX, but that's from a quick glance and most certainly not a good idea. However, the blist is a abstract enough API so that you can likely replace it with something that supports 64bit addresses (and thus 512*2^64 bytes of swap space per device) ... but I don't see why you'd want to do something like this. Remember that you need memory to manage your swap space as well! -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming ABI Breakage in RELENG_7
On Wednesday 30 July 2008 11:47:34 David Southwell wrote: > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: ... > For those of us who are not as well informed and experienced as others > could someone please explain what is meant by an ABI breakage, its > implications and how to deal with them. An Application Binary Interface (ABI) breakage means a change of a complex datatype, or a function prototype - in C usually the change of a struct in size or field sort order. This change will effect all consumers of this Interface unless they are recompiled with the changed header files to also use the new interface. The impact depends greatly on the interface that is being changed. As Ken described in the initial mail this change is in the filesystem/vnode layer interface and thus will (only) concern consumers of that ABI. The changed interface is also a kernel-only interface - that means that only 3rd party kernel modules will be affected. I personally don't know of any 3rd party modules that muck about with filesystems (for which you can't get the source). That said, you might have to rebuild stuff like fuse after the breakage has happened. I assume that port maintainers of affected (kernel module) ports will bump the port revision after the change to give you/portupgrade a hint. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 and BIND exploit
On Tuesday 22 July 2008 00:31:53 Charles Sprickman wrote: > On Mon, 21 Jul 2008, Kevin Oberman wrote: > >> From: Max Laier <[EMAIL PROTECTED]> > >> Date: Mon, 21 Jul 2008 21:38:46 +0200 > >> Sender: [EMAIL PROTECTED] > >> > >> On Monday 21 July 2008 21:14:22 Doug Barton wrote: > >>> Brett Glass wrote: > >>> | Everyone: > >>> | > >>> | Will FreeBSD 7.1 be released in time to use it as an upgrade to > >>> | close the BIND cache poisoning hole? > >>> > >>> Brett, et al, > >>> > >>> I'll make this simple for you. If you have a server that is running > >>> BIND, update BIND now. If you need to use the ports, that's fine, > >>> just do it now. Make sure that you are not specifying a port via > >>> any query-source* options in named.conf, and that any firewall > >>> between your named process and the outside world does keep-state on > >>> outgoing UDP packets. > >> > >> ... and that any NAT device employs at least a somewhat random port > >> allocation mechanism - pf provides this. > > > > And, if you are not sure how good a job it does (and I am not), you > > should use the OARC test to check how well it works: > > dig +short porttest.dns-oarc.net TXT > > > > If the result is not "GOOD", it's not good enough. > > I was playing around with this a bit. It seems like a patched server > will give a standard deviation of more than 18,000. If I make some > queries behind a one-to-many NAT using pf, it falls to somewhere around > 6,000 (with a patched BIND - unpatched is pitiful). While the standard deviation gives some *indication* about the randomness of the selection it is no real measurement for its quality. > PF is not *adding* any randomness to unpatched servers. Since it has a > (non-configurable?) range of ports it will grab when doing outbound > NAT, the results are not as good as with no NAT intervention, but > passable I suppose. You can configure the range on a per-NAT-rule basis, e.g.: nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if) port 1024:65535 but you have to take care so that you don't collide with the ephemeral port range of the host itself. Obviously you can't do much about an unpatched bind as with UDP there is no notion of "connection" so pf (or any NAT device for that matter) has to keep the NAT binding open for "some time" and a quick sequence of queries to the same server will be sent out through the same port. So putting a NAT firewall in front of a DNS resolver is *NOT* a workaround! > Of course in a 1:1 NAT setup it is transparent. > > Charles > > > You can test a remote server by adding "@remote-server" to the dig > > command. The server may be specified by name or IP address. > > > > Don't forget that ANY server that caches data, including an end > > system running a caching only server is vulnerable. > > -- > > R. Kevin Oberman, Network Engineer > > Energy Sciences Network (ESnet) > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 and BIND exploit
On Monday 21 July 2008 21:14:22 Doug Barton wrote: > Brett Glass wrote: > | Everyone: > | > | Will FreeBSD 7.1 be released in time to use it as an upgrade to > | close the BIND cache poisoning hole? > > Brett, et al, > > I'll make this simple for you. If you have a server that is running > BIND, update BIND now. If you need to use the ports, that's fine, just > do it now. Make sure that you are not specifying a port via any > query-source* options in named.conf, and that any firewall between > your named process and the outside world does keep-state on outgoing > UDP packets. ... and that any NAT device employs at least a somewhat random port allocation mechanism - pf provides this. > If you have a system with BIND installed (as it is by default) but you > are NOT running named, you don't need to worry about updating now, but > you should do it "soonish" just in case someone gets a wild hair and > starts up named on that box. > > As for the meta-question, FreeBSD is currently operating on a > time-based release schedule, not a feature-based one. And to your > actual question, the answer is no. > > > hope this helps, > > Doug -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New Mailinglist: freebsd-wip-status@
Hello everybody, SHORT SUMMARY: http://lists.freebsd.org/mailman/listinfo/freebsd-wip-status Subscribe today!! Tell all your friends, co-workers and everybody you know who's interested in FreeBSD. Post this on your blog! ;) LONG VERSION: if you've been around lately you might already know about our effort to provide periodical status reports about ongoing FreeBSD related WIPs. The past reports can be found at: http://www.freebsd.org/news/status This system has some shortcomings however. The biggest one is that due to the collection overhead and the high rate of exciting development under the FreeBSD umbrella most of the reports are somewhat outdated by the time they get to "print". Other projects never are announced in the status reports because they happen in-between and fall through the cracks. In order to improve this situation we have created a new mailing list that should receive status reports from now on. This list will be moderated in order to keep it close to the subject. The intend is to make this an inviting place for people with little time to still stay on top of the latest and greatest in and around FreeBSD, but where one can avoid the chatter that comes with the technical debates on the normal lists. For all developers, contributors, conference organizers, 3rd party distributions, SoC-students and whoeverelse has exciting news about their FreeBSD related project this means little work. Most of you already are sending out announcement- and update-emails to lists like current@, net@ or whichever fits your project in order to inform the world about the progress you've made. Now we would like to invite you to BCC: this email to freebsd-wip-status@ as well for maximum exposure. Emails with a lot of gory, technical details are probably not suited for this list, but the usual: "Hey, I've got these cool patches to test. Here is what they do: ..." most certainly is. So this is really like the status reports before, but everybody subscribed can get the news when they happen (and not three month later when the next status reports are due). I hope for your support in bootstrapping this idea. During the next few weeks I'll keep a close eye on the lists I'm subscribed to and will encourage people to forward matching posts to freebsd-wip-status@ You are welcome to do the same. We also plan to keep the status reports as is, but collecting the reports from this new list, too. This should give the best of both worlds, we hope. If you have any questions or would like to help with editing the status reports, please contact [EMAIL PROTECTED] (reply-to set) or myself directly. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Saturday 07 June 2008 21:41:18 Jo Rhett wrote: > On Jun 5, 2008, at 2:45 AM, Steven Hartland wrote: > > You are still fail to take to the time to even tell people what these > > bugs are, no ones a mind reader! > > > > People are trying to help you here but all I'm hearing is a child > > like "It doesn't work fix it", with no willingness to even explain > > what it is or provide resources to test if someone found the time to > > investigate > > your issues. > > Given this I don't see how you can expect these so called issues to > > ever get fixed. > > I think you are misunderstanding the point at hand. I'm not trying to > address specific issues. (I'd be happy to in another thread next > week). This thread was created to address the overall well-documented > list of bugs in 6.3, which is the *only* supported stable version of > the operating system. (7.0 is even less stable) > > The most stable (by numbers of bugs and numbers of reported problems) > is 6.2. > > I see no valid reasoning that can be backed up by numbers as to why > 6.2 should be EoL. That's the point I'm addressing. The specific > bugs that affect us are not necessarily relevant to the overall > stability. And anyone can do the same searches on the bug list to > confirm these numbers for themselves. Here is a cluebat for you: Messages in this flamboyant thread of yours: 113 and counting Messages in support of your claim not sent by yourself: 0 Now please: STFU or invest your time into something more productive. By the way, for somebody who claims to have no time to provide details about the bugs that make 6.3 so bad you seem to have a lot of time to send bogus emails (26 since Wednesday). If you had only spend a bit of that time into actual bughunting ... -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Thursday 05 June 2008 02:26:29 Jo Rhett wrote: > On Jun 4, 2008, at 5:05 PM, Scott Long wrote: > > Jo Rhett wrote: > >> On Jun 4, 2008, at 12:00 PM, Scott Long wrote: > >>> Can you describe the bugs that are affecting you? > >> > >> gmirror failures, 3ware raid driver timeouts, bge0 problems. All > >> three in production use on dozens of systems. > > > > Give me specific details on the 3ware and bge problems. > > Familiar with searching the open bug reports? That's where I found > them. > > Sorry, I'm knee-deep in a major project that I've been working 16+ > hours a day on right now, and I just don't have the time for spurious > queries. Query the open bug reports for 6.3 and then explain to me > again why 6.2 is no longer supported. Because the people who support FreeBSD 6.2 are also knee-deep in major projects of their own!? We try try to not introduce regressions as we move forward supporting new features and hardware, but unless people put in some effort of their own helping us to test ... You obviously did not put in any effort of your own so why would you expect us to do the work for you? Unless you can provide "*EXACT*" bug reports and show willingness to help debugging them, there really is not much point in this thread. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On Friday 30 May 2008 11:35:56 Robert Blayzor wrote: > On May 30, 2008, at 4:47 AM, David Malone wrote: > > There has been some talk about this sort of problem on the IETF TCP > > Maintainers list. I don't think any good conclusion was reached - > > whatever the solution was certainly needs to be tunable per-socket > > because this behaviour is perfectly valid in some situations but a > > bit of a pain in others. > > A timeout value would be fine. Obviously if the client keeps sending > back packets with a 0 size, there should be some option or work around > to tell the stack to drop the connection. There than to have the > server lock up resources on a "dead connection". Unfortunately we're > talking about the internet here, we can't insure that every one of the > clients connecting to our servers behaves correctly! ;-) > > On a side note, I could easily fix this problem by frontending the > server with a Cisco PIX or ASA. I believe they have "half closed" > timers just for this purpose... Perhaps a kernel tunable knob would be > a nice option/fix/hack also. pf does that, too. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Digitally Signed Binaries w/ Kernel support, etc.
On Wednesday 02 April 2008 21:09:59 Forrest Aldrich wrote: > Does FreeBSD have support for digitally signed binary checking, similar > to what Linux has with bsign and DigSig, where system binaries are > signed and this signature is verified before being run in the kernel? There is mac_chkexec[1], but I'm not sure about its status. > This would be very useful to have to further tighen-down the system. [1]http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/trustedbsd/mac/sys/security/mac%5fchkexec&HIDEDEL=NO -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about file system checks
On Friday 28 March 2008 22:50:39 Ivan Voras wrote: > Matthew Seaman wrote: > > Ivan Voras wrote: > >> 1. UFS+gjournal looses the least, but it's also the slowest. > >> 2. UFS+SU had no truncated files or files of unexpected length > >> (apparently it just looses the file that would end up in this state) > >> 3. XFS and JFS end up with a *huge* number of files that are > >> truncated or of unexpected length (40%-50%!) > >> 4. In no case has any of the above file systems gone completely > >> corrupted or lost any of the files/directories not being updated. > >> 5. ZFS on FreeBSD was the fastest, in the sense of creating the most > >> files during this benchmark (though speed was not the target for > >> this benchmark so this is a low-quality observation), closely > >> followed by JFS and XFS. > >> 6. ZFS crashed the kernel at least once. > > > > Hmmm in many ways a corrupt or truncated file is a worse outcome > > than a completely missing file -- at least if the file has gone away > > you know you've got to do something to fix it. A damaged file could > > end up silently causing weird behavioural effects and (by the law of > > natural cussedness) it is almost bound not to be tracked down until > > the day after the last good copy on the backup tapes gets > > overwritten... > > > > How do the different filesystems compare if you total all lost, > > damaged or truncated files? > > The only things that happen are that XFS and JFS get disproportionally > bad numbers and that ext3 gets almost identically bad results with > UFS+SU. Overall ratios remain approximately the same. > > To put this into perspective, for total "bad" files this means that, > e.g. UFS+SU created 2 files, of which 750 were in some way "bad", > and ZFS created 46000 files, of which 900 were bad (so percentage is in > favour of ZFS). JFS created 43000 files of which 2 were of wrong > size, but only 45 were completely lost. How bad this is depends, of > course on what is done with the file system. > > A big surprise for me was that Windows' NTFS did very good, though it > was the slowest in most other tests (which are smarter and probably use > fsync a lot), it managed to create 32000 files and have only 121 "bad" > in some way. Can you please give more details about your benchmark? It seems to me that the only thing you are measuring is how many files you managed to touch between the last sync(2) and plugging the power. This is not an interesting number. What would be interesting is to stop the syncer, touch a known number of files and then pull the plug. But in the end it boils down to: There is fsync to build transactions - use it or else. If you find that you lose fsync'ed files, that's a reason for concern, of course. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (traces)
Hi Alex, so it's basically back to square one. We only have LORs between the pfil R/W lock (read instance) and mutexes that don't have any lock order with the pfil R/W lock (write instance) at all. This means the deadlock can't be explained by the LORs that are reported (unless there is something I'm missing). Unless somebody who is seeing these kind of deadlocks can actually break into a debugger to identify the locks at play, everything else is just speculation. I will fix the fastroute LOR with the patch you have been testing, eventhough it didn't fix your problem. For the remaining issue, we need more IPFW or lock primitives knowledge (extending CC-list). Note that the first LOR features a recursive pickup of the pfil R/W lock. I remember that Attilio committed a patch to forbid this for CURRENT. Could this be the cause of a deadlock? Would it make sense to MFC rm_locks and try if they hold up under this scenario? On Tuesday 25 March 2008 20:21:15 Alex Popa wrote: [...] > Hello. > > I have tested the patch, booted with a WITNESS kernel including that > patch, and it has locked up (solid again, no numlock or console > changing, no control-alt-esc to debugger) after about 41 minutes > (timestamps in /var/log/all.log go from 19:12:57 to 19:53:40). > > I did get two LOR reports in dmesg, they are attached. > lock order reversal: > 1st 0x8096ebc8 PFil hook read/write mutex (PFil hook read/write > mutex) @ /usr/src/sys/net/pfil.c:73 > 2nd 0x8096f8e8 udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:385 This one could be avoided if dummynet_send where to use a queue instead of direct dispatch - with all associated problems. > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > witness_checkorder() at witness_checkorder+0x539 > _mtx_lock_flags() at _mtx_lock_flags+0x1f > udp_input() at udp_input+0x1f7 > ip_input() at ip_input+0xa7 >>> QUEUE here <<< > dummynet_send() at dummynet_send+0xde > dummynet_io() at dummynet_io+0x587 > ipfw_check_in() at ipfw_check_in+0x241 > pfil_run_hooks() at pfil_run_hooks+0xac > ip_input() at ip_input+0x292 > ether_demux() at ether_demux+0x1ac > ether_input() at ether_input+0x1bf > em_handle_rxtx() at em_handle_rxtx+0x1d2 > taskqueue_run() at taskqueue_run+0x95 > taskqueue_thread_loop() at taskqueue_thread_loop+0x53 > fork_exit() at fork_exit+0x112 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xa057ad30, rbp = 0 --- > > lock order reversal: > 1st 0xff00018ff690 inp (rawinp) @ /usr/src/sys/netinet/raw_ip.c:281 > 2nd 0x8096ebc8 PFil hook read/write mutex (PFil hook read/write > mutex) @ /usr/src/sys/net/pfil.c:73 I'm still a bit suspicious of this one due to the interaction of exclusive IPFW locks with raw sockets, but I still can't find the code path for the original order, which makes it a bit hard to follow. Alex, can you get a "show witness" after this LOR has been displayed? > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > witness_checkorder() at witness_checkorder+0x539 > _rw_rlock() at _rw_rlock+0x25 > pfil_run_hooks() at pfil_run_hooks+0x44 > ip_output() at ip_output+0x35a > rip_output() at rip_output+0x1eb > sosend_generic() at sosend_generic+0x289 > kern_sendit() at kern_sendit+0x122 > sendit() at sendit+0xc6 > sendto() at sendto+0x4d > syscall() at syscall+0x1b5 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (133, FreeBSD ELF64, sendto), rip = 0x80091132c, rsp = > 0x7ffee6e8, rbp = 0x40 --- Any input greatly appreciated! -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (traces)
Hi Alex,
On Saturday 22 March 2008 11:29:33 Alex Popa wrote:
> Sorry for the big delay, but here are the traces you requested.
don't worry, you are a great help!
Could you try the attached patch? I missed the fact that you are using
FASTROUTE in your setup. There is obviously a problem with it, but the
attached patch should work around that. The other LOR really is harmless
and rather an oversight in WITNESS: a LOR with a shared/read lock can't
cause a deadlock (unless there is also a LOR with the same lock in
exclusive mode). But this is rather complex to check and might not be
easily implemented in WITNESS.
Anyways - I believe this patch should work around your problem. Let us
know your findings - thanks.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: pf.c
===
RCS file: /home/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v
retrieving revision 1.51
diff -u -r1.51 pf.c
--- pf.c 21 Nov 2007 10:12:52 - 1.51
+++ pf.c 22 Mar 2008 15:42:18 -
@@ -6106,7 +6106,13 @@
dst->sin_addr = ip->ip_dst;
if (r->rt == PF_FASTROUTE) {
+#ifdef __FreeBSD__
+ PF_UNLOCK();
+#endif
rtalloc(ro);
+#ifdef __FreeBSD__
+ PF_LOCK();
+#endif
if (ro->ro_rt == 0) {
ipstat.ips_noroute++;
goto bad;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet
ut not bound for networks received via BGP and saved to > > tables and . Metro and special port 80 traffic goes > > directly to the destination server. > > > > Traffic from net1 and net2 is routed via the "other" external > > interface, which doesn't contain the default route... with the > > exception of traffic to pf table (from BGP, same as table 2 > > in ipfw). Traffic to is routed via fastroute in pf > > (meaning using the default route). That's quite a complex setup. It would really be interesting to get the trace for the first LOR in order to figure out which code path we are looking at. I have a feeling that it might be the dummynet entry point, but w/o the trace this is only speculation. > > Attached are full dmesg and the kernel config. > > > > I still have access to the hard drive with 7.0-STABLE on it, but not > > the motherboard/CPU and the network cards... they are running off the > > hard drive with 6.2 on it. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: USB support + Supermicro IPMI KVM = no keyboard
On Tuesday 29 January 2008, Steven Hartland wrote: > When booting a default kernel e.g. standard install cd the KVM over LAN > keyboard on Supermicro's IPMI modules refuse to function. Once > installed if we build a kernel without USB all is good. > > So two questions:- > 1. Can usb support be disabled from the loader? > 2. Anyone got any ideas why USB would break the IPMI keyboard? You could try hint.kbdmux.0.disabled="1" - see kdbmux(4) for details. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: FreeBSD on Dell T105? ($350 dual-core Opteron)
On Thursday 20 December 2007, Chris Shenton wrote: > [I'm adding -current as there are other discussions of hardware > compatibility there, trim if appropriate] > > Chris Shenton <[EMAIL PROTECTED]> writes: > > > > http://www.dell.com/downloads/global/products/pedge/en/pe_T105_spec_s > >heet.pdf > > > > Processors Single AMD Opteron TM 1000 series at up to > > 2.8GHz; Single AMD SempronTM LE1250 at 2.2GHz > > > > HyperTransportTMHyperTransport at 2000MT/s > > > > Chipset nVidia CK8-04 Pro > > > > Network Interfaces Single embedded Gigabit3 NIC > > I installed FreeBSD 7.0-BETA4 amd64 this morning and it boots fine, > detects both CPUs, but can't seem to find a driver for the ethernet. It > doesn't offer anything at install time (only slip and ppp) and shows > nothing in ifconfig when running. > > The one thing I see in dmesg is: > > pci2: at device 0.0 (no driver attached) > > Some pages I've found say this is a Broadcom 5721J chipset: > > > http://www1.ap.dell.com/content/products/features.aspx/servers_Q4_W5_20 >07-12-01_pedge_t105_Q421211?c=my&cs=mybsd1&l=en&s=bsd > > An Ubuntu message says they see it with a Broadcom NetXtreme BCM5722 > driver: > > > http://ubuntuforums.org/showthread.php?p=3961378 > > Any suggestions on how I can poke at it to find what kind of hardware > it's using and what driver I need to use for it? Sounds like the bge(4) driver might work. Take a look at "pciconfig -lv" to identify the chip and PCI vendor id. Try adding that information to src/sys/dev/bge/if_bge.c::bge_devs[] and subsequent chip revision arrays. It's easiest to build a kernel w/o device bge and loading bge from modules. This way you can cd to src/sys/modules/bge and "make load; #test; make unload; #change source; #repeat" until it works. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Motherboard Asus P5N-E SLI compatibility with FreeBSD 7
On Monday 17 December 2007, Fabien Degomme wrote: > Hi, > > my question is about the Asus P5N-E SLI motherboard. I searched if > this MB is compatible with FreeBSD 7 but I don't have concrete > answer. > > So I just want to know if anyone owns this card with FreeBSD 6 > or 7 and if it works well. > > Thanks in advance :) Last time I checked there was something wrong with the apic. hint.apic.0.disabled=1 from the loader got it booting and working well, but you loose SMP. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: IP Filter
On Monday 17 December 2007, Ollivier Robert wrote: > According to Stephen Clark: > > It looks like it would be as simple as adding: > > SYSCTL_IPF(_net_inet_ipf, OID_AUTO, pf_nattable_max, CTLFLAG_RWO, > >&ipf_nattable_max, 0, ""); > > Isn't the "pf_nattable_max" a typo for "ipf_nattable_max"? > > BTW, talk to Darren Reed about that, he is the author and ipf is > contributed software :) > > Cheers, # ipf -T list -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: missing .cshrc and pf.conf after upgrade to 7.0-beta3
On Tuesday 04 December 2007, Colin Percival wrote: > John Baldwin wrote: > > On Wednesday 28 November 2007 02:47:11 pm Colin Percival wrote: > >> Miroslav Lachman wrote: > >>> I am not 100% sure, maybe I overlook something in binary major > >>> version upgrade procedure, but after upgrade from 6.2 to 7.0-BETA3 > >>> my roots ~/.cshrc was "accidentally" replaced with dist version of > >>> .cshrc and /etc/pf.conf is missing. > >> > >> The fact that /etc/pf.conf disappeared is due to it being removed > >> from the release (it is now in /usr/share/examples/etc). The fact > >> that /.cshrc was upgraded in spite of having been locally modified > >> is probably a bad idea -- I'll change the default > >> freebsd-update.conf to deal with this. > > > > Considering that /etc/pf.conf is a file that users edit to configure > > pf(4), removing it out from under them is probably a very bad idea. > > The heuristics didn't work this time. :-( > > FreeBSD Update tries to guess what users want to have done -- in this > case, the heuristic is "if a configuration file is present in release X > but not in release Y, it's probably not relevant in release Y; so let's > delete it". The case of a default configuration file being moved from > /etc/ into /usr/share/examples/etc is one which I didn't consider; but > I think the general heuristic is a good one (consider the scenario > where a /etc/foo.conf is renamed to /etc/food.conf -- with the current > heuristic, at least the user gets a warning that the file is > disappearing rather than suddenly finding that the foo daemon isn't > starting up properly for no apparent reason). Yet they lose the configuration changes they might have applied to the original foo.conf. I don't think you should delete files that have changed. Maybe moving them somewhere for future reference would be the best thing to do? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Also seeing 2 x quad-core system slower that 2 x dual core
On Thursday 29 November 2007, Pete French wrote: > I think I also just came up against the same effect that the original > poster saw. I have two sets of machines here - one is a pair of dual > core Xeons, the other a pair of quad core Xeons. They are HP servers, > more or less identical apart from the processors I belive. > > Both have 7.0-BETA3 installed, and the same config on them with the > same files. I am trying to delete a gigabyte of files using 'rm -rf' > > On the dual core processors this takes about 20 seconds. On the quad > cores it takes about 3 minutes! This is true for both the 32 and 64 bit > versions of FreeBSD :-( Can you provide more details on this task? It seems like something that could easily be reproduced in a lab environment and serve as a regression test and baseline for future improvements. Is the server doing any other work while doing the rm, or is this it? What kind of directory layout are we looking at? How many files, directories, users ...? What type of filesystem, options, size? BTW, what's your nsswitch.conf like? If you don't need nis, removing it can mean a considerable speed improvement - or try nscd(8). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
On Tuesday 20 November 2007, Kris Kennaway wrote: > Kris Kennaway wrote: > > Kris Kennaway wrote: > >> In the meantime there is unfortunately not a lot that can be done, > >> AFAICT. There is one hack that I will send you later but it is not > >> likely to help much. I will also think about how to track down the > >> cause of the contention further (the profiling trace only shows that > >> it comes mostly from vget/vput but doesn't show where these are > >> called from). > > > > Actually this patch might help. It doesn't replace lockmgr but it > > does fix a silly thundering herd behaviour. It probably needs some > > adjustment to get it to apply cleanly (it is about 7 months old), and > > I apparently stopped using it because I ran into deadlocks. It might > > be stable enough to at least see how much it helps. > > > > Set the vfs.lookup_shared=1 sysctl to enable the other half of the > > patch. > > > > Kris > > Try this one instead, it applies to HEAD. You'll need to manually > enter the paths though because of how p4 mangles diffs. I rolled a tiny, simple, possibly braindamaged benchmark (but then again php code tends to be braindamaged): test.php includes 1000 different, essential empty files and is strated over and over from a shell script which counts the runs completed within 60seconds. 1-8,128 scripts are started in parallel. On a 2x dual Opteron running amd64 I get: stock RELENG_7 w/o patch ULE: jobs sum runs gain 1 6171 2 7841.27 3 9391.52 4 10151.65 5 6581.07 6 6421.04 7 6661.08 8 6961.13 128 7261.18 RELENG_7 patched ULE vfs.lookup_shared=1: jobs sum runs gain 1 6371 2 7841.23 3 9731.53 4 11041.73 5 7081.11 6 7331.15 7 7761.22 8 8401.32 128 9361.47 So there is still a lot of room for improvement here. I'll rebuild with lock profiling tomorrow and see what I can gather. Anything you'd like to see in particular? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: missing .cshrc and pf.conf after upgrade to 7.0-beta3
On Wednesday 21 November 2007, Miroslav Lachman wrote: > pluknet wrote: > > Hello. > > > > On 21/11/2007, Miroslav Lachman <[EMAIL PROTECTED]> wrote: > >>I am not 100% sure, maybe I overlook something in binary major > >> version upgrade procedure, but after upgrade from 6.2 to 7.0-BETA3 > >> my roots ~/.cshrc was "accidentally" replaced with dist version of > >> .cshrc and > > > > It could happen if the 'UpdateIfUnmodified' directive in your > > freebsd-update.conf does not include /root/ path (/etc/ /var/ by > > default). > > Hmmm it seems a little bit dangerous to me. OK, it is my fault. > > >>/etc/pf.conf is missing. > > > > It was moved to examples just before 7.0-BETA3. > > I had my pf.conf modified, but after upgrade and reboot, my machine > booted without firewall, because pf.conf is missing. > > Now I am looking in to /var/db/freebsd-update/install.MvUwSa/INDEX-OLD > and /var/db/freebsd-update/install.MvUwSa/INDEX-NEW - /etc/pf.conf is > only in INDEX-OLD, /root/.cshrc is in both - but I do not know if it > means something, I do not know freebsd-update principles in conjunction > with INDEX-*. It looks like freebsd-update will delete all files in INDEX-OLD but not in INDEX-NEW by default. Is there a way to make a certain file stick around? It was obviously a mistake to install /etc/pf.conf as an example file in the first place, but what can be done about it after the fact? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: 6.3 PRERELEASE
On Friday 09 November 2007, Jon Holstrom wrote: > I had 6.2 stable all setup & > had gnome 2.18 all humming along 100% > java & eclipse, tomcat, bah bah bah! > > updated src & rebuilt only to > find 6.2 is gone & 6.3 prerelease! > > ( I think there should be a button > we need to push to get > software we DONT want! j/k) > > with my setup as it is, can > i back date my cvsup file & > rebuild back to 6.2 stable not > losing any settings or software ? RELENG_6 (aka 6.2 stable) is the *development* branch for any FreeBSD 6.x releases. As we are closing in on 6.3 this branch obviously serves as the base for 6.3 pre-releases. You have a choice to either use the 6.2 security fix branch (RELENG_6_2) or the "stable" branch (RELENG_6) - which really is not recommended for production systems. If you really want to go back (not sure why you would want to, though) you should be able to cvsup RELENG_6_2 and do a src upgrade (or downgrade in this case). This, however, might leave you with some leftover files that were added to RELENG_6. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: System hangs up every day
0x378-0x37f,0x778-0x77f irq 7 > drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in > COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model IntelliMouse, device ID 3 > ichwd0: on isa0 > pmtimer0 on isa0 > orm0: at iomem > 0xc-0xc7fff,0xc8000-0xc8fff,0xc9800-0xca7ff,0xca800-0xcb7ff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on > isa0 Timecounter "TSC" frequency 2800118202 Hz quality 800 > Timecounters tick every 1.000 msec > acd0: CDROM at ata0-master UDMA33 > twed0: on twe0 > twed0: 152626MB (312579760 sectors) > Trying to mount root from ufs:/dev/twed0s1a > ext0: link state changed to UP > int0: link state changed to UP > vlan0: link state changed to UP > > This server hangs up every day without any messages in the log files > and on the system console. A keyboard dosen't work too. I can make only > hard reset and after restart coredump files are not appearing. Here is > my kernel configuration file: > > include GENERIC > ident KERNEL01_NOSMP > deviceichwd # Intel ICH watchdog timer > #options SMP > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_PRIQ > #options ALTQ_NOPCC > options SC_DISABLE_REBOOT > options MP_WATCHDOG > options SW_WATCHDOG > > If I make and install a kernel with SMP options the system under > working load begins hang up every two hours. > > The two days "Memtest" gave no result. > I tried to install the newest Intel ethernet adapter driver, but > without any results. As an experiment I tried also to plug a system HDD > to another sever platform (SuperServer 6015V-TB), but system hanging > didn't stop. I think that it is not only hardware problem. > Linux (Gentoo) and Windows server 2003 on this hardware were working > fine. > > Please help me to find a solution and solve a problem. > > Your faithfully > Dmitry Komaleev > IT Manager > "EDIPRESSE-KONLIGA" http://www.konliga.ru > Russia, Moscow > tel.: +7 (495) 775-14-35, ext. 169 > fax: +7 (495) 775-14-34 > > P.S. I have written the Bug Report on my problem but have received only > one advice to turn off ACPI-option. If I disable ACPI, then the > RAID-controller and both of the ethernet controllers on my server > recieve the same IRQ. I believe this is not good. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: libpcap/tcpdump update
Okay. libpcap 0.9.8 and tcpdump 3.9.8 are now imported into HEAD and RELENG_7. Is anyone eager to pull it down to RELENG_6 as well, because I don't have the resources available at the moment. The update was crucial to me in HEAD and RELENG_7 to get a working pflog tcpdump, but RELENG_6 isn't broken for me ... Any takers? If not I might get round to it eventually, but I'd prefer somebody with genuine interest would step up. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: 'nv' in RELENG_7 does not detect 7900GS
On Wednesday 17 October 2007, Peter Schuller wrote: > Hello, > > so I just upgraded my desktop to RELENG_7 and suddenly the nv driver > is completely unable to detect the presence of my 7900GS. It acts > exactly as if the card was not in the machine. driver loads without > errors, but does not detect any devices. > > I tried upgrading to the latest point release of the driver (as > available in ports), which did not help. > > At least one guyon ##freebsd apparantly has the same problem. > > Does anyone know what's going on? The lack of any kind of error means > I pretty much don't know where to look. > > It could have been triggered by the Xorg upgrade rather than RELENG_7; > unfortunately I am not sure which X server I started when I started up > my desktop last. did you do a xorg-server rebuild after (from UPDATING): 20070930: The PCI code has been made aware of PCI domains. This means that the location strings as used by pciconf(8) etc are now in the following format: pci::[:]. It also means that consumers of potentially need to be recompiled; this includes the hal and xorg-server ports. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: BIND 9.3.1 - How to get rid of AAAA querys?
On Wednesday 12 September 2007, Andreas Pettersson wrote: > When looking in the querylog for BIND 9.3.1 running on FreeBSD 5.4, > almost every other log entry specifies an query. The only client > is localhost. I see no reason right now to have BIND wasting resources > on IPv6 requests, so I added > > named_flags="-4" > > to rc.conf and restarted named. Sockstat tells me named is listening > only on udp4 and tcp4, but I still get lots of entries in the > querylog: ... > What can I do to get rid of these? Change your resolver. The name*server* can nothing do about what the *client* asks of them. The fact that you connect to a nameserver via IPv4 says nothing about what kind of queries you want to send to it. At the moment you can't change the behavior of the resolver in libc and (as far as I know) that of the isc implementation either. There has been a discussion to provide a environment variable to emit only IPv4 queries, though. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: RELENG_6 patch [Re: pf 4.1 Update available for testing]
On Thursday 02 August 2007, Frank Behrens wrote: > Max Laier <[EMAIL PROTECTED]> wrote on 25 Jul 2007 1:35: > > now available at: http://people.freebsd.org/~mlaier/PF41/ with > > instructions how to build. > > Thanks! I tested it, because I have some trouble with pf > > > Please test if possible and provide me with feedback. > > The build has following problems: > - libexec/Makefile has still reference to ftp_proxy, removing that line > helped That's in the patch, did you have a libexec/Makefile.rej? > - usr.sbin/Makefile has still reference to ftp_proxy, removing that line > helped That's supposed to be there, but as I forgot the new files in usr.sbin/ftp-proxy it breaks. > - sbin/ifconfig misses ifgroup.c, fetching from HEAD helped Ditto - forgot the new file. > I made not many tests, but this version seems to work in general. > Unfortunately it does not fix the bug I described in another thread (pf > eates syn packet? on freebsd-pf@). More in that thread. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: RELENG_6 patch [Re: pf 4.1 Update available for testing]
On Thursday 02 August 2007, Frank Behrens wrote: > Max Laier <[EMAIL PROTECTED]> wrote on 2 Aug 2007 17:13: > > On Thursday 02 August 2007, Frank Behrens wrote: > > > The build has following problems: > > > - libexec/Makefile has still reference to ftp_proxy, removing that > > > line helped > > > > That's in the patch, did you have a libexec/Makefile.rej? > > Sorry, I should better read, what I have on screen: > I believe it complained about "tftp-proxy" and that's not here. Right, these too. I updated the build instructions to reflect your findings. I essence you need to change step two to: $ cvs up -rHEAD contrib/pf sys/contrib/pf libexec/tftp-proxy \ usr.sbin/ftp-proxy sbin/ifconfig/ifgroup.c to fetch all the required new files before building. I had those checked out already, so I forgot. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
RELENG_6 patch [Re: pf 4.1 Update available for testing]
now available at: http://people.freebsd.org/~mlaier/PF41/ with instructions how to build. Please test if possible and provide me with feedback. Again, this work can't be MFC'ed, but I'll try to keep up2date patches available for RELENG_6 and release branches. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: kernel trap 12 while reloading pf + altq
On Friday 18 May 2007 13:10, Volker wrote: > I'm wondering if any of the hackers is able to take a look at this panic? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/106400 I will try to finally get this into comittable shape one of these days. Can you confirm that it fixes things for you, too? - Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tproxy on freebsd
On Tuesday 17 April 2007 09:17, zen wrote: > i know it seem out of topic, > i recently build a proxy server to serve our small ISP, > but i'm facing a big problem. as far as i know FreeBSD didn't support > TPROXY like linux had. > but i need to build this proxy transparently so only my client ips that > visible when browsing. > i use ipnat and ipf with Squid latest stable release. > does anyone has experience building a true transparent proxy with > FreeBSD? please share the knowledge and the regarding this problems. http://www.benzedrine.cx/transquid.html is a tutorial for OpenBSD + pf + squid, but almost the same steps are required for FreeBSD. If you build squid from the portstree you should enable: [X] SQUID_PF Enable transparent proxying with PF or [ ] SQUID_IPFILTER Enable transp. proxying with IPFilter if you want to stay with ipf + ipnat. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpZyIWIlCfoJ.pgp Description: PGP signature
Re: uid/gid lookups slower on 6.2 than 4.x?
On Wednesday 11 April 2007 01:19, Scott Lambert wrote: > I've run into an interesting performance "issue" with ls on a > 6.2-STABLE box, web1. This box is going to replace my current 4.11 > box, ns, and is not currently active. It's running all the daemons it > will be in production, but traffic is not pointed at it yet. > > I don't think the gmirror vs. adaptec RAID disk subsystem would explain > the performance differences. I could be wrong. If I am, I'm going to > have to get a RAID card for the new box. > > [EMAIL PROTECTED] /home > 17:58:57 Tue Apr 10 # time ls -l | wc -l > 3135 > > real0m35.224s > user0m6.748s > sys 0m28.482s ... > [EMAIL PROTECTED] /home > 18:01:13 Tue Apr 10 # uname -a > FreeBSD web1.hosting.tcworks.net 6.2-STABLE-200702 FreeBSD > 6.2-STABLE-200702 #0: Sun Feb 4 13:35:09 UTC 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 > > [EMAIL PROTECTED] /home > 18:03:38 Tue Apr 10 # time ls -ln | wc -l > 3135 > > real0m0.054s > user0m0.030s > sys 0m0.031s Well, with nsswitch things are a bit more difficult. If you don't need it, you can just use nsswitch.conf to turn it off for passwd/group. Otherwise, you'll have to look at MFCing cached(8) from current. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpegFSPbTVOW.pgp Description: PGP signature
Re: Bridge+flowtools
On Thursday 01 March 2007 15:38, AstraSerg wrote: > Is it possible to collect traffic on bridge? > freebsd 6.2 I don't know about flowtools. But in case it does not work, you could use pf and pfflowd (http://www.mindrot.org/projects/pfflowd/ or net/pfflowd). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpaTSJSi55Sw.pgp Description: PGP signature
Re: Sequence of packet processing with ipfw, pf, ipfilter ?
On Tuesday 27 February 2007 09:31, Kurt Jaeger wrote:
> can someone point me to some documentation about the sequence
> of packet processing in fbsd6 if more than one of the filter
> systems is active ?
Unfortunately, there is no defined sequence. Currently it depends on the
sequence the individual components are enabled, or - more specificly -
the sequence of pfil_add_hook() calls. Note that ipfw does this on
module load, while pf waits until you issue "pfctl -e". I had
experimental patches to control the sequence back in 2005 (see attached).
Note that this will not work!!! It's more for reference. Back then
nobody was interesting in testing.
> There once was a nice ascii graphic which described the flow
> of packets through the rules -- I can't find it any more ?
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: contrib/pf/net/pf_ioctl.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_ioctl.c,v
retrieving revision 1.21
diff -u -r1.21 pf_ioctl.c
--- contrib/pf/net/pf_ioctl.c 8 Sep 2005 15:06:52 - 1.21
+++ contrib/pf/net/pf_ioctl.c 4 Dec 2005 13:47:24 -
@@ -3461,19 +3461,23 @@
pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET);
if (pfh_inet == NULL)
return (ESRCH); /* XXX */
- pfil_add_hook(pf_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet);
- pfil_add_hook(pf_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet);
+ pfil_add_named_hook(pf_check_in, NULL, "pf", PFIL_IN|PFIL_WAITOK,
+ pfh_inet);
+ pfil_add_named_hook(pf_check_out, NULL, "pf", PFIL_OUT|PFIL_WAITOK,
+ pfh_inet);
#ifdef INET6
pfh_inet6 = pfil_head_get(PFIL_TYPE_AF, AF_INET6);
if (pfh_inet6 == NULL) {
- pfil_remove_hook(pf_check_in, NULL, PFIL_IN | PFIL_WAITOK,
+ pfil_remove_hook(pf_check_in, NULL, PFIL_IN|PFIL_WAITOK,
pfh_inet);
- pfil_remove_hook(pf_check_out, NULL, PFIL_OUT | PFIL_WAITOK,
+ pfil_remove_hook(pf_check_out, NULL, PFIL_OUT|PFIL_WAITOK,
pfh_inet);
return (ESRCH); /* XXX */
}
- pfil_add_hook(pf_check6_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet6);
- pfil_add_hook(pf_check6_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet6);
+ pfil_add_named_hook(pf_check6_in, NULL, "pf", PFIL_IN|PFIL_WAITOK,
+ pfh_inet6);
+ pfil_add_named_hook(pf_check6_out, NULL, "pf", PFIL_OUT|PFIL_WAITOK,
+ pfh_inet6);
#endif
pf_pfil_hooked = 1;
Index: net/bridge.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/net/Attic/bridge.c,v
retrieving revision 1.93.2.1
diff -u -r1.93.2.1 bridge.c
--- net/bridge.c 25 Aug 2005 05:01:19 - 1.93.2.1
+++ net/bridge.c 3 Dec 2005 16:47:15 -
@@ -995,7 +995,7 @@
* and pkts already gone through a pipe.
*/
if (src != NULL && (
- (inet_pfil_hook.ph_busy_count >= 0 && bdg_ipf != 0) ||
+ (!PFIL_IS_EMPTY(inet_pfil_hook) && bdg_ipf != 0) ||
(IPFW_LOADED && bdg_ipfw != 0))) {
int i;
@@ -1044,7 +1044,7 @@
* Enables ipf(8) in bridging.
*/
if (!IPFW_LOADED) { /* XXX: Prevent ipfw from being run twice. */
- if (inet_pfil_hook.ph_busy_count >= 0 &&
+ if (!PFIL_IS_EMPTY(inet_pfil_hook) &&
m0->m_pkthdr.len >= sizeof(struct ip) &&
ntohs(save_eh.ether_type) == ETHERTYPE_IP) {
/*
Index: net/if_bridge.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/net/if_bridge.c,v
retrieving revision 1.35
diff -u -r1.35 if_bridge.c
--- net/if_bridge.c 29 Nov 2005 20:29:44 - 1.35
+++ net/if_bridge.c 4 Dec 2005 13:47:57 -
@@ -1315,9 +1315,9 @@
return;
}
- if (inet_pfil_hook.ph_busy_count >= 0
+ if (!PFIL_IS_EMPTY(inet_pfil_hook)
#ifdef INET6
- || inet6_pfil_hook.ph_busy_count >= 0
+ || !PFIL_IS_EMPTY(inet6_pfil_hook)
#endif
) {
if (bridge_pfil(&m, sc->sc_ifp, ifp, PFIL_OUT) != 0)
@@ -1577,9 +1577,9 @@
}
/* run the packet filter */
- if (inet_pfil_hook.ph_busy_count >= 0
+ if (!PFIL_IS_EMPTY(inet_pfil_hook)
#ifdef INET6
- || inet6_pfil_hook.ph_busy_count >= 0
+ || !PFIL_IS_EMPTY(inet6_pfil_hook)
#endif
) {
BRIDGE_UNLOCK(sc);
@@ -1630,9 +1630,9 @@
BRIDGE_UNLOCK(sc);
- if (inet_pfil_hook.ph_busy_count >= 0
+ if (!PFIL_IS_EMPTY(inet_pfil_hook)
#ifdef INET6
- || inet6_pfil_hook.ph_busy_count >= 0
+ || !PFIL_IS_EMPTY(inet6_pfil_hook)
#endif
) {
if (bridge_pfil(&m, sc->sc_ifp, dst_if, PFIL_OUT) != 0)
@@ -1819,9 +1819,9 @@
}
/* Filter on the bridge interface before broadcasting */
- if (runfilt && (inet_pfil_hook.ph_busy_count >= 0
+ if (runfilt && (!PFI
Re: impossible rc.d ordering problem with stf and pf ?
On Monday 29 January 2007 13:02, Pete French wrote: > > 1) You use the interface name as address w/o dynamic lookup. > > i.e. "... from stf0 ..." > > Yes, thats it - I hadn't come across this 'dynamic lookup' thing before > though, so I didn't realise what it was. I still cant find it in the PF > manual, aside from a reference that you need to do it for NAT. > > > To 1 and 2 there is a simple sollution: Don't do that then! 1 can > > easily=20 be defused by adding parentheses. i.e. "... from (stf0) > > ...". > > pass out on (stf0) inet6 from any to any keep state No, that's a misunderstanding. The "on ifnX" part stays untouched. > Gives me a syntax error when I try and load it with pfctl. If I change > it to: > > pass out on stf0 inet6 from any to any keep state > > Then it works loading it with pfctl, but now does not work at boot due > to the lack of stf0 interface. :-( That's strange. Works here without a problem: # ifconfig -l fxp0 bge0 bge1 lo0 pflog0 No stf0 interface. # echo "pass out on stf0 inet6 from any to any keep state" | pfctl -vf- pass out on stf0 inet6 all keep state Still, rule loaded without problems ... The "(ifnX)" syntax is only for places where you use the interface as an address. The "on ifnX" part stays unchanged in any case and it does not matter if the interface exists already or not. What version are you using again? My tests are with 6.2 -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpi4J7JHSy3D.pgp Description: PGP signature
Re: impossible rc.d ordering problem with stf and pf ?
On Sunday 28 January 2007 16:33, Richard Coleman wrote: > Bruce M. Simpson wrote: > > Pete French wrote: > >> Am trying to solve a little problem with 'pf'. I have a ruleset > >> which has some firewall rules for the IPv6 interface stf0. This > >> works fine, except when I rreboot the machine, as the pf script is > >> run before the network_ipv6 script - so stf0 does not exist. but I > >> cannot work out how to arrange for stf0 to be created before the pf > >> script is run - as network_ipv6 requires 'routing', but the pf > >> script says it must be run before 'routing', if I am reading the > >> 'REQUIRE' and 'BEFORE' lines correctly. > > > > Just chiming in to confirm that this problem definitely exists. > > I don't have a solution, however, my IPv6 tunnels at home have all > > expired, so I may well get spare cycles to look at this the same time > > that I get spare cycles to revive the tunnels. > > > > BMS > > Essentially the same problem exists with pf and ppp. The tun device > (on which most of my pf rules depend) does not yet exist when pf is > started. > > Apparently, someone has looked at this before, since there are commands > to resync pf and ipf inside the rc.d script for ppp (in ppp_postcmd). > But this still doesn't work, since ppp is still negotiating the > connection when this function is run, so pf fails a second time. My > solution was to jam a "sleep 15" inside ppp_postcmd() right before the > point the commands to reload pf and ipf are run. It's major ugly, but > it works. Hopefully someone will find a better solution to these > problems. In oder to solve these problems you have to understand why pf is failing. This can be for three reasons: 1) You use the interface name as address w/o dynamic lookup. i.e. "... from stf0 ..." 2) You use "set loginterface sft0" 3) You use the interface with ALTQ "altq on stf0 ..." (now this doesn't work and wouldn't be a good idea either, but for tun0 it makes slightly more sense). To 1 and 2 there is a simple sollution: Don't do that then! 1 can easily be defused by adding parentheses. i.e. "... from (stf0) ...". If more control is required you have to write explicit addresses in your configuration anyway. 2 is obsolete by "pfctl -vvsI -i stf0" which has all the counters for all the interfaces. ALTQ is the only remaining problem. I did do some initial patches to tear down altq on interface removal, which could be extended to work the other way 'round on interface arrival - if only I had more time :-\ -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgppmlwFyq2eY.pgp Description: PGP signature
Re: FreeBSD 6.2 ipw3945 on HP Pavilion dv6000
On Tuesday 23 January 2007 10:48, Dominik Zalewski wrote: > I'm running FreeBSD 6.2-RELEASE on HP Pavilion dv6000. I have a problem > with intel 3945 wireless card. Simply, kernel didnt detect any ipw* > device. When I'm loading a module if_ipw nothing happen. I tried also > to compile this driver static into the kernel. No results :( > > I installed /usr/ports/net/ipw-firmware > > > Any ideas? From the ipw(4) manual page: ipw -- Intel PRO/Wireless 2100 IEEE 802.11 driver i.e. 3945 hardware is *not* supported by this driver - sorry. There is an ongoing effort to port a driver called wpi(4) to support this hardware, details at: http://www.clearchain.com/wiki/Wpi But this is in an early stage of development. Testing is welcome, however. An additional possibility is the ndis framework - see ndisgen(8). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpjdZq0zkQiY.pgp Description: PGP signature
Re: IPv6 problems with 6.2-RELEASE ?
On Sunday 21 January 2007 02:17, Pete French wrote: > I have a network with a 6.2-RELEASE machine as a gateway to > the outside world, and on the inside three machines hung off it, > running OSX, XPx64 and 6.2-RELEASE as well. The gateway machine > NATs the internal network under Ipv4 and runs IPv6 via 6to4. It > has routing advertised on the internal network. > > This *should* work - the OSX machine gets an IPv6 address and runs > fine. The Windows XP x64 machine also gets an IPv6 address, and > though it has problems with some wwebsites, it also basically works. > The only machine which refuses to work is the FreeBSD machine, which > refuses to acquire an IPv6 address! > > I find it very opuzzling, as this has worked in the past, and also > the one machine I nwould have thought I would have had no problems > with would have been the FreeBSD box - especially as the gateway > machine is running an identical OS! > > I am not even sure where to start debugging this - how can I make the > interface try and get an IPv6 address whilst watching what it is doing > ? Has anyone else had problems like this ? There has been some confusion a while back, I don't remember the details. As for debugging: 1) What do you have in rc.conf? ipv6_enable should be set to "YES" and ipv6_network_interfaces should be "auto" or a list of the interfaces that should use IPv6. 2) rtsol(8) is used to initiate stateless autoconfiguration. You might want to try "rtsol -d interface". 3) Check the net.inet6.ip6.accept_rtadv sysctl. ipv6_enable should take care of this. 4) Check your firewall rules. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp8FekRCnnjC.pgp Description: PGP signature
Re: dhclient - new IP via DHCP on WAN - NAT dont work
[ Moving badly filed pf(sense) PR to the more appropriate list ] On Friday 19 January 2007 00:51, Andreas Krauß wrote: > Hi FreeBSD-Team, > > i use "PfSende" a FreeBSD based Firewall-System and have a large > Problem. Please see > > http://cvstrac.pfsense.com/tktview?tn=1207 freebsd-stable@ is clearly the wrong mailing list and you do not give enough details, either. In order to debug this problem we need to know the pf rules you (or pfsense in this case) are using. In order to operate with dynamic IPs you need to use the "(ifnX)" syntax - I'm not sure if pfsense does this by default. In addition there is a problem with ppp under some circumstances that requires "(tun0:0)" in order to fully get the IP update. > > Ticket 1207: new IP via DHCP on WAN - NAT dont work > > I have the same Problem, described at Ticket #1176 > <http://cvstrac.pfsense.com/tktview?tn=1176> - and I down know, why > this Ticket was Closed without any Result ??? > > My Pfsense works behind a Cable Modem. Some times i get a new > WAN-IP-Adress from my Provider via DHCP. > > Pfsense updates the Interfaces Page und the complete WebGUI show > the new IP. But NAT-Connections to my server behind the Firewall dont > work. > > And its not a DNS-Problem. My Server behind the Firewall checks the > IP, and after a IP-Change a little Scripts make a DNS update via > nsupdate. So the resolved IP is correct !! > > After a reboot -> pfsense and NAT-Connections wirks fine !! > > Questions - send me a mail. > > Best regards > > Andreas Krauss > > [Append remarks <http://cvstrac.pfsense.com/tktappend?tn=1207>] > > > Remarks: > > /2007-Jan-18 16:07:54 by anonymous:/ > We have attempted to fix this with no luck. This is a FreeBSD dhclient > issue. Please install FreeBSD and post a bug report to > freebsd-stable@freebsd.org -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpvjOv2bm44K.pgp Description: PGP signature
Re: 6.2-PRE: Fatal Trap?
On Saturday 30 December 2006 15:11, Karol Kwiatkowski wrote:
> Ivan Voras wrote:
> > Karol Kwiatkowski wrote:
> >> This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006
> >> This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET
> >> 2006
> >>
> >> I'm not sure it that's all that matters, I can supply more
> >> information if needed.
> >
> > Yes, you'll need to send at least a kernel stack backtrace. See here:
> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
> >kerneldebug-online-ddb.html
> >
> > Get it to start the debugger on panic and post the backtrace (bt).
>
> Thanks for the link, I hope I've done it right. Here it is:
>
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x74
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc055d18d
> stack pointer = 0x28:0xe989dbbc
> frame pointer = 0x28:0xe989dbc0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = 637 (ntpd)
> [thread pid 637 tid 100059 ]
> Stopped at turnstile_setowner+0xd: movl0x74(%ecx),%eax
> db> bt
> Tracing pid 637 tid 100059 td 0xc4de2780
> turnstile_setowner(c4de9240,0,c4dc9240,c07201e0,c5102090,...) at
> turnstile_setowner+0xd
> turnstile_wait(c5101090,0,c5101000,c07234e0,e989dc24,...) at
> turnstile_wait+0xca
> _mtx_lock_sleep(c5102090,c4de2780,0,0,0,...) at _mtx_lock_sleep+0xb4
> in_pcballoc(c4e892c8,c07234e0,1,c06c8de5,38,...) at
> in_pcballoc+0xbe tcp_attach(c4e892c8,c4e8933c,c06c8de5,0,c4e892c8,...)
> at tcp_attach+0x58 tcp_usr_attach(c4e892c8,0,c4de2780,0,0,...) at
> tcp_usr_attach+0x63 socreate(2,e989dcb8,1,0,c4ab1c90,...) at
> socreate+0x167
> socket(c4de2780,e989dd04,c,c4de2780,80d3000,...) at socket+0xb3
> syscall(3b,3b,3b,0,7,...) at syscall+0x380
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (97, FreeBSD ELF32, socket), eip = 0x282939d3, esp =
> 0xbfbfeb1c, ebp = 0xbfbfebf8 ---
> db >
Something like the attached should fix it. Seems tcp was forgotten in a
recent change to INP locking.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: tcp_subr.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.228.2.12
diff -u -r1.228.2.12 tcp_subr.c
--- tcp_subr.c 1 Oct 2006 05:33:50 - 1.228.2.12
+++ tcp_subr.c 30 Dec 2006 15:06:45 -
@@ -300,6 +300,15 @@
uma_zone_set_max(tcptw_zone, tcptw_auto_size());
}
+static int
+tcp_inpcb_init(void *mem, int size, int flags)
+{
+ struct inpcb *inp = mem;
+
+ INP_LOCK_INIT(inp, "inp", "tcpinp");
+ return (0);
+}
+
void
tcp_init()
{
@@ -328,7 +337,7 @@
tcbinfo.porthashbase = hashinit(hashsize, M_PCB,
&tcbinfo.porthashmask);
tcbinfo.ipi_zone = uma_zcreate("inpcb", sizeof(struct inpcb),
- NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
+ NULL, NULL, tcp_inpcb_init, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
uma_zone_set_max(tcbinfo.ipi_zone, maxsockets);
#ifdef INET6
#define TCP_MINPROTOHDR (sizeof(struct ip6_hdr) + sizeof(struct tcphdr))
pgpTdZroeH8uw.pgp
Description: PGP signature
Re: manually dumping core ...
On Thursday 28 December 2006 09:49, Marc G. Fournier wrote: > How? I can break to DDB no problem, but 'panic' just gives me a > backtrace and then the ddb> prompt again ... reset didn't dump core, > just rebooted ... :( You might have to type 'panic' twice these days. Alternatively, 'call doadump' usually did the trick for me. > Had an 'out of swap' error tonight, and would have liked to have been > able to run a ps after the reboot to see if I could identify an 'out of > control' process using up all the RAM (6G of RAM, 8G of swap) :( DDB has a ps of it's own - I'm not sure how helpful it is for your specific problem, though. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpV1FNrhdgnA.pgp Description: PGP signature
Re: pf killing NFS
On Wednesday 13 December 2006 12:05, Pete French wrote: > > As Luke already pointed out, "no-df" on the scrub rule should help. > > As=20 for the "bad cksum!" - this is a symptom of checksumming done > > in=20 hardware. ifconfig bge1 -rxcsum -txcsum should get rid of > > them. > > I am a bit concerned by this - we use a lot of bge interfaces, and I > have hardware checksumming enabled on all of them. Are they known to > produce bad checksums ? You are misunderstanding. The problem is simply that the bpf device sees bad checksums as it sees the packet before the hardware has calculated it. On the receiver the checksum will be correct. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp78oYfArtpS.pgp Description: PGP signature
Re: pf killing NFS
On Wednesday 13 December 2006 07:10, Charles Sprickman wrote: > Hi all, > > I'm running a 6.2-RC1 box (cvsup'd today) that has two broadcom nics. > One is an internal network (nfs) and the other is external. > > PF has this rule for all traffic on the private net: > > [EMAIL PROTECTED] /home/jails]# pfctl -sr|grep bge1 > pass in quick on bge1 inet from 192.168.1.0/24 to any > pass out quick on bge1 inet from any to 192.168.1.0/24 > > No state since these are "quick" and symmetrical. > > Doing something like "ls /usr/ports" will just hang until interrupted. > Using tcp for nfs makes it workable, but very slow. > > If I disable pf (pfctl -d), both types of mounts work, and speed is > excellent. I also just found that if I remove the "scrub in all" > statement and change it to "scrub in on bge0", things are fine. > > Any idea what's going on? The tcpdump output confuses me (see "bad > cksum!"), so I'm posting some snippets here. As Luke already pointed out, "no-df" on the scrub rule should help. As for the "bad cksum!" - this is a symptom of checksumming done in hardware. ifconfig bge1 -rxcsum -txcsum should get rid of them. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgppB7vvCmPvM.pgp Description: PGP signature
Re: BREAK TO DDB over SSH (Was: Re: panic: sleeping thread)
On Tuesday 12 December 2006 22:59, Marc G. Fournier wrote: > --On Tuesday, December 12, 2006 17:49:33 -0400 "Marc G. Fournier" > > <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > > > - --On Tuesday, December 12, 2006 17:40:48 -0400 "Marc G. Fournier" > > > > <[EMAIL PROTECTED]> wrote: > >> I'll try the -e none the next time it crashes, unless someone else > >> has another idea for doing it? Actually, I'll try the -e none > >> after its up again, instead of waiting ... > > > > Nope, now it just echos back the ~B as if I was typing regular > > characters ... i hate to do it, but am turning off ssh and going to > > telnet until I can get a core dump ... > > 'k, I must have screwed something up altogether then ... I can't break > into DDB using 'send break' through a telnet session ... > > I have: > > ___options KDB > ___options DDB > ___options KDB_UNATTENDED > ___options BREAK_TO_DEBUGGER > > In my kernel ... is there something else I'm missing? Its the same > settings I have on my other box that I *can* do this with ... > > The only difference is that this is an HP Proliant box, and I'm using > REMCONS through iLO to connect to the console ... sysctl debug.kdb.enter=1 > > Marc G. Fournier Hub.Org Networking Services > (http://www.hub.org) Email . [EMAIL PROTECTED] > MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.org > ICQ . 7615664 > > ___________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpEw4czs5umt.pgp Description: PGP signature
Re: panic: sleeping thread
On Monday 11 December 2006 23:40, John Baldwin wrote: > On Monday 11 December 2006 17:21, Marc G. Fournier wrote: > > --On Monday, December 11, 2006 16:27:23 -0500 John Baldwin > > <[EMAIL PROTECTED]> > > > > wrote: > > > On Saturday 09 December 2006 03:30, Marc G. Fournier wrote: > > >> Without a core dump, does this mean anything to anyone? > > >> > > >> Sleeping thread (tid 101251, pid 38200) owns a non-sleepable lock > > >> panic: sleeping thread > > >> cpuid = 1 > > >> > > >> The kernel was last upgraded: > > >> > > >> FreeBSD 6.2-PRERELEASE #1: Fri Nov 17 23:31:41 AST 2006 > > >> > > >> I'm going to build in DDB stuff right now, as I know I've seen > > >> that one > > > > > > before > > > > > >> ... but figured I'd ask and see if someone had an idea with so > > >> very > > little > > > >> information :( > > > > > > ddb will give a lot more useful information, can't really debug it > > > further w/o that, sorry. :( > > > > NP, I've added DDB to my kernel, but I'm having a hard time finding > > out how > > to > > > break into DDB over an SSH connection ... telnet is easy, but all my > > HP > > remote > > > consoles use SSH ... > > Maybe use ssh -e none? You don't need to break into ddb though, when > it panics it will print out more useful info on its own. sysctl debug.kdb.enter=1 should work, I think. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpBCqZIGmJnr.pgp Description: PGP signature
Re: Status of 3945ABG and others
On Sunday 19 November 2006 19:26, Torfinn Ingolfsen wrote: > On Sat, 18 Nov 2006 22:26:08 +0100 > > Christian Lopez de Castilla Wagner <[EMAIL PROTECTED]> wrote: > > Sound is ALC861, > > Probably HDA, you should test the snd_hdac driver. Look on -multimedia > mailinglist for clues. > > > wireless 3945ABG. > > As far as I know (and I'm interested, because I have a laptop with > this device myself), nothing has happened on this front. It seems that > Intel, for reasons of their own, isn't able to (or doesn't want to) > release necessary docs to make a good driver. > OpenBSD (4.0) have support for this via the wpi driver, but it doesn't > support WPA yet, only WEP. There is an experimental FreeBSD version of this driver available via: http://people.freebsd.org/~flz/local/wpi/ ... there are a couple of people interested in getting this working, see Threads on freebsd-net@ from October and November. > Your best bet would be to > a) exchange the network card, if possible. Some laptop network cards > are miniPCI and can be exchanged, but I do not know if this is the case > for the 3945ABG. > b) use an external usb network "dongle". Look at the ural driver, you > can find some of the supported devices quite cheap. I dont know how > good they are, I have just tested one, and have some issues with it > (stability) but haven't been able to rule out if it is something with > my setup yet. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpFvO5rBEi3O.pgp Description: PGP signature
Re: Panic while starting OpenNTPD
Hey Scott, On Saturday 11 November 2006 04:44, Scott Ullrich wrote: > Sources from today, right before the compile. > > I have paused the virtual machine if someone would like me to issue > further db> commands. > > Thanks, > > Scott > > > FreeBSD 6.2-PRERELEASE #0: Sat Nov 11 02:47:35 UTC 2006 > [EMAIL PROTECTED]:/usr/obj.pfSense/usr/src/sys/pfSense_Dev.6 > > lock order reversal: (sleepable after non-sleepable) > 1st 0xc0a57000 pf task mtx (pf task mtx) @ > /usr/src/sys/contrib/pf/net/pf.c:6406 > 2nd 0xc0a787e4 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 This one we can ignore - it's a double fault artefact. > KDB: stack backtrace: > kdb_backtrace(0,,c0b59f08,c0b5b740,c0a03b2c,...) at > kdb_backtrace+0x29 witness_checkorder(c0a787e4,9,c09a1f59,c02) at > witness_checkorder+0x578 _sx_xlock(c0a787e4,c09a1f59,c02) at _sx_xlock+0x50 > _vm_map_lock_read(c0a787a0,c09a1f59,c02,18e17c0,c25846b0,...) at > _vm_map_lock_read+0x37 > vm_map_lookup(cc1c4a4c,0,1,cc1c4a50,cc1c4a40,cc1c4a44,cc1c4a27,cc1c4a28) > atvm_m ap_lookup+0x28 > vm_fault(c0a787a0,0,1,0,c2585a80,...) at vm_fault+0x66 > trap(cc1c4b14,0,104) at trap+0x65e > trap(8,28,28,c27432c4,c26aee00,...) at trap+0x341 > alltraps(1,c274e400,cc1c4c5c,0,0) at alltraps+0x1a > pfioctl(0,cc1c4c5c,c274e400,1,0) at pfioctl+0x3dd7 > pfil_run_hooks(c0b9c720,cc1c4cb0,c274e400,1,0) at pfil_run_hooks+0xc9 > ip_input(c2743200) at ip_input+0x274 > netisr_unregister(c0b99f78) at netisr_unregister+0x11e > netisr_queue(0) at netisr_queue+0x146 > ithread_destroy(c2584648,c25af480) at ithread_destroy+0xf6 > ithread_destroy(c25648c0,cc1c4d38,c25648c0,c06b4b5c,0,...) at > ithread_destroy+0x21b > fork_exit(c06b4b5c,c25648c0,cc1c4d38) at fork_exit+0xd0 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xcc1c4d6c, ebp = 0 --- > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x104 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0489090 > stack pointer = 0x28:0xcc1c4b54 > frame pointer = 0x28:0xcc1c4c1c > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 13 (swi1: net) > [thread pid 13 tid 13 ] > Stopped at pf_test+0x968: cmpl$0,0x104(%eax) > db> bt > Tracing pid 13 tid 13 td 0xc2585a80 > pf_test(1,c274e400,cc1c4c5c,0,0) at pf_test+0x968 > pfioctl(0,cc1c4c5c,c274e400,1,0) at pfioctl+0x3dd7 > pfil_run_hooks(c0b9c720,cc1c4cb0,c274e400,1,0) at pfil_run_hooks+0xc9 This part of the trace is *very* strange. I don't see how pfil would call to pfioctl. Can you get line numbers for pfioctl+0x3dd7 and pf_test+0x968 ? "ps" would also be helpful. Thanks. > ip_input(c2743200) at ip_input+0x274 > netisr_unregister(c0b99f78) at netisr_unregister+0x11e > netisr_queue(0) at netisr_queue+0x146 > ithread_destroy(c2584648,c25af480) at ithread_destroy+0xf6 > ithread_destroy(c25648c0,cc1c4d38,c25648c0,c06b4b5c,0,...) at > ithread_destroy+0x21b > fork_exit(c06b4b5c,c25648c0,cc1c4d38) at fork_exit+0xd0 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xcc1c4d6c, ebp = 0 --- > db> -- Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CARP not balancing automatically
On Monday 23 October 2006 22:38, Vivek Khera wrote: > On Oct 23, 2006, at 4:21 PM, Vivek Khera wrote: > >> Sounds like you forgot the net.inet.carp.preempt sysctl. See the > >> begining > >> of the EXAMPLES section of carp(4). > > > > But I don't have multiple interfaces that all need to go up/down > > together. I need one carp interface to be master and one backup on > > box A, and the opposite master/backup on box B. Or am I totally > > misunderstanding with the preemtp sysctl is for? > > Forgot to mention that setting preempt sysctl does instantly make the > carp load balanced interfaces work as expected: balancing the load by > offering one master on each server. > > So I'll say that the example needs to be made more clear that preempt > needs to be on. Make a suggestion on how it should be worded and submit as a doc PR. > It seems to me that preempt off is a mostly useless > configuraiton for load balance, but probably not for just simple > failover. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpjBWRcTdveA.pgp Description: PGP signature
Re: CARP not balancing automatically
On Monday 23 October 2006 17:34, Vivek Khera wrote: > I'm attempting to use CARP with arpbalance to load balance some > services. My only problem is that the balancing doesn't happen > automatically. > > The configuration is just from the carp man page: > > ifconfig_em0="inet XXX.XXX.XXX.55 netmask 255.255.255.192 " > ifconfig_em1="inet 192.168.100.55 netmask 255.255.255.0 " > ifconfig_carp0="inet 192.168.100.100 netmask 255.255.255.0 vhid 5 > pass dns-prv" > ifconfig_carp1="inet 192.168.100.100 netmask 255.255.255.0 vhid 6 > advskew 100 pass dns-prv" > cloned_interfaces="carp0 carp1" > > and on the other box: > > ifconfig_em0="inet XXX.XXX.XXX.56 netmask 255.255.255.192 " > ifconfig_em1="inet 192.168.100.56 netmask 255.255.255.0 " > ifconfig_carp0="inet 192.168.100.100 netmask 255.255.255.0 vhid 5 > advskew 100 pass dns-prv" > ifconfig_carp1="inet 192.168.100.100 netmask 255.255.255.0 vhid 6 > pass dns-prv" > cloned_interfaces="carp0 carp1" > > > and of course net.inet.carp.arpbalance=1 in /etc/sysctl.conf. > > > When I reboot the systems, the first one to boot up becomes the > MASTER for both carp0 and carp1 interfaces and remains so even after > the other machine comes up. The second machine to boot comes up in > BACKUP mode for both interfaces. > > The only way to make the balance change is to bring down carp0 on the > box not designated as the master for it momentarily until such time > that the first one (the designated master for carp0) takes over, then > bring up carp0 again. > > Until I perform this manual step, all traffic goes to the single box. > After I perform this step, the traffic is balanced nicely as expected > amongst the local network hosts. Each box then has one MASTER and > one BACKUP carp interface for this IP. Sounds like you forgot the net.inet.carp.preempt sysctl. See the begining of the EXAMPLES section of carp(4). > What can I do to make the balance automatic as the docs imply? This > also happens on another pair of machines I have which are CARP + > arpbalance for another IP. > > The NICs in question are hooked up to a gigabit switch. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpdbncRk7yOI.pgp Description: PGP signature
Re: iwi, hidden SSID and wpa_supplicant problem
On Monday 09 October 2006 20:26, Max Laier wrote:
> On Monday 09 October 2006 19:53, Andrew N. Below wrote:
> > Hi.
> >
> > [..]
> >
> > > You can try using ap_scan=2 or whatever it is in the
> > > wpa_supplicant.conf file. This causes wpa_supplicant to use
> > > directed broadcasts msgs to each ap listed in the file.
> >
> > In my case setting ap_scan to 2 doesn't help.
> >
> > BTW, I got successfull connection some time ago when I
> > start to use /etc/rc.d/netif start iwi0 instead of manual
> > running of wpa_supplicant:
> >
> > defanbook# ifconfig iwi0
> > iwi0: flags=8843 mtu 1500
> > inet 213.189.198.75 netmask 0xfff0 broadcast
> > 213.189.198.79 ether 00:12:f0:3d:cd:58
> > media: IEEE 802.11 Wireless Ethernet autoselect mode 11b
> > (DS/11Mbps) status: associated
> > ssid ZENON-RADIO channel 11 bssid 00:07:0e:b8:d8:ee
> > authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP
> > 3:128-bit txpowmax 100 bmiss 10 protmode CTS roaming MANUAL bintval
> > 100
> >
> > I wrote bssid value to /etc/wpa_supplicant.conf and run
> > /etc/rc.d/netif.
> >
> > Then I drop connection (netif stop iwi0) and tried to start it again.
> > I got "associated" state in 5-6 minutes.
> >
> > In rc.conf I have:
> >
> > ifconfig_iwi0="ssid MY-SSID channel 11 WPA
> >
> > How can I get "-dd" output from wpa_supplicant started with netif?
> > It could be interesting.
>
> No idea, but a bit more stress testing did reveal a similar problem
> here. After I associated with the AP w/ hidden SSID I changed the
> channel via webinterface. The disconnect resulted in the exact problem
> you were having. Only stopping and restarting wpa_supplicant fixed the
> issue and I got associated on the new channel. Not sure what happens
> there yet, but something seems to get stuck in an undefined state.
Could you try the attached - untested - patch? It seems - from looking at
the linux driver - that we have to remind the firmware of the ESSID
before doing a directed scan. That explains why it would sometimes work
(whenever we are coming straight from iwi_config) and sometimes not.
Let me know if that improves things for you. Thanks.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: if_iwi.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/dev/iwi/if_iwi.c,v
retrieving revision 1.39
diff -u -r1.39 if_iwi.c
--- if_iwi.c 26 Jul 2006 03:09:32 - 1.39
+++ if_iwi.c 10 Oct 2006 02:55:52 -
@@ -2699,7 +2699,7 @@
struct ieee80211com *ic = &sc->sc_ic;
const struct ieee80211_channel *c;
struct iwi_scan_ext scan;
- int i, ix, start, scan_type;
+ int i, ix, start, scan_type, error;
memset(&scan, 0, sizeof scan);
@@ -2710,8 +2710,22 @@
scan.full_scan_index = htole32(ic->ic_scan.nt_scangen);
- scan_type = (ic->ic_des_esslen != 0) ? IWI_SCAN_TYPE_BDIRECTED :
- IWI_SCAN_TYPE_BROADCAST;
+ if (ic->ic_des_esslen != 0) {
+ scan_type = IWI_SCAN_TYPE_BDIRECTED;
+#ifdef IWI_DEBUG
+ if (iwi_debug > 0) {
+ printf("Setting desired ESSID to ");
+ ieee80211_print_essid(ic->ic_des_essid,
+ ic->ic_des_esslen);
+ printf("\n");
+ }
+#endif
+ error = iwi_cmd(sc, IWI_CMD_SET_ESSID, ic->ic_des_essid,
+ ic->ic_des_esslen);
+ if (error != 0)
+ return error;
+ } else
+ scan_type = IWI_SCAN_TYPE_BROADCAST;
ix = 0;
if (ic->ic_modecaps & IEEE80211_MODE_5GHZ) {
pgpqkiqboHHXg.pgp
Description: PGP signature
Re: iwi, hidden SSID and wpa_supplicant problem
On Monday 09 October 2006 19:53, Andrew N. Below wrote: > Hi. > > [..] > > > You can try using ap_scan=2 or whatever it is in the > > wpa_supplicant.conf file. This causes wpa_supplicant to use directed > > broadcasts msgs to each ap listed in the file. > > In my case setting ap_scan to 2 doesn't help. > > BTW, I got successfull connection some time ago when I > start to use /etc/rc.d/netif start iwi0 instead of manual > running of wpa_supplicant: > > defanbook# ifconfig iwi0 > iwi0: flags=8843 mtu 1500 > inet 213.189.198.75 netmask 0xfff0 broadcast 213.189.198.79 > ether 00:12:f0:3d:cd:58 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11b > (DS/11Mbps) status: associated > ssid ZENON-RADIO channel 11 bssid 00:07:0e:b8:d8:ee > authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP > 3:128-bit txpowmax 100 bmiss 10 protmode CTS roaming MANUAL bintval 100 > > I wrote bssid value to /etc/wpa_supplicant.conf and run > /etc/rc.d/netif. > > Then I drop connection (netif stop iwi0) and tried to start it again. > I got "associated" state in 5-6 minutes. > > In rc.conf I have: > > ifconfig_iwi0="ssid MY-SSID channel 11 WPA > > How can I get "-dd" output from wpa_supplicant started with netif? > It could be interesting. No idea, but a bit more stress testing did reveal a similar problem here. After I associated with the AP w/ hidden SSID I changed the channel via webinterface. The disconnect resulted in the exact problem you were having. Only stopping and restarting wpa_supplicant fixed the issue and I got associated on the new channel. Not sure what happens there yet, but something seems to get stuck in an undefined state. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpbNNM2bWESe.pgp Description: PGP signature
Re: iwi, hidden SSID and wpa_supplicant problem
On Monday 09 October 2006 16:35, Andrew N. Below wrote:
> I have an Asus V6V (V6800) laptop with Intel wireless adapter:
> iwi0:
> and FreeBSD installed:
>
> defanbook# uname -v
> FreeBSD 6.2-PRERELEASE #3: Mon Oct 9 17:40:59 UTC 2006
>
> I want to connect to access point (cisco 350) with
> hidden (not broadcasted) SSID using WPA/TKIP authentication
> but still got no success.
>
> Here is my wpa_supplicant.conf:
>
> ===
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=0
> eapol_version=1
> ap_scan=1
> fast_reauth=1
>
> network={
> ssid="MY-SSID"
> scan_ssid=1
> key_mgmt=WPA-PSK
> proto=WPA
> pairwise=TKIP
> group=TKIP
> psk="PASSPHRASE"
> phase2="auth=MSCHAPV2"
> }
> ===
>
> Here is wpa_supplicant output:
>
> defanbook# wpa_supplicant -ddKt -i iwi0 -c /etc/wpa_supplicant.conf
> Oct 09 18:24:41.372235: Starting AP scan (specific SSID)
> Oct 09 18:24:41.372242: Scan SSID - hexdump_ascii(len=11):
> [MY-SSID]
> Oct 09 18:24:43.021948: Received 0 bytes of scan results (4 BSSes)
> Oct 09 18:24:43.021982: Scan results: 4
> Oct 09 18:24:43.021992: Selecting BSS from priority group 0
> Oct 09 18:24:43.021998: 0: 00:07:0e:b8:d8:ee ssid='' wpa_ie_len=26
> rsn_ie_len=0 caps=0x31
> Oct 09 18:24:43.022008:skip - SSID mismatch
> Oct 09 18:24:43.022014: 1: 02:3f:2d:21:0e:c2 ssid='ANY' wpa_ie_len=0
> rsn_ie_len=0 caps=0x2
> Oct 09 18:24:43.022023:skip - no WPA/RSN IE
> Oct 09 18:24:43.022029: 2: 00:60:b3:d4:0d:76 ssid='ADSL_Wireless'
> wpa_ie_len=0 rsn_ie_len=0 caps=0x61
> Oct 09 18:24:43.022038:skip - no WPA/RSN IE
> Oct 09 18:24:43.022044: 3: 00:14:6c:55:24:4a ssid='' wpa_ie_len=0
> rsn_ie_len=0 caps=0x11
> Oct 09 18:24:43.022052:skip - no WPA/RSN IE
> Oct 09 18:24:43.022058: No suitable AP found.
Is any of the above the AP you are looking for? (i.e. right bssid).
> Oct 09 18:24:43.022066: Setting scan request: 5 sec 0 usec
> Oct 09 18:24:48.023226: Starting AP scan (broadcast SSID)
> Oct 09 18:24:49.501060: Received 0 bytes of scan results (2 BSSes)
> Oct 09 18:24:49.501070: Scan results: 2
Strange, why would a broadcast SSID scan turn up less BSSes? Can you make
sure you have the dev.iwi.0.antenna sysctl set to "0"?
> Oct 09 18:24:49.501077: Selecting BSS from priority group 0
> Oct 09 18:24:49.501083: 0: 00:07:0e:b8:d8:ee ssid='' wpa_ie_len=26
> rsn_ie_len=0 caps=0x31
> Oct 09 18:24:49.501092:skip - SSID mismatch
> Oct 09 18:24:49.501098: 1: 00:14:6c:55:24:4a ssid='' wpa_ie_len=0
> rsn_ie_len=0 caps=0x11
> Oct 09 18:24:49.501106:skip - no WPA/RSN IE
> Oct 09 18:24:49.501112: No suitable AP found.
> As we can see, it just repeats specific and broadcast SSID scan
> in cycle, but always says "No suitable AP found" and "SSID mismatch".
> While this process is running I can see more and more
> "Number of frames with a bad CRC receive" with the iwicontrol utility.
iwicontrol? That's no longer useful. If you really have
> defanbook# uname -v
> FreeBSD 6.2-PRERELEASE #3: Mon Oct 9 17:40:59 UTC 2006
you should have removed net/iwi-firmware and replaced it with
net/iwi-firmware-kmod as stated in UPDATING.
> On another FreeBSD box with 6.1-release and same version of
> wpa_supplicant, but with another USB wireless device (ural) all works
> fine.
I reproduced your setup with a Linksys-54abg and a 2915ABG running a
recent RELENG_6. Works like a charm - see attached.
> Wireless connection in winxp on this laptop works fine too.
>
> Any ideas?
If you do have firmware-iwi-kmod and things are still not working properly
you should try the following:
1) Disable WPA on AP and see if you can attach w/o wpa_supplicant
2) See if you can attach w/ wpa_supplicant (key_mgmt=NONE)
etc. ... to find out which part really is the culprit. Then you should
set "sysctl debug.iwi=5" and check console output for problems. Let me
know how it goes.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Initializing interface 'iwi0' conf 'wpa_supplicant.conf' driver 'default'
ctrl_interface 'N/A'
Configuration file 'wpa_supplicant.conf' -> '/root/wpa_supplicant.conf'
Reading configuration file '/root/wpa_supplicant.conf'
Line: 1 - start of a new network block
ssid - hexdump_ascii(len=9):
6c 69 6e 6b 73 79 73 2d 67
Re: Start system with 'downed' carp interfaces
On Thursday 05 October 2006 13:58, Ulrich Spoerlein wrote: > Hello, > > I'm looking for a generic way to create and configure carp interfaces > upon boot (so daemons can bind against the IP address), but keep the > carp interfaces 'down'. > > This is to allow the administrator to first check every service after > the failure, and if deemed ready, put the system back into production > by simply issuing: ifconfig carp0 up Can't you just use a high value for advskew so it won't become MASTER unless all other hosts are dead as well. > But there are several problems: > ifconfig_carp0="foo bar" > will always "up" the interface first via /etc/rc.d/netif > ifconfig carp0 foo bar down > will ignore the 'down' and up the interface. This is especially > announing. I wish ifconfig would honour the down statement, even > though the manpage says the interface will always be brought up when > assigned its first address. > > Using a start_if.carp0 with the following contents > ifconfig carp0 vhid 1 1.2.3.4/24 > ifconfig carp0 down > > and > ifconfig_carp0="down" in rc.conf will result in an 'up' interface. I > also disabled devd, as it seems to be running pccard_ether carp0 start > as a result of the interface creation. Although it is started > sometime after the interface has been created. > > How are other people handling the startup of carp interfaces? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp7J1juukBMM.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Saturday 09 September 2006 19:38, Karl Denninger wrote: > This is not cool folks. Want a refund? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpabFdsW8NAv.pgp Description: PGP signature
Re: panic: integer divide fault on 6.1
On Saturday 09 September 2006 13:56, Joao Barros wrote: > Hi, > > I just installed 6.1 on my new (with old parts) machine and when > booting for the first time after installation I got this panic: > > ad0: 19130MB at ata0-master UDMA100 > > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc0853017 > stack pointer = 0x28:0xc0c20b28 > frame pointer = 0x28:0xc0c20bb0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > trap number = 18 > panic: integer divide fault > cpuid = 0 > Uptime: 1s > Cannot dump. No dump device defined Can you try to get a dump, trace, or at least figure out which function the IP is refering to? > The system is a single Xeon with HTT enabled and the HDD used is > somewhat old. I can try installing on another one. The swapper > process somehow points me to the HDD. > Of course any clues are most welcome. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpCLKuw5e8ob.pgp Description: PGP signature
Re: device carp / freebsd-update
Hello Andy, On Monday 21 August 2006 15:53, Andy Hilker wrote: > we are currently migrating our hosts to 6.1-RELEASE with official > binaries (from CD). This is because we want to make use of > freebsd-update binary patches. > > Our problem is that GENERIC kernel does not contain "device carp". > Is there any posibility to use carp without "device carp" in GENERIC > e.g. with /boot/loader.conf like other pseudo devices? No, there is no such possibility. The reason for this, is that carp(4) has to register a protocol which cannot be (easily) done on-the-fly. Since you should have a fail-over running it shouldn't be a problem to build a carp enabled backup while the failover host takes care of the service, however. As a fallback there is a userland implementaion of carp (google "ucarp"), but I am not sure what the status of that is or if it works with the in-kernel version. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpg0JXkwNWe3.pgp Description: PGP signature
Re: identity crisis of 6-STABLE in ipfw ipv6 ?
[ Kevin reported a similar problem on monday in "Lost IPv6 with ipfw in latest stable" - added to CC-list. ] On Wednesday 16 August 2006 10:53, David Malone wrote: > On Wed, Aug 16, 2006 at 08:13:20AM +0200, Kees Plonsz wrote: > > I just updated to 6-STABLE but my ipfw rules stopped working. > > It seems that "me6" is vanished into thin air. > > > > # ipfw add 7000 allow ip from me6 to me6 > > ipfw: hostname ``me6'' unknown > > I think it was broken by some missing brackets in this commit: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ipfw2.c#rev1.88 > > Can you try the patch below? If it looks good, Max or I can commit > the fix. Whichever you prefer. Since I don't really use IPFW, I wouldn't mind to get rid of the task ;) Note that I also MFCed 1.88 a couple of days ago. By the way, it's great to see actual IPv6 users ;) David's patch: Index: ipfw2.c === RCS file: /FreeBSD/FreeBSD-CVS/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.88 diff -u -r1.88 ipfw2.c --- ipfw2.c 14 May 2006 03:53:04 - 1.88 +++ ipfw2.c 16 Aug 2006 08:50:04 - @@ -3707,10 +3707,10 @@ inet_pton(AF_INET6, host, &a)) ret = add_srcip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ - if ((ret == NULL) && proto == IPPROTO_IP || strcmp(av, "me") == 0 || - !inet_pton(AF_INET6, host, &a)) + if ((ret == NULL) && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || + !inet_pton(AF_INET6, host, &a))) ret = add_srcip(cmd, av); - if ((ret == NULL) && strcmp(av, "any") != 0) + if ((ret == NULL) && (strcmp(av, "any") != 0)) ret = cmd; > free(host); @@ -3733,10 +3733,10 @@ inet_pton(AF_INET6, host, &a)) ret = add_dstip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ - if ((ret == NULL) && proto == IPPROTO_IP || strcmp(av, "me") == 0 || - !inet_pton(AF_INET6, av, &a)) + if ((ret == NULL) && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || + !inet_pton(AF_INET6, av, &a))) ret = add_dstip(cmd, av); - if ((ret == NULL) && strcmp(av, "any") != 0) + if ((ret == NULL) && (strcmp(av, "any") != 0)) ret = cmd; free(host); -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpBYLkXoGk54.pgp Description: PGP signature
Re: I can't compile 6.1 kernel on 5.3 (amd64)
On Saturday 12 August 2006 15:39, Gábor Kövesdán wrote: > Hi, > > I'm about to upgrading a server from FreeBSD 5.3/amd64 to 6.1/amd64. I > just removed some unnecessary RAID drivers from the GENERIC kernel and > tried to compile it, but I got: > > ../../../fs/devfs/devfs_vnops.c:1172: warning: redundant redeclaration > of 'devfs_ops_f' > ../../../fs/devfs/devfs_vnops.c:70: warning: previous declaration of > 'devfs_ops_f' was here > ../../../fs/devfs/devfs_vnops.c:1183: warning: redundant redeclaration > of 'devfs_vnodeops' > ../../../fs/devfs/devfs_vnops.c:68: warning: previous declaration of > 'devfs_vnodeops' was here > ../../../fs/devfs/devfs_vnops.c:1205: warning: redundant redeclaration > of 'devfs_specops' > ../../../fs/devfs/devfs_vnops.c:69: warning: previous declaration of > 'devfs_specops' was here > *** Error code 1 > > Stop in /usr/src/sys/amd64/compile/TEST. > > Am I missing something or what might be wrong? You seem to be trying the "old" method using config and make depend && make. The supported way is using "make buildworld" and "make buildkernel". Order is crucial as "make buildworld" also builds a new compiler and includes that are used later. There is a separate target to only build the tools that are required to build a kernel. Check the Makefile. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpvEeFwLzhWE.pgp Description: PGP signature
Re: iwi(4) in RELENG_6
[Please don't top-post] On Thursday 27 July 2006 21:01, Don Wilde wrote: > Yes, I have. I just did another CVSup, and when I recompiled -kmod it did > indeed put a bunch of .ko files in /build/modules, but a) I still get a > whole bunch of Can't load firmware complaints, and b) it doesn't work. It > goes through the DISCOVER process, but doesn't get any offers it > recognizes. I've tried this both with an open DHCP and also with my > parameters wired in. > > Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from > another gent who has a 2200G pci card and is having the same problem with > STABLE. > > This all was working two weeks ago. Just to get the facts straight and assembled in one place: You are running a somewhat recent RELENG_6, have net/iwi-firmware-kmod installed and "device iwi" and "options firmware" built into your kernel? When do you get the "Can't load firmware" messages? What does kldstat [-v] say before and after that point? Can you try "kldload iwi_bss" before and see if that gets you up and running? > On 7/27/06, Mark Willson <[EMAIL PROTECTED]> wrote: > > Have you tried using the firmware from iwi-firmware-kmod, rather than > > iwi-firmware. I am using the former on a Thinkpad T42 and it is working > > ok. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpi7UJEn3h0i.pgp Description: PGP signature
Re: Kernel panic with PF
./../../contrib/pf/net/pf.c:3013 > #11 0x801b5694 in pf_test (dir=1, ifp=0xffbee800, > m0=0xb1adeaa0, eh=0xb1ade97e, inp=0x0) > at ../../../contrib/pf/net/pf.c:6449 > #12 0x801bafb2 in pf_check_in (arg=0x2, m=0xb1adeaa0, > ifp=0xff004cc7cac0, dir=-1314002464, inp=0xb1ade9e0) > at ../../../contrib/pf/net/pf_ioctl.c:3358 > #13 0x80461c2e in pfil_run_hooks (ph=0x807e0920, > mp=0xb1adeb28, ifp=0xffbee800, dir=1, inp=0x0) > at ../../../net/pfil.c:139 > #14 0x8048d225 in ip_input (m=0xff0042ede900) > at ../../../netinet/ip_input.c:465 > #15 0x8046180c in netisr_processqueue (ni=0x807df690) > at ../../../net/netisr.c:236 > #16 0x80461abd in swi_net (dummy=0x2) > at ../../../net/netisr.c:349 > #17 0x803bbd99 in ithread_loop (arg=0xff0506a0) > at ../../../kern/kern_intr.c:684 > #18 0x803ba527 in fork_exit ( > callout=0x803bbc50 , arg=0xff0506a0, > frame=0xb1adec50) at ../../../kern/kern_fork.c:805 > #19 0x8053020e in fork_trampoline () > at ../../../amd64/amd64/exception.S:394 > #20 0x in ?? () > > The firewall also reports lots of PF problems durings operation: > > Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: KERN-100-E > [natutil.c:770] ioctl(): Invalid argument (EINVAL=22) > Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: NATT-111-E > add_rule(): PF ioctl DIOCADDRULE failed > Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: NATT-701-E > addnatmap out(): Adding TCP NAT MAP from [127.0.0.1]:60860 to > [212.80.76.13]:80 -> [193.179.161.10]:60860 failed > Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: NETL-210-E > netbind(server,10): NAT binding failed > > Kernel often reports "pool_ticket: 1429 != 1430" (with increasing > numbers over time). > > Thank you very much for any advice. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp9eMgfP1Sfc.pgp Description: PGP signature
Re: iwi(4) in RELENG_6
On Wednesday 12 July 2006 20:07, Bartosz Fabianowski wrote: > Since the iwi driver has been MFC'd, I cannot build a kernel any more. I > csupped my src/sys to RELENG_6 a couple of hours ago. Everything > compiles fine, but when linking the kernel, make barfs: > > linking kernel > > if_iwi.o(.text+0x29c4): In function `iwi_getfw': > : undefined reference to `firmware_get' > > if_iwi.o(.text+0x29d3): In function `iwi_getfw': > : undefined reference to `firmware_get' > > if_iwi.o(.text+0x2a1d): In function `iwi_put_fw': > : undefined reference to `firmware_put' > > if_iwi.o(.text+0x49a5): In function `iwi_init_locked': > : undefined reference to `firmware_get' > > I have "device iwi" in my kernel configuration. Should I remove it and > use a module instead? Or is this supposed to work? This is from the firmware(9) support code. Add "options firmware" and you should be fine. You will still need to load the firmware blobs as modules, but that's another story. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpM3oBmnzNnn.pgp Description: PGP signature
Re: iwi(4) in RELENG_6
On Tuesday 11 July 2006 15:04, Michael Butler wrote: > Max Laier wrote: > | net/iwi-firmware-kmod, but it needs to be updated to the new > | __FreeBSD_version > | Right now it will tell you that you need iwi-firmware instead, which is > | wrong. > > Once the updates have been merged, is this the right place to start with > adding 3945ABG? I have u-code but haven't had time enough to look at the > driver to date .. I'd really like to get my (dual-core) T-2400 Toshiba > "on the air" ;-) The 3945ABG is a completely different kind of animal and needs a separate driver. There is one in OpenBSD called wpi(4), but I'm unaware of the state of that undertaking. From what I hear, ndis doesn't work for those cards either, but it might make sense to confirm that and possibly look into fixing ndis-support as a first line of support. I don't have 3945ABG hardware. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpJgIckOKMW3.pgp Description: PGP signature
Re: iwi(4) in RELENG_6
On Tuesday 11 July 2006 14:35, Mark Andrews wrote: > > On 7/10/06, Max Laier <[EMAIL PROTECTED]> wrote: > > > On Monday 10 July 2006 16:40, Vlad GALU wrote: > > > > Is the iwi driver going to be synced with rev. 1.3x of HEAD? I'm > > > > using 1.36 along with a RELENG_6 tree, since it works better (read: > > > > it works). From the HEAD commit messages I understand that some MFCs > > > > would've been in order by now. Are there any show-stoppers that push > > > > that schedule ahead ? > > > > > > no. The only thing that bugs me a bit, is that the change will break > > > POLA > > > > for > > > > > people using the old version. I have yet to hear from somebody using > > > that successfully, though. > > > > > > I will get on MFCing it later today. > > > >Thanks, Max! > > Which of the iwi ports should be used now on RELENG6 now that > this has been MFC'd. > > net/iwi-firmware-kmod or net/iwi-firmware? net/iwi-firmware-kmod, but it needs to be updated to the new __FreeBSD_version Right now it will tell you that you need iwi-firmware instead, which is wrong. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpfs4vIylCCL.pgp Description: PGP signature
Re: iwi(4) in RELENG_6
On Monday 10 July 2006 16:40, Vlad GALU wrote: > Is the iwi driver going to be synced with rev. 1.3x of HEAD? I'm > using 1.36 along with a RELENG_6 tree, since it works better (read: it > works). From the HEAD commit messages I understand that some MFCs > would've been in order by now. Are there any show-stoppers that push > that schedule ahead ? no. The only thing that bugs me a bit, is that the change will break POLA for people using the old version. I have yet to hear from somebody using that successfully, though. I will get on MFCing it later today. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp3dTcOo1C4r.pgp Description: PGP signature
Re: 0.0% user, 0.0% nice, 0.0% system, 53.8% interrupt, 46.2% idle - Unusual interrupt use?
On Thursday 06 July 2006 02:17, Vye Wilson wrote: > # vmstat -i > interrupt total rate > irq1: atkbd0 5 0 > irq6: fdc0 3 0 > irq10: uhci1 915633230 262810 > irq15: ata1 1306 0 > irq17: fwohci0 1 0 > irq18: fxp0 2876 0 > irq21: twa0 153 0 > cpu0: timer 6964974 1999 > Total 922602548 264811 Are you using usb on that box? If not, get rid of device uhci in your kernel config to see if that fixes it. If you are using usb - I have no idea. A BIOS upgrade might help. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgprlUTcGe4ux.pgp Description: PGP signature
Re: 0.0% user, 0.0% nice, 0.0% system, 53.8% interrupt, 46.2% idle - Unusual interrupt use?
On Thursday 06 July 2006 02:02, Vye Wilson wrote: > I'm really not sure how to go about troubleshooting this issue. Can someone > point me in the right direction? "vmstat -i" should give a good idea what is causing the interrupt load. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpF9ZSmeYtaR.pgp Description: PGP signature
Re: vmstat 'b' (disk busy?) field keeps climbing ...
On Monday 26 June 2006 20:25, Marc G. Fournier wrote: > I think I might have found *at least* one of the problems, and that being > the excessively high blocked states while ps isn't finding anything ... > > MySQL > > We just recently started allowing clients to run a MySQL server *within* > their vServer ... in a drastic move, I just shut them all down on pluto, > and blocked drop'd from ~86 down to 5 in a matter of moments ... > restarting them all has it climbing once more, being up around 22 already > ... > > I'm going to go with that theory for now, and keep an eye on things ... > > Just curious as to why, even with -H, its not showing any blocked states > within ps though ... ? The "blocked" column shows also processes that have objects "paging". Most likely you are *short* on memory. In order to relieve the pressure program .text pages are free'ed and need to be refetched from disc whenever the respective code is being executed. If you allow every vServer to run its own mySQL with all the libaries etc it's clear what is killing you! Add more memory or make sure that .text pages can be reused by several processes. As far as I understand vServer will all see a different source and thus not share buffers or the like. > Thx > > On Mon, 26 Jun 2006, Kostik Belousov wrote: > > On Mon, Jun 26, 2006 at 02:20:12AM -0300, Marc G. Fournier wrote: > >> On Mon, 26 Jun 2006, Kostik Belousov wrote: > >>> Yes, this looks like a deadlock. As I understand, that's on 6.1-STABLE > >>> ? > >> > >> Yes, kernel sources, it seems, from May 25th, according to my /usr/src > >> tree ... > >> > >>> BTW, do you use snapshots ? > >> > >> Not that I've explicitly enabled ... > >> > >>> I think that without ddb access, diagnose and debug the problem would > >>> be quite hard. > >> > >> Would it be a simple matter of: > >> > >> CTL-ALT-ESC > >> panic > >> > >> to get it to dump core? Or would more be involved? Would a core dump > >> even work? > > > > Core dumps are somewhat unconvenient in this situation. Better, > > sending report to me, follow my advise in > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern > >eldebug-deadlocks.html > > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] > Yahoo . yscrappy Skype: hub.orgICQ . 7615664 > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgptYDCrhfoid.pgp Description: PGP signature
Re: Crash with FreeBSD 6.1 STABLE of today
On Monday 26 June 2006 15:32, Gavin Atkinson wrote: > On Mon, 2006-06-26 at 15:15 +0200, Martin Blapp wrote: > > A remote stress testing of a tty session over serial cable > > with a patched kernel worked fine. > > > > How to proceed now ? The patch also applies to CURRENT > > as there where no big changes since the repo has been > > branched. > > > > Should I commit it to CURRENT ? > > > > > http://mx.imp.ch/patch-tty.t_pgrp.diff > > I'm still not convinced that the proctree lock is the correct lock to > use - maybe a new lock for the tty subsystem? Also, some of the locking > in the patch appears to be unnecessary. I can't help feeling that this > patch is the heavy-handed solution to the problem, and given how > heavyweight locks can be, maybe it's not a good solution. > > Is the problem actually understood? Do we know what's racing with what? I found kern_proc.c:461 to be a likely candidate for a race. > Given there only ever seems to be a single backtrace involved, as far as > I can tell, it's ttymodem racing with tty_close - can those two > functions alone be locked? When locking something you have to lock every access to do it right. It makes no sense to lock just paths that exhibit the race. Indeed a new lock for tty would make sense, but be warned that you will have to use this lock in a dozen places that are now rightfully protected with the proctree lock. So instead of one locking operation you now have to do two. The only benefit you get is reduced lock contention. I am against pushing in the heavy handed patch as well, but I rather have the heavy handed version in than a nasty race. > Alas, I can't recreate the problem on-demand so can't really find a > better solution. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpYREcWHnING.pgp Description: PGP signature
Re: Crash with FreeBSD 6.1 STABLE of today
On Friday 23 June 2006 18:03, Gavin Atkinson wrote: > On Fri, 2006-06-23 at 13:46 +0200, Martin Blapp wrote: > > Hi, > > > > Maybe this is the solution ? IMHO there is a race window > > open between the first tp->t_session test and the locking > > of the proc tree. > > I'm not sure if t_session is supposed to be protected by the proctree > lock though. With an initial glance of the code, it would seem odd to > be protected by the proctree lock, although I can't see any other locks > Someone with more knowledge of this code will probably know the answer > to this. > > There does seem to be a worrying comment above tty_close (which is the > only place that t_session seems to be set to NULL): > > * XXX our caller should have done `spltty(); l_close(); tty_close();' > * and l_close() should have flushed, but we repeat the spltty() and > * the flush in case there are buggy callers. > > As I understand it, spltty() is now a no-op. Does this mean that this > code is now essentially running without any locks that were used to > serialise changes to struct tty in days gone by? Or is the whole tty > subsystem still running under Giant? Just as a random note. I remember looking at a somewhat similar problem during the 6.0 release cycle and comming up with a patch[1]. Somehow the problem went away and I lost track of the patch. Can't remember who was testing it. I think I talked with Christan about it, though [CC-list++] Note, I am not sure if the patch still applies or is correct at all, but from looking at it (and the name of the file) I seem to remember that there was a problem with t_pgrp and t_session being accessed unlocked in some places. Maybe it helps, maybe it doesn't. [1] http://people.freebsd.org/~mlaier/tty.t_pgrp.diff -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp4lER89nlY7.pgp Description: PGP signature
Re: 6.1-stable hangs and LORs
On Sunday 11 June 2006 23:46, Brad Waite wrote: > Kris Kennaway wrote: > > We need to know the LOR before anyone can tell what is going wrong ;-) > > Ask and you will receive: > > lock order reversal: > 1st 0xc077a440 pf task mtx (pf task mtx) @ > /usr/src/sys/contrib/pf/net/pf.c:6331 > 2nd 0xc07d3fac tcp (tcp) @ /usr/src/sys/contrib/pf/net/pf.c:2719 > KDB: stack backtrace: > witness_checkorder(c07d3fac,9,c06fd2f7,a9f) at witness_checkorder+0x55c > _mtx_lock_flags(c07d3fac,0,c06fd2f7,a9f,c07d3fac) at _mtx_lock_flags+0x40 > pf_socket_lookup(e35ccacc,e35ccad0,1,e35ccb8c,0) at pf_socket_lookup+0x103 > pf_test_tcp(e35ccb3c,e35ccb34,1,c4d3e400,c5027c00,14,c5032810,e35ccb8c,e35c >cb40,e35ccb44,0,0) at pf_test_tcp+0x10d6 > pf_test(1,c4ba3c00,e35ccc2c,0,0) at pf_test+0xb77 > pf_check_in(0,e35ccc2c,c4ba3c00,1,0) at pf_check_in+0x37 > pfil_run_hooks(c07d3b60,e35c,c4ba3c00,1,0) at pfil_run_hooks+0xee > ip_input(c5027c00,18,c07d3138,e35cccec,c05dcd63) at ip_input+0x1b2 > netisr_processqueue(c4b24500,c4b28000,0,e35ccd0c,c055877b) at > netisr_processqueue+0xf > swi_net(0,c4b28038,c4ad6d80,c0558590,c4ad520c) at swi_net+0x8b > ithread_loop(c4ab68d0,e35ccd38,c4ab68d0,c0558590,0) at ithread_loop+0x1eb > fork_exit(c0558590,c4ab68d0,e35ccd38) at fork_exit+0x7d > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe35ccd6c, ebp = 0 --- From pf.conf(5): BUGS Due to a lock order reversal (LOR) with the socket layer, the use of the group and user filter parameter in conjuction with a Giant-free netstack can result in a deadlock. If you have to use group or user you must set debug.mpsafenet to ``0'' from the loader(8), for the moment. This work- around will still produce the LOR, but Giant will protect from the dead- lock. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpGYFFvbEVpy.pgp Description: PGP signature
Re: Yet another LOR
On Wednesday 07 June 2006 19:46, Robert Watson wrote: > On Wed, 7 Jun 2006, Bjoern A. Zeeb wrote: > > On Wed, 7 Jun 2006, Václav Haisman wrote: > >> I've yet another LOR to report. > >> > >> lock order reversal: (sleepable after non-sleepable) > >> 1st 0xc45651f8 inp (tcpinp) @ sys/netinet/tcp_usrreq.c:1029 > >> 2nd 0xc3a2f9a4 user map (user map) @ sys/vm/vm_map.c:2997 > > > > added with LOR ID 190: http://sources.zabbadoz.net/freebsd/lor.html#190 > > The calltrap() handler suggests this is either a page fault handled holding > a lock, or a panic, rather than a lock order reversal. Vaclav -- was this > a crash, or just some console output that happened while the system was up > and it kept on running? Judgeing from the original message, this is a copyin with a non-sleepable mutex held: Jun 6 21:14:08 logout kernel: calltrap() at calltrap+0x5 Jun 6 21:14:08 logout kernel: --- trap 0xc, eip = 0xc07cfe72, esp = 0xd8b51ae8, ebp = 0xd8b51b08 --- Jun 6 21:14:08 logout kernel: generic_copyin(d8b51c84,d8b51b28,4,4,c4565168) at generic_copyin+0x32 Jun 6 21:14:08 logout kernel: tcp_ctloutput(c3b1ab20,d8b51c84,0,c36b9700,d8b51c68) at tcp_ctloutput+0x184 -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpaonQXsqwuI.pgp Description: PGP signature
Re: burncd audio produces white noise
On Tue, May 16, 2006 4:55 am, Stephen Hurd wrote: > Michael A. Koerber wrote: >> All, >> >> Once upon a time, I think with 5.x or perhaps earlier, the command >> (ATAPI drive) >> >> burncd -ef /dev/acd0 audio *.cdr fixate >> >> would produce an audio CD for me. However, under 6.0 and recently 6.1 >> this same command produces an CD filled with white noise only. The >> entire >> procedure I've used is: >> >> 1. Start w/ some MP3 files. >> >> 2. Use sox (or lame) to convert to CDR format >> >> 3. Verify the CDR format with 'xine filename.cdr' (sounds good) >> >> 4. Make CD with above command. >> >> 5. Play CD on two different players (one on PC, one on entertainment >> system) >> (sounds like white noise) >> >> 6. Extract a CD track with dd if=/dev/acd0t01 of=tmp.cdr bs=2532 >> >> 7. Test ripped track with 'xine tmp.cdr' sound just like the original >> MP3! >> >> To ensure that there weren't permissions problems along the way, I've >> executed >> these commands as root, though I once did this as a normal user. >> >> Any ideas on what I should look at to fix this problem? >> > Yeah, I've noticed that too now that you mention it. When it happened > to me, I switched to using atapicam and cdrecord with the -swab parameter. > Also, you may want to look at audio/mp3burn (still need to pass -swab > though) > > I would recommend that you file a PR on this one. Obviously you are giving the wrong options to sox/lame. Most likely you are confusing byte-order. Might also be a problem with the configuration options for the respective ports. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iwi-firmware-kmod and iwi-firmware
Hello Manfred, On Mon, May 15, 2006 9:53 pm, Manfred Lotz wrote: > Is there a description about how to use iwi-firmware-kmod and > iwi-firmware? no, but see below ... > Can both be installed and used simultaneously? Yes-ish. > I know how to use iwi-firmware but how does iwi.firmware-kmod relate? > > > Currently, iwi-firmware is quite unreliable in the sense that after > resuming my laptop and restarting wpa_supplicant I often get panics. Newer versions of the iwi(4) driver require you to use iwi-firmware-kmod (iwi-firmware won't work anymore). Those drivers utilize the firmware(9) framework to load the firmware. Together with other changes (at this time only available in CURRENT) this makes iwi(4) much more stable. You should be able to use sys/dev/iwi/* from CURRENT in RELENG_6 to get the changes. MFC is planed, but more testing is required and encouraged. Let us know if that works better for you. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_xe and altq on FreeBSD-6
Hi Mateusz, On Sat, May 13, 2006 2:04 pm, Mateusz JÄdrasik wrote: > I've recently became an owner of Xircom 16-bit PCMCIA 10/100 Ethernet > Card, > which gets picked up by FreeBSD-6.1 as xe0 by the if_xe(4) driver. Here is > a > line from dmesg: > > > xe0: at port 0xd040-0xd04f iomem > 0xff904000-0xff904fff irq 11 function 0 config 1 on pccard1 > xe0: [GIANT-LOCKED] > xe0: version 0x45/0x04, 100Mbps capable > > So my kind request here i guess would be if someone could perhaphs find > some > time in their schedule to mayhap enable altq on this interface, or at > least > reply to me why it is not possible.. Look at the drivers at: http://people.freebsd.org/~mlaier/ALTQ_driver/ It's usually a rather simple task, but having it locked first certainly helps to make it not explode. I won't get to it right now, but write me an email or send in a PR after you've looked at it and got somewhere (or didn't) and I see it into the tree. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf not loading the rules at boot
On Sunday 07 May 2006 01:59, Iantcho Vassilev wrote:
> I noticed such a problem:
>
> I have a 6.1 RC2 and i have in rc.conf
>
> pf_enable="YES"
> pflogd_enable="YES"
>
> but when the system boots i test with:
>
> pfctl -vs rules
>
> and there are not rules loaded.if i load them by hand there is no problem..
> then i made:
>
> rc_debug="YES"
>
> and the first thing that i saw was: when pf_enable is after pflogd_enable ;
> it is not printed(checked)..
>
> then i changed the place of pf and pflogd in the rc.conf and i saw some
> output in the /var/log/messages..
> but still the ruleset wasn`t loaded..
>
> i put pf_load="YES" >> /boot/loader.conf
> and still the ruleset is NOT loaded on boot...
What is your pf.conf like? Do you have ALTQ in use? Do you maybe try to use
ALTQ on an interface that is created later on (tun0 or the like)? What does
"/etc/rc.d/{pf, pflog} rcvar" give you? Does "/etc/rc.d/pf start" work after
it failed on boot? Try setting pf_flags="-v" to get additional error
messages.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpFLwW2AMRHE.pgp
Description: PGP signature
FreeBSD Status Report First Quarter 2006
ent. This should be available by mid-April. We have received a positive response from the FreeBSD community regarding the release of the binaries. We received a few requests to support the FreeBSD 6.1/amd64 platform. We have decided to move forward and support this too. We currently are working with a contractor to provide Java support on 5.5/i386, 6.1/i386, and 6.1/amd64. Once 5.5 and 6.1 are released, we'll update the FreeBSD Foundation website with the Java status. Regular updates to the website will continue. _ libpkg - Package management library URL: http://libpkg.berlios.de/ URL: http://developer.berlios.de/projects/libpkg/ Contact: Andrew Turner <[EMAIL PROTECTED]> Libpkg is a package management library using libarchive to extract the package files. It is able to download, install and get a list of installed packages. Work has also been started on implementing the package tools from the base system. Most of pkg_info has been implemented and pkg_add has been started. Open tasks: 1. Support for more command line options in pkg_info and pkg_add 2. Creating a package 3. Test pkg_add works as expected for all implemented command line options _ Low-overhead performance monitoring for FreeBSD URL: http://people.freebsd.org/~jkoshy/projects/perf-measurement Contact: Joseph Koshy <[EMAIL PROTECTED]> This projects implements a kernel module (hwpmc(4)), an application programming interface (pmc(3)) and a few simple applications (pmcstat(8) and pmccontrol(8)) for measuring system performance using event monitoring hardware in modern CPUs. New features since the last status report: * Support for profiling dynamically loaded kernel and user objects has been added. * pmcstat(8) now supports command-line syntax for logging to a network socket. _ Mouse Driver Framework URL: http://www.semicomplete.com/projects/newpsm Contact: Jordan Sissel <[EMAIL PROTECTED]> The current mouse system is a mess with moused, psm, ums, and mse supporting, individually, multiple kinds of mice. This project aims to move all driver support into moused modules in userland. In addition, many features lacking in the existing mouse infrastructure are being added. It is my hope that this new system will make both using mice and writing drivers easier down the road. Open tasks: 1. Testing. Contact if interested. _ OpenBSD dhclient Contact: Brooks Davis <[EMAIL PROTECTED]> Contact: Sam Leffler <[EMAIL PROTECTED]> All dhclient changes in HEAD have been merged to 6-STABLE for 6.1-RELEASE. New patches currently in testing include startup script support for fully asynchronous starting of dhclient which eliminates the wait for link during startup and support for sending the system hostname to the server when non is specified. _ OpenBSD packet filter - pf Contact: Max Laier <[EMAIL PROTECTED]> Work towards importing the upcoming OpenBSD 3.9 version of pf is starting slowly. There are a couple of infrastructural changes (e.g. interface groups) that need to be imported beforehand. This work is in the final stage of progress. A couple of bugfixes have happend since the last report and will be available in FreeBSD 6.1/5.5. pf users are strongly encouraged to upgrade to RELENG_6 as the version present in RELENG_5 is collecting dust. _ pfSense URL: http://www.pfsense.com Contact: Scott Ullrich <[EMAIL PROTECTED]> pfSense continues to grow and fix bugs. Since the last report we have grown to 14 developers working part and full time on bringing pfSense to 1.0. Beta 3 is scheduled for release on 4/15/2006. Open tasks: 1. Fix remaining bugs listed in CVSTrac 2. Fine tune existing code _ Ports Collection URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://people.freebsd.org/~fenner/portsurvey/ URL: http://edwin.adsl.barnet.com.au/~edwin/ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon <[EMAIL PROTECTED]> During this time, the number of ports PRs rose dramatically from its impressive low number seen late last quarter. This was due to the holidays, the freeze for the 5.5/6.1 release cy
Re: [panic] ipw and kismet
On Saturday 08 April 2006 13:49, Ulrich Spoerlein wrote: > Max Laier wrote: > > Could you try the attached patch, please? This is something I did for > > iwi and just moved the general idea over without testing or close > > evaluation. So be aware and let me know either way. Thanks. > > Great, Thanks! > > I ran with this patch and loaded different fimwares, upped and downed > the interface like mad and not a single panic! > > I only ran with INVARIANTS, I'm currently recompiling with > INVARIANTS+WITNESS and will give it another try, but it seems to work > just fine. > > Please commit this, and I hope if will make it into 6.1-RELEASE. Thanks > again! This is partly fixed in CURRENT already, but needs more work to be MFCed. Is there any chance that you can test CURRENT plus this patch as well? I will then commit and MFC, but doubt that it will make 6.1 - too late I'm afraid. Note, you need the new fireware modules (net/ipw-firmware-kmod) in CURRENT. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgphzWCyVJufn.pgp Description: PGP signature
Re: Call for FreeBSD Status Reports
On Thursday 30 March 2006 02:36, Brad Davis wrote: > Hi All, > > It is time for the quarterly Status Reports. As always, reports are > encouraged for anything that relates to FreeBSD development, > documentation, independent projects, or anything else that might be > interesting to the community as a whole. Reports should be one to two > paragraphs in length. > > The template for submissions is here: > http://www.freebsd.org/news/status/report-sample.xml > > Submissions should be submitted to monthly at FreeBSD.org by April 7th. Unfortunately we have a not too convincing turnout so far. There are - as always - very interesting reports we'd like to publish as soon as possible, but as we have less than half of the reports we had last round we are extending the deadline to Wednesday, April 12th. Please remember that even small progress to you might be worth reporting. Even if you didn't make progress at all it might help to expose your project in the status reports to get feedback to make progress as a consequence of that. Looking forward to your submissions. Thanks a lot. http://www.freebsd.org/cgi/monthly.cgi http://www.freebsd.org/news/status/report-sample.xml -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpp0xhEZswgI.pgp Description: PGP signature
Re: [panic] ipw and kismet
On Thursday 06 April 2006 14:14, Ulrich Spoerlein wrote:
> Hello,
>
> I almost always get a panic when running kismet on my ipw-Interface
> under 6.1-PRERELEASE. This has been the case ever since ipw hit the
> tree. Sometimes kismet works, sometimes it doesn't. A sure way to
> trigger the panic is to switch between bss/ibss/monitor mode prior to
> running kismet. Perhaps there is a bug in the re-initialization when
> loading a different firmware?
>
> Is this panic known? Does the new firmware-framework address this?
The trace below seems unrelated to firmware loading, but there have been some
problems with firmware loading before and we hope to improve things with the
new firmware framework.
Could you try the attached patch, please? This is something I did for iwi and
just moved the general idea over without testing or close evaluation. So be
aware and let me know either way. Thanks.
> ipw0: mem 0xfaffc000-0xfaffcfff irq 9
> at device 3.0 on pci2 ...
> panic: mutex ipw0 recursed at /usr/src/sys/kern/kern_synch.c:177
> KDB: enter: panic
> [thread pid 1527 tid 100119 ]
> Stopped at kdb_enter+0x2b: nop
> db> tr
> Tracing pid 1527 tid 100119 td 0xc5cca300
> kdb_enter(c06d3e90) at kdb_enter+0x2b
> panic(c06d332c,c4c5d600,c06d4661,b1,0) at panic+0xbb
> _mtx_assert(c4d3cc74,9,c06d4661,b1,0) at _mtx_assert+0x83
> msleep(c4d3c000,c4d3cc74,0,c0912121,3e8) at msleep+0x16a
> ipw_init(c4d3c000,c4d3c000,2080,c4d3c904,c4c2dc00) at ipw_init+0xb63
> ipw_media_change(c4c2dc00,c4f6fd00,80,c4d36600,0) at ipw_media_change+0x8b
> ifmedia_ioctl(c4c2dc00,c4d9a360,c4d3c904,c0206937,0) at ifmedia_ioctl+0x93
> ieee80211_ioctl(c4d3c004,c0206937,c4d9a360,c4d3cc74,c4d3c000) at
> ieee80211_ioctl+0xc1
> ipw_ioctl(c4c2dc00,c0206937,c4d9a360,ef577c38,c051bbee) at ipw_ioctl+0x5c
> ifhwioctl(c0206937,c4c2dc00,c4d9a360,c5cca300,c074a4c0) at ifhwioctl+0x9ac
> ifioctl(c5a4f858,c0206937,c4d9a360,c5cca300,0) at ifioctl+0xc3
> soo_ioctl(c59c0750,c0206937,c4d9a360,c5a41a80,c5cca300) at soo_ioctl+0x2db
> ioctl(c5cca300,ef577d04,3,2,282) at ioctl+0x370
> syscall(3b,3b,3b,bfbf90a0,80dc400) at syscall+0x22f
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x482d468f, esp = 0xbfbf906c,
> ebp = 0xbfbf90e8 ---
>
>
> Ulrich Spoerlein
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: if_ipw.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/dev/ipw/if_ipw.c,v
retrieving revision 1.7.2.4
diff -u -r1.7.2.4 if_ipw.c
--- if_ipw.c 29 Jan 2006 15:13:01 - 1.7.2.4
+++ if_ipw.c 7 Apr 2006 22:27:33 -
@@ -220,7 +220,7 @@
sc->sc_dev = dev;
mtx_init(&sc->sc_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
- MTX_DEF | MTX_RECURSE);
+ MTX_DEF);
if (pci_get_powerstate(dev) != PCI_POWERSTATE_D0) {
device_printf(dev, "chip is in D%d power mode "
@@ -380,6 +380,7 @@
struct ipw_softc *sc = device_get_softc(dev);
struct ieee80211com *ic = &sc->sc_ic;
struct ifnet *ifp = ic->ic_ifp;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -722,6 +723,7 @@
{
struct ipw_softc *sc = device_get_softc(dev);
struct ifnet *ifp = sc->sc_ic.ic_ifp;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -743,6 +745,7 @@
{
struct ipw_softc *sc = ifp->if_softc;
int error;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -1222,6 +1225,7 @@
{
struct ipw_softc *sc = arg;
uint32_t r;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -1474,6 +1478,7 @@
struct mbuf *m0;
struct ether_header *eh;
struct ieee80211_node *ni;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -1557,6 +1562,7 @@
struct ieee80211com *ic = &sc->sc_ic;
struct ifreq *ifr;
int error = 0;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -1769,6 +1775,7 @@
struct ipw_firmware_hdr hdr;
u_char *p = data;
int error;
+ IPW_LOCK_DECL;
ipw_free_firmware(sc);
Index: if_ipwvar.h
===
RCS file: /usr/store/mlaier/fcvs/src/sys/dev/ipw/if_ipwvar.h,v
retrieving revision 1.3
diff -u -r1.3 if_ipwvar.h
--- if_ipwvar.h 10 Jun 2005 16:49:11 - 1.3
+++ if_ipwvar.h 7 Apr 2006 22:23:46 -
@@ -170,5 +170,12 @@
#define SIOCSLOADFW _IOW('i', 137, struct ifreq)
#define SIOCSKILLFW _IOW('i', 138, struct ifreq)
-#define IPW_LOCK(sc) mtx_lock(&(sc)->sc_mtx)
-#define IPW_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx)
+#define IPW_LOCK_DECL int __waslocked = 0
+#define IPW_LOCK(sc) do {\
+ if (!(__waslocked = mtx_owned(&(sc)->sc_mtx))) \
+ mtx_lock(&(sc)->sc_mtx); \
+} while (0)
+#define IPW_UNLOCK(sc) do { \
+ if (!__waslocked) \
+ mtx_unlock(&(sc)->sc_mtx); \
+} while (0)
pgpRDnZ1xjljg.pgp
Description: PGP signature
