* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Benjamin Morgan @ 2016-12-13 18:42 UTC (permalink / raw)
To: Nagarajan, Ashok Raj, Mohammed Shafi Shajakhan
Cc: agreen@cococorp.com, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <58472E7B.7090603@cococorp.com>
Just tested the latest 10.2.4.70.59-2 firmware and it still crashes with
wpa_supplicant encrypted mesh =(
[ 85.201440] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
b7f44483-0488-46af-8dff-db88f4b56327)
[ 85.210573] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c
chip_id 0x043202ff sub 0000:0000
[ 85.219940] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 1
[ 85.233034] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.59-2 api
5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[ 85.245177] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[ 85.252592] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
cal file max-sta 128 raw 0 hwcrypto 1
[ 85.264235] ath10k_pci 0000:01:00.0: firmware register dump:
[ 85.269992] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
0x009A45AF 0x00955B31
[ 85.278031] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130
0x00000002 0x00439E98
[ 85.286078] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
0x00407120 0x004436CC
[ 85.294107] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
0x009A3550 0x009A355E
[ 85.302152] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
0x00000000 0x00000000
[ 85.310195] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4
0x0040AC60 0x0040AC09
[ 85.318239] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24
0x00400000 0xC09A45AF
[ 85.326282] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84
0x0044110C 0x00442074
[ 85.334314] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4
0x0044110C 0x00407120
[ 85.342350] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4
0x0040AC14 0x00001580
[ 85.350393] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04
0x009C6458 0x004436CC
[ 85.358437] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64
0x004208FC 0x00439E4C
[ 85.366479] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84
0x004208FC 0x00425AAC
[ 85.374512] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4
0x00424FE8 0x00000002
[ 85.382548] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
0x00000004 0x004039D0
[ 85.487067] ieee80211 phy0: Hardware restart was requested
[ 85.492701] ath10k_pci 0000:01:00.0: wmi disable pktlog
Any new leads on tracking down this issue?
~Benjamin
On 12/06/2016 01:32 PM, Benjamin Morgan wrote:
> 1. Yes, this appears to happens every time a unicast packet with
> wpa_supplicant encryption in VHT80 mode is received. I haven't seen a
> successful ping-pong pair.
> 2. We tried with 10.2.4.70.42-2 firmware and still saw crashes.
> 3. We ran our experiment again with extra debugging turned on.
> Node A: 18:A6:F7:23:6E:66 | 10.230.5.41
> Node B: 18:A6:F7:26:0F:21 | 10.230.5.42
> The ping command we used was run on Node A was 'ping -s 1500 -i
> 0.1 10.230.5.42'
> Here is the dmesg log from Node B.
>
> [ 5413.478170] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5413.503954] ath10k_pci 0000:01:00.0: scan event bss channel type 4
> reason 3 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
> [ 5413.503985] ath10k_pci 0000:01:00.0: chan info err_code 0 freq 5825
> cmd_flags 1 noise_floor -105 rx_clear_count 7692807 cycle_count 312271423
> [ 5413.504029] ath10k_pci 0000:01:00.0: scan event completed type 2
> reason 0 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
> [ 5413.525868] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
> cipher 4 len 16
> [ 5413.526014] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
> value 1
> [ 5413.526193] ath10k_pci 0000:01:00.0: mac vdev 0 set keyidx 1
> [ 5413.526216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
> value 1
> [ 5413.526532] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180
> width 3 ptr 86db29b0
> [ 5413.526556] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
> needed? 0 allowed? 1
> [ 5413.526574] ath10k_pci 0000:01:00.0: mac chanctx assign ptr
> 86db29b0 vdev_id 0
> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
> 5180 phymode 11ac-vht80
> [ 5413.526616] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 5413.533099] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 5413.533148] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
> [ 5413.533163] ath10k_pci 0000:01:00.0: mac txpower 23
> [ 5413.533180] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
> [ 5413.533247] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
> [ 5413.533295] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
> width 3 ptr 86db29b0 changed 10
> [ 5413.533318] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
> width 3 ptr 86db29b0 changed 2
> [ 5413.533337] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
> needed? 1 allowed? 1
> [ 5413.533357] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
> subtype 0 macaddr 18:a6:f7:26:0f:21
> [ 5413.533412] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
> [ 5413.533463] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 5413.937652] ath10k_pci 0000:01:00.0: wmi event debug mesg len 152
> [ 5413.978273] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5414.478363] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5414.527015] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 5414.527067] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc
> id 0 bssid 18:a6:f7:26:0f:21
> [ 5414.527121] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
> [ 5414.527165] ath10k_pci 0000:01:00.0: mac monitor started
> [ 5414.527216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
> value 1000
> [ 5414.527262] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
> [ 5414.527278] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 5414.527294] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 5414.527314] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 5414.527330] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 5414.527457] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc
> id 0 bssid 00:00:00:00:00:00
> [ 5414.527501] ath10k_pci 0000:01:00.0: mac vdev 0 up
> [ 5414.527564] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
> [ 5414.541090] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
> needed? 1 allowed? 1
> [ 5414.978454] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5415.478548] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5415.978649] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5416.445280] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
> needed? 1 allowed? 1
> [ 5416.478761] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5416.978879] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5417.478985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5417.979081] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5418.479190] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5418.979301] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5419.479403] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5419.979551] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5420.479643] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5420.979746] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5421.479841] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5421.979940] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5422.480288] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5422.980386] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5423.480490] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5423.980600] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5424.480702] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5424.971969] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
> 18:a6:f7:23:6e:66 (new sta) sta 1 / 128 peer 2 / 144
> [ 5424.972000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
> peer_addr 18:a6:f7:23:6e:66
> [ 5424.975107] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 5424.975134] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 5424.975219] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 5424.975238] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 5424.980787] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5425.204468] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:23:6e:66
> associated
> [ 5425.204531] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:23:6e:66
> mcs cnt 24 nss 3
> [ 5425.204548] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 qos 1
> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
> phymode 11na-ht40
> [ 5425.204585] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
> 18:a6:f7:23:6e:66 (new)
> [ 5425.204614] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
> 0x18:a6:f7:23:6e:66 set param 1 value 0
> [ 5425.205376] ath10k_pci 0000:01:00.0: received event id 36891 not
> implemented
> [ 5425.209240] ath10k_pci 0000:01:00.0: wmi vdev install key idx 0
> cipher 4 len 16
> [ 5425.209655] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
> cipher 4 len 16
> [ 5425.209848] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
> value 1
> [ 5425.210196] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 5425.210221] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 5425.210296] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 5425.210315] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 5425.480863] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5425.938619] ath10k_pci 0000:01:00.0: wmi event debug mesg len 100
> [ 5425.980946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5425.995007] ath10k_pci 0000:01:00.0: mac sta rc update for
> 18:a6:f7:23:6e:66 changed 00000001 bw 2 nss 3 smps 1
> [ 5425.995060] ath10k_pci 0000:01:00.0: mac update sta
> 18:a6:f7:23:6e:66 peer bw 2
> [ 5425.995081] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
> 0x18:a6:f7:23:6e:66 set param 4 value 2
> [ 5426.481030] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5426.981117] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5427.481206] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5427.981294] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5428.481628] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5428.981718] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5429.481812] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5429.981894] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5430.481985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5430.982073] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5431.482174] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5431.982505] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5432.482597] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5432.982679] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5433.482765] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5433.982857] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5434.482946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5434.983008] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5435.483100] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5435.983181] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5436.483276] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5436.983366] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5437.483445] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5437.983516] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5438.483607] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5438.983692] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5439.439875] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> db76b67c-ca98-4519-a762-4ff4edb45526)
> [ 5439.449007] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 5439.458378] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
> tracing 0 dfs 1 testmode 1
> [ 5439.471460] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [ 5439.481844] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 5439.489267] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> cal file max-sta 128 raw 0 hwcrypto 1
> [ 5439.500918] ath10k_pci 0000:01:00.0: firmware register dump:
> [ 5439.506678] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009A4577 0x00955B31
> [ 5439.514706] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> 0x00000002 0x00439E98
> [ 5439.522751] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [ 5439.530794] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x009A3518 0x009A3526
> [ 5439.538834] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [ 5439.546871] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [ 5439.554915] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> 0x00400000 0xC09A4577
> [ 5439.562948] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> 0x0044110C 0x00442074
> [ 5439.570992] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> 0x0044110C 0x00407120
> [ 5439.579032] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> 0x0040AC14 0x00001580
> [ 5439.587070] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> 0x009C643C 0x004436CC
> [ 5439.595113] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> 0x004208FC 0x00439E4C
> [ 5439.603146] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> 0x004208FC 0x00425E00
> [ 5439.611191] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> 0x00424FE8 0x00000002
> [ 5439.619230] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x00000004 0x004039D0
> [ 5439.726818] ieee80211 phy0: Hardware restart was requested
> [ 5439.732433] ath10k_pci 0000:01:00.0: wmi mgmt vdev down id 0x1
> [ 5439.732461] ath10k_pci 0000:01:00.0: wmi vdev stop id 0x1
> [ 5439.732482] ath10k_pci 0000:01:00.0: failed to synchronize monitor
> vdev 1 stop: -143
> [ 5439.740370] ath10k_pci 0000:01:00.0: mac monitor vdev 1 stopped
> [ 5439.740386] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> [ 5439.747042] ath10k_pci 0000:01:00.0: wmi disable pktlog
>
> We noticed in this log that when the radio starts up it says that it
> is in VHT80 mode:
> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
> 5180 phymode 11ac-vht80
>
> But when a peer connects it seems to think the peer is in HT40 mode:
> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
> phymode 11na-ht40
>
> Compared to no encryption case - this log was taken from Node A:
>
> [ 24.874253] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180
> width 3 ptr 86d26db0
> [ 24.874278] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
> needed? 0 allowed? 1
> [ 24.874296] ath10k_pci 0000:01:00.0: mac chanctx assign ptr
> 86d26db0 vdev_id 0
> [ 24.874312] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
> 5180 phymode 11ac-vht80
> [ 24.874337] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 24.881335] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 24.881423] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
> [ 24.881438] ath10k_pci 0000:01:00.0: mac txpower 23
> [ 24.881454] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
> [ 24.881491] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
> [ 24.881515] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
> width 3 ptr 86d26db0 changed 10
> [ 24.881535] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
> width 3 ptr 86d26db0 changed 2
> [ 24.881554] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
> needed? 1 allowed? 1
> [ 24.881574] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
> subtype 0 macaddr 18:a6:f7:23:6e:66
> [ 24.881689] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
> [ 24.881745] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 25.273460] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 25.730570] ath10k_pci 0000:01:00.0: wmi event debug mesg len 300
> [ 25.773566] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 25.874556] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 25.879992] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc
> id 0 bssid 18:a6:f7:23:6e:66
> [ 25.880077] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
> [ 25.880093] ath10k_pci 0000:01:00.0: mac monitor started
> [ 25.880139] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
> value 1000
> [ 25.880184] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
> [ 25.880199] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.880215] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.880235] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.880250] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.880988] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc
> id 0 bssid 00:00:00:00:00:00
> [ 25.881035] ath10k_pci 0000:01:00.0: mac vdev 0 up
> [ 25.881097] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
> [ 25.882968] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 25.928796] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.928821] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.928866] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.928883] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.929020] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
> needed? 1 allowed? 1
> [ 25.941886] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.941911] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.941955] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.941972] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.953727] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.953753] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.953798] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.953817] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.970588] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.970614] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.970659] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.970676] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.989056] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.989081] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.989126] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.989143] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 26.071686] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
> 18:a6:f7:26:0f:21 (new sta) sta 1 / 128 peer 2 / 144
> [ 26.071712] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
> peer_addr 18:a6:f7:26:0f:21
> [ 26.071952] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:26:0f:21
> associated
> [ 26.071981] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:26:0f:21
> mcs cnt 24 nss 3
> [ 26.071999] ath10k_pci 0000:01:00.0: mac vht peer 18:a6:f7:26:0f:21
> max_mpdu 1048575 flags 0x601b001
> [ 26.072013] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 qos 1
> [ 26.072028] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21
> phymode 11ac-vht80
> [ 26.072047] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
> 18:a6:f7:26:0f:21 (new)
> [ 26.072071] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
> 0x18:a6:f7:26:0f:21 set param 1 value 0
> [ 26.072502] ath10k_pci 0000:01:00.0: received event id 36891 not
> implemented
> [ 26.074194] ath10k_pci 0000:01:00.0: mac sta rc update for
> 18:a6:f7:26:0f:21 changed 00000000 bw 2 nss 3 smps 1
> [ 26.074586] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 26.074609] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 26.074682] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 26.074701] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 26.074760] ath10k_pci 0000:01:00.0: mac vdev 0 slot_time 2
> [ 26.074779] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 7
> value 2
> [ 26.273652] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 26.730650] ath10k_pci 0000:01:00.0: wmi event debug mesg len 44
> [ 26.773733] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 27.135445] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
> needed? 1 allowed? 1
> [ 27.273810] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>
> It seems to start up in VHT80 mode and when it peers with Node B it
> thinks Node B is also in VHT80 mode and ping works.
>
> 4. Beacons are sent at 6 Mb/s basic rate and unicast QoS Data is sent
> with three spatial streams. Attached is the full pcap of the experiment.
>
> Thank you for looking into this!
>
> ~Benjamin
>
> On 12/05/2016 11:24 AM, Nagarajan, Ashok Raj wrote:
>> 0x009A4577 0x00955B31
>>
>> Benjamin, Thanks for the logs.
>> Quick questions to further debug the issue here,
>>
>> 1. Is this issue seen every time you start sending data traffic?
>> 2. Issue seen with older firmwares? (FYR,
>> http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
>> 3. Could you please share the dmesg from your device after enabling
>> MAC and WMI logs in ath10k driver
>> To enable debug logs please see
>> http://linuxwireless.org/en/users/Drivers/ath10k/debug/
>> 4. Do you know what is the Number of Spatial Streams seen in mesh
>> beacons and in mesh data packet?
>>
>> Thanks,
>> Ashok
>
^ permalink raw reply
* Re: [RFC v2 05/11] ath10k: htc: refactorization
From: Michal Kazior @ 2016-12-13 19:21 UTC (permalink / raw)
To: Erik Stromdahl
Cc: Valo, Kalle, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>
On 13 December 2016 at 19:37, Erik Stromdahl <erik.stromdahl@gmail.com> wro=
te:
>
>
> On 12/13/2016 06:26 PM, Valo, Kalle wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> On 13 December 2016 at 14:44, Valo, Kalle <kvalo@qca.qualcomm.com> wrot=
e:
>>>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>>>>
>>>>> Code refactorization:
>>>>>
>>>>> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
>>>>> to ath10k_htc_control_rx_complete.
>>>>>
>>>>> This eases the implementation of SDIO/mbox significantly since
>>>>> the ep_rx_complete cb is invoked directly from the SDIO/mbox
>>>>> hif layer.
>>>>>
>>>>> Since the ath10k_htc_control_rx_complete already is present
>>>>> (only containing a warning message) there is no reason for not
>>>>> using it (instead of having a special case for ep 0 in
>>>>> ath10k_htc_rx_completion_handler).
>>>>>
>>>>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>>>>
>>>> I tested this on QCA988X PCI board just to see if there are any
>>>> regressions. It crashes immediately during module load, every time, an=
d
>>>> bisected that the crashing starts on this patch:
>>>>
>>>> [ 1239.715325] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 ir=
q_mode 0 reset_mode 0
>>>> [ 1239.885125] ath10k_pci 0000:02:00.0: Direct firmware load for ath10=
k/pre-cal-pci-0000:02:00.0.bin failed with error -2
>>>> [ 1239.885260] ath10k_pci 0000:02:00.0: Direct firmware load for ath10=
k/cal-pci-0000:02:00.0.bin failed with error -2
>>>> [ 1239.885687] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016=
c chip_id 0x043202ff sub 0000:0000
>>>> [ 1239.885699] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 trac=
ing 1 dfs 1 testmode 1
>>>> [ 1239.885899] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 ap=
i 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
>>>> [ 1239.941836] ath10k_pci 0000:02:00.0: Direct firmware load for ath10=
k/QCA988X/hw2.0/board-2.bin failed with error -2
>>>> [ 1239.941993] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A cr=
c32 bebc7c08
>>>> [ 1241.136693] BUG: unable to handle kernel NULL pointer dereference a=
t (null)
>>>> [ 1241.136738] IP: [< (null)>] (null)
>>>> [ 1241.136759] *pdpt =3D 0000000000000000 *pde =3D f0002a55f0002a55 [ =
1241.136781]
>>>> [ 1241.136793] Oops: 0010 [#1] SMP
>>>>
>>>> What's odd is that when I added some printks on my own and enabled bot=
h
>>>> boot and htc debug levels it doesn't crash anymore. After everything
>>>> works normally after that, I can start AP mode and connect to it. Is i=
t
>>>> a race somewhere?
>>>
>>> Yes. htc_wait_target() is called after hif_start(). The ep_rx_complete
>>> is set in htc_wait_target() [changed patch 4, but still too late].
>>>
>>> ep_rx_complete must be set prior to calling hif_start(). You probably
>>> crash on end of ath10k_htc_rx_completion_handler() when trying to call
>>> ep->ep_ops.ep_rx_complete(ar, skb).
>>
>> Yeah, just checked and ep->ep_ops.ep_rx_complete is NULL at the end of
>> ath10k_htc_rx_completion_handler().
>>
> It is indeed correct as Michal points out, there is a risk that the
> first HTC control message (typically an HTC ready message) is received
> before the HTC control endpoint is connected.
>
> I have experienced a similar race with my SDIO implementation as well.
> In this case I did solve the issue by enabling HIF target interrupts
> after the HTC control endpoint was connected. I am not sure however if
> this is the most elegant way to solve this problem.
>
> My SDIO target won't send the HTC ready message before this is done.
> The fix essentially consists of moving the ..._irg_enable call from
> hif_start into another hif op.
It makes more sense to move ep_rx_complete setup/assignment before
hif_start(). This assignment should be done very early as there is
nothing to change/override for this endpoint during operation, is
there? It's known what it needs to store very early on.
> I have made a few updates since I submitted the original RFC and created
> a repo on github:
>
> https://github.com/erstrom/linux-ath
>
> I have a bunch of branches that are all based on the tags on the ath mast=
er.
>
> As of this moment the latest version is:
>
> ath-201612131156-ath10k-sdio
>
> This branch contains the original RFC patches plus some addons/fixes.
>
> In the above mentioned branch there are a few commits related to this
> race condition. Perhaps you can have a look at them?
>
> The commits are:
> 821672913328cf737c9616786dc28d2e4e8a4a90
I would avoid if(bus=3D=3Dxx) checks.
> dd7fcf0a1f78e68876d14f90c12bd37f3a700ad7
> 7434b7b40875bd08a3a48a437ba50afed7754931
>
> Perhaps this approach can work with PCIe as well?
I think I did contemplate the unmask/start distinction at some point
but I didn't go with it for some reason I can't recall now.
Micha=C5=82
^ permalink raw reply
* Re: [RFC V3 01/11] nl80211: add reporting of gscan capabilities
From: Arend Van Spriel @ 2016-12-13 20:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1481645701.20412.39.camel@sipsolutions.net>
On 13-12-2016 17:15, Johannes Berg wrote:
>
>> + case 14:
>> + if (!rdev->wiphy.gscan) {
>> + /* done */
>> + state->split_start = 0;
>> + break;
>> + }
>>
>
> Nit, but I'm not really happy with this - this assumes that case 14 is
> the last case, if anyone ever adds one we break this code but it would
> still work if the device has gscan. Move the gscan stuff into a new
> function and make that return immediately if gscan is NULL or so?
Agree. When coding this piece I was aware that this would need to change
when 'case 15' would be added, which is probably too easy to overlook. I
will change it.
Regards,
Arend
^ permalink raw reply
* Re: [RFC V3 03/11] nl80211: add support for gscan
From: Arend Van Spriel @ 2016-12-13 20:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1481645962.20412.41.camel@sipsolutions.net>
On 13-12-2016 17:19, Johannes Berg wrote:
> On Mon, 2016-12-12 at 11:59 +0000, Arend van Spriel wrote:
>> This patch adds support for GScan which is a scan offload feature
>> used in Android.
>
> Found a few places with spaces instead of tabs as indentation, and
> spurious braces around single-statement things, but other than that it
> looks fine from a patch/nl80211 POV.
I added a check in wiphy_register() in this patch which actually is more
appropriate with the "gscan capabilities" patch.
> Haven't really looked into the details of gscan itself now though,
> sorry.
>
> There's a bit of a weird hard-coded restriction to 16 channels too,
> that's due to the bucket map?
Uhm. Is there? I will check, but if you can give me a pointer where to
look it is appreciated.
Regards,
Arend
^ permalink raw reply
* Re: [Patch] NFC: trf7970a:
From: Mark Greer @ 2016-12-13 22:05 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, justin
In-Reply-To: <20160422000119.GA21754@animalcreek.com>
On Thu, Apr 21, 2016 at 05:01:19PM -0700, Mark Greer wrote:
> On Mon, Apr 18, 2016 at 03:48:37PM -0400, Geoff Lansberry wrote:
>
> Hi Geoff.
>
> > The current version of the trf7970a driver is missing support for several features that we needed to operate a custom board.
> > We feel that these features will be useful to others as well, and we want to share them.
> >
> > 1: Support for using a gpio as Slave-Select. Our processor has several devices on the spi bus, and we ran out of ss lines. This patch gives TRF7970A the ability to
> > drive the ss line of the chip from a gpio that is defined in the device tree.
> >
> > 2. When reviewing problems we were having in our implementation with TI support staff, they recommended that during initialization, address 0x18 should be written to zero. This patch adds that change
> >
> > 3. This existing version of the driver assumes that the crystal driving the trf7970a is 13.56 MHz, because there are several places in the driver code where the rel
> > ated register is re-written, there is clean way to change to 27.12 MHz. This patch adds a device tree option for 27 MHz and properly or's in changes in locations w
> > here the register is changed.
> >
> > 4. the existing version of the driver assumes that 3.3 volt io is used. The trf7970a has a special register where you can configure it for 1.8 volt io. This patch
> > adds a device tree option to select that this setting should be made.
> >
> > [PATCH 1/4] NFC: trf7970a: Add support for gpio as SS
> > [PATCH 2/4] NFC: trf7970a: add TI recommended write of zero to
> > [PATCH 3/4] NFC: trf7970a: add device tree option for 27MHz clock
> > [PATCH 4/4] NFC: trf7970a: Add device tree option of 1.8 Volt IO
>
> I'm on vacation this week but will be back next week. I'll take a
> look once I'm back.
>
> In the meantime, for emails sent to public (techie) list always keep
> the lines less than 80 characters and always bottom-post (i.e., put
> your text *underneath* the text that you are responding to). Also,
> when you change one or more patches in a series, re-submit the entire
> series with the version number incremented (.e.g., v2, v3, ...) even
> when you change only one of them. It is a easier for others to know
> what the latest versions are that way.
Hi Geoff.
I know its been a ridiculously long time since I said I would look at
your patches but I have time now. Do you have an updated version of
your patch series?
Mark
--
^ permalink raw reply
* Re: [RFC V3 03/11] nl80211: add support for gscan
From: Johannes Berg @ 2016-12-13 22:29 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless
In-Reply-To: <3dd64ef5-f05e-4a80-0c98-9a2548affd1c@broadcom.com>
On Tue, 2016-12-13 at 21:09 +0100, Arend Van Spriel wrote:
>
> > There's a bit of a weird hard-coded restriction to 16 channels too,
> > that's due to the bucket map?
>
> Uhm. Is there? I will check, but if you can give me a pointer where
> to look it is appreciated.
Just look for "< 16" or "<= 16" or so in the patch. I do think that's
because the channel map is a u16 though, not sure we'd want to change
that.
johannes
^ permalink raw reply
* [PATCH V2] ath10k: fix incorrect txpower set by P2P_DEVICE interface
From: ryanhsu @ 2016-12-13 22:55 UTC (permalink / raw)
To: ath10k, linux-wireless; +Cc: ryanhsu
From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Ath10k reports the phy capability that supports P2P_DEVICE interface.
When we use the P2P supported wpa_supplicant to start connection, it'll
create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).
ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
...
ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0
And the txpower in per vif bss_conf will only be set to valid tx power when
the interface is assigned with channel_ctx.
But this P2P_DEVICE interface will never be used for any connection, so
that the uninitialized bss_conf.txpower=0 is assinged to the
arvif->txpower when interface created.
Since the txpower configuration is firmware per physical interface.
So the smallest txpower of all vifs will be the one limit the tx power
of the physical device, that causing the low txpower issue on other
active interfaces.
wlan0: Limiting TX power to 21 (24 - 3) dBm
ath10k_pci mac vdev_id 0 txpower 21
ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
ath10k_pci mac txpower 0
This issue only happens when we use the wpa_supplicant that supports
P2P or if we use the iw tool to create the control P2P_DEVICE interface.
Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index fe42bf5..6e1550b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4671,7 +4671,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar)
lockdep_assert_held(&ar->conf_mutex);
list_for_each_entry(arvif, &ar->arvifs, list) {
- WARN_ON(arvif->txpower < 0);
+ if (arvif->txpower <= 0)
+ continue;
if (txpower == -1)
txpower = arvif->txpower;
@@ -4679,8 +4680,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar)
txpower = min(txpower, arvif->txpower);
}
- if (WARN_ON(txpower == -1))
- return -EINVAL;
+ if (txpower == -1)
+ return 0;
ret = ath10k_mac_txpower_setup(ar, txpower);
if (ret) {
--
1.9.1
^ permalink raw reply related
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Benjamin Morgan @ 2016-12-13 23:24 UTC (permalink / raw)
To: Nagarajan, Ashok Raj, Mohammed Shafi Shajakhan
Cc: agreen@cococorp.com, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <58504113.2080702@cococorp.com>
Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT
encryption and it still crashes. I suspect this means wpa_supplicant is
setting up the interface incorrectly and/or transmitting a malformed
packet that is causing the driver to crash.
[ 162.010206] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
d30144f6-a8fb-4c0d-bcdf-6ff3b2c37243)
[ 162.019322] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c
chip_id 0x043202ff sub 0000:0000
[ 162.028687] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 1
[ 162.041764] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.59-2 api
5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[ 162.053908] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[ 162.061332] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
cal file max-sta 128 raw 0 hwcrypto 1
[ 162.072975] ath10k_pci 0000:01:00.0: firmware register dump:
[ 162.078732] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
0x009A45AF 0x00955B31
[ 162.086771] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130
0x00000001 0x40000000
[ 162.094804] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
0x00407120 0x004436CC
[ 162.102849] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
0x009A3550 0x009A355E
[ 162.110892] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
0x00000000 0x00000000
[ 162.118935] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4
0x0040AC60 0x0040AC09
[ 162.126978] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24
0x00000000 0xC09A45AF
[ 162.135011] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84
0x0044110C 0x00442074
[ 162.143056] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4
0x0044110C 0x00407120
[ 162.151099] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4
0x0040AC10 0x00001580
[ 162.159142] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04
0x009C6458 0x004436CC
[ 162.167185] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64
0x004208FC 0x00439E4C
[ 162.175225] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84
0x004208FC 0x004265C4
[ 162.183253] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4
0x00424FE8 0x00000002
[ 162.191298] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
0x00000004 0x004039D0
[ 162.297229] ieee80211 phy0: Hardware restart was requested
[ 162.302880] ath10k_pci 0000:01:00.0: wmi disable pktlog
~Benjamin
On 12/13/2016 10:42 AM, Benjamin Morgan wrote:
> Just tested the latest 10.2.4.70.59-2 firmware and it still crashes
> with wpa_supplicant encrypted mesh =(
>
> [ 85.201440] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> b7f44483-0488-46af-8dff-db88f4b56327)
> [ 85.210573] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 85.219940] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
> tracing 0 dfs 1 testmode 1
> [ 85.233034] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.59-2
> api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
> [ 85.245177] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 85.252592] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> cal file max-sta 128 raw 0 hwcrypto 1
> [ 85.264235] ath10k_pci 0000:01:00.0: firmware register dump:
> [ 85.269992] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009A45AF 0x00955B31
> [ 85.278031] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130
> 0x00000002 0x00439E98
> [ 85.286078] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [ 85.294107] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x009A3550 0x009A355E
> [ 85.302152] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [ 85.310195] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [ 85.318239] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24
> 0x00400000 0xC09A45AF
> [ 85.326282] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84
> 0x0044110C 0x00442074
> [ 85.334314] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4
> 0x0044110C 0x00407120
> [ 85.342350] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4
> 0x0040AC14 0x00001580
> [ 85.350393] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04
> 0x009C6458 0x004436CC
> [ 85.358437] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64
> 0x004208FC 0x00439E4C
> [ 85.366479] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84
> 0x004208FC 0x00425AAC
> [ 85.374512] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4
> 0x00424FE8 0x00000002
> [ 85.382548] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x00000004 0x004039D0
> [ 85.487067] ieee80211 phy0: Hardware restart was requested
> [ 85.492701] ath10k_pci 0000:01:00.0: wmi disable pktlog
>
> Any new leads on tracking down this issue?
>
> ~Benjamin
>
>
> On 12/06/2016 01:32 PM, Benjamin Morgan wrote:
>> 1. Yes, this appears to happens every time a unicast packet with
>> wpa_supplicant encryption in VHT80 mode is received. I haven't seen a
>> successful ping-pong pair.
>> 2. We tried with 10.2.4.70.42-2 firmware and still saw crashes.
>> 3. We ran our experiment again with extra debugging turned on.
>> Node A: 18:A6:F7:23:6E:66 | 10.230.5.41
>> Node B: 18:A6:F7:26:0F:21 | 10.230.5.42
>> The ping command we used was run on Node A was 'ping -s 1500 -i
>> 0.1 10.230.5.42'
>> Here is the dmesg log from Node B.
>>
>> [ 5413.478170] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5413.503954] ath10k_pci 0000:01:00.0: scan event bss channel type 4
>> reason 3 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running
>> (2)
>> [ 5413.503985] ath10k_pci 0000:01:00.0: chan info err_code 0 freq
>> 5825 cmd_flags 1 noise_floor -105 rx_clear_count 7692807 cycle_count
>> 312271423
>> [ 5413.504029] ath10k_pci 0000:01:00.0: scan event completed type 2
>> reason 0 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running
>> (2)
>> [ 5413.525868] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
>> cipher 4 len 16
>> [ 5413.526014] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
>> value 1
>> [ 5413.526193] ath10k_pci 0000:01:00.0: mac vdev 0 set keyidx 1
>> [ 5413.526216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
>> value 1
>> [ 5413.526532] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180
>> width 3 ptr 86db29b0
>> [ 5413.526556] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
>> needed? 0 allowed? 1
>> [ 5413.526574] ath10k_pci 0000:01:00.0: mac chanctx assign ptr
>> 86db29b0 vdev_id 0
>> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
>> 5180 phymode 11ac-vht80
>> [ 5413.526616] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 5413.533099] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 5413.533148] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
>> [ 5413.533163] ath10k_pci 0000:01:00.0: mac txpower 23
>> [ 5413.533180] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
>> [ 5413.533247] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
>> [ 5413.533295] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
>> width 3 ptr 86db29b0 changed 10
>> [ 5413.533318] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
>> width 3 ptr 86db29b0 changed 2
>> [ 5413.533337] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
>> needed? 1 allowed? 1
>> [ 5413.533357] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
>> subtype 0 macaddr 18:a6:f7:26:0f:21
>> [ 5413.533412] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
>> [ 5413.533463] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 5413.937652] ath10k_pci 0000:01:00.0: wmi event debug mesg len 152
>> [ 5413.978273] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5414.478363] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5414.527015] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 5414.527067] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc
>> id 0 bssid 18:a6:f7:26:0f:21
>> [ 5414.527121] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
>> [ 5414.527165] ath10k_pci 0000:01:00.0: mac monitor started
>> [ 5414.527216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
>> value 1000
>> [ 5414.527262] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
>> [ 5414.527278] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 5414.527294] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 5414.527314] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 5414.527330] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 5414.527457] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc
>> id 0 bssid 00:00:00:00:00:00
>> [ 5414.527501] ath10k_pci 0000:01:00.0: mac vdev 0 up
>> [ 5414.527564] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
>> [ 5414.541090] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
>> needed? 1 allowed? 1
>> [ 5414.978454] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5415.478548] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5415.978649] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5416.445280] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
>> needed? 1 allowed? 1
>> [ 5416.478761] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5416.978879] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5417.478985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5417.979081] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5418.479190] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5418.979301] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5419.479403] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5419.979551] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5420.479643] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5420.979746] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5421.479841] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5421.979940] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5422.480288] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5422.980386] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5423.480490] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5423.980600] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5424.480702] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5424.971969] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
>> 18:a6:f7:23:6e:66 (new sta) sta 1 / 128 peer 2 / 144
>> [ 5424.972000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
>> peer_addr 18:a6:f7:23:6e:66
>> [ 5424.975107] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 5424.975134] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 5424.975219] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 5424.975238] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 5424.980787] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5425.204468] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:23:6e:66
>> associated
>> [ 5425.204531] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:23:6e:66
>> mcs cnt 24 nss 3
>> [ 5425.204548] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 qos 1
>> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
>> phymode 11na-ht40
>> [ 5425.204585] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
>> 18:a6:f7:23:6e:66 (new)
>> [ 5425.204614] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
>> 0x18:a6:f7:23:6e:66 set param 1 value 0
>> [ 5425.205376] ath10k_pci 0000:01:00.0: received event id 36891 not
>> implemented
>> [ 5425.209240] ath10k_pci 0000:01:00.0: wmi vdev install key idx 0
>> cipher 4 len 16
>> [ 5425.209655] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
>> cipher 4 len 16
>> [ 5425.209848] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
>> value 1
>> [ 5425.210196] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 5425.210221] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 5425.210296] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 5425.210315] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 5425.480863] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5425.938619] ath10k_pci 0000:01:00.0: wmi event debug mesg len 100
>> [ 5425.980946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5425.995007] ath10k_pci 0000:01:00.0: mac sta rc update for
>> 18:a6:f7:23:6e:66 changed 00000001 bw 2 nss 3 smps 1
>> [ 5425.995060] ath10k_pci 0000:01:00.0: mac update sta
>> 18:a6:f7:23:6e:66 peer bw 2
>> [ 5425.995081] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
>> 0x18:a6:f7:23:6e:66 set param 4 value 2
>> [ 5426.481030] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5426.981117] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5427.481206] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5427.981294] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5428.481628] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5428.981718] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5429.481812] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5429.981894] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5430.481985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5430.982073] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5431.482174] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5431.982505] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5432.482597] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5432.982679] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5433.482765] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5433.982857] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5434.482946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5434.983008] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5435.483100] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5435.983181] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5436.483276] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5436.983366] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5437.483445] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5437.983516] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5438.483607] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5438.983692] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5439.439875] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
>> db76b67c-ca98-4519-a762-4ff4edb45526)
>> [ 5439.449007] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>> [ 5439.458378] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
>> tracing 0 dfs 1 testmode 1
>> [ 5439.471460] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
>> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
>> [ 5439.481844] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>> crc32 bebc7c08
>> [ 5439.489267] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
>> cal file max-sta 128 raw 0 hwcrypto 1
>> [ 5439.500918] ath10k_pci 0000:01:00.0: firmware register dump:
>> [ 5439.506678] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
>> 0x009A4577 0x00955B31
>> [ 5439.514706] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
>> 0x00000002 0x00439E98
>> [ 5439.522751] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
>> 0x00407120 0x004436CC
>> [ 5439.530794] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
>> 0x009A3518 0x009A3526
>> [ 5439.538834] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
>> 0x00000000 0x00000000
>> [ 5439.546871] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
>> 0x0040AC60 0x0040AC09
>> [ 5439.554915] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
>> 0x00400000 0xC09A4577
>> [ 5439.562948] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
>> 0x0044110C 0x00442074
>> [ 5439.570992] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
>> 0x0044110C 0x00407120
>> [ 5439.579032] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
>> 0x0040AC14 0x00001580
>> [ 5439.587070] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
>> 0x009C643C 0x004436CC
>> [ 5439.595113] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
>> 0x004208FC 0x00439E4C
>> [ 5439.603146] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
>> 0x004208FC 0x00425E00
>> [ 5439.611191] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
>> 0x00424FE8 0x00000002
>> [ 5439.619230] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
>> 0x00000004 0x004039D0
>> [ 5439.726818] ieee80211 phy0: Hardware restart was requested
>> [ 5439.732433] ath10k_pci 0000:01:00.0: wmi mgmt vdev down id 0x1
>> [ 5439.732461] ath10k_pci 0000:01:00.0: wmi vdev stop id 0x1
>> [ 5439.732482] ath10k_pci 0000:01:00.0: failed to synchronize monitor
>> vdev 1 stop: -143
>> [ 5439.740370] ath10k_pci 0000:01:00.0: mac monitor vdev 1 stopped
>> [ 5439.740386] ath10k_pci 0000:01:00.0: failed to stop monitor vdev:
>> -143
>> [ 5439.747042] ath10k_pci 0000:01:00.0: wmi disable pktlog
>>
>> We noticed in this log that when the radio starts up it says that it
>> is in VHT80 mode:
>> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
>> 5180 phymode 11ac-vht80
>>
>> But when a peer connects it seems to think the peer is in HT40 mode:
>> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
>> phymode 11na-ht40
>>
>> Compared to no encryption case - this log was taken from Node A:
>>
>> [ 24.874253] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180
>> width 3 ptr 86d26db0
>> [ 24.874278] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
>> needed? 0 allowed? 1
>> [ 24.874296] ath10k_pci 0000:01:00.0: mac chanctx assign ptr
>> 86d26db0 vdev_id 0
>> [ 24.874312] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
>> 5180 phymode 11ac-vht80
>> [ 24.874337] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 24.881335] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 24.881423] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
>> [ 24.881438] ath10k_pci 0000:01:00.0: mac txpower 23
>> [ 24.881454] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
>> [ 24.881491] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
>> [ 24.881515] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
>> width 3 ptr 86d26db0 changed 10
>> [ 24.881535] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
>> width 3 ptr 86d26db0 changed 2
>> [ 24.881554] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
>> needed? 1 allowed? 1
>> [ 24.881574] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
>> subtype 0 macaddr 18:a6:f7:23:6e:66
>> [ 24.881689] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
>> [ 24.881745] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 25.273460] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 25.730570] ath10k_pci 0000:01:00.0: wmi event debug mesg len 300
>> [ 25.773566] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 25.874556] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 25.879992] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc
>> id 0 bssid 18:a6:f7:23:6e:66
>> [ 25.880077] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
>> [ 25.880093] ath10k_pci 0000:01:00.0: mac monitor started
>> [ 25.880139] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
>> value 1000
>> [ 25.880184] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
>> [ 25.880199] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.880215] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.880235] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.880250] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.880988] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc
>> id 0 bssid 00:00:00:00:00:00
>> [ 25.881035] ath10k_pci 0000:01:00.0: mac vdev 0 up
>> [ 25.881097] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
>> [ 25.882968] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>> [ 25.928796] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.928821] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.928866] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.928883] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.929020] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
>> needed? 1 allowed? 1
>> [ 25.941886] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.941911] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.941955] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.941972] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.953727] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.953753] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.953798] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.953817] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.970588] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.970614] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.970659] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.970676] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.989056] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.989081] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.989126] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.989143] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 26.071686] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
>> 18:a6:f7:26:0f:21 (new sta) sta 1 / 128 peer 2 / 144
>> [ 26.071712] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
>> peer_addr 18:a6:f7:26:0f:21
>> [ 26.071952] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:26:0f:21
>> associated
>> [ 26.071981] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:26:0f:21
>> mcs cnt 24 nss 3
>> [ 26.071999] ath10k_pci 0000:01:00.0: mac vht peer
>> 18:a6:f7:26:0f:21 max_mpdu 1048575 flags 0x601b001
>> [ 26.072013] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 qos 1
>> [ 26.072028] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21
>> phymode 11ac-vht80
>> [ 26.072047] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
>> 18:a6:f7:26:0f:21 (new)
>> [ 26.072071] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
>> 0x18:a6:f7:26:0f:21 set param 1 value 0
>> [ 26.072502] ath10k_pci 0000:01:00.0: received event id 36891 not
>> implemented
>> [ 26.074194] ath10k_pci 0000:01:00.0: mac sta rc update for
>> 18:a6:f7:26:0f:21 changed 00000000 bw 2 nss 3 smps 1
>> [ 26.074586] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 26.074609] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 26.074682] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 26.074701] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 26.074760] ath10k_pci 0000:01:00.0: mac vdev 0 slot_time 2
>> [ 26.074779] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 7
>> value 2
>> [ 26.273652] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 26.730650] ath10k_pci 0000:01:00.0: wmi event debug mesg len 44
>> [ 26.773733] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 27.135445] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
>> needed? 1 allowed? 1
>> [ 27.273810] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>>
>> It seems to start up in VHT80 mode and when it peers with Node B it
>> thinks Node B is also in VHT80 mode and ping works.
>>
>> 4. Beacons are sent at 6 Mb/s basic rate and unicast QoS Data is sent
>> with three spatial streams. Attached is the full pcap of the experiment.
>>
>> Thank you for looking into this!
>>
>> ~Benjamin
>>
>> On 12/05/2016 11:24 AM, Nagarajan, Ashok Raj wrote:
>>> 0x009A4577 0x00955B31
>>>
>>> Benjamin, Thanks for the logs.
>>> Quick questions to further debug the issue here,
>>>
>>> 1. Is this issue seen every time you start sending data traffic?
>>> 2. Issue seen with older firmwares? (FYR,
>>> http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
>>> 3. Could you please share the dmesg from your device after enabling
>>> MAC and WMI logs in ath10k driver
>>> To enable debug logs please see
>>> http://linuxwireless.org/en/users/Drivers/ath10k/debug/
>>> 4. Do you know what is the Number of Spatial Streams seen in mesh
>>> beacons and in mesh data packet?
>>>
>>> Thanks,
>>> Ashok
>>
>
^ permalink raw reply
* RE: ath10k firmware crashes in mesh mode on QCA9880
From: Manoharan, Rajkumar @ 2016-12-13 23:51 UTC (permalink / raw)
To: Benjamin Morgan, Nagarajan, Ashok Raj, Mohammed Shafi Shajakhan
Cc: agreen@cococorp.com, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <5850831D.7020206@cococorp.com>
PiBUZXN0ZWQgdGhlIDEwLjIuNC43MC41OS0yIGZpcm13YXJlIGFuZCB3cGFfc3VwcGxpY2FudCBy
dW5uaW5nIFdJVEhPVVQNCj4gZW5jcnlwdGlvbiBhbmQgaXQgc3RpbGwgY3Jhc2hlcy4gSSBzdXNw
ZWN0IHRoaXMgbWVhbnMgd3BhX3N1cHBsaWNhbnQgaXMgc2V0dGluZyB1cA0KPiB0aGUgaW50ZXJm
YWNlIGluY29ycmVjdGx5IGFuZC9vciB0cmFuc21pdHRpbmcgYSBtYWxmb3JtZWQgcGFja2V0IHRo
YXQgaXMgY2F1c2luZw0KPiB0aGUgZHJpdmVyIHRvIGNyYXNoLg0KPiANCkJlbiwNCg0KSUlSQyBt
ZXNoIHN1cHBvcnQgd2FzIHZhbGlkYXRlZCBpbiBxY2E5ODh4IGluIFZIVCBtb2RlIHdoaWxlIGFn
by4gIEVpdGhlciBpdCBjb3VsZA0KYmUgcmVncmVzc2lvbiBpbiBkcml2ZXIvZncgb3IgbGVkZSBt
YWM4MDIxMSBwYWNrYWdlLg0KDQoxKSBDb3VsZCB5b3UgcGxlYXNlIHRyeSBwbGFpbiBiYWNrcG9y
dHMgaW4gbGVkZSB3L28gYXBwbHlpbmcgYXRoMTBrIHBhdGNoZXMuDQogICAgIEkgZG8gc2VlIDE2
ME1IeiBzdXBwb3J0IGluIExFREUuDQoyKSBUaGVyZSBhcmUgc29tZSBwZWVyIHN0YXRzIGR1bXAg
ZnJvbSB5b3VyIGVhcmxpZXIgbG9nLiBEaXNhYmxlIHBlZXIgc3RhdHMgDQogICAgIGJ5ICJwZWVy
X3N0YXRzIiBkZWJ1Z2ZzLg0KMykgUGxlYXNlIGNvbmZpcm0gdGhlIGJlaGF2aW9yIHdpdGggb2xk
ZXIgZmlybXdhcmUgcmV2aXNpb25zLg0KNCkgdXNlIGl3IHRvIGJyaW5nIHVwIG9wZW4gbWVzaCB0
byBydWxlIG91dCB3cGFfcyBjb25maWcNCg0KLVJhamt1bWFyDQoNCg==
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Alexis Green @ 2016-12-14 5:36 UTC (permalink / raw)
To: Manoharan, Rajkumar
Cc: Benjamin Morgan, Nagarajan, Ashok Raj, Mohammed Shafi Shajakhan,
lede-dev@lists.infradead.org, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <ccf17009a52748c99accdaa005ea837a@NALASEXR01H.na.qualcomm.com>
Thank you for your help Rajkumar,
We've traced the problem down to a peering issue. Looks like there was
a missing compile flag that caused some kind of incongruence. My best
guest is that beacons are generated by firmware and advertise support
for AC mode, whereas wpa_supplicant, when not compiled with
CONFIG_IEEE80211AC=y, sends mesh peering messages and creates peers
without AC support, causing firmware to get confused. After
recompiling supplicant with the correct flag, no more crashes were
observed in casual testing. I submitted a pull request to LEDE to,
hopefully, fix it in upstream.
Best regards,
Alexis
On Tue, Dec 13, 2016 at 3:51 PM, Manoharan, Rajkumar
<rmanohar@qca.qualcomm.com> wrote:
>> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT
>> encryption and it still crashes. I suspect this means wpa_supplicant is setting up
>> the interface incorrectly and/or transmitting a malformed packet that is causing
>> the driver to crash.
>>
> Ben,
>
> IIRC mesh support was validated in qca988x in VHT mode while ago. Either it could
> be regression in driver/fw or lede mac80211 package.
>
> 1) Could you please try plain backports in lede w/o applying ath10k patches.
> I do see 160MHz support in LEDE.
> 2) There are some peer stats dump from your earlier log. Disable peer stats
> by "peer_stats" debugfs.
> 3) Please confirm the behavior with older firmware revisions.
> 4) use iw to bring up open mesh to rule out wpa_s config
>
> -Rajkumar
>
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Alexis Green @ 2016-12-14 6:06 UTC (permalink / raw)
To: Adrian Chadd
Cc: Manoharan, Rajkumar, Benjamin Morgan, Nagarajan, Ashok Raj,
Mohammed Shafi Shajakhan, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAJ-Vmo=iLryhOS--PPYCGa9pE2GovPDOXi6xoH22xFOYXXKNVA@mail.gmail.com>
Hi Adrian,
I have not done much testing of ath10k and ath9k devices in a single
encrypted mesh recently, but I have a memory of only having this issue
when communicating between ath10k devices.
Alexis
On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi!
>
> Hm! So is there a firmware bug if there are 11n only capable nodes in
> an 11s mesh?
>
>
>
> -adrian
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Adrian Chadd @ 2016-12-14 5:53 UTC (permalink / raw)
To: Alexis Green
Cc: Manoharan, Rajkumar, Benjamin Morgan, Nagarajan, Ashok Raj,
Mohammed Shafi Shajakhan, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAAnMG+OmeataRKYRjOjtBXF_1-De-F4zWbUsWoYRhVu02NPrrw@mail.gmail.com>
Hi!
Hm! So is there a firmware bug if there are 11n only capable nodes in
an 11s mesh?
-adrian
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Adrian Chadd @ 2016-12-14 6:17 UTC (permalink / raw)
To: Alexis Green
Cc: Manoharan, Rajkumar, Benjamin Morgan, Nagarajan, Ashok Raj,
Mohammed Shafi Shajakhan, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAAnMG+MY=LhfJxxUVdfRNYUW-2R+EXdLm2o6yDcCH0T1brRVxw@mail.gmail.com>
Hi!
ok, thanks! I've seen some .. annoying rate control related firmware
crashes if you aren't using 11ac / 11n rates (ie you're /really/
legacy, so I wondered if something similar is going on here.
Thanks!
-a
On 13 December 2016 at 22:06, Alexis Green <agreen@cococorp.com> wrote:
> Hi Adrian,
>
> I have not done much testing of ath10k and ath9k devices in a single
> encrypted mesh recently, but I have a memory of only having this issue
> when communicating between ath10k devices.
>
> Alexis
>
> On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>> Hi!
>>
>> Hm! So is there a firmware bug if there are 11n only capable nodes in
>> an 11s mesh?
>>
>>
>>
>> -adrian
^ permalink raw reply
* Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements
From: Adrian Chadd @ 2016-12-14 6:45 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Valo, Kalle, ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, devicetree@vger.kernel.org,
arnd@arndb.de, chunkeey@googlemail.com, nbd@nbd.name
In-Reply-To: <CAFBinCC6JWBhZwma=66fBi3_to2SaHOMNDQS23jHNhcc+RUcYQ@mail.gmail.com>
hi,
On 12 December 2016 at 12:05, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> It seems that there are a few devices out there where the whole EEPROM
> is swab16'ed which switches the position of the 1-byte fields
> opCapFlags and eepMisc.
> those still work fine with the new code, however I had a second patch
> in LEDE [0] which results in ath9k_platform_data.endian_check NOT
> being set anymore.
> that endian_check flag was used before to swab16 the whole EEPROM, to
> correct the position of the 1-byte fields again.
> Currently we are fixing this in the firmware hotplug script: [1]
> This is definitely not a blocker for this series though (if we want to
> have a devicetree replacement for "ath9k_platform_data.endian_check"
> then I'd work on that within a separate series, but I somewhat
> consider these EEPROMs as "broken" so fixing them in
> userspace/firmware hotplug script is fine for me)
As a reference - the reference driver has been doign this for a while.
It attempts to detect the endianness by looking at the 0xa55a
signature endian and figuring out which endian the actual contents are
in.
So just FYI yeah, this is a "thing" for reasons I don't quite know.
-adrian
>
>
> Regards,
> Martin
>
>
> [0] https://git.lede-project.org/?p=source.git;a=commitdiff;h=a20616863d32d91163043b6657a63c836bd9c5ba
> [1] https://git.lede-project.org/?p=source.git;a=commitdiff;h=afa37092663d00aa0abf8c61943d9a1b5558b144
^ permalink raw reply
* RE: ATH9 driver issues on ARM64
From: Bharat Kumar Gogada @ 2016-12-14 5:09 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tobias Klausmann, Kalle Valo, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, rmanohar@qti.qualcomm.com,
ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org
In-Reply-To: <20161212163114.GA32712@bhelgaas-glaptop.roam.corp.google.com>
> On Sat, Dec 10, 2016 at 02:40:48PM +0000, Bharat Kumar Gogada wrote:
> > Hi,
> >
> > After taking some more lecroy traces, we see that after 2nd ASSERT from=
EP
> on ARM64 we see continuous data movement of 32 dwords or 12 dwords and
> never sign of DEASSERT.
> > Comparatively on working traces (x86) after 2nd assert there are only B=
AR
> register reads and writes and then DEASSERT, for almost most of the inter=
rupts
> and we haven't seen 12 or 32 dwords data movement on this trace.
> >
> > I did not work on EP wifi/network drivers, any help why EP needs those =
many
> number of data at scan time ?
>=20
> The device doesn't know whether it's in an x86 or an arm64 system. If it=
works
> differently, it must be because the PCI core or the driver is programming=
the
> device differently.
>=20
> You should be able to match up Memory transactions from the host in the t=
race
> with things the driver does. For example, if you see an Assert_INTx mess=
age
> from the device, you should eventually see a Memory Read from the host to=
get
> the ISR, i.e., some read done in the bowels of ath9k_hw_getisr().
>=20
> I don't know how the ath9k device works, but there must be some Memory Re=
ad
> or Write done by the driver that tells the device "we've handled this int=
errupt".
> The device should then send a Deassert_INTx; of course, if the device sti=
ll
> requires service, e.g., because it has received more packets, it might le=
ave the
> INTx asserted.
>=20
> I doubt you'd see exactly the same traces on x86 and arm64 because they a=
ren't
> seeing the same network packets and the driver is executing at different =
rates.
> But you should at least be able to identify interrupt assertion and the a=
ctions of
> the driver's interrupt service routine.
Thanks Bjorn.
As you mentioned we did try to debug in that path. After we start scan afte=
r 2nd ASSERT we see lots of 32 and 12 dword
data, and in function
void ath9k_hw_enable_interrupts(struct ath_hw *ah)=20
{
...
..
REG_WRITE(ah, AR_IER, AR_IER_ENABLE);
// EP driver hangs at this position after 2nd ASSERT
// The following writes are not happening
if (!AR_SREV_9100(ah)) { =09
REG_WRITE(ah, AR_INTR_ASYNC_ENABLE, async_mask);
REG_WRITE(ah, AR_INTR_ASYNC_MASK, async_mask);
REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
REG_WRITE(ah, AR_INTR_SYNC_MASK, sync_default);
} =20
ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER));
}
The above funtion is invoked from tasklet.
I tried several boots every it stops here. The condition (!AR_SREV_9100(ah)=
) is true as per before 1st ASSERT handling.
Regards,
Bharat
>=20
> > > Hello there,
> > >
> > > as this is a thread about ath9k and ARM64, i'm not sure if i should
> > > answer here or not, but i have similar "stalls" with ath9k on x86_64
> > > (starting with 4.9rc), stack trace is posted down below where the ori=
ginal
> ARM64 stall traces are.
> > >
> > > Greetings,
> > >
> > > Tobias
> > >
> > >
> > > On 08.12.2016 18:36, Kalle Valo wrote:
> > > > Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> writes:
> > > >
> > > >> > [+cc Kalle, ath9k list]
> > > > Thanks, but please also CC linux-wireless. Full thread below for
> > > > the folks there.
> > > >
> > > >>> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada
> wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> Did anyone test Atheros ATH9
> > > >>>> driver(drivers/net/wireless/ath/ath9k/)
> > > >>>> on ARM64. The end point is TP link wifi card with which
> > > >>>> supports only legacy interrupts.
> > > >>> If it works on other arches and the arm64 PCI enumeration works,
> > > >>> my first guess would be an INTx issue, e.g., maybe the driver is
> > > >>> waiting for an interrupt that never arrives.
> > > >> We are not sure for now.
> > > >>>> We are trying to test it on ARM64 with
> > > >>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> > > >>>>
> > > >>>> EP is getting enumerated and able to link up.
> > > >>>>
> > > >>>> But when we start scan system gets hanged.
> > > >>> When you say the system hangs when you start a scan, I assume
> > > >>> you mean a wifi scan, not the PCI enumeration. A problem with a
> > > >>> wifi scan might cause a *process* to hang, but it shouldn't hang
> > > >>> the entire system.
> > > >>>
> > > >> Yes wifi scan.
> > > >>>> When we took trace we see that after we start scan assert
> > > >>>> message is sent but there is no de assert from end point.
> > > >>> Are you talking about a trace from a PCIe analyzer? Do you see
> > > >>> an Assert_INTx PCIe message on the link?
> > > >>>
> > > >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx
> > > >> happening
> > > when we do interface link up.
> > > >> When we have less debug prints in Atheros driver, and do wifi
> > > >> scan we see Assert_INTx but never Deassert_INTx,
> > > >>>> What might cause end point not sending de assert ?
> > > >>> If the endpoint doesn't send a Deassert_INTx message, I expect
> > > >>> that would mean the driver didn't service the interrupt and
> > > >>> remove the condition that caused the device to assert the
> > > >>> interrupt in the first place.
> > > >>>
> > > >>> If the driver didn't receive the interrupt, it couldn't service
> > > >>> it, of course. You could add a printk in the ath9k interrupt
> > > >>> service routine to see if you ever get there.
> > > >>>
> > > >> The interrupt behavior is changing w.r.t amount of debug prints
> > > >> we add. (I kept many prints to aid debug)
> > > >> root@Xilinx-ZCU102-2016_3:~# iw dev
> > > wlan0 scan
> > > >> [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.074257] ath9k_hw_kill_interrupts 793
> > > >> [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.087882] ath9k_hw_kill_interrupts 793
> > > >> [ 83.095450] ath9k_hw_enable_interrupts 821
> > > >> [ 83.099557] ath9k_hw_enable_interrupts 825
> > > >> [ 83.103721] ath9k_hw_enable_interrupts 832
> > > >> [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.112748] AR_SREV_9100 0
> > > >> [ 83.115438] ath9k_hw_enable_interrupts 848
> > > >> [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.124389] ath9k_hw_intrpend 762
> > > >> [ 83.127761] (AR_SREV_9340(ah) val 0
> > > >> [ 83.131234] ath9k_hw_intrpend 767
> > > >> [ 83.134628] ath_isr 603
> > > >> [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.146771] ath9k_hw_kill_interrupts 793
> > > >> [ 83.150864] ath9k_hw_enable_interrupts 821
> > > >> [ 83.154971] ath9k_hw_enable_interrupts 825
> > > >> [ 83.159135] ath9k_hw_enable_interrupts 832
> > > >> [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.168161] AR_SREV_9100 0
> > > >> [ 83.170852] ath9k_hw_enable_interrupts 848
> > > >> [ 83.170855] ath9k_hw_intrpend 762
> > > >> [ 83.178398] (AR_SREV_9340(ah) val 0
> > > >> [ 83.181873] ath9k_hw_intrpend 767
> > > >> [ 83.185265] ath_isr 603
> > > >> [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.197411] ath9k_hw_kill_interrupts 793
> > > >> [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.206258] ath9k_hw_enable_interrupts 821
> > > >> [ 83.210368] ath9k_hw_enable_interrupts 825
> > > >> [ 83.214531] ath9k_hw_enable_interrupts 832
> > > >> [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.223558] AR_SREV_9100 0
> > > >> [ 83.226243] ath9k_hw_enable_interrupts 848
> > > >> [ 83.226246] ath9k_hw_intrpend 762
> > > >> [ 83.233794] (AR_SREV_9340(ah) val 0
> > > >> [ 83.237268] ath9k_hw_intrpend 767
> > > >> [ 83.240661] ath_isr 603
> > > >> [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.252806] ath9k_hw_kill_interrupts 793
> > > >> [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.261651] ath9k_hw_enable_interrupts 821
> > > >> [ 83.265753] ath9k_hw_enable_interrupts 825
> > > >> [ 83.269919] ath9k_hw_enable_interrupts 832
> > > >> [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.278945] AR_SREV_9100 0
> > > >> [ 83.281630] ath9k_hw_enable_interrupts 848
> > > >> [ 83.281633] ath9k_hw_intrpend 762
> > > >> [ 83.281634] (AR_SREV_9340(ah) val 0
> > > >> [ 83.281637] ath9k_hw_intrpend 767
> > > >> [ 83.281648] ath_isr 603
> > > >> [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.281654] ath9k_hw_kill_interrupts 793
> > > >> [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.317030] ath9k_hw_enable_interrupts 821
> > > >> [ 83.321132] ath9k_hw_enable_interrupts 825
> > > >> [ 83.325297] ath9k_hw_enable_interrupts 832
> > > >> [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.334324] AR_SREV_9100 0
> > > >> [ 83.337014] ath9k_hw_enable_interrupts 848
> > > >> ..
> > > >> ..
> > > >> This log continues until I turn off board without obtaining scanni=
ng result.
> > > >>
> > > >> In between I get following cpu stall outputs :
> > > >> 230.457179] INFO: rcu_sched self-detected stall on CPU
> > > >> [ 230.457185] 2-...: (31314 ticks this GP)
> > > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D36713
> > > >> [ 230.457189] (t=3D36756 jiffies g=3D161 c=3D160 q=3D16169)
> > > >> [ 230.457191] Task dump for CPU 2:
> > > >> [ 230.457196] kworker/u8:4 R running task 0 1342 =
2
> 0x00000002
> > > >> [ 230.457207] Workqueue: phy0 ieee80211_scan_work [ 230.457208]
> > > >> Call trace:
> > > >> [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198 [
> > > >> 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20 [
> > > >> 230.457224] [<ffffff80080c0930>] sched_show_task+0x98/0xf8 [
> > > >> 230.457228] [<ffffff80080c2628>] dump_cpu_task+0x40/0x50 [
> > > >> 230.457233] [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0 [
> > > >> 230.457239] [<ffffff80080e4cd8>] rcu_check_callbacks+0x468/0x748
> > > >> [ 230.457243] [<ffffff80080e7cfc>]
> > > >> update_process_times+0x3c/0x68 [ 230.457249]
> > > >> [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
> > > >> [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90 [
> > > >> 230.457257] [<ffffff80080e86b0>] __hrtimer_run_queues+0xf0/0x178
> > > >> ** 10 printk messages dropped ** [ 230.457302] f8c0:
> > > >> 0000000000000000 0000000005f5e0ff 000000000001379a
> > > 3866666666666620 [
> > > >> 230.457306] f8e0: ffffff800a1b4065 0000000000000006
> > > >> ffffff800a129000
> > > >> ffffffc87b8010a8 [ 230.457310] f900: ffffff808a1b4057
> > > >> ffffff800a1c3000 ffffff800a1b3000 ffffff800a13b000 [ 230.457314]
> > > >> f920: 0000000000000140 0000000000000006 ffffff800a1b3b10
> > > >> ffffff800a1c39e8 [ 230.457318] f940: 000000000000002f
> > > >> ffffff800a1b8a98 ffffff800a1b3ae8 ffffffc87b07f990 [ 230.457322]
> > > >> f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d6234
> > > >> 0000000060000145
> > > >> ** 1 printk messages dropped ** [ 230.457329]
> > > >> [<ffffff8008085720>]
> > > >> el1_irq+0xa0/0x100
> > > >> ** 9 printk messages dropped ** [ 230.457373]
> > > >> [<ffffff800885ad60>]
> > > >> ieee80211_hw_config+0x50/0x290 [ 230.457377]
> > > >> [<ffffff8008863690>]
> > > >> ieee80211_scan_work+0x1f8/0x480 [ 230.457383]
> > > >> [<ffffff80080b15d0>]
> > > >> process_one_work+0x120/0x378 [ 230.457386] [<ffffff80080b1870>]
> > > >> worker_thread+0x48/0x4b0 [ 230.457391] [<ffffff80080b7108>]
> > > >> kthread+0xd0/0xe8 [ 230.457395] [<ffffff8008085dd0>]
> > > ret_from_fork+0x10/0x40
> > > >> [ 230.480389] ath9k_hw_intrpend 762
> > > >>
> > > >>
> > > >> [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024 [
> > > >> 545.526189]
> > > >> INFO: rcu_sched self-detected stall on CPU
> > > >> [ 545.526195] 2-...: (97636 ticks this GP)
> > > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D115374
> > > >> [ 545.526199] (t=3D115523 jiffies g=3D161 c=3D160 q=3D51066)
> > > >> [ 545.526201] Task dump for CPU 2:
> > > >> [ 545.526206] kworker/u8:4 R running task 0 1342 =
2
> 0x00000002
> > > >> ** 3 printk messages dropped ** [ 545.526231]
> > > >> [<ffffff8008089a0c>]
> > > >> show_stack+0x14/0x20
> > > >> ** 9 printk messages dropped ** [ 545.526280]
> > > >> [<ffffff80086a71e8>]
> > > >> arch_timer_handler_phys+0x30/0x40 [ 545.526284]
> > > >> [<ffffff80080dbe18>]
> > > >> handle_percpu_devid_irq+0x78/0xa0 [ 545.526291]
> > > >> [<ffffff80080d760c>]
> > > >> generic_handle_irq+0x24/0x38 [ 545.526296] [<ffffff80080d7944>]
> > > >> __handle_domain_irq+0x5c/0xb8 [ 545.526299] [<ffffff80080824bc>]
> > > >> gic_handle_irq+0x64/0xc0 [ 545.526302] Exception
> > > >> stack(0xffffffc87b07f870
> > > to 0xffffffc87b07f990)
> > > >> [ 545.526306] f860: 00000000000=
09732
> ffffff800a1eaaa8
> > > >> ** 8 printk messages dropped ** [ 545.526341] f980:
> > > >> ffffff800a1c39e8
> > > >> 0000000000000036 [ 545.526345] [<ffffff8008085720>]
> > > >> el1_irq+0xa0/0x100 [ 545.526349] [<ffffff80080d6234>]
> > > >> console_unlock+0x384/0x5b0 [ 545.526353] [<ffffff80080d673c>]
> > > >> vprintk_emit+0x2dc/0x4b0 [ 545.526357] [<ffffff80080d6a50>]
> > > >> vprintk_default+0x38/0x40 [ 545.526362] [<ffffff8008129704>]
> > > >> printk+0x58/0x60 [ 545.526366] [<ffffff800859e3e4>]
> > > >> ath9k_iowrite32+0x9c/0xa8 [ 545.526372] [<ffffff80085c7ca8>]
> > > >> ath9k_hw_kill_interrupts+0x28/0xf0
> > > >> [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
> > > >> ** 2 printk messages dropped ** [ 545.526391]
> > > >> [<ffffff800885ad60>]
> > > ieee80211_hw_config+0x50/0x290
> > > >> ** 11 printk messages dropped ** [ 545.532834]
> > > >> ath9k_hw_kill_interrupts
> > > 793
> > > >> [ 545.532890] ath9k_hw_enable_interrupts 821
> > >
> > > [ 81.876902] INFO: rcu_preempt detected stalls on CPUs/tasks:
> > > [ 81.876912] Tasks blocked on level-0 rcu_node (CPUs 0-7): P0
> > > [ 81.876932] (detected by 4, t=3D60002 jiffies, g=3D1873, c=3D1=
872, q=3D4967)
> > > [ 81.876936] swapper/4 R running task 0 0 1
> > > 0x00000000
> > > [ 81.876941] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> > > ffffffff81a3dc40
> > > [ 81.876945] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> > > ffffffff81a3dc40
> > > [ 81.876948] 00000000ffffffff ffffffff810a7333 ffff88017ecee698
> > > ffff88017edbc240
> > > [ 81.876951] Call Trace:
> > > [ 81.876970] <IRQ>
> > > [ 81.876979] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> > > [ 81.876983] [<ffffffff81101e46>] ?
> > > rcu_print_detail_task_stall_rnp+0x40/0x61
> > > [ 81.876989] [<ffffffff810a7333>] ? rcu_check_callbacks+0x6b3/0x8c=
0
> > > [ 81.876993] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40=
/0x40
> > > [ 81.876996] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
> > > [ 81.876999] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> > > [ 81.877002] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x15=
0
> > > [ 81.877004] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> > > [ 81.877008] [<ffffffff81031b1e>] ?
> > > smp_trace_apic_timer_interrupt+0x5e/0x90
> > > [ 81.877012] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
> > > [ 81.877013] <EOI>
> > > [ 81.877017] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f=
0
> > > [ 81.877019] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f=
0
> > > [ 81.877021] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
> > > [ 81.877027] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> > > [ 81.877029] swapper/4 R running task 0 0 1
> > > 0x00000000
> > > [ 81.877032] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> > > ffffffff81a3dc40
> > > [ 81.877035] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> > > ffffffff81a3dc40
> > > [ 81.877038] 00000000ffffffff ffffffff810a7368 ffff88017ecee698
> > > ffff88017edbc240
> > > [ 81.877041] Call Trace:
> > > [ 81.877045] <IRQ>
> > > [ 81.877049] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> > > [ 81.877051] [<ffffffff81101e46>] ?
> > > rcu_print_detail_task_stall_rnp+0x40/0x61
> > > [ 81.877055] [<ffffffff810a7368>] ? rcu_check_callbacks+0x6e8/0x8c=
0
> > > [ 81.877058] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40=
/0x40
> > > [ 81.877060] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
> > > [ 81.877063] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> > > [ 81.877065] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x15=
0
> > > [ 81.877068] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> > > [ 81.877070] [<ffffffff81031b1e>] ?
> > > smp_trace_apic_timer_interrupt+0x5e/0x90
> > > [ 81.877073] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
> > > [ 81.877074] <EOI>
> > > [ 81.877076] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f=
0
> > > [ 81.877078] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f=
0
> > > [ 81.877080] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
> > > [ 81.877084] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> > > [ 91.132787] INFO: rcu_preempt detected expedited stalls on
> > > CPUs/tasks: { P0 } 63785 jiffies s: 505 root: 0x0/T
> > > [ 91.132796] blocking rcu_node structures:
> > >
> > > >>
> > > >>
> > > >> But if we have less debug prints it does not reach EP handler
> > > >> sometimes, due to following Condition in "kernel/irq/chip.c" in
> > > >> function handle_simple_irq
> > > >>
> > > >> if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data)))=
{
> > > >> desc->istate |=3D IRQS_PENDING;
> > > >> goto out_unlock;
> > > >> }
> > > >> Here irqd_irq_disabled is being set to 1.
> > > >>
> > > >> With lesser debug prints it stops after following prints:
> > > >> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> > > >> [ 54.781045] ath9k_hw_kill_interrupts 793
> > > >> [ 54.785007] ath9k_hw_kill_interrupts 793
> > > >> [ 54.792535] ath9k_hw_enable_interrupts 821
> > > >> [ 54.796642] ath9k_hw_enable_interrupts 825
> > > >> [ 54.800807] ath9k_hw_enable_interrupts 832
> > > >> [ 54.804973] AR_SREV_9100 0
> > > >> [ 54.807663] ath9k_hw_enable_interrupts 848
> > > >> [ 54.811843] ath9k_hw_intrpend 762
> > > >> [ 54.815211] (AR_SREV_9340(ah) val 0
> > > >> [ 54.818684] ath9k_hw_intrpend 767
> > > >> [ 54.822078] ath_isr 603
> > > >> [ 54.824587] ath9k_hw_kill_interrupts 793
> > > >> [ 54.828601] ath9k_hw_enable_interrupts 821
> > > >> [ 54.832750] ath9k_hw_enable_interrupts 825
> > > >> [ 54.836916] ath9k_hw_enable_interrupts 832
> > > >> [ 54.841082] AR_SREV_9100 0
> > > >> [ 54.843772] ath9k_hw_enable_interrupts 848
> > > >> [ 54.843775] ath9k_hw_intrpend 762
> > > >> [ 54.851319] (AR_SREV_9340(ah) val 0
> > > >> [ 54.854793] ath9k_hw_intrpend 767
> > > >> [ 54.858185] ath_isr 603
> > > >> [ 54.860696] ath9k_hw_kill_interrupts 793
> > > >> [ 54.864776] ath9k_hw_enable_interrupts 821
> > > >> [ 54.867061] ath9k_hw_kill_interrupts 793
> > > >> [ 54.872870] ath9k_hw_enable_interrupts 825
> > > >> [ 54.877036] ath9k_hw_enable_interrupts 832
> > > >> [ 54.881202] AR_SREV_9100 0
> > > >> [ 54.883892] ath9k_hw_enable_interrupts 848
> > > >> [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > >> [ 75.968602] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> > > softirq=3D1103/1109 fqs=3D519
> > > >> [ 75.976675] (detected by 2, t=3D5274 jiffies, g=3D64, c=3D63, =
q=3D11)
> > > >> [ 75.982485] Task dump for CPU 0:
> > > >> [ 75.985696] ksoftirqd/0 R running task 0 3 =
2 0x00000002
> > > >> [ 75.992726] Call trace:
> > > >> [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> > > >> [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
> > > >> [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > >> [ 139.064430] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> > > softirq=3D1103/1109 fqs=3D2097
> > > >> [ 139.072593] (detected by 2, t=3D21049 jiffies, g=3D64, c=3D63,=
q=3D11)
> > > >> [ 139.078489] Task dump for CPU 0:
> > > >> [ 139.081700] ksoftirqd/0 R running task 0 3 =
2 0x00000002
> > > >> [ 139.088731] Call trace:
> > > >> [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0 [
> > > >> 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
> > > >>
> > > >>
> > > >>>> We are not seeing any issues on 32-bit ARM platform and X86
> > > >>>> platform.
> > > >>> Can you collect a dmesg log (or, if the system hang means you
> > > >>> can't collect that, a console log with "ignore_loglevel"), and "l=
spci -vv"
> > > >>> output as root? That should have clues about whether the INTx
> > > >>> got routed correctly. /proc/interrupts should also show whether
> > > >>> we're receiving interrupts from the device.
> > > >> Here is the lspci output:
> > > >> 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00
> > > >> [Normal
> > > decode])
> > > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> > > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > >> Latency: 0
> > > >> Interrupt: pin A routed to IRQ 224
> > > >> Bus: primary=3D00, secondary=3D01, subordinate=3D0c, sec-latency=
=3D0
> > > >> I/O behind bridge: 00000000-00000fff
> > > >> Memory behind bridge: e0000000-e00fffff
> > > >> Prefetchable memory behind bridge: 00000000fff00000-
> > > 00000000000fffff
> > > >> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> > > <TAbort- <MAbort- <SERR- <PERR-
> > > >> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> > > >> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> > > >> Capabilities: [40] Power Management version 3
> > > >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA
> > > PME(D0+,D1+,D2+,D3hot+,D3cold-)
> > > >> Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
> > > >> Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
> > > >> DevCap: MaxPayload 256 bytes, PhantFunc 0
> > > >> ExtTag- RBE+
> > > >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > > Unsupported-
> > > >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> > > >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> > > TransPend+
> > > >> LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not supported,
> > > Exit Latency L0s unlimited, L1 unlimited
> > > >> ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
> > > >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> > > >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > > >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > > DLActive- BWMgmt- ABWMgmt-
> > > >> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-
> > > CRSVisible+
> > > >> RootCap: CRSVisible+
> > > >> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> > > >> DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR-,
> > > OBFF Not Supported ARIFwd-
> > > >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> > > OBFF Disabled ARIFwd-
> > > >> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> > > >> Transmit Margin: Normal Operating Range,
> > > EnterModifiedCompliance- ComplianceSOS-
> > > >> Compliance De-emphasis: -6dB
> > > >> LnkSta2: Current De-emphasis Level: -3.5dB,
> > > EqualizationComplete-, EqualizationPhase1-
> > > >> EqualizationPhase2-, EqualizationPhase3-,
> > > LinkEqualizationRequest-
> > > >> Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-=
00
> > > >> Capabilities: [10c v1] Virtual Channel
> > > >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> > > >> Ctrl: ArbSelect=3DFixed
> > > >> Status: InProgress-
> > > >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> > > >> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> > > WRR256-
> > > >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > >> Status: NegoPending- InProgress-
> > > >> Capabilities: [128 v1] Vendor Specific Information: ID=3D1234
> > > >> Rev=3D1
> > > >> Len=3D018 <?>
> > > >>
> > > >> 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless
> > > >> Network
> > > Adapter (rev 01)
> > > >> Subsystem: Qualcomm Atheros Device 3112
> > > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> > > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > >> Latency: 0, Cache Line Size: 128 bytes
> > > >> Interrupt: pin A routed to IRQ 224
> > > >> Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=3D1=
28K]
> > > >> [virtual] Expansion ROM at e0020000 [disabled] [size=3D64K]
> > > >> Capabilities: [40] Power Management version 3
> > > >> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA
> > > PME(D0+,D1+,D2-,D3hot+,D3cold-)
> > > >> Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-
> > > >> Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
> > > >> Address: 0000000000000000 Data: 0000
> > > >> Masking: 00000000 Pending: 00000000
> > > >> Capabilities: [70] Express (v2) Endpoint, MSI 00
> > > >> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency
> > > L0s <1us, L1 <8us
> > > >> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> > > SlotPowerLimit 0.000W
> > > >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > > Unsupported-
> > > >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> > > >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> > > TransPend-
> > > >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit
> > > Latency L0s <2us, L1 <64us
> > > >> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> > > >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> > > >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > > >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > > DLActive- BWMgmt- ABWMgmt-
> > > >> DevCap2: Completion Timeout: Not Supported, TimeoutDis+,
> > > LTR-, OBFF Not Supported
> > > >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> > > OBFF Disabled
> > > >> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> > > SpeedDis-
> > > >> Transmit Margin: Normal Operating Range,
> > > EnterModifiedCompliance- ComplianceSOS-
> > > >> Compliance De-emphasis: -6dB
> > > >> LnkSta2: Current De-emphasis Level: -6dB,
> > > EqualizationComplete-, EqualizationPhase1-
> > > >> EqualizationPhase2-, EqualizationPhase3-,
> > > LinkEqualizationRequest-
> > > >> Capabilities: [100 v1] Advanced Error Reporting
> > > >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > >> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> > > RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> > > >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > > NonFatalErr-
> > > >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > > NonFatalErr+
> > > >> AERCap: First Error Pointer: 00, GenCap- CGenEn-
> > > ChkCap- ChkEn-
> > > >> Capabilities: [140 v1] Virtual Channel
> > > >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> > > >> Ctrl: ArbSelect=3DFixed
> > > >> Status: InProgress-
> > > >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> > > >> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> > > WRR256-
> > > >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > >> Status: NegoPending- InProgress-
> > > >> Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-=
00
> > > >> Kernel driver in use: ath9k
> > > >>
> > > >> Here is the cat /proc/interrupts (after we do interface up):
> > > >>
> > > >> root@:~# ifconfig wlan0 up
> > > >> [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not
> > > >> ready root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
> > > >> CPU0 CPU1 CPU2 CPU3
> > > >> 1: 0 0 0 0 GICv2 29 Ed=
ge arch_timer
> > > >> 2: 19873 20058 19089 17435 GICv2 30 Ed=
ge arch_timer
> > > >> 12: 0 0 0 0 GICv2 156 Le=
vel zynqmp-dma
> > > >> 13: 0 0 0 0 GICv2 157 Le=
vel zynqmp-dma
> > > >> 14: 0 0 0 0 GICv2 158 Le=
vel zynqmp-dma
> > > >> 15: 0 0 0 0 GICv2 159 Le=
vel zynqmp-dma
> > > >> 16: 0 0 0 0 GICv2 160 Le=
vel zynqmp-dma
> > > >> 17: 0 0 0 0 GICv2 161 Le=
vel zynqmp-dma
> > > >> 18: 0 0 0 0 GICv2 162 Le=
vel zynqmp-dma
> > > >> 19: 0 0 0 0 GICv2 163 Le=
vel zynqmp-dma
> > > >> 20: 0 0 0 0 GICv2 164 Le=
vel Mali_GP_MMU,
> > > Mali_GP, Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
> > > >> 30: 0 0 0 0 GICv2 95 Le=
vel eth0, eth0
> > > >> 206: 314 0 0 0 GICv2 49 Lev=
el cdns-i2c
> > > >> 207: 40 0 0 0 GICv2 50 Lev=
el cdns-i2c
> > > >> 209: 0 0 0 0 GICv2 150 Lev=
el nwl_pcie:misc
> > > >> 214: 12 0 0 0 GICv2 47 Lev=
el ff0f0000.spi
> > > >> 215: 0 0 0 0 GICv2 58 Lev=
el ffa60000.rtc
> > > >> 216: 0 0 0 0 GICv2 59 Lev=
el ffa60000.rtc
> > > >> 217: 0 0 0 0 GICv2 165 Lev=
el ahci-
> > > ceva[fd0c0000.ahci]
> > > >> 218: 61 0 0 0 GICv2 81 Lev=
el mmc0
> > > >> 219: 0 0 0 0 GICv2 187 Lev=
el arm-smmu global
> fault
> > > >> 220: 471 0 0 0 GICv2 53 Lev=
el xuartps
> > > >> 223: 0 0 0 0 GICv2 154 Lev=
el fd4c0000.dma
> > > >> 224: 3 0 0 0 dummy 1 Edg=
e ath9k
> > > >> 225: 0 0 0 0 GICv2 97 Lev=
el xhci-hcd:usb1
> > > >>
> > > >> Regards,
> > > >> Bharat
> >
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics
From: Mohammed Shafi Shajakhan @ 2016-12-14 7:33 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k, Kalle Valo
In-Reply-To: <2870294.lMmxz9iPmq@debian64>
On Tue, Dec 13, 2016 at 01:41:33PM +0100, Christian Lamparter wrote:
> Hello,
>
> It looks like google put your mail into the spam-can.
> I'm sorry for not answering sooner.
[shafi] np, thanks for your reply !
>
> On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan wrote:
> > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > The 10.4 firmware adds extended peer information to the
> > > firmware's statistics payload. This additional info is
> > > stored as a separate data field and the elements are
> > > stored in their own "peers_extd" list.
> > >
> > > These elements can pile up in the same way as the peer
> > > information elements. This is because the
> > > ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> > > pull the same amount (num_peer_stats) for every statistic
> > > data unit.
> > >
> > > Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > > ---
> > > drivers/net/wireless/ath/ath10k/debug.c | 7 +++++--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > index 82a4c67f3672..4acd9eb65910 100644
> > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > @@ -399,6 +399,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > > * prevent firmware from DoS-ing the host.
> > > */
> > > ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
> > > + ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);
> >
> > [shafi] thanks for fixing this !
> >
> > > ath10k_warn(ar, "dropping fw peer stats\n");
> > > goto free;
> > > }
> > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > > goto free;
> > > }
> > >
> > > + if (!list_empty(&stats.peers))
> >
> > [shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
> > for normal 'peer stats' ? Is this the fix intended, i had started a build to
> > check your change and we will keep you posted, does this fix displaying
> > 'rx_duration' in ath10k fw_stats.
> The idea is not to queue any "extended peer stats" when there where no "peer stats" to
> begin with. Because otherwise, the function is still vulnerable to OOM since the
> extended peers stats will be queued unchecked (not that this is currently a problem).
[shafi] list_splice_tail_init should still check for non-empty 'peers_extd' list
and append if required ? please let me know if i am still missing something
>
> > > + list_splice_tail_init(&stats.peers_extd,
> > > + &ar->debug.fw_stats.peers_extd);
> > > +
> > > list_splice_tail_init(&stats.peers, &ar->debug.fw_stats.peers);
> > > list_splice_tail_init(&stats.vdevs, &ar->debug.fw_stats.vdevs);
> > > - list_splice_tail_init(&stats.peers_extd,
> > > - &ar->debug.fw_stats.peers_extd);
> > > }
> > >
> > > complete(&ar->debug.fw_stats_complete);
>
> Regards,
> Christian
>
>
^ permalink raw reply
* Re: [RFC V3 03/11] nl80211: add support for gscan
From: Arend Van Spriel @ 2016-12-14 9:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1481668194.22319.0.camel@sipsolutions.net>
On 13-12-2016 23:29, Johannes Berg wrote:
> On Tue, 2016-12-13 at 21:09 +0100, Arend Van Spriel wrote:
>>
>>> There's a bit of a weird hard-coded restriction to 16 channels too,
>>> that's due to the bucket map?
>>
>> Uhm. Is there? I will check, but if you can give me a pointer where
>> to look it is appreciated.
>
> Just look for "< 16" or "<= 16" or so in the patch. I do think that's
> because the channel map is a u16 though, not sure we'd want to change
> that.
Had to look for "> 16" ;-)
> + /* ignore channels if band is specified */
> + if (band_select)
> + return 0;
> +
> + nla_for_each_nested(chan,
tb[NL80211_GSCAN_BUCKET_ATTR_CHANNELS], rem) {
> + num_chans++;
> + }
Here an instance of the tab vs. space issue you mentioned. Will go over
the patch and fix that.
> + if (num_chans > 16)
> + return -EINVAL;
I suspect this is the restriction you were referring to. There is no
reason for this although the android wifi hal has max 16 channels in a
bucket so I might have picked that up. So could a driver have a similar
limit and should we add such to the gscan capabilities? For instance our
firmware api has a nasty restriction of 64 channels for all buckets
together, eg. can do 4 buckets of 16 channels each.
Regards,
Arend
^ permalink raw reply
* Re: [RFC V3 04/11] nl80211: add driver api for gscan notifications
From: Arend Van Spriel @ 2016-12-14 10:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1481646049.20412.43.camel@sipsolutions.net>
On 13-12-2016 17:20, Johannes Berg wrote:
> On Mon, 2016-12-12 at 11:59 +0000, Arend van Spriel wrote:
>> The driver can indicate gscan results are available or gscan
>> operation has stopped.
>
> This patch is renumbering the previous patches' nl80211 API, which is
> best avoided, even if I do realize it doesn't matter now. :)
Indeed. Will be more careful in upcoming revision(s).
> Even here it's not clear how things are reported though. Somehow I
> thought that gscan was reporting only partial information through the
> buckets, or is that not true?
Not sure what is meant by "through the buckets". Referring to your
remark/question in the "Unversal scan proposal" thread:
"""
I'm much more worried about the "bucket reporting" since that doesn't
fit into the current full BSS reporting model at all. What's your
suggestion for this?
"""
So this is exactly the dilemma I considered so I decided to stick with
the full BSS reporting model for gscan as well merely to get it
discussed so glad you brought it up ;-). The problem here is that
gscan is a vehicle that serves a number of use-cases. So ignoring
hotlists, ePNO, etc. the gscan configuration still hold several
notification types:
- report after completing M scans capturing N best APs or a
percentage of (M * N).
- report after completing a scan include a specific bucket.
- report full scan results.
The first two notification trigger retrieval of gscan results which are
historic, ie. partial scan results for max M scans.
As said earlier the universal scan proposal has some similarities to
gscan. Guess you share that as you are using the term "bucket reporting"
in that discussion ;-). The historic results are needed for location (if
I am not mistaken) so the full BSS reporting model does not fit that.
Question is what particular attribute in the historic results is needed
for location (suspecting only rssi and possibly the timestamp, but would
like to see that confirmed). I was thinking about have historic storage
in cfg80211 so we do not need a per-driver solution.
Regards,
Arend
^ permalink raw reply
* Re: [RFC v2 05/11] ath10k: htc: refactorization
From: Valo, Kalle @ 2016-12-14 13:46 UTC (permalink / raw)
To: Erik Stromdahl
Cc: michal.kazior@tieto.com, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> I have made a few updates since I submitted the original RFC and created
> a repo on github:
>
> https://github.com/erstrom/linux-ath
>
> I have a bunch of branches that are all based on the tags on the ath mast=
er.
>
> As of this moment the latest version is:
>
> ath-201612131156-ath10k-sdio
>
> This branch contains the original RFC patches plus some addons/fixes.
Good, this makes it easier to follow the development. So what's the
current status with this branch? What works and what doesn't?
Especially I'm interested about the state of the HTT high latency
support. How much work is to add that? It would also make it easier to
add USB support to ath10k.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [RFC v2 05/11] ath10k: htc: refactorization
From: Valo, Kalle @ 2016-12-14 13:49 UTC (permalink / raw)
To: michal.kazior@tieto.com
Cc: Erik Stromdahl, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <CA+BoTQmRV59imnmSykjs=ym0qut9akUHzFKfAMioK=MT8my98A@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
>> I have made a few updates since I submitted the original RFC and created
>> a repo on github:
>>
>> https://github.com/erstrom/linux-ath
>>
>> I have a bunch of branches that are all based on the tags on the ath mas=
ter.
>>
>> As of this moment the latest version is:
>>
>> ath-201612131156-ath10k-sdio
>>
>> This branch contains the original RFC patches plus some addons/fixes.
>>
>> In the above mentioned branch there are a few commits related to this
>> race condition. Perhaps you can have a look at them?
>>
>> The commits are:
>> 821672913328cf737c9616786dc28d2e4e8a4a90
>
> I would avoid if(bus=3D=3Dxx) checks.
Very much agreed. For example to enable HTT high latency support you
could add an enum to ath10k_core_create() with values for both high and
low latency. This way sdio.c and pci.c can enable the correct mode
during initialisation.
--=20
Kalle Valo=
^ permalink raw reply
* [PATCH 1/5] mwifiex: get rid of mwifiex_do_flr wrapper
From: Amitkumar Karwar @ 2016-12-14 14:10 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
This patch gets rid of mwifiex_do_flr. We will call
mwifiex_shutdown_sw() and mwifiex_reinit_sw() directly.
These two general purpose functions will be useful for
sdio card reset handler.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 31 +++++------------------------
drivers/net/wireless/marvell/mwifiex/main.h | 3 ++-
drivers/net/wireless/marvell/mwifiex/pcie.c | 4 ++--
3 files changed, 9 insertions(+), 29 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index c1821aa..3fc6221 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1348,7 +1348,7 @@ static void mwifiex_main_work_queue(struct work_struct *work)
* This function gets called during PCIe function level reset. Required
* code is extracted from mwifiex_remove_card()
*/
-static int
+int
mwifiex_shutdown_sw(struct mwifiex_adapter *adapter)
{
struct mwifiex_private *priv;
@@ -1417,13 +1417,13 @@ static void mwifiex_main_work_queue(struct work_struct *work)
exit_return:
return 0;
}
+EXPORT_SYMBOL_GPL(mwifiex_shutdown_sw);
/* This function gets called during PCIe function level reset. Required
* code is extracted from mwifiex_add_card()
*/
-static int
-mwifiex_reinit_sw(struct mwifiex_adapter *adapter, struct completion *fw_done,
- struct mwifiex_if_ops *if_ops, u8 iface_type)
+int
+mwifiex_reinit_sw(struct mwifiex_adapter *adapter)
{
char fw_name[32];
struct pcie_service_card *card = adapter->card;
@@ -1432,9 +1432,6 @@ static void mwifiex_main_work_queue(struct work_struct *work)
if (adapter->if_ops.up_dev)
adapter->if_ops.up_dev(adapter);
- adapter->iface_type = iface_type;
- adapter->fw_done = fw_done;
-
adapter->hw_status = MWIFIEX_HW_STATUS_INITIALIZING;
adapter->surprise_removed = false;
init_waitqueue_head(&adapter->init_wait_q);
@@ -1507,25 +1504,7 @@ static void mwifiex_main_work_queue(struct work_struct *work)
return -1;
}
-
-/* This function processes pre and post PCIe function level resets.
- * It performs software cleanup without touching PCIe specific code.
- * Also, during initialization PCIe stuff is skipped.
- */
-void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
-{
- struct mwifiex_if_ops if_ops;
-
- if (!prepare) {
- mwifiex_reinit_sw(adapter, adapter->fw_done, &if_ops,
- adapter->iface_type);
- } else {
- memcpy(&if_ops, &adapter->if_ops,
- sizeof(struct mwifiex_if_ops));
- mwifiex_shutdown_sw(adapter);
- }
-}
-EXPORT_SYMBOL_GPL(mwifiex_do_flr);
+EXPORT_SYMBOL_GPL(mwifiex_reinit_sw);
static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
{
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index d501d03..5f7a010 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1666,5 +1666,6 @@ void mwifiex_process_multi_chan_event(struct mwifiex_private *priv,
void mwifiex_dev_debugfs_init(struct mwifiex_private *priv);
void mwifiex_dev_debugfs_remove(struct mwifiex_private *priv);
#endif
-void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare);
+int mwifiex_reinit_sw(struct mwifiex_adapter *adapter);
+int mwifiex_shutdown_sw(struct mwifiex_adapter *adapter);
#endif /* !_MWIFIEX_MAIN_H_ */
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 55c79e3..02f6db0 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -375,7 +375,7 @@ static void mwifiex_pcie_reset_notify(struct pci_dev *pdev, bool prepare)
* Cleanup all software without cleaning anything related to
* PCIe and HW.
*/
- mwifiex_do_flr(adapter, prepare);
+ mwifiex_shutdown_sw(adapter);
adapter->surprise_removed = true;
} else {
/* Kernel stores and restores PCIe function context before and
@@ -383,7 +383,7 @@ static void mwifiex_pcie_reset_notify(struct pci_dev *pdev, bool prepare)
* and firmware including firmware redownload
*/
adapter->surprise_removed = false;
- mwifiex_do_flr(adapter, prepare);
+ mwifiex_reinit_sw(adapter);
}
mwifiex_dbg(adapter, INFO, "%s, successful\n", __func__);
}
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] mwifiex: sdio card reset enhancement
From: Amitkumar Karwar @ 2016-12-14 14:10 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1481724651-30397-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
Commit b4336a282db8 ("mwifiex: sdio: reset adapter using mmc_hw_reset")
introduces a simple sdio card reset solution based on card remove and
re-probe. This solution has proved to be vulnerable, as card and
adapter structures are not protected, concurrent access will result in
kernel panic issues.
Let's reuse PCIe FLR's functions for SDIO reset to avoid freeing and
reallocating adapter and card structures.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 73 +++++++++++++----------------
drivers/net/wireless/marvell/mwifiex/sdio.h | 3 --
2 files changed, 33 insertions(+), 43 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 44eb65a..b3aca10 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -104,7 +104,6 @@ static int mwifiex_sdio_probe_of(struct device *dev)
init_completion(&card->fw_done);
card->func = func;
- card->device_id = id;
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
@@ -2196,33 +2195,13 @@ static void mwifiex_cleanup_sdio(struct mwifiex_adapter *adapter)
port, card->mp_data_port_mask);
}
-static void mwifiex_recreate_adapter(struct sdio_mmc_card *card)
+static struct mwifiex_adapter *save_adapter;
+static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
{
+ struct sdio_mmc_card *card = adapter->card;
struct sdio_func *func = card->func;
- const struct sdio_device_id *device_id = card->device_id;
-
- /* TODO mmc_hw_reset does not require destroying and re-probing the
- * whole adapter. Hence there was no need to for this rube-goldberg
- * design to reload the fw from an external workqueue. If we don't
- * destroy the adapter we could reload the fw from
- * mwifiex_main_work_queue directly.
- * The real difficulty with fw reset is to restore all the user
- * settings applied through ioctl. By destroying and recreating the
- * adapter, we take the easy way out, since we rely on user space to
- * restore them. We assume that user space will treat the new
- * incarnation of the adapter(interfaces) as if they had been just
- * discovered and initializes them from scratch.
- */
- __mwifiex_sdio_remove(func);
-
- /*
- * Normally, we would let the driver core take care of releasing these.
- * But we're not letting the driver core handle this one. See above
- * TODO.
- */
- sdio_set_drvdata(func, NULL);
- devm_kfree(&func->dev, card);
+ mwifiex_shutdown_sw(adapter);
/* power cycle the adapter */
sdio_claim_host(func);
@@ -2235,21 +2214,7 @@ static void mwifiex_recreate_adapter(struct sdio_mmc_card *card)
clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags);
clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &iface_work_flags);
- mwifiex_sdio_probe(func, device_id);
-}
-
-static struct mwifiex_adapter *save_adapter;
-static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
-{
- struct sdio_mmc_card *card = adapter->card;
-
- /* TODO card pointer is unprotected. If the adapter is removed
- * physically, sdio core might trigger mwifiex_sdio_remove, before this
- * workqueue is run, which will destroy the adapter struct. When this
- * workqueue eventually exceutes it will dereference an invalid adapter
- * pointer
- */
- mwifiex_recreate_adapter(card);
+ mwifiex_reinit_sw(adapter);
}
/* This function read/write firmware */
@@ -2677,6 +2642,33 @@ static void mwifiex_sdio_device_dump(struct mwifiex_adapter *adapter)
return p - drv_buf;
}
+/* sdio device/function initialization, code is extracted
+ * from init_if handler and register_dev handler.
+ */
+static void mwifiex_sdio_up_dev(struct mwifiex_adapter *adapter)
+{
+ struct sdio_mmc_card *card = adapter->card;
+ u8 sdio_ireg;
+
+ sdio_claim_host(card->func);
+ sdio_enable_func(card->func);
+ sdio_set_block_size(card->func, MWIFIEX_SDIO_BLOCK_SIZE);
+ sdio_release_host(card->func);
+
+ /* tx_buf_size might be changed to 3584 by firmware during
+ * data transfer, we will reset to default size.
+ */
+ adapter->tx_buf_size = card->tx_buf_size;
+
+ /* Read the host_int_status_reg for ACK the first interrupt got
+ * from the bootloader. If we don't do this we get a interrupt
+ * as soon as we register the irq.
+ */
+ mwifiex_read_reg(adapter, card->reg->host_int_status_reg, &sdio_ireg);
+
+ mwifiex_init_sdio_ioport(adapter);
+}
+
static struct mwifiex_if_ops sdio_ops = {
.init_if = mwifiex_init_sdio,
.cleanup_if = mwifiex_cleanup_sdio,
@@ -2702,6 +2694,7 @@ static void mwifiex_sdio_device_dump(struct mwifiex_adapter *adapter)
.reg_dump = mwifiex_sdio_reg_dump,
.device_dump = mwifiex_sdio_device_dump,
.deaggr_pkt = mwifiex_deaggr_sdio_pkt,
+ .up_dev = mwifiex_sdio_up_dev,
};
module_driver(mwifiex_sdio, sdio_register_driver, sdio_unregister_driver);
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index cdbf3a3a..afa10d5 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -267,9 +267,6 @@ struct sdio_mmc_card {
struct mwifiex_sdio_mpa_tx mpa_tx;
struct mwifiex_sdio_mpa_rx mpa_rx;
-
- /* needed for card reset */
- const struct sdio_device_id *device_id;
};
struct mwifiex_sdio_device {
--
1.9.1
^ permalink raw reply related
* [PATCH 5/5] mwifiex: get rid of global save_adapter and sdio_work
From: Amitkumar Karwar @ 2016-12-14 14:10 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1481724651-30397-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
This patch moves sdio_work to card structure, in this way we can get
adapter structure in the work, so save_adapter won't be needed.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 39 ++++++++++++++++-------------
drivers/net/wireless/marvell/mwifiex/sdio.h | 3 +++
2 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 0fda87a..a4b356d 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -32,10 +32,8 @@
#define SDIO_VERSION "1.0"
static void mwifiex_sdio_work(struct work_struct *work);
-static DECLARE_WORK(sdio_work, mwifiex_sdio_work);
static struct mwifiex_if_ops sdio_ops;
-static unsigned long iface_work_flags;
static struct memory_type_mapping generic_mem_type_map[] = {
{"DUMP", NULL, 0, 0xDD},
@@ -123,6 +121,7 @@ static int mwifiex_sdio_probe_of(struct device *dev)
card->fw_dump_enh = data->fw_dump_enh;
card->can_auto_tdls = data->can_auto_tdls;
card->can_ext_scan = data->can_ext_scan;
+ INIT_WORK(&card->work, mwifiex_sdio_work);
}
sdio_claim_host(func);
@@ -388,7 +387,7 @@ static int mwifiex_check_winner_status(struct mwifiex_adapter *adapter)
if (!adapter || !adapter->priv_num)
return;
- cancel_work_sync(&sdio_work);
+ cancel_work_sync(&card->work);
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
@@ -2190,7 +2189,6 @@ static void mwifiex_cleanup_sdio(struct mwifiex_adapter *adapter)
port, card->mp_data_port_mask);
}
-static struct mwifiex_adapter *save_adapter;
static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
{
struct sdio_mmc_card *card = adapter->card;
@@ -2206,8 +2204,8 @@ static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
/* Previous save_adapter won't be valid after this. We will cancel
* pending work requests.
*/
- clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags);
- clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &iface_work_flags);
+ clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags);
+ clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &card->work_flags);
mwifiex_reinit_sw(adapter);
}
@@ -2513,35 +2511,40 @@ static void mwifiex_sdio_device_dump_work(struct mwifiex_adapter *adapter)
static void mwifiex_sdio_work(struct work_struct *work)
{
+ struct sdio_mmc_card *card =
+ container_of(work, struct sdio_mmc_card, work);
+
if (test_and_clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP,
- &iface_work_flags))
- mwifiex_sdio_device_dump_work(save_adapter);
+ &card->work_flags))
+ mwifiex_sdio_device_dump_work(card->adapter);
if (test_and_clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET,
- &iface_work_flags))
- mwifiex_sdio_card_reset_work(save_adapter);
+ &card->work_flags))
+ mwifiex_sdio_card_reset_work(card->adapter);
}
/* This function resets the card */
static void mwifiex_sdio_card_reset(struct mwifiex_adapter *adapter)
{
- save_adapter = adapter;
- if (test_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &iface_work_flags))
+ struct sdio_mmc_card *card = adapter->card;
+
+ if (test_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &card->work_flags))
return;
- set_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &iface_work_flags);
+ set_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &card->work_flags);
- schedule_work(&sdio_work);
+ schedule_work(&card->work);
}
/* This function dumps FW information */
static void mwifiex_sdio_device_dump(struct mwifiex_adapter *adapter)
{
- save_adapter = adapter;
- if (test_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags))
+ struct sdio_mmc_card *card = adapter->card;
+
+ if (test_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags))
return;
- set_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags);
- schedule_work(&sdio_work);
+ set_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags);
+ schedule_work(&card->work);
}
/* Function to dump SDIO function registers and SDIO scratch registers in case
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index afa10d5..dccf7fd 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -267,6 +267,9 @@ struct sdio_mmc_card {
struct mwifiex_sdio_mpa_tx mpa_tx;
struct mwifiex_sdio_mpa_rx mpa_rx;
+
+ struct work_struct work;
+ unsigned long work_flags;
};
struct mwifiex_sdio_device {
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] mwifiex: cleanup in PCIe flr code path
From: Amitkumar Karwar @ 2016-12-14 14:10 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1481724651-30397-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
adapter and card variables don't get freed during PCIe function level
reset. "adapter->ext_scan" variable need not be re-initialized.
fw_name and tx_buf_size initialization is moved to pcie specific code
so that mwifiex_reinit_sw() can be used by SDIO.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 9 ---------
drivers/net/wireless/marvell/mwifiex/pcie.c | 12 +++++++++++-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 3fc6221..9d80180 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1425,9 +1425,6 @@ static void mwifiex_main_work_queue(struct work_struct *work)
int
mwifiex_reinit_sw(struct mwifiex_adapter *adapter)
{
- char fw_name[32];
- struct pcie_service_card *card = adapter->card;
-
mwifiex_init_lock_list(adapter);
if (adapter->if_ops.up_dev)
adapter->if_ops.up_dev(adapter);
@@ -1468,18 +1465,12 @@ static void mwifiex_main_work_queue(struct work_struct *work)
* mwifiex_register_dev()
*/
mwifiex_dbg(adapter, INFO, "%s, mwifiex_init_hw_fw()...\n", __func__);
- strcpy(fw_name, adapter->fw_name);
- strcpy(adapter->fw_name, PCIE8997_DEFAULT_WIFIFW_NAME);
- adapter->tx_buf_size = card->pcie.tx_buf_size;
- adapter->ext_scan = card->pcie.can_ext_scan;
if (mwifiex_init_hw_fw(adapter, false)) {
- strcpy(adapter->fw_name, fw_name);
mwifiex_dbg(adapter, ERROR,
"%s: firmware init failed\n", __func__);
goto err_init_fw;
}
- strcpy(adapter->fw_name, fw_name);
mwifiex_dbg(adapter, INFO, "%s, successful\n", __func__);
complete_all(adapter->fw_done);
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 02f6db0..66226c6 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -3082,6 +3082,17 @@ static void mwifiex_pcie_up_dev(struct mwifiex_adapter *adapter)
struct pci_dev *pdev = card->dev;
const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
+ /* Bluetooth is not on pcie interface. Download Wifi only firmware
+ * during pcie FLR, so that bluetooth part of firmware which is
+ * already running doesn't get affected.
+ */
+ strcpy(adapter->fw_name, PCIE8997_DEFAULT_WIFIFW_NAME);
+
+ /* tx_buf_size might be changed to 3584 by firmware during
+ * data transfer, we should reset it to default size.
+ */
+ adapter->tx_buf_size = card->pcie.tx_buf_size;
+
card->cmdrsp_buf = NULL;
ret = mwifiex_pcie_create_txbd_ring(adapter);
if (ret) {
@@ -3143,7 +3154,6 @@ static void mwifiex_pcie_down_dev(struct mwifiex_adapter *adapter)
mwifiex_dbg(adapter, ERROR, "Failed to write driver not-ready signature\n");
adapter->seq_num = 0;
- adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K;
if (reg->sleep_cookie)
mwifiex_pcie_delete_sleep_cookie_buf(adapter);
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] mwifiex: get rid of __mwifiex_sdio_remove helper
From: Amitkumar Karwar @ 2016-12-14 14:10 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1481724651-30397-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
__mwifiex_sdio_remove helper is not needed after
our enhancements in SDIO card reset.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index b3aca10..0fda87a 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -370,7 +370,7 @@ static int mwifiex_check_winner_status(struct mwifiex_adapter *adapter)
* This function removes the interface and frees up the card structure.
*/
static void
-__mwifiex_sdio_remove(struct sdio_func *func)
+mwifiex_sdio_remove(struct sdio_func *func)
{
struct sdio_mmc_card *card;
struct mwifiex_adapter *adapter;
@@ -388,6 +388,8 @@ static int mwifiex_check_winner_status(struct mwifiex_adapter *adapter)
if (!adapter || !adapter->priv_num)
return;
+ cancel_work_sync(&sdio_work);
+
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
ret = mwifiex_sdio_read_fw_status(adapter, &firmware_stat);
@@ -402,13 +404,6 @@ static int mwifiex_check_winner_status(struct mwifiex_adapter *adapter)
mwifiex_remove_card(adapter);
}
-static void
-mwifiex_sdio_remove(struct sdio_func *func)
-{
- cancel_work_sync(&sdio_work);
- __mwifiex_sdio_remove(func);
-}
-
/*
* SDIO suspend.
*
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox