On Friday 27 July 2018 11:39:16 Mindaugas Rasiukevicius wrote:
> This is an indication that you are trying to acquire an adaptive lock
> while holding a spin-lock. Adaptive mutex (using IPL_NONE) blocks and,
> by design, you cannot block while holding a spin-mutex (> IPL_NONE).
> If you will
Phil Nelson wrote:
> I'm getting a mutex error here in that the lock is held.
> Backtrace:
> System panicked: LOCKDEBUG: Mutex error: mutex_vector_enter,528: spin
> lock held Backtrace from time of crash is available.
> crash> bt
> _KERNEL_OPT_NARCNET() at 0
> _KERNEL_OPT_ACPI_SCANPCI() at
On Thursday 26 July 2018 23:23:13 Taylor R Campbell wrote:
> Is this a conceptual problem, or do you have a symptom that you're
> actually hitting with specific code? If the latter, can you describe
> the symptom and quote the code?
Yes, this a real problem I'm having.
This is my real "f()":
Le 25/07/2018 à 19:56, Siddharth Muralee a écrit :
I guess that makes sense. Should I submit a patch for the same as you
suggested?
I've committed it. But in the end I used VM_MIN_KERNEL_ADDRESS, because
the variable being "kernelbase", it was less confusing. I guess we could
remove the
> Date: Thu, 26 Jul 2018 22:57:57 -0700
> From: Phil Nelson
>
> I'm trying to work with workqueues and am having a locking problem
Is this a conceptual problem, or do you have a symptom that you're
actually hitting with specific code? If the latter, can you describe
the symptom and quote
