DragonFly bugs List (threaded) for 2009-08
DragonFly BSD
DragonFly bugs List (threaded) for 2009-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: [issue1449] AHCI panic on Intel 6321ESB AHCI

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 18 Aug 2009 09:13:03 -0700 (PDT)

:Perhaps your "if intel but AHCI is not enabled then write some value to
:a particular config register" change. I'm thinking there's more work to
:do to kick the chip into AHCI mode and not confuse the BIOS; besides
:that, I think it's not clean. If the device doesn't advertise itself as
:being an AHCI subclass, then don't try to force it.

    I don't know what that kick code is for but the BIOS is already
    advertising the device as AHCI in the PCI configuration space.
    The AHCI driver only picks it up if it is advertised as AHCI.

    I think you are onto something regarding the BIOS handoff, though.
    Combined with Rumko's report that the HR reset sequence seems to be
    the core of the issue that seems to indicate an issue with
    the BIOS supervisory code running in ring -1.

    A third possibility is that the HR sequence is bricking the chip's
    PCI physical interface for a short while and that ANY access to the
    chip registers just after HR is set is blowing the system up.

    A fourth possibility is that the HR sequence is not clearing the AHCI
    enable bit as it is supposed to, and perhaps cycling the AE bit will
    deal with the case.

    So I would like to try two more things.  First to try this patch:

	fetch http://apollo.backplane.com/DFlyMisc/ahci11.patch

    If the patch does not work, then modify line 141 from:



	ahci_write(sc, AHCI_REG_GHC, AHCI_REG_GHC_HR);

    IF it can be gotten to work then I also want to try to reduce those
    500ms delays I have in there to something more reasonable, like 200ms,
    and see if it continues to work.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]