Hi Gregory, On Wed, Jun 22, 2022 at 10:08:15PM -0700, Gregory Erwin wrote: > Hello, > > I bisected down to commit [fcd09c90c3c5] "ath9k: use hw_random API instead of > directly dumping into random.c'' while investigating a long delay when entering > suspend on kernels v5.18 onward. There are other reports of hangs or > unresponsiveness at https://bugs.archlinux.org/task/75138 with some more info. > > AFAIKT, the issue is triggered by the ath9k hwrng when the interface is up, > but not associated with any AP. In this state, 'dd if=/dev/hwrng' will block > for up to 231 seconds before finally returning an input/output error. Similarly, > I get a kernel log message "hwrng: no data available" every 231 seconds. > > The hwrng will unblock when attempting to connect to an SSID that doesn't exist, > but not when performing a scan, so I'm guessing AR_PHY_TST_ADC only produces new > data when the phy is transmitting. > > Admittedly, I don't actually know if this blocking behavior is > expected or not, but it certainly seems undesirable. Thanks for the report. I wish somebody from one of those bug reports would have emailed earlier. I don't have hardware to test this, but could you let me know if the below patch does something? I'm sort of guessing, but maybe this is right? Jason diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c index cb5414265a9b..a6291f5f0d47 100644 --- a/drivers/net/wireless/ath/ath9k/rng.c +++ b/drivers/net/wireless/ath/ath9k/rng.c @@ -80,7 +80,7 @@ static int ath9k_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait) bytes_read += max & 3UL; memzero_explicit(&word, sizeof(word)); } - if (!wait || !max || likely(bytes_read) || fail_stats > 110) + if (!wait || !max || likely(bytes_read) || fail_stats > 110 || kthread_should_stop()) break; msleep_interruptible(ath9k_rng_delay_get(++fail_stats));
