> Date: Thu, 7 Dec 2017 18:24:22 -0500 (EST)
> From: Mouse <mo...@rodents-montreal.org>
>
> db{0}> tr
> breakpoint() at netbsd:breakpoint+0x5
> comintr() at netbsd:comintr+0x53a
> Xintr_ioapic_edge7() at netbsd:Xintr_ioapic_edge7+0xeb
> --- interrupt ---
> x86_pause() at netbsd:x86_pause
> intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x16
> Xintr_ioapic_level5() at netbsd:Xintr_ioapic_level5+0xf3
> --- interrupt ---
> x86_pause() at netbsd:x86_pause+0x2
> cdev_poll() at netbsd:cdev_poll+0x6d
This stack trace suggests that you're in the middle of a busy-wait
loop somewhere inside your d_poll routine -- x86_pause is used between
iterations in a busy-wait. I suspect there may be an intermediate
call frame that ddb isn't picking up. It may be helpful to build with
all debug options enabled.
> On reflection, I think I know why. Userland's syscall handler took the
> mutex in preparation for cv_wait_sig(), the interrupt happens, my code
> is called (verified with a printf), and it tries to take the same mutex
> so it can cv_broadcast(). Of course, the mutex is held and, because
> it's held by code which can't run until the interrupt handler exits,
> will never be released. Then, when a hardware interrupt hit it found
> the biglock held....
cv_wait_sig releases the lock while it waits.
> I can of course provide more information if it would help, but I'm not
> sure what would be useful to mention here.
Can you provide the code you're using? Hard to guess otherwise.
