On Mon, Mar 25, 2019 at 3:14 PM Brian Norris wrote:
> On Mon, Mar 25, 2019 at 2:20 PM Michał Kazior wrote:
> > For one, you'll need to defer ath10k_pci_fw_crashed_dump to a worker.
> > Maybe into ar->restart_work which the dump function calls now.
>
> Hmm, that's an idea -- although I'm not sure
Hi Michal,
Thanks for the quick and useful response.
On Mon, Mar 25, 2019 at 2:20 PM Michał Kazior wrote:
> On Mon, 25 Mar 2019 at 21:27, Brian Norris wrote:
> > It would appear that this triggers new warnings
> >
> > BUG: sleeping function called from invalid context
> >
> > when handling
Hi Brian,
On Mon, 25 Mar 2019 at 21:27, Brian Norris wrote:
> Hi Kalle,
>
> On Wed, Feb 06, 2019 at 05:41:43PM -0800, Brian Norris wrote:
> > The DIAG copy engine is only used via polling, but it holds a spinlock
> > with softirqs disabled. Each iteration of our read/write loops can
> >
Hi Kalle,
On Wed, Feb 06, 2019 at 05:41:43PM -0800, Brian Norris wrote:
> The DIAG copy engine is only used via polling, but it holds a spinlock
> with softirqs disabled. Each iteration of our read/write loops can
> theoretically take 20ms (two 10ms timeout loops), and this loop can be
> run an
Brian Norris wrote:
> The DIAG copy engine is only used via polling, but it holds a spinlock
> with softirqs disabled. Each iteration of our read/write loops can
> theoretically take 20ms (two 10ms timeout loops), and this loop can be
> run an unbounded number of times while holding the spinlock
The DIAG copy engine is only used via polling, but it holds a spinlock
with softirqs disabled. Each iteration of our read/write loops can
theoretically take 20ms (two 10ms timeout loops), and this loop can be
run an unbounded number of times while holding the spinlock -- dependent
on the request
