Re: 9.2-STABLE r255918 with GENERIC and iwn - core dump

[J.R. Oldroyd]

On Wed, 23 Oct 2013 13:12:05 -0700 Adrian Chadd  wrote:
>
> On 23 October 2013 13:10, claudiu vasadi  wrote:
> 
> > Hi,
> >
> > Still getting the "Cannot reset interface wlan0 - exit status 1" in
> > wifimgr but no crash yet. Will keep trying :D
> >
> 
> I have no idea about that. It's likely there's some net80211/iwn bug(s) but
> I don't use wifimgr so I don't know what it's doing.
> 
> For that I'd bug the wifimgr people in PCBSD. they can always file bug
> reports with me :)
> 
> Thanks,
> 
> 
> 
> -adrian

wifimgr isn't a PCBSD tool.

wifimgr just a GUI front-end invoking standard FreeBSD command line
tools to do what needs to be done.  In this case, the command being
executed is:

/etc/rc.d/netif restart wlan0

Run this command from a shell to make sure there are no errors.
Also check that wifimgr's su module is installed properly.  It is
%%PREFIX%%/libexec/wifimgrsu and should be mode 4511.

-jr


signature.asc
Description: PGP signature

Re: forwarding didn't work if wlan0 is member of a bridge

[J.R. Oldroyd]

On Mon, 11 Jan 2016 23:52:47 +0100 Olivier Cochard-Labbé  
wrote:
>
> After weeks of troubleshooting, at last I found how to reproduce this
> problem ;-)
> 
> Here is the setup:
> 
> LAN0 <--> [(re0) fbsd router (bridge0 addm re1 addm wlan0)] <--> Wireless
> LAN
> 
> If interface re1 (bridge0 member with wlan0) is in "active" status
> (=ethernet cable plugged to something): I don't have any problem, all is
> working great for my wireless clients connected to wlan0: They can ping
> devices in LAN0.
> But once I've unplug the ethernet cable connected to re1 (bridge member
> with wlan0) and re1 state switch to "no carrier", Wireless LAN clients are
> not able to reach LAN0.
> 
> Here is my rc.conf with simple subnetting for Adrian ;-)
> 
> wlans_ath0="wlan0"
> ifconfig_wlan0="hostap channel 6"
> create_args_wlan0="wlanmode hostap"
> cloned_interfaces="bridge0"
> ifconfig_re0="inet 1.0.0.1/24"
> ifconfig_re1="up"
> ifconfig_bridge0="inet 1.1.1.1/24 addm re1 addm wlan0 up"
> gateway_enable="YES"
> 
> And an example with re1 in "no carrier" status:
> 
> root@fbsd-router:~ # ifconfig bridge0
> bridge0: flags=8843 metric 0 mtu
> 1500
> ether 02:6b:c0:de:b8:00
> inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255
> nd6 options=9
> groups: bridge
> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> member: wlan0 flags=143
> ifmaxaddr 0 port 5 priority 128 path cost 3
> member: re1 flags=143
> ifmaxaddr 0 port 2 priority 128 path cost 55
> 
> 
> root@fbsd-router:~ # ifconfig re1
> re1: flags=8943 metric 0
> mtu 1500
> 
> options=82099
> ether 00:0d:b9:3c:ae:25
> nd6 options=29
> media: Ethernet autoselect (none)
> status: no carrier
> 
> => from a wireless LAN client (1.1.1.2) I'm trying to ping a host on LAN0
> (1.0.0.2):
> 
> root@fbsd-router:~ # tcpdump -pni re0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 23:38:04.466866 ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 28
> 23:38:04.467052 ARP, Reply 1.0.0.2 is-at 00:08:a2:09:c4:a2, length 46
> 23:38:04.467090 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 1,
> length 64
> 23:38:04.467226 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 1, length
> 64
> 23:38:04.467300 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length
> 36
> 23:38:05.483053 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 2,
> length 64
> 23:38:05.483259 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 2, length
> 64
> 23:38:05.483318 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length
> 36
> 23:38:06.387304 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 3,
> length 64
> 23:38:06.387466 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 3, length
> 64
> 23:38:06.387514 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length
> 36
> ^C
> 11 packets captured
> 11 packets received by filter
> 0 packets dropped by kernel
> root@fbsd-router:~ # arp -na
> ? (1.1.1.1) at 02:6b:c0:de:b8:00 on bridge0 permanent [bridge]
> ? (1.1.1.2) at fc:64:ba:97:c0:ff on bridge0 expires in 1168 seconds [bridge]
> ? (1.0.0.1) at 00:0d:b9:3c:ae:24 on re0 permanent [ethernet]
> 
> => The FreeBSD router answers "unreacheable" to the host: My wireless LAN
> client never get the ICMP reply.
> 
> => Now I plug eth1 to a dummy machine (just for changing its status):
> 
> root@fbsd-router:~ # ifconfig re1
> re1: flags=8943 metric 0
> mtu 1500
> 
> options=82099
> ether 00:0d:b9:3c:ae:25
> nd6 options=29
> media: Ethernet autoselect (1000baseT )
> status: active
> 
> => and I restart the same ping from the wireless LAN client:
> 
> root@fbsd-router:~ # tcpdump -pni re0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 23:44:08.597429 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 1,
> length 64
> 23:44:08.597660 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 1, length
> 64
> 23:44:09.604447 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 2,
> length 64
> 23:44:09.604683 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 2, length
> 64
> 23:44:10.609711 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 3,
> length 64
> 23:44:10.609874 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 3, length
> 64
> 
> => It's works :-)
> 
> How the status of a member of the bridge can impact the routing behavior of
> other interfaces ?
> How to fix this problem ?
> 
> Thanks
> ___
> freebsd-wireless@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@

Toshiba L675D wifi rfkill acpi support

[J.R. Oldroyd]

I have just upgraded the wifi mini-PCIe adapters in some older model
Toshiba laptops, specifically L305D and L675D models, to AR9280
adapters.  This in order to be able to use the 5 GHz band.

On the L305D, everything is working well.

But on the L675D, the AR9280 radio remains off.  Switching the wifi
adapter to an Intel 6200 actually reports:
iwn0: radio is disabled by hardware switch
They both probe and initialize normally in the dmesg and you can
talk to them normally using ifconfig.  It is just the radio that
remains off.

Thing is, the L675D does not have a hardware rfkill switch.  It does
have Fn+F8, however.

I should note that two other wifi adapters, the original RTL8191SE
and also an AR9285 do both work fine in the L675D.  They do not seem
to see a phantom rfkill switch!  But, neither of these adapters
support the 5 GHz band.

Despite the RTL8191SE and AR9285 working, I figured that it would be
useful to have Fn+F8 working so that I could check and toggle the
radio state of the AT9280.  I therefore set about updating
acpi_toshiba.c to support the TOS1900 HID [1].

I am still no closer, though.  I was not able to enable the hotkey
Fn+Fx support, so I've implemented a hw.acpi.toshiba.wireless_wifi
sysctl which shows that the wifi is enabled and allows it to be
toggled.  Testing with one of the working adapters (AR9285) does show
the wifi LED going on and off and the interface does pass or not-pass
traffic accordingly.  But, with the AR9280, the LED and the radio
remain steadfastly off.

I have studied the acpidump[2] and found that the relevant ACPI method
(TOI0==0xFF00 TOI1==0x56) supports four devices:
0x0200  wifi
0x0800  unknown
0x2000  wwan (3G device, according to google)
0x  unknown

I have played with all of them, but still cannot get the AR9280 radio
or the wifi LED on.

I have not found any documentation, other than the Linux driver
toshiba_acpi.c which provides no further help.

Anyone have any thoughts about what is needed to enable the AR9280 (or
Intel 6200) in the Toshiba L675D?

Thanks,
-jr

[1] http://opal.com/jr/toshiba_l675d/acpi_toshiba.c
[2] http://opal.com/jr/toshiba_l675d/toshiba_l675d.asl
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Toshiba L675D wifi rfkill acpi support

[J.R. Oldroyd]

On Sun, 31 Jan 2016 09:58:05 +0100 Lars Engels  wrote:
> 
> You could try to "patch" PIN 20 on the card as described here:
> 
> http://www.allthingstechie.net/2014/10/bypass-laptop-wireless-hardware-radio.html
> 
> Then the H/W switch is always turned on.

News of this pin-20 patch of which you speak had not yet reached
these lands.  This new learning amazes me.

Being the pioneering type and always keen to be on the bleeding
edge (!), I went ahead and tried it.  It does, indeed, work!

Thank you, Lars, for bringing enlightenment.

And thanks, Adrian for your comments on the GPIO routing.

Now, given that the L305D works with both the AR9285 and AR9280
NICs and toggling the ACPI wireless 0x200 line works too, and given
that on the L675D the AR9285 also works as does the ACPI wireless
0x200 line, I guess we can conclude:
- the ACPI wireless 0x200 line is routed to something
  other than pin 20
- the L305D does not assert pin 20, the L675D does
- the AR9285 that I have (an AzureWave) ignores pin 20

I am thinking out loud here... I was hoping to be able to complete
the acpi_toshiba.c enhancements by making this work, but I have already
tested all four ACPI wireless lines on the L675D and none seem to
do what we need.

-jr
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Regression: ethernet + wireless/ath under lagg

[J.R. Oldroyd]

Since something like 9.0-release, I have used the following to config
an re and an ath interface together in a lagg.  The intent is to have
both ethernet and wireless interfaces share the lagg and be seamlessly 
pluggable between the two networks.  It was necessary to set the ath's
MAC address to be the same as the re's, else the wlan created from the
ath would not associate.  (The wlan's MAC address must be the same as
the underlying device's MAC, else the wlan fails WPA authentication.
Changing the underlying device's MAC before the wlan is created works
OK.)  This config has worked just fine on both 9.x and 10.x:

In /etc/rc.conf:

ifconfig_re0="up"
ifconfig_re0_ipv6="inet6 accept_rtadv"
ifconfig_ath0="`ifconfig re0 ether`"
ifconfig_ath0="ether ${ifconfig_ath0##*ether }"
wlans_ath0=wlan0
create_args_wlan0="regdomain FCC country US"
ifconfig_wlan0="WPA"
ifconfig_wlan0_ipv6="inet6 accept_rtadv"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport re0 laggport wlan0 DHCP"
# WAN_IF
ifconfig_lagg0_ipv6="inet6 accept_rtadv"

Now, with 11.0-release, this no longer works because the ath interface
doesn't exist any more, so ifconfig cannot pre-change its MAC.  And, I
have been unable to find a way of either determining or setting the
ath's MAC address using sysctls.

Now, the following does work, hard-coding the ath's MAC, and changing
the re's address to that value, instead of the other way around:

ether_ath0="70:1a:11:22:33:44"   # actual ath0 MAC address
ifconfig_re0="ether $ether_ath0 up"
ifconfig_re0_ipv6="inet6 accept_rtadv"
wlans_ath0=wlan0
create_args_wlan0="regdomain FCC country US"
ifconfig_wlan0="WPA"
ifconfig_wlan0_ipv6="inet6 accept_rtadv"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport re0 laggport wlan0 DHCP"
# WAN_IF
ifconfig_lagg0_ipv6="inet6 accept_rtadv"

Obviously, hard-coding a MAC address isn't a good solution.

Am I missing something?  Is there a way to config this without a
hard-coded address?

Or, do we need to fix the bug that is preventing setting the wlan's
MAC address to be something different from the underlying ath's
address? 

-jr
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Regression: ethernet + wireless/ath under lagg

[J.R. Oldroyd]

On Wed, 12 Oct 2016 09:08:20 -0700 Adrian Chadd  wrote:
>
> hiya,
> 
> there should be a way to create a vap with a specific mac address upon
> creation time. Sorry, doing lagg+wlan is not something we've been
> collectively using. :(
> 
> Thanks,
> 
> 
> -adrian
> 
> 

PR#213207 appears to be discussing this same problem.

I am truly amazed that this "is not something we've been collectively
using"!  Here, we have all of Macs, Windows, Linux for which this
"just works" and it also worked fine (with the config I posted
earlier) on 9.x and 10.x.  Your bog-standard, cheapo Linksys/Netgear/
whatever, bridge their wireless network to their wired ports, and it
is common practice here to be using wireless and then to later plug
into a wired port on those routers and have connections continue
seamlessly.

A way of determining the ath's MAC address so it can be used to set
the re's MAC, or a way of setting the ath's MAC address prior to wlan
creation is needed in 11.x.

-jr
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Boot freeze 11.0p3 during network initialization

[J.R. Oldroyd]

I have observed a 11.0p3 freezing during the boot process several times
now.

It gets as far as running the netif script, displaying the interfaces and
then goes on to devd and dhclient at which point it stops dead.  No keyboard
response.  It requires long-press of power to shut it down and restart, at
which point it typically boots normally:

wlan0: Ethernet address: 70:1a:04:xx:yy:zz
Created wlan(4) interfaces: wlan0.
Created clone interfaces: lagg0.
re0: link state changed to DOWN
Starting wpa_supplicant.
lagg0: link state changed to DOWN
re0: link state changed to UP
lagg0: link state changed to UP
Starting Network: lo0 re0 wlan0 lagg0.
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21
groups: lo
re0: flags=8843 metric 0 mtu 1500
options=82098
ether 70:1a:04:xx:yy:zz
nd6 options=29
media: Ethernet autoselect (100baseTX )
status: active
wlan0: flags=8843 metric 0 mtu 1500
ether 70:1a:04:xx:yy:zz
nd6 options=29
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid "" channel 153 (5765 MHz 11a)
regdomain FCC country US indoor ecm authmode WPA1+WPA2/802.11i
privacy MIXED deftxkey UNDEF txpower 23 bmiss 7 mcastrate 6 mgmtrate 6
scanvalid 60 wme burst roaming MANUAL bintval 0
groups: wlan
lagg0: flags=8843 metric 0 mtu 1500
ether 70:1a:04:xx:yy:zz
inet6 fe80::721a:4ff:fexx:yyzz%lagg0 prefixlen 64 scopeid 0x4
nd6 options=23
media: Ethernet autoselect
status: active
groups: lagg
laggproto failover lagghash l2,l3,l4
laggport: re0 flags=5
laggport: wlan0 flags=0<>
Starting devd.
Starting dhclient.
- freezes dead here

On a normal boot, the next lines would be:
wlan0: link state changed to UP
Starting pflog.
pflog0: promiscuous mode enabled

This is a laptop with its re0 and wlan0 interfaces configured together
under lagg using the wlan's MAC as the re's MAC too.

The relevant config in rc.conf are these:

ether_wlan0="70:1a:04:xx:yy:zz"
ifconfig_re0="ether $ether_wlan0 -txcsum -rxcsum up"
wlans_ath0=wlan0
create_args_wlan0="regdomain FCC country US"
ifconfig_wlan0="WPA"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport re0 laggport wlan0 DHCP"# WAN_IF
ifconfig_lagg0_ipv6="inet6 accept_rtadv"

This boot freeze happens probably 5-10% of the time, so problematic
enough.

This problem was never observed on 10.x or 9.x or even 8.x on the same
laptop.

What other info can I provide?

-jr
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Boot freeze 11.0p3 during network initialization

[J.R. Oldroyd]

On Thu, 08 Dec 2016 21:29:32 +0200 "Andriy Voskoboinyk"  
wrote:
>
> Thu, 08 Dec 2016 16:57:19 +0200 було написано J.R. Oldroyd :
> 
> Is there any additional output with
> wlandebug_wlan0="scan+state+auth+assoc"
> in /etc/rc.conf ?
> 

I have put that in and rebooted several times, all times OK.
I will report back again in due course when it next hangs.

-jr
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Boot freeze 11.0p3 during network initialization

[J.R. Oldroyd]

On Thu, 8 Dec 2016 17:19:26 -0500 "J.R. Oldroyd"  wrote:
>
> On Thu, 08 Dec 2016 21:29:32 +0200 "Andriy Voskoboinyk"  
> wrote:
> >
> > Thu, 08 Dec 2016 16:57:19 +0200 було написано J.R. Oldroyd :
> > 
> > Is there any additional output with
> > wlandebug_wlan0="scan+state+auth+assoc"
> > in /etc/rc.conf ?
> >   
> 
> I have put that in and rebooted several times, all times OK.
> I will report back again in due course when it next hangs.
> 
>   -jr
> 

The boot hang occurred again today.  I noted the point of the hang and
rebooted; the log from the good boot with annotation of the previous hang
point is here [1].

-jr

[1] http://opal.com/jr/freebsd/20161220-fbsd11.3-boot_hang_wlan_debug.txt
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Boot freeze 11.0p3 during network initialization

[J.R. Oldroyd]

On Fri, 23 Dec 2016 10:17:34 -0800 Adrian Chadd  wrote:
>
> On 20 December 2016 at 08:18, J.R. Oldroyd  wrote:
> > On Thu, 8 Dec 2016 17:19:26 -0500 "J.R. Oldroyd"  wrote:  
> >>
> >> On Thu, 08 Dec 2016 21:29:32 +0200 "Andriy Voskoboinyk" 
> >>  wrote:  
> >> >
> >> > Thu, 08 Dec 2016 16:57:19 +0200 було написано J.R. Oldroyd 
> >> > :
> >> >
> >> > Is there any additional output with
> >> > wlandebug_wlan0="scan+state+auth+assoc"
> >> > in /etc/rc.conf ?
> >> >  
> >>
> >> I have put that in and rebooted several times, all times OK.
> >> I will report back again in due course when it next hangs.
> >>
> >>   -jr
> >>  
> >
> > The boot hang occurred again today.  I noted the point of the hang and
> > rebooted; the log from the good boot with annotation of the previous hang
> > point is here [1].
> >
> > -jr
> >
> > [1] http://opal.com/jr/freebsd/20161220-fbsd11.3-boot_hang_wlan_debug.txt
> > ___
> > freebsd-wireless@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> > To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org" 
> >  
> 
> 
> can you compile with witness and invariants? I'd like to see if its
> locking related.
> 
> thanks
> 
> 
> -adrian
> 
> 

Hmm, maybe:

Dec 23 14:30:34 shibato kernel: wlan0: ieee80211_swscan_add_scan: chan  11g min 
dwell met (2146895553 > 2146895553)
Dec 23 14:30:34 shibato kernel: wlan0: scan_mindwell: called
Dec 23 14:30:34 shibato kernel: wlan0: scan_curchan_task: loop start; scandone=0
Dec 23 14:30:34 shibato kernel: wlan0: scan_curchan_task: chan  11g ->   7g 
[active, dwell min 20ms max 200ms]
Dec 23 14:30:34 shibato kernel: wlan0: scan_curchan: calling; maxdwell=200
Dec 23 14:30:34 shibato kernel: wlan0: scan_curchan_task: waiting
Dec 23 14:30:34 shibato kernel: re0: link state changed to UP
Dec 23 14:30:34 shibato kernel: lagg0: link state changed to UP
Dec 23 14:30:34 shibato kernel: lock order reversal:
Dec 23 14:30:34 shibato kernel: 1st 0xf800095d2208 if_lagg rmlock (if_lagg 
rmlock) @ /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:1530
Dec 23 14:30:34 shibato kernel: 2nd 0xfee10218 re0 (network driver) @ 
dev/re/if_re.c:3433
Dec 23 14:30:34 shibato kernel: stack backtrace:
Dec 23 14:30:34 shibato kernel: #0 0x80a98b60 at witness_debugger+0x70
Dec 23 14:30:34 shibato kernel: #1 0x80a98a54 at 
witness_checkorder+0xe54
Dec 23 14:30:34 shibato kernel: #2 0x80a1c794 at __mtx_lock_flags+0xa4
Dec 23 14:30:34 shibato kernel: #3 0x8078c279 at re_ioctl+0x3a9
Dec 23 14:30:34 shibato kernel: #4 0x8222428e at lagg_port_ioctl+0xde
Dec 23 14:30:34 shibato kernel: #5 0x80b20bbf at if_addmulti+0x39f
Dec 23 14:30:34 shibato kernel: #6 0x82224708 at 
lagg_ether_cmdmulti+0x158
Dec 23 14:30:34 shibato kernel: #7 0x822219dd at lagg_ioctl+0xdd
Dec 23 14:30:34 shibato kernel: #8 0x80b20bbf at if_addmulti+0x39f
Dec 23 14:30:34 shibato kernel: #9 0x80c35a97 at 
in6_mc_join_locked+0x1d7
Dec 23 14:30:34 shibato kernel: #10 0x80c35715 at in6_joingroup+0x75
Dec 23 14:30:34 shibato kernel: #11 0x80c2f9e9 at in6_update_ifa+0x1339
Dec 23 14:30:34 shibato kernel: #12 0x80c33eb3 at in6_ifattach+0x413
Dec 23 14:30:34 shibato kernel: #13 0x80b1fd84 at ifioctl+0xfe4
Dec 23 14:30:34 shibato kernel: #14 0x80a9d946 at kern_ioctl+0x246
Dec 23 14:30:34 shibato kernel: #15 0x80a9d691 at sys_ioctl+0x171
Dec 23 14:30:34 shibato kernel: #16 0x80e9d40b at amd64_syscall+0x2db
Dec 23 14:30:34 shibato kernel: #17 0x80e7d8ab at Xfast_syscall+0xfb
Dec 23 14:30:34 shibato kernel: wlan0: scan_curchan_task: loop start; scandone=0
Dec 23 14:30:34 shibato kernel: wlan0: scan_curchan_task: chan   7g ->  36a 
[active, dwell min 20ms max 200ms]
Dec 23 14:30:34 shibato kernel: wlan0: scan_curchan: calling; maxdwell=200
Dec 23 14:30:34 shibato kernel: wlan0: scan_curchan_task: waiting

This boot then continued normally, no hang.

-jr


pgprURuM70zNM.pgp
Description: OpenPGP digital signature

Re: Boot freeze 11.0p3 during network initialization

[J.R. Oldroyd]

Sorry for the time gap, I had to deal with family matters.

OK, I patched if_lagg.c to drop and re-acquire the lock around
the call to init the underlying driver.  I've been running this
for some weeks now and haven't seen the boot-hang since.  Hopefully
I have tested long enough.

Someone more familiar with this driver and use of this lock there
should review this patch and comment.

-jr


Index: sys/net/if_lagg.c
===
--- sys/net/if_lagg.c   (revision 307319)
+++ sys/net/if_lagg.c   (working copy)
@@ -995,6 +995,21 @@
LAGG_RUNLOCK(sc, &tracker);
break;
 
+   case SIOCADDMULTI:
+   case SIOCDELMULTI:
+   /*
+* Drivers like if_re.c cause a LOR on WLOCK, so we must
+* drop and re-aquire the lock around the call.
+*/
+   if (lp->lp_ioctl == NULL) {
+   error = EINVAL;
+   break;
+   }
+   LAGG_WUNLOCK(sc);
+   error = (*lp->lp_ioctl)(ifp, cmd, data);
+   LAGG_WLOCK(sc);
+   break;
+
case SIOCSIFCAP:
if (lp->lp_ioctl == NULL) {
error = EINVAL;


On Wed, 28 Dec 2016 00:24:09 -0800 Adrian Chadd  wrote:
>
> hi,
> 
> yes, the LOR is why the boot hang occurs :(
> 
> 
> 
> -a
> 
> 
> On 27 December 2016 at 14:30, J.R. Oldroyd  wrote:
> > Sorry, Adrian, I'm missing the back-story here and I'm not that
> > familiar with the lagg code.
> >
> > Are you saying that this LOR is likely relevant to this boot hang,
> > or are you saying that this is a known problem that's not relevant?
> >
> > Jan Kokemüller posted some lagg patches.  I don't know if they are
> > likely applicable to this problem, but I could try those.
> >
> > https://reviews.freebsd.org/D6845
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211689#c4
> >
> > The first removes an RLOCK, but not the one referenced in the LOR
> > report.  The second is a patch for the ath/iwm panic.  If you're
> > unfamiliar with them, I will study up on this code and patches
> > to get up to speed on it.
> >
> > -jr
> >
> >
> > On Fri, 23 Dec 2016 11:41:33 -0800 Adrian Chadd  
> > wrote:  
> >>
> >> Right, that's the known lock order issue with lagg. :(
> >>
> >>
> >> -adrian
> >>
> >>
> >> On 23 December 2016 at 11:37, J.R. Oldroyd  wrote:  
> >> > On Fri, 23 Dec 2016 10:17:34 -0800 Adrian Chadd  
> >> > wrote:  
> >> >>
> >> >> On 20 December 2016 at 08:18, J.R. Oldroyd  wrote:  
> >> >> > On Thu, 8 Dec 2016 17:19:26 -0500 "J.R. Oldroyd"  
> >> >> > wrote:  
> >> >> >>
> >> >> >> On Thu, 08 Dec 2016 21:29:32 +0200 "Andriy Voskoboinyk" 
> >> >> >>  wrote:  
> >> >> >> >
> >> >> >> > Thu, 08 Dec 2016 16:57:19 +0200 було написано J.R. Oldroyd 
> >> >> >> > :
> >> >> >> >
> >> >> >> > Is there any additional output with
> >> >> >> > wlandebug_wlan0="scan+state+auth+assoc"
> >> >> >> > in /etc/rc.conf ?
> >> >> >> >  
> >> >> >>
> >> >> >> I have put that in and rebooted several times, all times OK.
> >> >> >> I will report back again in due course when it next hangs.
> >> >> >>
> >> >> >>   -jr
> >> >> >>  
> >> >> >
> >> >> > The boot hang occurred again today.  I noted the point of the hang and
> >> >> > rebooted; the log from the good boot with annotation of the previous 
> >> >> > hang
> >> >> > point is here [1].
> >> >> >
> >> >> > -jr
> >> >> >
> >> >> > [1] 
> >> >> > http://opal.com/jr/freebsd/20161220-fbsd11.3-boot_hang_wlan_debug.txt
> >> >> > ___
> >> >> > freebsd-wireless@freebsd.org mailing list
> >> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> >> >> > To unsubscribe, send any mail to 
> >> >> > "freebsd-wireless-unsubscr...@freebsd.org"  
> >> >>
> >> >>
> &

Re: Boot freeze 11.0p3 during network initialization

[J.R. Oldroyd]

I have filed a PR with this patch so that it doesn't get overlooked.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216731

-jr


On Thu, 26 Jan 2017 10:20:17 -0500 "J.R. Oldroyd"  wrote:
>
> Sorry for the time gap, I had to deal with family matters.
> 
> OK, I patched if_lagg.c to drop and re-acquire the lock around
> the call to init the underlying driver.  I've been running this
> for some weeks now and haven't seen the boot-hang since.  Hopefully
> I have tested long enough.
> 
> Someone more familiar with this driver and use of this lock there
> should review this patch and comment.
> 
>   -jr
> 
> 
> Index: sys/net/if_lagg.c
> ===
> --- sys/net/if_lagg.c (revision 307319)
> +++ sys/net/if_lagg.c (working copy)
> @@ -995,6 +995,21 @@
>   LAGG_RUNLOCK(sc, &tracker);
>   break;
>  
> + case SIOCADDMULTI:
> + case SIOCDELMULTI:
> + /*
> +  * Drivers like if_re.c cause a LOR on WLOCK, so we must
> +  * drop and re-aquire the lock around the call.
> +  */
> + if (lp->lp_ioctl == NULL) {
> + error = EINVAL;
> + break;
> + }
> + LAGG_WUNLOCK(sc);
> + error = (*lp->lp_ioctl)(ifp, cmd, data);
> + LAGG_WLOCK(sc);
> + break;
> +
>   case SIOCSIFCAP:
>   if (lp->lp_ioctl == NULL) {
>   error = EINVAL;
> 
> 
> On Wed, 28 Dec 2016 00:24:09 -0800 Adrian Chadd  
> wrote:
> >
> > hi,
> > 
> > yes, the LOR is why the boot hang occurs :(
> > 
> > 
> > 
> > -a
> > 
> > 
> > On 27 December 2016 at 14:30, J.R. Oldroyd  wrote:  
> > > Sorry, Adrian, I'm missing the back-story here and I'm not that
> > > familiar with the lagg code.
> > >
> > > Are you saying that this LOR is likely relevant to this boot hang,
> > > or are you saying that this is a known problem that's not relevant?
> > >
> > > Jan Kokemüller posted some lagg patches.  I don't know if they are
> > > likely applicable to this problem, but I could try those.
> > >
> > > https://reviews.freebsd.org/D6845
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211689#c4
> > >
> > > The first removes an RLOCK, but not the one referenced in the LOR
> > > report.  The second is a patch for the ath/iwm panic.  If you're
> > > unfamiliar with them, I will study up on this code and patches
> > > to get up to speed on it.
> > >
> > > -jr
> > >
> > >
> > > On Fri, 23 Dec 2016 11:41:33 -0800 Adrian Chadd  
> > > wrote:
> > >>
> > >> Right, that's the known lock order issue with lagg. :(
> > >>
> > >>
> > >> -adrian
> > >>
> > >>
> > >> On 23 December 2016 at 11:37, J.R. Oldroyd  wrote:
> > >> > On Fri, 23 Dec 2016 10:17:34 -0800 Adrian Chadd 
> > >> >  wrote:
> > >> >>
> > >> >> On 20 December 2016 at 08:18, J.R. Oldroyd  wrote:
> > >> >> > On Thu, 8 Dec 2016 17:19:26 -0500 "J.R. Oldroyd"  
> > >> >> > wrote:
> > >> >> >>
> > >> >> >> On Thu, 08 Dec 2016 21:29:32 +0200 "Andriy Voskoboinyk" 
> > >> >> >>  wrote:
> > >> >> >> >
> > >> >> >> > Thu, 08 Dec 2016 16:57:19 +0200 було написано J.R. Oldroyd 
> > >> >> >> > :
> > >> >> >> >
> > >> >> >> > Is there any additional output with
> > >> >> >> > wlandebug_wlan0="scan+state+auth+assoc"
> > >> >> >> > in /etc/rc.conf ?
> > >> >> >> >
> > >> >> >>
> > >> >> >> I have put that in and rebooted several times, all times OK.
> > >> >> >> I will report back again in due course when it next hangs.
> > >> >> >>
> > >> >> >>   -jr
> > >> >> >>
> > >> >> >
> > >> >> > The boot hang occurred again today.  I noted the point of the hang 
> > >> >> > and
> > >> >> > rebooted; the log from the g