Summary: | if_iwm firmware crashes and recovers | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Rene Ladan <rene> | ||||||||||||||||
Component: | wireless | Assignee: | freebsd-wireless (Nobody) <wireless> | ||||||||||||||||
Status: | New --- | ||||||||||||||||||
Severity: | Affects Only Me | CC: | avos, dpetrov67, ish | ||||||||||||||||
Priority: | --- | Keywords: | crash | ||||||||||||||||
Version: | CURRENT | ||||||||||||||||||
Hardware: | amd64 | ||||||||||||||||||
OS: | Any | ||||||||||||||||||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211653 | ||||||||||||||||||
Attachments: |
|
AFAIK, sysasserts are triggered by wrong firmware command parameters; can you recompile the kernel with 'options IWM_DEBUG' and upload log file with firmware exception(s) and command / scan debugging ('sysctl dev.iwm.0.debug=0x9000') ? Created attachment 174106 [details]
/var/log/messages
This messages are from my Dell XPS12 (9q33) with 7260 on 12.0-CURRENT r304876 with IWM_DEBUG and sysctl dev.iwm.0.debug=0x9000.
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
ether 5c:51:4f:11:73:f3
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 5c:51:4f:11:73:f3
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11a
status: associated
ssid ishorg-iNEi4Udw-a channel 36 (5180 MHz 11a) bssid dc:fb:02:2b:d9:90
regdomain JAPAN country JP authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit txpower 23 bmiss 10 mcastrate 6
mgmtrate 6 scanvalid 60 wme roaming MANUAL
groups: wlan
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 5c:51:4f:11:73:f3
inet 192.168.1.8 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::5e51:4fff:fe11:73f3%lagg0 prefixlen 64 scopeid 0x4
inet6 2400:7800:4d3a:6100:5e51:4fff:fe11:73f3 prefixlen 64 autoconf
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: active
groups: lagg
laggproto failover lagghash l2,l3,l4
laggport: ue0 flags=5<MASTER,ACTIVE>
laggport: wlan0 flags=0<>
Created attachment 174115 [details] Disable SF_CFG_CMD command temporarily > iwm0: iwm_send_cmd 0xd1 size=96 (async) > iwm0: sending command 0xd1 qid 9, idx 30 << SF_CFG_CMD > iwm0: iwm_send_cmd 0xd0 size=16 > iwm0: sending command 0xd0 qid 9, idx 31 << MCAST_FILTER_CMD Since SF_CFG_CMD was never sent before r303327 (and MCAST_FILTER_CMD remains unchanged), I assume that it is the reason; the patch just comments out places where it sent. Created attachment 174117 [details]
/var/log/messages
I applied this patch but it remains panic.
Created attachment 174140 [details]
Comment out SF_CFG_CMD + revert changes for MAC_CONTEXT
iwm0: iwm_send_cmd 0x28 size=152
iwm0: sending command 0x28 qid 9, idx 31 << IWM_MAC_CONTEXT_CMD
iwm0: dumping device error log
The only functional change in this command is in the
iwm_mvm_mac_ctxt_cmd_common(); newer patch reverts it too.
Created attachment 174153 [details]
/var/log/messages
It remains panic.
It is good working on my dell xps12 with AC 7260 at r306007. Created attachment 175022 [details]
/var/log/messages
Sorry, it became to lost connections.
No 'controller panicked' message was seen, but it couldn't connect any more.
|
Created attachment 173718 [details] iwm firmware panic messages if_iwm crashes firmware randomly(?) crashes with my iwm3165 card (which if_iwm indeed shows as an iwm3165 but is handled by iwm7265fw.ko) The firmware successfully restarts after these crashes, I'm typing this PR with a restarted firmware. It also seems to crash after a few days of uptime (typically 2+ days). dmesg samples attached. uname -a: FreeBSD e17 12.0-CURRENT FreeBSD 12.0-CURRENT #7 r303697: Wed Aug 3 10:41:19 CEST 2016 rene@e17:/usr/obj/usr/home/rene/freebsd/src/head/sys/GENERIC amd64