On 06/04/2023 18:09, Martin Kaistra wrote: > Am 06.04.23 um 02:42 schrieb Ping-Ke Shih: >> >> >>> -----Original Message----- >>> From: Martin Kaistra <martin.kaistra@xxxxxxxxxxxxx> >>> Sent: Wednesday, April 5, 2023 11:31 PM >>> To: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> >>> Cc: Jes Sorensen <Jes.Sorensen@xxxxxxxxx>; Kalle Valo <kvalo@xxxxxxxxxx>; Ping-Ke Shih >>> <pkshih@xxxxxxxxxxx>; Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>; linux-wireless@xxxxxxxxxxxxxxx >>> Subject: Re: [RFC PATCH 00/14] wifi: rtl8xxxu: Add AP mode support for 8188f >>> >>> Am 23.03.23 um 18:12 schrieb Bitterblue Smith: >>>> On 22/03/2023 19:18, Martin Kaistra wrote: >>>> Then I was able to turn on the AP and connect my phone to it. However, >>>> the system froze after a few seconds. I had `journalctl --follow` >>>> running. The last thing printed before the system froze was the DHCP >>>> stuff (discover, offer, request, ack). The phone said it was connected, >>>> but speedtest.net didn't have time to load before the freeze. >>> >>> Hi >>> >>> I could reproduce a frozen system with my hostapd setup, though it >>> doesn't happen reliably and I don't have an error message when it happens. >>> >> >> Using netcat would help to capture useful messages when system gets frozen. >> >> Ping-Ke >> > > Thanks. I got a trace by using netconsole and netcat. It is a NULL pointer dereference in rtl8xxxu_fill_txdesc_v2(): > > > if (rate_flags & IEEE80211_TX_RC_MCS && > !ieee80211_is_mgmt(hdr->frame_control)) > rate = tx_info->control.rates[0].idx + DESC_RATE_MCS0; > else > rate = tx_rate->hw_value; <-- error happens here > > if (rtl8xxxu_debug & RTL8XXXU_DEBUG_TX) > dev_info(dev, "%s: TX rate: %d, pkt size %u\n", > > This happens when ieee80211_get_tx_rate() hits the WARN_ON_ONCE and maybe also when c->control.rates[0].idx has another invalid value. > See my previous comments about HAS_RATE_CONTROL. Good job finding the problem! ieee80211_get_tx_rate() is used since the initial commit, so only Jes may know why. I assume we only ever need to use the rate from mac80211 for frame injection (IEEE80211_TX_CTRL_RATE_INJECT, currently ignored). If c->control.rates[0].idx is negative, is c->control.rates[0].flags also unusable? ieee80211_get_rts_cts_rate() probably causes the same problem.
