* ath10k panic with 5.1 kernel and qca9984 on association @ 2019-05-28 0:54 Vjaceslavs Klimovs 2019-05-28 11:22 ` Kalle Valo 0 siblings, 1 reply; 7+ messages in thread From: Vjaceslavs Klimovs @ 2019-05-28 0:54 UTC (permalink / raw) To: ath10k Hi, With 5.1 and head kernel, machine running as AP with qca9984 locks up without being able to complete stack trace to console after a client tries to associate with it. Following are (OCR transcribed) error messages: [ 177.161539] BUG: unable to handle kernel paging request at fffffffffffff7bo [ 177.161553] #PF error: (normal kernel read fault) [ 177.161561] PGD 703812067 P4D 703812067 PUD 20381406 PMD 0 [ 177.161571] Oops: 0000 (#1) SMP PTI [ 177.161577] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G OE 5.1.3-gentoo #1 [Garbage on screen after that point] and [67.805490] RBP: ffff9c4c57983d 18 R08: 0000000000000000 R09: 0000000000000000 [67.805501] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000001 [67.805512] R13: 0000000000000000 R14: 0000000000060002 R15: 0000000000000000 [67.805523] FS: 000000000000000000000) GS:ffff9c4c57980000 (0000) knIGS:000000000 [67.805535] CS: 0010 DS: 0000 ES: 0000 CRO: 0000000080050033 [67.805544] CR2: fffffffffffff7b0 CR3: 00000005f7e0e006 CR4: 00000000003606e0 [67.805555] DRO: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [67.805566] DR3: 0000000000000000 DR6: 00000000fffeoffO DR7: 0000000000000400 [67.805577] Call Trace: [67.805582] <IRQ> [67.805592] ath10k_htt_t2h_msg_handler+0xbda/0xf80 [ath10k_core] [67.805603] ? _raw_spin_unlock_bh+0xie/0x20 [67.805614] ? ath1ok_ce_per_engine_service+0xf1/0x100 [ath10k_corel [67.805626] ath10k_pci_htt_rx_cb+0x172/0x260 [ath10k_pci] [67.8056391] ath10k_ce_per_engine_service+0x9e/0x100 [ath10k_core) [Garbage on screen after that point] The issue does not reproduce on 5.0.17 but is reliably reproducible in 5.1+ by just trying to associate to that AP. So I thought I'd run git bisect. After bisecting, 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956, ath10k: add support for ack rssi value of data tx packets is the first commit that triggers the problem. Reverting that commit from head or from 5.1.5 reliably makes everything work as expected. Device parameters and FW are as follows: [ 4.502988] ath10k_pci 0000:0a:00.0: enabling device (0000 -> 0002) [ 4.503324] ath10k_pci 0000:0a:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 [ 4.615989] ath10k_pci 0000:0a:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe [ 4.615990] ath10k_pci 0000:0a:00.0: kconfig debug 0 debugfs 1 tracing 1 dfs 1 testmode 0 [ 4.616269] ath10k_pci 0000:0a:00.0: firmware ver 10.4-3.9.0.2-00021 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 9626782c [ 5.845294] ath10k_pci 0000:0a:00.0: board_file api 2 bmi_id 0:1 crc32 cf58c3bc [ 8.390524] ath10k_pci 0000:0a:00.0: unsupported HTC service id: 1536 [ 8.503161] ath10k_pci 0000:0a:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 I also tried with firmware-5.bin_10.4-3.9.0.2-00044, same results. _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ath10k panic with 5.1 kernel and qca9984 on association 2019-05-28 0:54 ath10k panic with 5.1 kernel and qca9984 on association Vjaceslavs Klimovs @ 2019-05-28 11:22 ` Kalle Valo 2019-05-28 18:23 ` Vjaceslavs Klimovs 0 siblings, 1 reply; 7+ messages in thread From: Kalle Valo @ 2019-05-28 11:22 UTC (permalink / raw) To: Vjaceslavs Klimovs; +Cc: Abhishek Ambure, ath10k + Abhishek Vjaceslavs Klimovs <vklimovs@gmail.com> writes: > With 5.1 and head kernel, machine running as AP with qca9984 locks up > without being able to complete stack trace to console after a client > tries to associate with it. Following are (OCR transcribed) error > messages: > > [ 177.161539] BUG: unable to handle kernel paging request at fffffffffffff7bo > [ 177.161553] #PF error: (normal kernel read fault) > [ 177.161561] PGD 703812067 P4D 703812067 PUD 20381406 PMD 0 > [ 177.161571] Oops: 0000 (#1) SMP PTI > [ 177.161577] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G OE 5.1.3-gentoo #1 > > [Garbage on screen after that point] > > and > > [67.805490] RBP: ffff9c4c57983d 18 R08: 0000000000000000 R09: > 0000000000000000 [67.805501] R10: 0000000000000002 R11: > 0000000000000000 R12: 0000000000000001 [67.805512] R13: > 0000000000000000 R14: 0000000000060002 R15: 0000000000000000 > [67.805523] FS: 000000000000000000000) GS:ffff9c4c57980000 (0000) > knIGS:000000000 [67.805535] CS: 0010 DS: 0000 ES: 0000 CRO: > 0000000080050033 > [67.805544] CR2: fffffffffffff7b0 CR3: 00000005f7e0e006 CR4: 00000000003606e0 > [67.805555] DRO: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 [67.805566] DR3: 0000000000000000 DR6: > 00000000fffeoffO DR7: 0000000000000400 [67.805577] Call Trace: > [67.805582] <IRQ> > [67.805592] ath10k_htt_t2h_msg_handler+0xbda/0xf80 [ath10k_core] > [67.805603] ? _raw_spin_unlock_bh+0xie/0x20 > [67.805614] ? ath1ok_ce_per_engine_service+0xf1/0x100 [ath10k_corel > [67.805626] ath10k_pci_htt_rx_cb+0x172/0x260 [ath10k_pci] > [67.8056391] ath10k_ce_per_engine_service+0x9e/0x100 [ath10k_core) > > [Garbage on screen after that point] > > The issue does not reproduce on 5.0.17 but is reliably reproducible in > 5.1+ by just trying to associate to that AP. So I thought I'd run git > bisect. After bisecting, > > 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956, ath10k: add support for ack > rssi value of data tx packets > > is the first commit that triggers the problem. Reverting that commit > from head or from 5.1.5 reliably makes everything work as expected. Thank you for the bisect, this is really helpful. Full commit log below. Abhishek, please fix this or send a revert for 5.2. commit 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956 Author: Abhishek Ambure <aambure@codeaurora.org> AuthorDate: Mon Feb 25 11:45:48 2019 +0200 Commit: Kalle Valo <kvalo@codeaurora.org> CommitDate: Tue Feb 26 14:58:06 2019 +0200 ath10k: add support for ack rssi value of data tx packets In WCN3990, WMI_TLV_SERVICE_TX_DATA_MGMT_ACK_RSSI service Indicates that the firmware has the capability to send the RSSI value of the ACK for all data and management packets transmitted. If WMI_RSRC_CFG_FLAG_TX_ACK_RSSI is set in host capability then firmware sends RSSI value in "data" tx completion event. Host extracts ack rssi values of data packets from their tx completion event. Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1 Signed-off-by: Abhishek Ambure <aambure@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ath10k panic with 5.1 kernel and qca9984 on association 2019-05-28 11:22 ` Kalle Valo @ 2019-05-28 18:23 ` Vjaceslavs Klimovs [not found] ` <000001d516ec$fed6f190$fc84d4b0$@codeaurora.org> 0 siblings, 1 reply; 7+ messages in thread From: Vjaceslavs Klimovs @ 2019-05-28 18:23 UTC (permalink / raw) To: Kalle Valo; +Cc: Abhishek Ambure, ath10k Abhishek, I am happy to test a proposed fix, let me know. On Tue, May 28, 2019 at 4:22 AM Kalle Valo <kvalo@codeaurora.org> wrote: > > + Abhishek > > Vjaceslavs Klimovs <vklimovs@gmail.com> writes: > > > With 5.1 and head kernel, machine running as AP with qca9984 locks up > > without being able to complete stack trace to console after a client > > tries to associate with it. Following are (OCR transcribed) error > > messages: > > > > [ 177.161539] BUG: unable to handle kernel paging request at fffffffffffff7bo > > [ 177.161553] #PF error: (normal kernel read fault) > > [ 177.161561] PGD 703812067 P4D 703812067 PUD 20381406 PMD 0 > > [ 177.161571] Oops: 0000 (#1) SMP PTI > > [ 177.161577] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G OE 5.1.3-gentoo #1 > > > > [Garbage on screen after that point] > > > > and > > > > [67.805490] RBP: ffff9c4c57983d 18 R08: 0000000000000000 R09: > > 0000000000000000 [67.805501] R10: 0000000000000002 R11: > > 0000000000000000 R12: 0000000000000001 [67.805512] R13: > > 0000000000000000 R14: 0000000000060002 R15: 0000000000000000 > > [67.805523] FS: 000000000000000000000) GS:ffff9c4c57980000 (0000) > > knIGS:000000000 [67.805535] CS: 0010 DS: 0000 ES: 0000 CRO: > > 0000000080050033 > > [67.805544] CR2: fffffffffffff7b0 CR3: 00000005f7e0e006 CR4: 00000000003606e0 > > [67.805555] DRO: 0000000000000000 DR1: 0000000000000000 DR2: > > 0000000000000000 [67.805566] DR3: 0000000000000000 DR6: > > 00000000fffeoffO DR7: 0000000000000400 [67.805577] Call Trace: > > [67.805582] <IRQ> > > [67.805592] ath10k_htt_t2h_msg_handler+0xbda/0xf80 [ath10k_core] > > [67.805603] ? _raw_spin_unlock_bh+0xie/0x20 > > [67.805614] ? ath1ok_ce_per_engine_service+0xf1/0x100 [ath10k_corel > > [67.805626] ath10k_pci_htt_rx_cb+0x172/0x260 [ath10k_pci] > > [67.8056391] ath10k_ce_per_engine_service+0x9e/0x100 [ath10k_core) > > > > [Garbage on screen after that point] > > > > The issue does not reproduce on 5.0.17 but is reliably reproducible in > > 5.1+ by just trying to associate to that AP. So I thought I'd run git > > bisect. After bisecting, > > > > 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956, ath10k: add support for ack > > rssi value of data tx packets > > > > is the first commit that triggers the problem. Reverting that commit > > from head or from 5.1.5 reliably makes everything work as expected. > > Thank you for the bisect, this is really helpful. Full commit log below. > Abhishek, please fix this or send a revert for 5.2. > > commit 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956 > Author: Abhishek Ambure <aambure@codeaurora.org> > AuthorDate: Mon Feb 25 11:45:48 2019 +0200 > Commit: Kalle Valo <kvalo@codeaurora.org> > CommitDate: Tue Feb 26 14:58:06 2019 +0200 > > ath10k: add support for ack rssi value of data tx packets > > In WCN3990, WMI_TLV_SERVICE_TX_DATA_MGMT_ACK_RSSI service Indicates that > the firmware has the capability to send the RSSI value of the ACK for all > data and management packets transmitted. > > If WMI_RSRC_CFG_FLAG_TX_ACK_RSSI is set in host capability then firmware > sends RSSI value in "data" tx completion event. Host extracts ack rssi > values of data packets from their tx completion event. > > Tested HW: WCN3990 > Tested FW: WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1 > > Signed-off-by: Abhishek Ambure <aambure@codeaurora.org> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org> > > -- > Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <000001d516ec$fed6f190$fc84d4b0$@codeaurora.org>]
* Re: ath10k panic with 5.1 kernel and qca9984 on association [not found] ` <000001d516ec$fed6f190$fc84d4b0$@codeaurora.org> @ 2019-05-30 13:58 ` Balaji Pothunoori 2019-06-01 18:07 ` Vjaceslavs Klimovs 0 siblings, 1 reply; 7+ messages in thread From: Balaji Pothunoori @ 2019-05-30 13:58 UTC (permalink / raw) To: Vjaceslavs Klimovs, kvalo; +Cc: Abhishek Ambure, ath10k Hi, We are not seeing mentioned issue with following setup. Setup details are : AP - X86 with 5.1.0 kernel + QCA9984. STA - Standard STA. Observation : Crash is not observed during STA join. Could you please share the steps what you have followed ? Regards, Balaji. > -----Original Message----- > From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of > Vjaceslavs Klimovs > Sent: Tuesday, May 28, 2019 11:53 PM > To: kvalo@codeaurora.org > Cc: Abhishek Ambure <aambure@codeaurora.org>; > ath10k@lists.infradead.org > Subject: [EXT] Re: ath10k panic with 5.1 kernel and qca9984 on > association > > Abhishek, > I am happy to test a proposed fix, let me know. > > On Tue, May 28, 2019 at 4:22 AM Kalle Valo <kvalo@codeaurora.org> > wrote: >> >> + Abhishek >> >> Vjaceslavs Klimovs <vklimovs@gmail.com> writes: >> >> > With 5.1 and head kernel, machine running as AP with qca9984 locks >> > up without being able to complete stack trace to console after a >> > client tries to associate with it. Following are (OCR transcribed) >> > error >> > messages: >> > >> > [ 177.161539] BUG: unable to handle kernel paging request at >> > fffffffffffff7bo [ 177.161553] #PF error: (normal kernel read fault) >> > [ 177.161561] PGD 703812067 P4D 703812067 PUD 20381406 PMD 0 [ >> > 177.161571] Oops: 0000 (#1) SMP PTI [ 177.161577] CPU: 6 PID: 0 >> > Comm: swapper/6 Tainted: G OE 5.1.3-gentoo #1 >> > >> > [Garbage on screen after that point] >> > >> > and >> > >> > [67.805490] RBP: ffff9c4c57983d 18 R08: 0000000000000000 R09: >> > 0000000000000000 [67.805501] R10: 0000000000000002 R11: >> > 0000000000000000 R12: 0000000000000001 [67.805512] R13: >> > 0000000000000000 R14: 0000000000060002 R15: 0000000000000000 >> > [67.805523] FS: 000000000000000000000) GS:ffff9c4c57980000 (0000) >> > knIGS:000000000 [67.805535] CS: 0010 DS: 0000 ES: 0000 CRO: >> > 0000000080050033 >> > [67.805544] CR2: fffffffffffff7b0 CR3: 00000005f7e0e006 CR4: >> > 00000000003606e0 [67.805555] DRO: 0000000000000000 DR1: 0000000000000000 DR2: >> > 0000000000000000 [67.805566] DR3: 0000000000000000 DR6: >> > 00000000fffeoffO DR7: 0000000000000400 [67.805577] Call Trace: >> > [67.805582] <IRQ> >> > [67.805592] ath10k_htt_t2h_msg_handler+0xbda/0xf80 [ath10k_core] >> > [67.805603] ? _raw_spin_unlock_bh+0xie/0x20 [67.805614] ? >> > ath1ok_ce_per_engine_service+0xf1/0x100 [ath10k_corel [67.805626] >> > ath10k_pci_htt_rx_cb+0x172/0x260 [ath10k_pci] [67.8056391] >> > ath10k_ce_per_engine_service+0x9e/0x100 [ath10k_core) >> > >> > [Garbage on screen after that point] >> > >> > The issue does not reproduce on 5.0.17 but is reliably reproducible >> > in 5.1+ by just trying to associate to that AP. So I thought I'd run >> > git bisect. After bisecting, >> > >> > 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956, ath10k: add support for >> > ack rssi value of data tx packets >> > >> > is the first commit that triggers the problem. Reverting that commit >> > from head or from 5.1.5 reliably makes everything work as expected. >> >> Thank you for the bisect, this is really helpful. Full commit log >> below. >> Abhishek, please fix this or send a revert for 5.2. >> >> commit 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956 >> Author: Abhishek Ambure <aambure@codeaurora.org> >> AuthorDate: Mon Feb 25 11:45:48 2019 +0200 >> Commit: Kalle Valo <kvalo@codeaurora.org> >> CommitDate: Tue Feb 26 14:58:06 2019 +0200 >> >> ath10k: add support for ack rssi value of data tx packets >> >> In WCN3990, WMI_TLV_SERVICE_TX_DATA_MGMT_ACK_RSSI service >> Indicates that >> the firmware has the capability to send the RSSI value of the ACK >> for all >> data and management packets transmitted. >> >> If WMI_RSRC_CFG_FLAG_TX_ACK_RSSI is set in host capability then >> firmware >> sends RSSI value in "data" tx completion event. Host extracts ack >> rssi >> values of data packets from their tx completion event. >> >> Tested HW: WCN3990 >> Tested FW: WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1 >> >> Signed-off-by: Abhishek Ambure <aambure@codeaurora.org> >> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> >> >> -- >> Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ath10k panic with 5.1 kernel and qca9984 on association 2019-05-30 13:58 ` Balaji Pothunoori @ 2019-06-01 18:07 ` Vjaceslavs Klimovs 2019-06-28 9:17 ` Balaji Pothunoori 0 siblings, 1 reply; 7+ messages in thread From: Vjaceslavs Klimovs @ 2019-06-01 18:07 UTC (permalink / raw) To: Balaji Pothunoori; +Cc: Abhishek Ambure, ath10k, Kalle Valo Hi Balaji, Thank you for looking into this. 1) x86_64 AP 2) Compex WLE1216V5-23 or WLE1216V5-20 card with QCA9984 3) any kernel with commit 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956 present 4) kernel has DFS enabled and CONFIG_ATH10K_DFS_CERTIFIED=y, CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS=y, CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING=y set 5) any firmware from https://github.com/kvalo/ath10k-firmware/tree/master/QCA9984/hw1.0/3.9.0.2, see card initialization dmesg in my first message 6) hostapd with the following config: interface=wlp9s0 ctrl_interface=/var/run/hostapd bridge=br0 ssid=XXXXXXXX hw_mode=a chanlist=52 100 116 132 acs_chan_bias=116:0.1 132:0.1 country_code=US ieee80211d=1 ieee80211h=1 ieee80211n=1 ht_capab=[LDPC][HT40+][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40] ieee80211ac=1 vht_capab=[MAX-MPDU-11454][VHT160-80PLUS80][RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][RX-STBC-1][SU-BEAMFORMER][SU-BEAMFORMEE][BF-ANTENNA-4][SOUNDING-DIMENSION-4][MU-BEAMFORMER][MAX-A-MPDU-LEN-EXP7][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN] vht_oper_chwidth=1 auth_algs=1 wpa=2 wpa_key_mgmt=WPA-PSK wpa_passphrase=XXXXXXXX wpa_disable_eapol_key_retries=1 rsn_pairwise=CCMP wmm_enabled=1 ap_isolate=1 7) any STA (ChromeOS, Android, Windows tried) triggers the crash. On Thu, May 30, 2019 at 6:58 AM Balaji Pothunoori <bpothuno@codeaurora.org> wrote: > > Hi, > > We are not seeing mentioned issue with following setup. > Setup details are : > AP - X86 with 5.1.0 kernel + QCA9984. > STA - Standard STA. > Observation : Crash is not observed during STA join. > > Could you please share the steps what you have followed ? > > Regards, > Balaji. > > > -----Original Message----- > > From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of > > Vjaceslavs Klimovs > > Sent: Tuesday, May 28, 2019 11:53 PM > > To: kvalo@codeaurora.org > > Cc: Abhishek Ambure <aambure@codeaurora.org>; > > ath10k@lists.infradead.org > > Subject: [EXT] Re: ath10k panic with 5.1 kernel and qca9984 on > > association > > > > Abhishek, > > I am happy to test a proposed fix, let me know. > > > > On Tue, May 28, 2019 at 4:22 AM Kalle Valo <kvalo@codeaurora.org> > > wrote: > >> > >> + Abhishek > >> > >> Vjaceslavs Klimovs <vklimovs@gmail.com> writes: > >> > >> > With 5.1 and head kernel, machine running as AP with qca9984 locks > >> > up without being able to complete stack trace to console after a > >> > client tries to associate with it. Following are (OCR transcribed) > >> > error > >> > messages: > >> > > >> > [ 177.161539] BUG: unable to handle kernel paging request at > >> > fffffffffffff7bo [ 177.161553] #PF error: (normal kernel read fault) > >> > [ 177.161561] PGD 703812067 P4D 703812067 PUD 20381406 PMD 0 [ > >> > 177.161571] Oops: 0000 (#1) SMP PTI [ 177.161577] CPU: 6 PID: 0 > >> > Comm: swapper/6 Tainted: G OE 5.1.3-gentoo #1 > >> > > >> > [Garbage on screen after that point] > >> > > >> > and > >> > > >> > [67.805490] RBP: ffff9c4c57983d 18 R08: 0000000000000000 R09: > >> > 0000000000000000 [67.805501] R10: 0000000000000002 R11: > >> > 0000000000000000 R12: 0000000000000001 [67.805512] R13: > >> > 0000000000000000 R14: 0000000000060002 R15: 0000000000000000 > >> > [67.805523] FS: 000000000000000000000) GS:ffff9c4c57980000 (0000) > >> > knIGS:000000000 [67.805535] CS: 0010 DS: 0000 ES: 0000 CRO: > >> > 0000000080050033 > >> > [67.805544] CR2: fffffffffffff7b0 CR3: 00000005f7e0e006 CR4: > >> > 00000000003606e0 [67.805555] DRO: 0000000000000000 DR1: 0000000000000000 DR2: > >> > 0000000000000000 [67.805566] DR3: 0000000000000000 DR6: > >> > 00000000fffeoffO DR7: 0000000000000400 [67.805577] Call Trace: > >> > [67.805582] <IRQ> > >> > [67.805592] ath10k_htt_t2h_msg_handler+0xbda/0xf80 [ath10k_core] > >> > [67.805603] ? _raw_spin_unlock_bh+0xie/0x20 [67.805614] ? > >> > ath1ok_ce_per_engine_service+0xf1/0x100 [ath10k_corel [67.805626] > >> > ath10k_pci_htt_rx_cb+0x172/0x260 [ath10k_pci] [67.8056391] > >> > ath10k_ce_per_engine_service+0x9e/0x100 [ath10k_core) > >> > > >> > [Garbage on screen after that point] > >> > > >> > The issue does not reproduce on 5.0.17 but is reliably reproducible > >> > in 5.1+ by just trying to associate to that AP. So I thought I'd run > >> > git bisect. After bisecting, > >> > > >> > 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956, ath10k: add support for > >> > ack rssi value of data tx packets > >> > > >> > is the first commit that triggers the problem. Reverting that commit > >> > from head or from 5.1.5 reliably makes everything work as expected. > >> > >> Thank you for the bisect, this is really helpful. Full commit log > >> below. > >> Abhishek, please fix this or send a revert for 5.2. > >> > >> commit 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956 > >> Author: Abhishek Ambure <aambure@codeaurora.org> > >> AuthorDate: Mon Feb 25 11:45:48 2019 +0200 > >> Commit: Kalle Valo <kvalo@codeaurora.org> > >> CommitDate: Tue Feb 26 14:58:06 2019 +0200 > >> > >> ath10k: add support for ack rssi value of data tx packets > >> > >> In WCN3990, WMI_TLV_SERVICE_TX_DATA_MGMT_ACK_RSSI service > >> Indicates that > >> the firmware has the capability to send the RSSI value of the ACK > >> for all > >> data and management packets transmitted. > >> > >> If WMI_RSRC_CFG_FLAG_TX_ACK_RSSI is set in host capability then > >> firmware > >> sends RSSI value in "data" tx completion event. Host extracts ack > >> rssi > >> values of data packets from their tx completion event. > >> > >> Tested HW: WCN3990 > >> Tested FW: WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1 > >> > >> Signed-off-by: Abhishek Ambure <aambure@codeaurora.org> > >> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> > >> > >> -- > >> Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ath10k panic with 5.1 kernel and qca9984 on association 2019-06-01 18:07 ` Vjaceslavs Klimovs @ 2019-06-28 9:17 ` Balaji Pothunoori 2019-07-05 2:20 ` Vjaceslavs Klimovs 0 siblings, 1 reply; 7+ messages in thread From: Balaji Pothunoori @ 2019-06-28 9:17 UTC (permalink / raw) To: Vjaceslavs Klimovs; +Cc: Abhishek Ambure, ath10k, Kalle Valo Hi, Can you try with this patch ? https://patchwork.kernel.org/patch/11021495/ Regards, Balaji. On 2019-06-01 23:37, Vjaceslavs Klimovs wrote: > Hi Balaji, > Thank you for looking into this. > > 1) x86_64 AP > 2) Compex WLE1216V5-23 or WLE1216V5-20 card with QCA9984 > 3) any kernel with commit 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956 > present > 4) kernel has DFS enabled and CONFIG_ATH10K_DFS_CERTIFIED=y, > CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS=y, > CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING=y set > 5) any firmware from > https://github.com/kvalo/ath10k-firmware/tree/master/QCA9984/hw1.0/3.9.0.2, > see card initialization dmesg in my first message > 6) hostapd with the following config: > > interface=wlp9s0 > ctrl_interface=/var/run/hostapd > bridge=br0 > ssid=XXXXXXXX > hw_mode=a > chanlist=52 100 116 132 > acs_chan_bias=116:0.1 132:0.1 > country_code=US > ieee80211d=1 > ieee80211h=1 > ieee80211n=1 > ht_capab=[LDPC][HT40+][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40] > ieee80211ac=1 > vht_capab=[MAX-MPDU-11454][VHT160-80PLUS80][RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][RX-STBC-1][SU-BEAMFORMER][SU-BEAMFORMEE][BF-ANTENNA-4][SOUNDING-DIMENSION-4][MU-BEAMFORMER][MAX-A-MPDU-LEN-EXP7][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN] > vht_oper_chwidth=1 > auth_algs=1 > wpa=2 > wpa_key_mgmt=WPA-PSK > wpa_passphrase=XXXXXXXX > wpa_disable_eapol_key_retries=1 > rsn_pairwise=CCMP > wmm_enabled=1 > ap_isolate=1 > > 7) any STA (ChromeOS, Android, Windows tried) triggers the crash. > > On Thu, May 30, 2019 at 6:58 AM Balaji Pothunoori > <bpothuno@codeaurora.org> wrote: >> >> Hi, >> >> We are not seeing mentioned issue with following setup. >> Setup details are : >> AP - X86 with 5.1.0 kernel + QCA9984. >> STA - Standard STA. >> Observation : Crash is not observed during STA join. >> >> Could you please share the steps what you have followed ? >> >> Regards, >> Balaji. >> >> > -----Original Message----- >> > From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of >> > Vjaceslavs Klimovs >> > Sent: Tuesday, May 28, 2019 11:53 PM >> > To: kvalo@codeaurora.org >> > Cc: Abhishek Ambure <aambure@codeaurora.org>; >> > ath10k@lists.infradead.org >> > Subject: [EXT] Re: ath10k panic with 5.1 kernel and qca9984 on >> > association >> > >> > Abhishek, >> > I am happy to test a proposed fix, let me know. >> > >> > On Tue, May 28, 2019 at 4:22 AM Kalle Valo <kvalo@codeaurora.org> >> > wrote: >> >> >> >> + Abhishek >> >> >> >> Vjaceslavs Klimovs <vklimovs@gmail.com> writes: >> >> >> >> > With 5.1 and head kernel, machine running as AP with qca9984 locks >> >> > up without being able to complete stack trace to console after a >> >> > client tries to associate with it. Following are (OCR transcribed) >> >> > error >> >> > messages: >> >> > >> >> > [ 177.161539] BUG: unable to handle kernel paging request at >> >> > fffffffffffff7bo [ 177.161553] #PF error: (normal kernel read fault) >> >> > [ 177.161561] PGD 703812067 P4D 703812067 PUD 20381406 PMD 0 [ >> >> > 177.161571] Oops: 0000 (#1) SMP PTI [ 177.161577] CPU: 6 PID: 0 >> >> > Comm: swapper/6 Tainted: G OE 5.1.3-gentoo #1 >> >> > >> >> > [Garbage on screen after that point] >> >> > >> >> > and >> >> > >> >> > [67.805490] RBP: ffff9c4c57983d 18 R08: 0000000000000000 R09: >> >> > 0000000000000000 [67.805501] R10: 0000000000000002 R11: >> >> > 0000000000000000 R12: 0000000000000001 [67.805512] R13: >> >> > 0000000000000000 R14: 0000000000060002 R15: 0000000000000000 >> >> > [67.805523] FS: 000000000000000000000) GS:ffff9c4c57980000 (0000) >> >> > knIGS:000000000 [67.805535] CS: 0010 DS: 0000 ES: 0000 CRO: >> >> > 0000000080050033 >> >> > [67.805544] CR2: fffffffffffff7b0 CR3: 00000005f7e0e006 CR4: >> >> > 00000000003606e0 [67.805555] DRO: 0000000000000000 DR1: 0000000000000000 DR2: >> >> > 0000000000000000 [67.805566] DR3: 0000000000000000 DR6: >> >> > 00000000fffeoffO DR7: 0000000000000400 [67.805577] Call Trace: >> >> > [67.805582] <IRQ> >> >> > [67.805592] ath10k_htt_t2h_msg_handler+0xbda/0xf80 [ath10k_core] >> >> > [67.805603] ? _raw_spin_unlock_bh+0xie/0x20 [67.805614] ? >> >> > ath1ok_ce_per_engine_service+0xf1/0x100 [ath10k_corel [67.805626] >> >> > ath10k_pci_htt_rx_cb+0x172/0x260 [ath10k_pci] [67.8056391] >> >> > ath10k_ce_per_engine_service+0x9e/0x100 [ath10k_core) >> >> > >> >> > [Garbage on screen after that point] >> >> > >> >> > The issue does not reproduce on 5.0.17 but is reliably reproducible >> >> > in 5.1+ by just trying to associate to that AP. So I thought I'd run >> >> > git bisect. After bisecting, >> >> > >> >> > 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956, ath10k: add support for >> >> > ack rssi value of data tx packets >> >> > >> >> > is the first commit that triggers the problem. Reverting that commit >> >> > from head or from 5.1.5 reliably makes everything work as expected. >> >> >> >> Thank you for the bisect, this is really helpful. Full commit log >> >> below. >> >> Abhishek, please fix this or send a revert for 5.2. >> >> >> >> commit 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956 >> >> Author: Abhishek Ambure <aambure@codeaurora.org> >> >> AuthorDate: Mon Feb 25 11:45:48 2019 +0200 >> >> Commit: Kalle Valo <kvalo@codeaurora.org> >> >> CommitDate: Tue Feb 26 14:58:06 2019 +0200 >> >> >> >> ath10k: add support for ack rssi value of data tx packets >> >> >> >> In WCN3990, WMI_TLV_SERVICE_TX_DATA_MGMT_ACK_RSSI service >> >> Indicates that >> >> the firmware has the capability to send the RSSI value of the ACK >> >> for all >> >> data and management packets transmitted. >> >> >> >> If WMI_RSRC_CFG_FLAG_TX_ACK_RSSI is set in host capability then >> >> firmware >> >> sends RSSI value in "data" tx completion event. Host extracts ack >> >> rssi >> >> values of data packets from their tx completion event. >> >> >> >> Tested HW: WCN3990 >> >> Tested FW: WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1 >> >> >> >> Signed-off-by: Abhishek Ambure <aambure@codeaurora.org> >> >> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> >> >> >> >> -- >> >> Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ath10k panic with 5.1 kernel and qca9984 on association 2019-06-28 9:17 ` Balaji Pothunoori @ 2019-07-05 2:20 ` Vjaceslavs Klimovs 0 siblings, 0 replies; 7+ messages in thread From: Vjaceslavs Klimovs @ 2019-07-05 2:20 UTC (permalink / raw) To: Balaji Pothunoori; +Cc: Abhishek Ambure, ath10k, Kalle Valo Hi Balaji, This patch fixes it, thank you. On Fri, Jun 28, 2019 at 2:17 AM Balaji Pothunoori <bpothuno@codeaurora.org> wrote: > > Hi, > > Can you try with this patch ? > > https://patchwork.kernel.org/patch/11021495/ > > Regards, > Balaji. > > On 2019-06-01 23:37, Vjaceslavs Klimovs wrote: > > Hi Balaji, > > Thank you for looking into this. > > > > 1) x86_64 AP > > 2) Compex WLE1216V5-23 or WLE1216V5-20 card with QCA9984 > > 3) any kernel with commit 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956 > > present > > 4) kernel has DFS enabled and CONFIG_ATH10K_DFS_CERTIFIED=y, > > CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS=y, > > CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING=y set > > 5) any firmware from > > https://github.com/kvalo/ath10k-firmware/tree/master/QCA9984/hw1.0/3.9.0.2, > > see card initialization dmesg in my first message > > 6) hostapd with the following config: > > > > interface=wlp9s0 > > ctrl_interface=/var/run/hostapd > > bridge=br0 > > ssid=XXXXXXXX > > hw_mode=a > > chanlist=52 100 116 132 > > acs_chan_bias=116:0.1 132:0.1 > > country_code=US > > ieee80211d=1 > > ieee80211h=1 > > ieee80211n=1 > > ht_capab=[LDPC][HT40+][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40] > > ieee80211ac=1 > > vht_capab=[MAX-MPDU-11454][VHT160-80PLUS80][RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][RX-STBC-1][SU-BEAMFORMER][SU-BEAMFORMEE][BF-ANTENNA-4][SOUNDING-DIMENSION-4][MU-BEAMFORMER][MAX-A-MPDU-LEN-EXP7][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN] > > vht_oper_chwidth=1 > > auth_algs=1 > > wpa=2 > > wpa_key_mgmt=WPA-PSK > > wpa_passphrase=XXXXXXXX > > wpa_disable_eapol_key_retries=1 > > rsn_pairwise=CCMP > > wmm_enabled=1 > > ap_isolate=1 > > > > 7) any STA (ChromeOS, Android, Windows tried) triggers the crash. > > > > On Thu, May 30, 2019 at 6:58 AM Balaji Pothunoori > > <bpothuno@codeaurora.org> wrote: > >> > >> Hi, > >> > >> We are not seeing mentioned issue with following setup. > >> Setup details are : > >> AP - X86 with 5.1.0 kernel + QCA9984. > >> STA - Standard STA. > >> Observation : Crash is not observed during STA join. > >> > >> Could you please share the steps what you have followed ? > >> > >> Regards, > >> Balaji. > >> > >> > -----Original Message----- > >> > From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of > >> > Vjaceslavs Klimovs > >> > Sent: Tuesday, May 28, 2019 11:53 PM > >> > To: kvalo@codeaurora.org > >> > Cc: Abhishek Ambure <aambure@codeaurora.org>; > >> > ath10k@lists.infradead.org > >> > Subject: [EXT] Re: ath10k panic with 5.1 kernel and qca9984 on > >> > association > >> > > >> > Abhishek, > >> > I am happy to test a proposed fix, let me know. > >> > > >> > On Tue, May 28, 2019 at 4:22 AM Kalle Valo <kvalo@codeaurora.org> > >> > wrote: > >> >> > >> >> + Abhishek > >> >> > >> >> Vjaceslavs Klimovs <vklimovs@gmail.com> writes: > >> >> > >> >> > With 5.1 and head kernel, machine running as AP with qca9984 locks > >> >> > up without being able to complete stack trace to console after a > >> >> > client tries to associate with it. Following are (OCR transcribed) > >> >> > error > >> >> > messages: > >> >> > > >> >> > [ 177.161539] BUG: unable to handle kernel paging request at > >> >> > fffffffffffff7bo [ 177.161553] #PF error: (normal kernel read fault) > >> >> > [ 177.161561] PGD 703812067 P4D 703812067 PUD 20381406 PMD 0 [ > >> >> > 177.161571] Oops: 0000 (#1) SMP PTI [ 177.161577] CPU: 6 PID: 0 > >> >> > Comm: swapper/6 Tainted: G OE 5.1.3-gentoo #1 > >> >> > > >> >> > [Garbage on screen after that point] > >> >> > > >> >> > and > >> >> > > >> >> > [67.805490] RBP: ffff9c4c57983d 18 R08: 0000000000000000 R09: > >> >> > 0000000000000000 [67.805501] R10: 0000000000000002 R11: > >> >> > 0000000000000000 R12: 0000000000000001 [67.805512] R13: > >> >> > 0000000000000000 R14: 0000000000060002 R15: 0000000000000000 > >> >> > [67.805523] FS: 000000000000000000000) GS:ffff9c4c57980000 (0000) > >> >> > knIGS:000000000 [67.805535] CS: 0010 DS: 0000 ES: 0000 CRO: > >> >> > 0000000080050033 > >> >> > [67.805544] CR2: fffffffffffff7b0 CR3: 00000005f7e0e006 CR4: > >> >> > 00000000003606e0 [67.805555] DRO: 0000000000000000 DR1: 0000000000000000 DR2: > >> >> > 0000000000000000 [67.805566] DR3: 0000000000000000 DR6: > >> >> > 00000000fffeoffO DR7: 0000000000000400 [67.805577] Call Trace: > >> >> > [67.805582] <IRQ> > >> >> > [67.805592] ath10k_htt_t2h_msg_handler+0xbda/0xf80 [ath10k_core] > >> >> > [67.805603] ? _raw_spin_unlock_bh+0xie/0x20 [67.805614] ? > >> >> > ath1ok_ce_per_engine_service+0xf1/0x100 [ath10k_corel [67.805626] > >> >> > ath10k_pci_htt_rx_cb+0x172/0x260 [ath10k_pci] [67.8056391] > >> >> > ath10k_ce_per_engine_service+0x9e/0x100 [ath10k_core) > >> >> > > >> >> > [Garbage on screen after that point] > >> >> > > >> >> > The issue does not reproduce on 5.0.17 but is reliably reproducible > >> >> > in 5.1+ by just trying to associate to that AP. So I thought I'd run > >> >> > git bisect. After bisecting, > >> >> > > >> >> > 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956, ath10k: add support for > >> >> > ack rssi value of data tx packets > >> >> > > >> >> > is the first commit that triggers the problem. Reverting that commit > >> >> > from head or from 5.1.5 reliably makes everything work as expected. > >> >> > >> >> Thank you for the bisect, this is really helpful. Full commit log > >> >> below. > >> >> Abhishek, please fix this or send a revert for 5.2. > >> >> > >> >> commit 6ddc3860a5668808bacbfcb1f1bf50d5d7ad1956 > >> >> Author: Abhishek Ambure <aambure@codeaurora.org> > >> >> AuthorDate: Mon Feb 25 11:45:48 2019 +0200 > >> >> Commit: Kalle Valo <kvalo@codeaurora.org> > >> >> CommitDate: Tue Feb 26 14:58:06 2019 +0200 > >> >> > >> >> ath10k: add support for ack rssi value of data tx packets > >> >> > >> >> In WCN3990, WMI_TLV_SERVICE_TX_DATA_MGMT_ACK_RSSI service > >> >> Indicates that > >> >> the firmware has the capability to send the RSSI value of the ACK > >> >> for all > >> >> data and management packets transmitted. > >> >> > >> >> If WMI_RSRC_CFG_FLAG_TX_ACK_RSSI is set in host capability then > >> >> firmware > >> >> sends RSSI value in "data" tx completion event. Host extracts ack > >> >> rssi > >> >> values of data packets from their tx completion event. > >> >> > >> >> Tested HW: WCN3990 > >> >> Tested FW: WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1 > >> >> > >> >> Signed-off-by: Abhishek Ambure <aambure@codeaurora.org> > >> >> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> > >> >> > >> >> -- > >> >> Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-07-05 2:21 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-28 0:54 ath10k panic with 5.1 kernel and qca9984 on association Vjaceslavs Klimovs
2019-05-28 11:22 ` Kalle Valo
2019-05-28 18:23 ` Vjaceslavs Klimovs
[not found] ` <000001d516ec$fed6f190$fc84d4b0$@codeaurora.org>
2019-05-30 13:58 ` Balaji Pothunoori
2019-06-01 18:07 ` Vjaceslavs Klimovs
2019-06-28 9:17 ` Balaji Pothunoori
2019-07-05 2:20 ` Vjaceslavs Klimovs
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.