https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082012-04-28T01:39:25ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #2353: panic: assertion "gd->gd_spinlocks_wr == 0" failed in bsd4_schedulerclockhttps://bugs.dragonflybsd.org/issues/2353?journal_id=107922012-04-28T01:39:25Zvsrinivasvsrinivas@ops101.org
<ul></ul><p>If you could upload the dump to leaf or someplace accessible, that would be very useful!</p>
<p>Thanks,<br />-- vs;</p> DragonFlyBSD - Bug #2353: panic: assertion "gd->gd_spinlocks_wr == 0" failed in bsd4_schedulerclockhttps://bugs.dragonflybsd.org/issues/2353?journal_id=108082012-05-03T17:35:18Zjaydg
<ul></ul><p>I've uploaded the dump on leaf, ~jaydg/crash/2353.</p> DragonFlyBSD - Bug #2353: panic: assertion "gd->gd_spinlocks_wr == 0" failed in bsd4_schedulerclockhttps://bugs.dragonflybsd.org/issues/2353?journal_id=108122012-05-05T04:49:06Zvsrinivasvsrinivas@ops101.org
<ul></ul><p>Some preliminary debugging:</p>
<p>was in 'moused' thread, we were interrupted or somehow called splz. We were probably in a critical section; crit_exit can splz() itself.</p>
<p>splz<br /> ++critcount from splz itself (exp critcount=1)</p>
<pre><code>splz_timer<br /> lapic_timer_process<br /> lapic_timer_process_oncpu<br /> systimer_intr<br /> ++crit_enter from systimer_intr (exp.cc=2)<br /> ++gd_syst_next from systimer_intr</code></pre>
<pre><code>--crit_enter from systimer_intr (exp.cc=1)</code></pre>
<pre><code>schedclock [first systimer]</code></pre>
<pre><code>lp = 'moused thread'</code></pre>
<pre><code>bsd4_schedulerclock</code></pre>
<pre><code>on CPU0; below rrinterval, no need_user_resched<br /> [exp.critcount=1, found cc=4]</code></pre>
<pre><code>(pollclock)<br /> (emergency_intr_timer_callback)<br /> (hardclock)<br /> (statclock)</code></pre> DragonFlyBSD - Bug #2353: panic: assertion "gd->gd_spinlocks_wr == 0" failed in bsd4_schedulerclockhttps://bugs.dragonflybsd.org/issues/2353?journal_id=108342012-05-19T05:13:34Zvsrinivasvsrinivas@ops101.org
<ul></ul><p>Okay,</p>
<p>The problem is that we hold an MTX spinlock while attempting to go to sleep. The specific callpath and problem is that we hold the syscons MTX spinlock at :769, :771 of sys/dev/misc/syscons/syscons.c, around a device ioctl routine which may explicitly tsleep. The specific tsleep in question is via sysmouse_event, ultimately hitting kern_kevent and sleeping in kqueue.</p>
<p>First, why are we using MTX spinlocks at all?</p>
<p>Second, it is probably inappropriate to hold an MTX spinlock around the entire ioctl path here. The path gets the tty_token, among many other things, the chances of blocking are high.</p>
<p>What is it synchronizing that the tty_token is not?</p> DragonFlyBSD - Bug #2353: panic: assertion "gd->gd_spinlocks_wr == 0" failed in bsd4_schedulerclockhttps://bugs.dragonflybsd.org/issues/2353?journal_id=111302012-11-28T09:57:51Zalexh
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> set to <i>alexh</i></li></ul>