Re: is lagg (re+wlan) working on 11.0-RELEASE?

[J.R. Oldroyd]

On Tue, 18 Oct 2016 14:43:13 +0300 "Zeus Panchenko"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I'm using lagg(4) in failover to set up roaming between wired and
> wireless networks, just as manual describes (last example) and all
> was working perfectly on 11-CURRENT
> 
> now on 11.0-RELEASE (with the same configuration) wlan interface is
> unable to associate and auth against AP, while wired link works as
> expected
> 

It does not work as you have it configured, see PR#213207.

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

There is a work-around.  Configure the re interface with the MAC
address of the wlan instead of the other way around.

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

Re: FreeBSD10.3-RELEASE. Kernel panic.

[Cassiano Peixoto]

Hi guys,

I have some update about this issue. After my last email i had 3 crashes.
Two of them had the same message on kernel debug:

(kgdb) list *0x8228c918
0x8228c918 is in trim_map_seg_compare
(/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/trim_map.c:108).
103trim_map_seg_compare(const void *x1, const void *x2)
104{
105const trim_seg_t *s1 = x1;
106const trim_seg_t *s2 = x2;
107
108if (s1->ts_start < s2->ts_start) {
109if (s1->ts_end > s2->ts_start)
110return (0);
111return (-1);
112}
Current language:  auto; currently minimal
(kgdb) bt
#0  doadump (textdump=) at pcpu.h:221
#1  0x80ad8e69 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:366
#2  0x80ad941b in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0x80ad9253 in panic (fmt=0x0) at
/usr/src/sys/kern/kern_shutdown.c:690
#4  0x80fa0d31 in trap_fatal (frame=0xfe02374957f0,
eva=4294967343) at /usr/src/sys/amd64/amd64/trap.c:841
#5  0x80fa0f23 in trap_pfault (frame=0xfe02374957f0,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:691
#6  0x80fa04cc in trap (frame=0xfe02374957f0) at
/usr/src/sys/amd64/amd64/trap.c:442
#7  0x80f84141 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:236
#8  0x8228c918 in trim_map_seg_compare (x1=0xfe0237495920,
x2=0x10007) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/trim_map.c:108
#9  0x821a98e1 in avl_find (tree=,
value=, where=0x0) at
/usr/src/sys/cddl/contrib/opensolaris/common/avl/avl.c:268
#10 0x8228ce9e in trim_map_write_start (zio=)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/trim_map.c:363
#11 0x822592df in zio_vdev_io_start (zio=0xf802191ea000) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2866
#12 0x82255b26 in zio_execute (zio=) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1556
#13 0x822551e9 in zio_nowait (zio=0xf802191ea000) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1610
#14 0x8223c738 in vdev_queue_io_done (zio=) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:884
#15 0x822594a9 in zio_vdev_io_done (zio=0xf8006daad000) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2895
#16 0x82255b26 in zio_execute (zio=) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1556
#17 0x80b363ca in taskqueue_run_locked (queue=) at /usr/src/sys/kern/subr_taskqueue.c:449
#18 0x80b372d8 in taskqueue_thread_loop (arg=)
at /usr/src/sys/kern/subr_taskqueue.c:703
#19 0x80a90055 in fork_exit (callout=0x80b371f0
, arg=0xf8001006b920, frame=0xfe0237495c00)
at /usr/src/sys/kern/kern_fork.c:1038
#20 0x80f8467e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:611
#21 0x in ?? ()
(kgdb) up 8
#8  0x8228c918 in trim_map_seg_compare (x1=0xfe0237495920,
x2=0x10007) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/trim_map.c:108
108if (s1->ts_start < s2->ts_start) {

But my last crash had a different message:

(kgdb) list *0x80b3a89c
0x80b3a89c is in turnstile_broadcast
(/usr/src/sys/kern/subr_turnstile.c:837).
832
833/*
834 * Transfer the blocked list to the pending list.
835 */
836mtx_lock_spin(_contested_lock);
837TAILQ_CONCAT(>ts_pending, >ts_blocked[queue], td_lockq);
838mtx_unlock_spin(_contested_lock);
839
840/*
841 * Give a turnstile to each thread.  The last thread gets
Current language:  auto; currently minimal
(kgdb) bt
#0  doadump (textdump=) at pcpu.h:221
#1  0x80ad8e69 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:366
#2  0x80ad941b in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0x80ad9253 in panic (fmt=0x0) at
/usr/src/sys/kern/kern_shutdown.c:690
#4  0x80fa0d31 in trap_fatal (frame=0xfe0237384870, eva=48) at
/usr/src/sys/amd64/amd64/trap.c:841
#5  0x80fa0f23 in trap_pfault (frame=0xfe0237384870,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:691
#6  0x80fa04cc in trap (frame=0xfe0237384870) at
/usr/src/sys/amd64/amd64/trap.c:442
#7  0x80f84141 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:236
#8  0x80b3a89c in turnstile_broadcast (ts=0x0, queue=1) at
/usr/src/sys/kern/subr_turnstile.c:837
#9  0x80ad48cf in __rw_wunlock_hard (c=0xf8024f3c2960,
tid=, file=, line=)
at /usr/src/sys/kern/kern_rwlock.c:1027
#10 0x80e1a75c in vm_map_delete (map=,
start=, end=) at
/usr/src/sys/vm/vm_map.c:2960
#11 0x80e1828e in vmspace_exit (td=) at
/usr/src/sys/vm/vm_map.c:3077
#12 0x80a88686 in exit1 (td=0xf80015533a00, rval=268849920,
signo=0) at 

Re: is lagg (re+wlan) working on 11.0-RELEASE?

[Zeus Panchenko]

thanks for quick reply

J.R. Oldroyd  wrote:
> There is a work-around.  Configure the re interface with the MAC
> address of the wlan instead of the other way around.

I done it and here is what happens:

1. I boot notebook with wire *not* plugged in
   wlan is up, associated and authed, network is OK

2. I plug wire and network becomes stale

3. I run `tcpdump -ni lagg0' to see what's going on and oh, wonder,
   network comes back lo life!


so ... either to not to use lagg or run tcpdump constantly ... it is
rather weird :(

-- 
Zeus V. Panchenko   jid:z...@im.ibs.dn.ua
IT Dpt., I.B.S. LLC   GMT+2 (EET)


pgpi3chBzMziI.pgp
Description: PGP signature