https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082007-07-11T01:59:01ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #727: unloading sound driver panics boxhttps://bugs.dragonflybsd.org/issues/727?journal_id=32072007-07-11T01:59:01Zdillon
<ul></ul><p>:<br />:we should switch back to spinlocks and maybe sync the sound code to FreeBSD-7.</p>
<pre><code>We can't use spinlocks in that code. FreeBSD assumes they are sleepable<br /> mutexes so we have to use lockmgr locks (which are basically the same<br /> thing).</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #727: unloading sound driver panics boxhttps://bugs.dragonflybsd.org/issues/727?journal_id=32102007-07-11T03:07:01Zcorecode
<ul></ul><p>actually it assumes so only in one place, the uaudio driver, and this is even a bug which has been fixed in freebsd-7. so i'd say let's sacrifice uaudio (seems our only consumer didn't come back) and make the rest work properly.</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #727: unloading sound driver panics boxhttps://bugs.dragonflybsd.org/issues/727?journal_id=32162007-07-11T05:41:01Zdillon
<ul></ul><p>:actually it assumes so only in one place, the uaudio driver, and this is =<br />:even a bug which has been fixed in freebsd-7. so i'd say let's sacrifice=<br />: uaudio (seems our only consumer didn't come back) and make the rest work=<br />: properly.<br />:<br />:cheers<br />: simon</p>
<pre><code>The design of the audio stuff does not fill me with confidence.<br /> I really think we need to stick with high level locks just from<br /> a safety and kernel stability point of view, because snafus <br /> will be a lot easier to debug. Our spinlocks are simply not<br /> designed (on purpose) to handle large swaths of code.</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #727: unloading sound driver panics boxhttps://bugs.dragonflybsd.org/issues/727?journal_id=32252007-07-11T14:48:01Zcorecode
<ul></ul><p>I agree, however we definitely want to avoid the interrupt thread blocking when grabbing the lock, because this will stall all interrupt processing on this IRQ. Spinlocks worked very well since the first import of the updated sound code, so we should keep them for this release. We can still find something better after the release.</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #727: unloading sound driver panics boxhttps://bugs.dragonflybsd.org/issues/727?journal_id=32272007-07-12T00:57:01Zdillon
<ul></ul><p>:I agree, however we definitely want to avoid the interrupt thread blockin=<br />:g when grabbing the lock, because this will stall all interrupt processin=<br />:g on this IRQ. Spinlocks worked very well since the first import of the =<br />:updated sound code, so we should keep them for this release. We can stil=<br />:l find something better after the release.<br />:<br />:cheers<br />: simon</p>
<pre><code>Interrupt threads have a higher priority then anything else. The<br /> moment the lock is released the thread will run. We don't<br /> do priority inheritence so it isn't perfect, but we also do not<br /> do preemptive scheduling between non-interrupt threads when a thread<br /> is in the kernel so it doesn't matter (the non-interrupt thread holding<br /> a sound lock will not be switched away).</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #727: unloading sound driver panics boxhttps://bugs.dragonflybsd.org/issues/727?journal_id=33352007-07-23T05:49:13Zcorecode
<ul></ul><p>hack committed.</p>