https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082009-08-11T07:10:08ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70212009-08-11T07:10:08Zdillon
<ul></ul><p>:New submission from Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>>:<br />:<br />:I have a panic here with AHCI enabled. See screenshot here:=20<br />:http://omploader.org/vMjRueA. Console gets completely unusable and fills wi=<br />:th=20<br />:garbage.<br />:<br />:DragonFly dmesg with ahci disabled:<br />:http://leaf.dragonflybsd.org/~polachok/dmesg.dfly<br />:<br />:OpenBSD dmesg with ahci enabled:<br />:http://leaf.dragonflybsd.org/~polachok/dmesg.obsd</p>
<pre><code>Under what circumstances does the panic occur? During boot?</code></pre>
<pre><code>The softreset sequence is supposed to be serialized, so SACT<br /> shouldn't have any bits set (indicating active requests), let alone<br /> 7 bits set!</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70232009-08-11T16:59:59Zpolachok
<ul></ul><blockquote>
<p>Under what circumstances does the panic occur? During boot?</p>
</blockquote>
<p>Yes, during boot.</p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70242009-08-12T01:17:18Zdillon
<ul></ul><p>:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:<br />:<br />:>Under what circumstances does the panic occur? During boot?<br />:<br />:Yes, during boot.</p>
<pre><code>Hmm. Your AHCI part does not support NCQ so there is no SACT register<br /> at all on-chip. Here's a patch which should conditionalize-out the<br /> SACT register accesses:</code></pre>
<pre><code>fetch <a class="external" href="http://apollo.backplane.com/DFlyMisc/ahci07.patch">http://apollo.backplane.com/DFlyMisc/ahci07.patch</a></code></pre>
<pre><code>The actual crash is an assertion on the CI register, though, so my<br /> expectation is that it will still crash.</code></pre>
<pre><code>The ahci port stop/start sequence is supposed to clear CI. Another<br /> thing I tried in the patch was to put a delay between the port stop<br /> and port start, and also after the port start.</code></pre>
<pre><code>Lets see if either of these adjustments fixes your problem. if they<br /> do I'd like you to then remove the ahci_os_sleep() calls I added<br /> in the patch and test again, so I can determine what actual fix is<br /> needed.</code></pre>
<pre><code>If the problem still persists I'm a bit at a loss as the port stop/start<br /> sequence is always supposed to reset CI to 0.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70252009-08-12T02:56:26Zpolachok
<ul></ul><p>Still crashes: <a class="external" href="http://omploader.org/vMjR4Mg">http://omploader.org/vMjR4Mg</a></p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70292009-08-12T07:19:24Zdillon
<ul></ul><p>:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:<br />:<br />:Still crashes: <a class="external" href="http://omploader.org/vMjR4Mg">http://omploader.org/vMjR4Mg</a></p>
<pre><code>See if you can get the messages before the crash backtrace (see if<br /> you can get a crash that does not have a secondary NMI crash which<br /> scrolls the extra information I printed out off the screen).</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70302009-08-12T07:33:24Zdillon
<ul></ul><p>: See if you can get the messages before the crash backtrace (see if<br />: you can get a crash that does not have a secondary NMI crash which<br />: scrolls the extra information I printed out off the screen).</p>
<pre><code>Also see if you can get anything more out of it with a verbose boot.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70382009-08-12T20:28:39Zpolachok
<ul></ul><p>I built a UP kernel, now it fails like this:</p>
<p><a class="external" href="http://omploader.org/vMjUxcw">http://omploader.org/vMjUxcw</a><br />or<br /><a class="external" href="http://omploader.org/vMjUxdw">http://omploader.org/vMjUxdw</a></p>
<p>doesn't look like ahci-related at all to me, but happens only with ahci enabled.</p>
<p>With boot -v it scrolls too fast, so I cannot capture anything useful.</p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70422009-08-14T11:12:55Zdillon
<ul></ul><p>Ok, here's another AHCI patch to try.</p>
<pre><code>fetch <a class="external" href="http://apollo.backplane.com/DFlyMisc/ahci08.patch">http://apollo.backplane.com/DFlyMisc/ahci08.patch</a></code></pre>
<pre><code>It is a bit of a long-shot but I'm crossing my fingers. Your AHCI<br /> chipset is running ahci-1.1 and does not have the PMD bit set. It's<br /> possible that the disk identify command is overlapping a page-boundary<br /> and the AHCI chip is blowing up the machine when that occurs.</code></pre>
<pre><code>I'm a bit at a loss as the problem appears to be a bit<br /> non-deterministic.</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70432009-08-14T11:20:57Zdillon
<ul></ul><p>Also be sure you aren't special-casing your kernel build. i.e. not<br /> doing extra optimizations or anything like that.</p>
<pre><code>(I'm grasping at straws)</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70442009-08-14T12:26:03Zdillon
<ul></ul><p>I put a slightly updated patch up, same URL. I noticed a bug in the<br /> chip reset sequence. I don't know if it has anything to do with the<br /> problem but it is possible that chip did not get properly reset from<br /> a previous BIOS-created compatibility mode.</p>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70462009-08-14T17:56:13Zpolachok
<ul></ul><p>Now it looks like this (different on each boot, sometimes everything scrolls <br />quickly and fill the screen with crap, sometimes not):<br /> <a class="external" href="http://omploader.org/vMjVnZA">http://omploader.org/vMjVnZA</a></p>
<blockquote>
<p>Also be sure you aren't special-casing your kernel build. i.e. not<br />doing extra optimizations or anything like that.</p>
</blockquote>
<p>No. <br />$ cat /etc/make.conf <br />CITRUS_MODS=UTF8<br />KERNCONF=XEON</p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70492009-08-15T00:11:12Zdillon
<ul></ul><p>:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:</p>
<pre><code>Hmm. If the chip reset change didn't fix it... the CI register just<br /> could not possibly have a value of 0x00439cdb. It's impossible.<br /> So it must not be mapped properly or in the right mode.</code></pre>
<pre><code>Here is a new patch to try:</code></pre>
<pre><code>fetch <a class="external" href="http://apollo.backplane.com/DFlyMisc/ahci09.patch">http://apollo.backplane.com/DFlyMisc/ahci09.patch</a></code></pre>
<pre><code>This one plays some intel magic that may get the chipset into the<br /> correct operating mode. I wish intel wouldn't play these games,<br /> AHCI is supposed to be AHCI, not some bastardized compatibility mode<br /> that requires screwing around with to make it AHCI. The AE/HR sequence<br /> is supposed to do the job.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70502009-08-15T01:12:55Zpolachok
<ul></ul><p><a class="external" href="http://omploader.org/vMjVpZg">http://omploader.org/vMjVpZg</a></p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70512009-08-15T03:02:15Zdillon
<ul></ul><p>:<br />:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:<br />:<br />:http://omploader.org/vMjVpZg</p>
<pre><code>Ok, try this.</code></pre>
<pre><code>fetch <a class="external" href="http://apollo.backplane.com/DFlyMisc/ahci10.patch">http://apollo.backplane.com/DFlyMisc/ahci10.patch</a></code></pre>
<pre><code>Hopefully I coded it properly. I reordered some of the reset<br /> sequencing and also reordered the Intel hocus pocus, using the<br /> linux driver as a template.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70522009-08-15T03:32:15Zpolachok
<ul></ul><p><a class="external" href="http://omploader.org/vMjVqOQ">http://omploader.org/vMjVqOQ</a></p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70542009-08-15T04:25:14Zdillon
<ul></ul><p>:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:<br />:<br />:http://omploader.org/vMjVqOQ</p>
<pre><code>Is there just one hard drive in the system? This time it failed<br /> on port 4. The previous time it failed on port 3. The time before<br /> that it failed on port 0.</code></pre>
<pre><code>Reboot a couple of times. Is it failing on the same port every time<br /> or is it jumping around?</code></pre>
<pre><code>It shouldn't even be reaching the softreset code for the ports that<br /> do not have connected devices.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70552009-08-15T05:15:40Zpolachok
<ul></ul><blockquote>
<p>Is there just one hard drive in the system?</p>
</blockquote>
<p>Second one is connected to mpt (see <a class="external" href="http://bugs.dragonflybsd.org/issue1451">http://bugs.dragonflybsd.org/issue1451</a>).</p>
<blockquote>
<p>Reboot a couple of times. Is it failing on the same port every time<br />or is it jumping around?</p>
</blockquote>
<p>Finally, I opened the case and started to switch ports. It works okay (YEH!) <br />with ports from 2 to 5 (I tried 2 times each), with port 1 one time it hanged <br />and second time it worked. With port zero (where it was connected initially) it <br />fails in different manners, like <br />1.ahci0.0: <skipped> ci 00004014<br />2.alignment fault while in user mode (screen filled with garbage)<br />3.hangs (I waited for 5 minutes).</p>
<p>It's late here, so I'm going to sleep now and will continue my experiments <br />tomorrow.</p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70562009-08-15T05:25:08Zdillon
<ul></ul><p>:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:<br />:<br />:) it=20<br />:fails in different manners, like=20<br />:1=2Eahci0.0: <skipped> ci 00004014<br />:2=2Ealignment fault while in user mode (screen filled with garbage)<br />:3=2Ehangs (I waited for 5 minutes).<br />:<br />:It's late here, so I'm going to sleep now and will continue my experiments=20<br />:tomorrow.</p>
<pre><code>You know what that sounds like? That sounds like the chip is still<br /> going through a reset sequence. When you wake up tomorrow try adding<br /> various ahci_os_sleep() calls, starting with the one on line 143 of<br /> ahci.c. Try increasing that from 100 to 1000.</code></pre>
<pre><code>Then try adding another ahci_os_sleep() call near the end of ahci_init(),<br /> around line 202. And maybe a few others.</code></pre>
<pre><code>I sure hope that winds up being the case, though if it is I'll be<br /> really pissed at Intel because the chip reset is fully handshaked.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70582009-08-15T23:20:02Zpolachok
<ul></ul><p>I changed value to 1000 on line 143 and added ahci_os_sleep(1000) before return <br />in ahci_init. Still panics.</p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70672009-08-18T04:57:07Zdillon
<ul></ul><p>:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:<br />:<br />:I changed value to 1000 on line 143 and added ahci_os_sleep(1000) before re=<br />:turn=20<br />:in ahci_init. Still panics.</p>
<pre><code>Rumko is now getting a panic with a AHCI1.0 Intel chipset with the<br /> changes that he was NOT getting before the changes.</code></pre>
<pre><code>The results are very similar to what you got... what appears to be<br /> random memory corruption and in Rumko's case an immediate machine<br /> reboot and the BIOS configuration got messed up as well.</code></pre>
<pre><code>I feel they must be related issues. If Rumko and I can figure out<br /> which change caused his machine to stop booting it may give me a<br /> good idea where to look for the problem you are reporting.</code></pre>
<pre><code>What is really annoying to me is that the NATA driver is able to<br /> attach with its AHCI sub-driver. I don't know what I am doing<br /> different that is causing the breakage.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70682009-08-18T22:06:26ZTGEN
<ul></ul><p>Matthew Dillon wrote:</p>
<blockquote>
<p>:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:<br />:<br />:I changed value to 1000 on line 143 and added ahci_os_sleep(1000) before re=<br />:turn=20<br />:in ahci_init. Still panics.</p>
<p>Rumko is now getting a panic with a AHCI1.0 Intel chipset with the<br />changes that he was NOT getting before the changes.</p>
<p>The results are very similar to what you got... what appears to be<br />random memory corruption and in Rumko's case an immediate machine<br />reboot and the BIOS configuration got messed up as well.</p>
<p>I feel they must be related issues. If Rumko and I can figure out<br />which change caused his machine to stop booting it may give me a<br />good idea where to look for the problem you are reporting.</p>
<p>What is really annoying to me is that the NATA driver is able to<br />attach with its AHCI sub-driver. I don't know what I am doing<br />different that is causing the breakage.</p>
</blockquote>
<p>Perhaps your "if intel but AHCI is not enabled then write some value to<br />a particular config register" change. I'm thinking there's more work to<br />do to kick the chip into AHCI mode and not confuse the BIOS; besides<br />that, I think it's not clean. If the device doesn't advertise itself as<br />being an AHCI subclass, then don't try to force it.</p>
<p>Cheers,<br />-- <br /> Thomas E. Spanjaard<br /> <a class="email" href="mailto:tgen@netphreax.net">tgen@netphreax.net</a><br /> <a class="email" href="mailto:tgen@deepbone.net">tgen@deepbone.net</a></p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70692009-08-18T23:15:23Zdillon
<ul></ul><p>:Perhaps your "if intel but AHCI is not enabled then write some value to<br />:a particular config register" change. I'm thinking there's more work to<br />:do to kick the chip into AHCI mode and not confuse the BIOS; besides<br />:that, I think it's not clean. If the device doesn't advertise itself as<br />:being an AHCI subclass, then don't try to force it.</p>
<pre><code>I don't know what that kick code is for but the BIOS is already<br /> advertising the device as AHCI in the PCI configuration space.<br /> The AHCI driver only picks it up if it is advertised as AHCI.</code></pre>
<pre><code>I think you are onto something regarding the BIOS handoff, though.<br /> Combined with Rumko's report that the HR reset sequence seems to be<br /> the core of the issue that seems to indicate an issue with<br /> the BIOS supervisory code running in ring -1.</code></pre>
<pre><code>A third possibility is that the HR sequence is bricking the chip's<br /> PCI physical interface for a short while and that ANY access to the<br /> chip registers just after HR is set is blowing the system up.</code></pre>
<pre><code>A fourth possibility is that the HR sequence is not clearing the AHCI<br /> enable bit as it is supposed to, and perhaps cycling the AE bit will<br /> deal with the case.</code></pre>
<pre><code>So I would like to try two more things. First to try this patch:</code></pre>
<pre><code>fetch <a class="external" href="http://apollo.backplane.com/DFlyMisc/ahci11.patch">http://apollo.backplane.com/DFlyMisc/ahci11.patch</a></code></pre>
<pre><code>If the patch does not work, then modify line 141 from:</code></pre>
<pre><code>ahci_write(sc, AHCI_REG_GHC, AHCI_REG_GHC_AE | AHCI_REG_GHC_HR);</code></pre>
<pre><code>To:</code></pre>
<pre><code>ahci_write(sc, AHCI_REG_GHC, AHCI_REG_GHC_HR);</code></pre>
<pre><code>IF it can be gotten to work then I also want to try to reduce those<br /> 500ms delays I have in there to something more reasonable, like 200ms,<br /> and see if it continues to work.</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70802009-08-19T14:28:28Zdillon
<ul></ul><p>Please try the latest master. With Rumko's help testing all sorts of<br /> combinations I think we found the bricking issue.</p>
<pre><code>Basically Intel screwed up, but the bit in question is ancillary to the<br /> main operation of the chip so we can just not use it. It turns off<br /> the Phy on a port.</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70822009-08-19T18:23:36Zrumcic
<ul></ul><p>Matthew Dillon wrote:</p>
<blockquote>
<p>Please try the latest master. With Rumko's help testing all sorts of<br />combinations I think we found the bricking issue.</p>
<p>Basically Intel screwed up, but the bit in question is ancillary to the<br />main operation of the chip so we can just not use it. It turns off<br />the Phy on a port.</p>
<p>-Matt</p>
</blockquote>
<p>Confirming that the latest master does work.<br />-- <br />Regards,<br />Rumko</p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70832009-08-19T21:39:02Zpolachok
<ul></ul><p>Still panics with "ci not 0".</p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70842009-08-19T22:13:42Zdillon
<ul></ul><p>:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:<br />:<br />:Still panics with "ci not 0".<br />:</p>
<pre><code>Well, half the problem is solved. Does plugging the drive into<br /> different ports still help like it did before?</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70852009-08-19T23:25:36Zdillon
<ul></ul><p>Maybe we can track this down more quickly via IRC instead of <br /> email. on #dragonflybsd. Once Rumko got online we were able<br /> to run a ton of test cases in less then an hour.</p>
<pre><code>If the chipset crash has been fixed maybe cycling the port will<br /> fix the CI issue this time, so lets try that again. It also looks<br /> to me that there is a possible interrupt race. So try this patch:</code></pre>
<pre><code>fetch <a class="external" href="http://apollo.backplane.com/DFlyMisc/ahci12.patch">http://apollo.backplane.com/DFlyMisc/ahci12.patch</a></code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70862009-08-19T23:26:31Zpolachok
<ul></ul><blockquote>
<p>Does plugging the drive into<br />different ports still help like it did before?</p>
</blockquote>
<p>No. Now it panics with any port.</p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70882009-08-19T23:59:26Zpolachok
<ul></ul><blockquote>
<p>fetch <a class="external" href="http://apollo.backplane.com/DFlyMisc/ahci12.patch">http://apollo.backplane.com/DFlyMisc/ahci12.patch</a></p>
</blockquote>
<p>Holy crap! Works now! <a class="external" href="http://leaf.dragonflybsd.org/~polachok/dmesg.dfly">http://leaf.dragonflybsd.org/~polachok/dmesg.dfly</a></p> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70892009-08-20T00:10:32Zdillon
<ul></ul><p>:Alexander Polakov <<a class="email" href="mailto:polachok@gmail.com">polachok@gmail.com</a>> added the comment:<br />:<br />:>fetch <a class="external" href="http://apollo.backplane.com/DFlyMisc/ahci12.patch">http://apollo.backplane.com/DFlyMisc/ahci12.patch</a><br />:Holy crap! Works now! <a class="external" href="http://leaf.dragonflybsd.org/~polachok/dmesg.dfly">http://leaf.dragonflybsd.org/~polachok/dmesg.dfly</a><br />:</p>
<pre><code>Holy crap! That means it was an interrupt race with the <br /> initialization code. That patch makes sure that AHCI interrupts<br /> are not processed until all ports have gotten past the port<br /> initialization code.</code></pre>
<pre><code>Ok, I'll commit it. It took too long for me to find that bug.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1449: AHCI panic on Intel 6321ESB AHCIhttps://bugs.dragonflybsd.org/issues/1449?journal_id=70972009-08-21T02:04:09Zcorecode
<ul></ul><p>fixed</p>