Hey again, On Fri, Jun 24, 2022 at 1:47 AM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > Hey Gregory, > > On Fri, Jun 24, 2022 at 1:36 AM Gregory Erwin <gregerwin256@xxxxxxxxx> wrote: > > > > No luck. > > > > The first patch caused a warning and oops with ath9k_rng_read() at the > > top of the call stack when reading from /dev/hwrng: > > WARNING: CPU: 1 PID: 454 at kernel/kthread.c:75 kthread_should_stop+0x2a/0x30 > > BUG: kernel NULL pointer dereference, address: 0000000000000000 > > > > The second didn't have a noticeable effect, for better or worse. > > Alright. That's actually getting us somewhere. So the path in question > here is from reading /dev/hwrng, not from the kthread that's doing the > same read. > > Can you do a `cat /dev/hwrng > /dev/null`, and then do whatever it is > you do that causes everything to hang, and then while things are hung > in the bad way, look at the contents of /proc/[the pid of the cat you > just ran]/stack? There's another flow I'm interested in. You said it prevents the system from sleeping. Does it also make a `ip link set wlan0 down` hang too? If so, could you send the `/proc/[pid of ip link set down]/stack ` of a hung ip process? That seems like the more relevant deadlock to look into. Jason
