Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock
The following reply was made to PR kern/140036; it has been noted by GNATS.
From: Bernhard Schmidt
To: Benjamin Kaduk
Cc: s...@freebsd.org, bug-follo...@freebsd.org
Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock
and iwn0 softc lock
Date: Sat, 5 Dec 2009 09:56:23 +0100
On Saturday 05 December 2009 03:49:42 Benjamin Kaduk wrote:
> Okay, I've been getting these lockups fairly frequently -- in fact,
> there was this one room where I was getting them every five minutes
> or so. I hypothesized that dissociation/association events might
> be triggers, so I set dev.iwn.0.debug=-1 and started wandering around
> this building (which is chock full of APs).
> I get:
> panic: lock (sleep mutex) iwn0_com_lock not locked @
> /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3254
Are you sure your code is in sync? there is nothing accessing the lock in
if_iwn.c:3254
3251 if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) {
3252 ieee80211_free_node(ni);
3253 m_freem(m);
3254 return ENETDOWN;
3255 }
> Unfortunately, it appears to have messed up my machine pretty badly,
> as only numlock blinks the LED, and I don't have a db> prompt ...
>
> Trying again without the debugging spew gets a useful debugger, though.
> "show alllocks" produces empty output (?!).
> backtrace is:
> kdb_enter
> panic
> witness_unlock
> _mtx_unlock_flags
> iwn_raw_xmit
> ieee80211_send_probereq
> beacom_miss
> taskqueue_run
> taskqueue_thread_loop
> fork_exit
>
> Looking at the coredump, I'm inclined to suspect this block of
> ieee80211_proto.c (in beacon_miss() ):
> 1.46 sam 1379:/* XXX locking */
> 1380:TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) {
> 1.38 sam 1381:/*
> 1.46 sam 1382: * We only pass events through for sta
> vap's in RUN state; 1383: * may be too restrictive but for
> now this saves all the 1384: * handlers duplicating these
> checks. 1.38 sam 1385: */
> 1.46 sam 1386:if (vap->iv_opmode == IEEE80211_M_STA
> && 1.64 sam 1387:vap->iv_state >=
> IEEE80211_S_RUN && 1.46 sam 1388:vap->iv_bmiss
> != NULL)
> 1389:vap->iv_bmiss(vap);
>
>
> Sam, do you have any thoughts as to why throwing a
> IEEE80211_LOCK(ic)/IEEE80211_UNLOCK(ic) block around the TAILQ_FOREACH
> might not be a good idea?
> I'm currently running with that, which gives me a new LOR
> (iwn_com_lock @ /usr/src/sys/net80211/ieee80211_scan.c:683 and
> iwn0 @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3289)
> but it hasn't locked up or panic()ed on me, yet.
>
>
> I am happy to pull more information from the coredump if needed.
>
> Thanks,
>
> Ben Kaduk
>
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8: ipfw fwd and pf route-to broken?
Hi! sbin/ipfw in RELENG_8 do not set sin_len in fwd rule, so sockaddr_in from ipfw is sucked into rtalloc1_fib() at last with zero length and is routed to lo0 instead of correct interface. Returning sin_len into sbin/ipfw resolves issue. sin_len setting was removed in revision 1.146 by luigi. What is correct solution? Return sin_len setting into sbin/ipfw or something else? On Fri, Dec 4, 2009 at 11:47 AM, Lytochkin Boris wrote: > Hi! > > It seems that FreeBSD 8 has ipfw fwd and pf's route-to malfunctioning: > 1) ipfw fwd > a) net.inet.ip.forwarding = 0 > Packets altered by fwd rule are silently dropped somewhere > between ip_output() checking forward tag and bpf (tcpdump does not > show these packets) > b) net.inet.ip.forwarding = 1 > Packets altered by fwd rule are forwarded according to normal > routing table (in my case they were forwarded to default gateway), not > fwd statement > > 2) pf route-to > Both values of net.inet.ip.forwarding replicates 1b case. > > > Sample configs > > 1) ipfw > add 60 fwd 10.60.128.254 ip from 10.60.128.0/24 to any out > add 65534 allow ip from any to any > > 2) pf > scrub in all fragment reassemble > pass in all flags S/SA keep state > pass out quick route-to (em0 10.60.128.254) inet from 10.60.128.0/24 > to any flags S/SA keep state > > ~>uname -a > FreeBSD thost 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #5: Wed Dec 2 > 13:43:48 MSK 2009 r...@thost:/usr/obj/usr/src/sys/CSUP amd64 > > -- Regards, Boris Lytochkin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock
The following reply was made to PR kern/140036; it has been noted by GNATS.
From: Benjamin Kaduk
To: Bernhard Schmidt
Cc: s...@freebsd.org, bug-follo...@freebsd.org
Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock
and iwn0 softc lock
Date: Sat, 5 Dec 2009 15:25:25 -0500 (EST)
On Sat, 5 Dec 2009, Bernhard Schmidt wrote:
> On Saturday 05 December 2009 03:49:42 Benjamin Kaduk wrote:
>> Okay, I've been getting these lockups fairly frequently -- in fact,
>> there was this one room where I was getting them every five minutes
>> or so. I hypothesized that dissociation/association events might
>> be triggers, so I set dev.iwn.0.debug=-1 and started wandering around
>> this building (which is chock full of APs).
>> I get:
>> panic: lock (sleep mutex) iwn0_com_lock not locked @
>> /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3254
>
> Are you sure your code is in sync? there is nothing accessing the lock in
> if_iwn.c:3254
>
> 3251 if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) {
> 3252 ieee80211_free_node(ni);
> 3253 m_freem(m);
> 3254 return ENETDOWN;
> 3255 }
>
Apparently not -- `svn info` claims that I only have r13, and
the web the web interface shows up to r20.
I guess I've been using cvs for too long, and expected
`${VCS_COMMAND} diff` to default to showing differences from the
head of the repository/current branch.
I'll update and revert my change to net80211/ieee80211_proto.c and
see what changes.
Sorry for the noise,
Ben
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock
The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt Cc: bug-follo...@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Sat, 5 Dec 2009 16:30:35 -0500 (EST) On Sat, 5 Dec 2009, Benjamin Kaduk wrote: > > I'll update and revert my change to net80211/ieee80211_proto.c and > see what changes. Okay, now I only get a LOR on beacon miss (no panic): lock order reversal: 1st 0xff8000309010 iwn0 (network driver) @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:2655 2nd 0xff800033d018 iwn0_com_lock (iwn0_com_lock) @ /usr/src/sys/net80211/ieee80211_proto.c:1365 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 ieee80211_beacon_miss() at ieee80211_beacon_miss+0x2e iwn_notif_intr() at iwn_notif_intr+0x33a iwn_intr() at iwn_intr+0x334 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff803a97ed30, rbp = 0 --- I kind of expect that it's a bad idea to drop the softc lock around the call to ieee80211_beacom_miss() from iwn_notif_intr(), but don't see an easy alternative. More concerning, though, is the firmware error that was logged some twenty seconds after the beacon miss, leaving networking in an unuseable state: firmware error log: error type = "SYSASSERT" (0x0005) program counter = 0x1E28 source line = 0x0696 error data = 0x00010696 branch link = 0x08FA08FA interrupt link = 0x08B2 time= 2190683577 driver status: tx ring 0: qid=0 cur=99 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=7 queued=0 tx ring 4: qid=4 cur=186 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=26 Hm, maybe I should move this to not-this-ticket ... -Ben ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8: ipfw fwd and pf route-to broken?
Lytochkin Boris wrote: Hi! sbin/ipfw in RELENG_8 do not set sin_len in fwd rule, so sockaddr_in from ipfw is sucked into rtalloc1_fib() at last with zero length and is routed to lo0 instead of correct interface. Returning sin_len into sbin/ipfw resolves issue. sin_len setting was removed in revision 1.146 by luigi. What is correct solution? Return sin_len setting into sbin/ipfw or something else? poke luigi On Fri, Dec 4, 2009 at 11:47 AM, Lytochkin Boris wrote: Hi! It seems that FreeBSD 8 has ipfw fwd and pf's route-to malfunctioning: 1) ipfw fwd a) net.inet.ip.forwarding = 0 Packets altered by fwd rule are silently dropped somewhere between ip_output() checking forward tag and bpf (tcpdump does not show these packets) b) net.inet.ip.forwarding = 1 Packets altered by fwd rule are forwarded according to normal routing table (in my case they were forwarded to default gateway), not fwd statement 2) pf route-to Both values of net.inet.ip.forwarding replicates 1b case. Sample configs 1) ipfw add 60 fwd 10.60.128.254 ip from 10.60.128.0/24 to any out add 65534 allow ip from any to any 2) pf scrub in all fragment reassemble pass in all flags S/SA keep state pass out quick route-to (em0 10.60.128.254) inet from 10.60.128.0/24 to any flags S/SA keep state ~>uname -a FreeBSD thost 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #5: Wed Dec 2 13:43:48 MSK 2009 r...@thost:/usr/obj/usr/src/sys/CSUP amd64 -- Regards, Boris Lytochkin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
