From owner-freebsd-wireless@freebsd.org Wed Jan 18 14:47:42 2017 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B1E4CB5ED9 for ; Wed, 18 Jan 2017 14:47:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 419711FC3 for ; Wed, 18 Jan 2017 14:47:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0IElfQ1032916 for ; Wed, 18 Jan 2017 14:47:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 211689] panic with lagg failover wireless ath and iwm Date: Wed, 18 Jan 2017 14:47:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: crash, needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: robin.randhawa@arm.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 14:47:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211689 --- Comment #13 from Robin Randhawa --- It appears I spoke too soon. While networking seems fine in general, I find that with the patch included= , an ACPI suspend to state S3 causes the system to panic silently while suspendi= ng and eventually reboot. The backtrace from the crash dump is as follows: (kgdb) bt #0 doadump (textdump=3D1) at pcpu.h:222 #1 0xffffffff80a30125 in kern_reboot (howto=3D) at /usr/src/sys/kern/kern_shutdown.c:386 #2 0xffffffff80a30700 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:779 #3 0xffffffff80a30536 in kassert_panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:669 #4 0xffffffff80a11b4c in __mtx_lock_flags (c=3D0xfffffe00011da080, opts=3D= 0, file=3D, line=3D1614) at /usr/src/sys/kern/kern_mutex.c:279 #5 0xffffffff80b7ab88 in ieee80211_suspend_all (ic=3D0xfffffe00011da048) at /usr/src/sys/net80211/ieee80211_proto.c:1614 #6 0xffffffff822dddff in iwm_suspend (dev=3D) at /usr/src/sys/modules/iwm/../../dev/iwm/if_iwm.c:6193 #7 0xffffffff80a64714 in bus_generic_suspend_child (dev=3D, child=3D0xfffff80007b5d500) at device_if.h:275 #8 0xffffffff806c562d in pci_suspend_child (dev=3D0xfffff80007b5d600, child=3D0xfffff80007b5d500) at /usr/src/sys/dev/pci/pci.c:4247 #9 0xffffffff80a647f7 in bus_generic_suspend (dev=3D)= at bus_if.h:975 #10 0xffffffff80a64714 in bus_generic_suspend_child (dev=3D, child=3D0xfffff80007b5d600) at device_if.h:275 #11 0xffffffff80a647f7 in bus_generic_suspend (dev=3D)= at bus_if.h:975 #12 0xffffffff80a64714 in bus_generic_suspend_child (dev=3D, child=3D0xfffff80007b5e900) at device_if.h:275 #13 0xffffffff806c562d in pci_suspend_child (dev=3D0xfffff80007b5f300, child=3D0xfffff80007b5e900) at /usr/src/sys/dev/pci/pci.c:4247 #14 0xffffffff80a647f7 in bus_generic_suspend (dev=3D)= at bus_if.h:975 #15 0xffffffff80a64714 in bus_generic_suspend_child (dev=3D, child=3D0xfffff80007b5f300) at device_if.h:275 #16 0xffffffff80a647f7 in bus_generic_suspend (dev=3D)= at bus_if.h:975 #17 0xffffffff80a64714 in bus_generic_suspend_child (dev=3D, child=3D0xfffff800077f6000) at device_if.h:275 #18 0xffffffff80a647f7 in bus_generic_suspend (dev=3D)= at bus_if.h:975 #19 0xffffffff803b960f in acpi_suspend (dev=3D0xfffff800077f7700) at /usr/src/sys/dev/acpica/acpi.c:729 #20 0xffffffff80a64714 in bus_generic_suspend_child (dev=3D, child=3D0xfffff800077f7700) at device_if.h:275 #21 0xffffffff80a647f7 in bus_generic_suspend (dev=3D)= at bus_if.h:975 #22 0xffffffff80a64714 in bus_generic_suspend_child (dev=3D, child=3D0xfffff800077f7c00) at device_if.h:275 #23 0xffffffff80a647f7 in bus_generic_suspend (dev=3D)= at bus_if.h:975 #24 0xffffffff803b71bf in acpi_EnterSleepState (sc=3D, state=3D) at device_if.h:275 #25 0xffffffff803b7b60 in acpi_AckSleepState (clone=3D, error=3D) at /usr/src/sys/dev/acpica/acpi.c:2780 #26 0xffffffff8090aaa3 in devfs_ioctl (ap=3D) at /usr/src/sys/fs/devfs/devfs_vnops.c:831 #27 0xffffffff81002d50 in VOP_IOCTL_APV (vop=3D, a=3D<= value optimized out>) at vnode_if.c:1067 #28 0xffffffff80b01634 in vn_ioctl (fp=3D0xfffff8000d2b1960, com=3D, data=3D0xfffffe08595f4780, active_cred=3D0xfffff80007701d00, td=3D) at vnode_= if.h:448 #29 0xffffffff8090b1cf in devfs_ioctl_f (fp=3D, com=3D= , data=3D, cred=3D, td=3D0xfffff8000d09d500) at /usr/src/sys/fs/devfs/devfs_vnops.c:789 #30 0xffffffff80a94870 in kern_ioctl (td=3D, fd=3D, com=3D, data=3D) at file.h:321 #31 0xffffffff80a9450f in sys_ioctl (td=3D, uap=3D0xfffffe08595f4930) at /usr/src/sys/kern/sys_generic.c:746 #32 0xffffffff80ea09b9 in amd64_syscall (td=3D0xfffff8000d09d500, traced=3D= 0) at subr_syscall.c:135 #33 0xffffffff80e806db in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #34 0x000000080097cbaa in ?? () Previous frame inner to this frame (corrupt stack?) Perhaps there is some reliance on the sc_lladr_task for some housekeeping action in the suspend path ? I've tested this across three suspend runs and the same panic occurred all three times. With the patch removed, the panic doesn't happen and suspend-resume cycles succeed. --=20 You are receiving this mail because: You are the assignee for the bug.=