Bug 15841 - dell optiplex 755 with sata controller in ahci mode won't boot without pci=nocrs
dell optiplex 755 with sata controller in ahci mode won't boot without pci=nocrs
Status: CLOSED DUPLICATE of bug 15744
Product: ACPI
Classification: Unclassified
Component: Config-Other
All Linux
: P1 normal
Assigned To: Bjorn Helgaas
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-23 12:25 UTC by Andy Bailey
Modified: 2010-09-29 01:23 UTC (History)
2 users (show)

See Also:
Kernel Version:
Tree: Mainline
Regression: Yes


Attachments
dmesg with sata controller in ahci mode, acpi debug + patches, crs disabled (29.87 KB, application/octet-stream)
2010-04-23 12:27 UTC, Andy Bailey
Details
dmesg with sata controller in ata mode, acpi debug + patches, crs enabled (29.89 KB, application/octet-stream)
2010-04-23 12:28 UTC, Andy Bailey
Details
serial boot capture with ahci enabled, crs enabled (103.34 KB, application/octet-stream)
2010-04-23 13:32 UTC, Andy Bailey
Details

Description Andy Bailey 2010-04-23 12:25:40 UTC
email thread between Bjorn and I:

On Thursday 22 April 2010 01:42:01 pm R. Andrew Bailey wrote:
>   I noticed a couple of recent kernel bugs that you fielded, having to
>   do with achi controllers having issues at boot time. I think I've got
>   another example for you- this is a little Dell Optiplex 755 that
>   won't boot if the bios "SATA Operation" setting is configured for
>   "AHCI" and I don't append pci=nocrs.
>
>   I've got /proc/iomem with the controller set to AHCI and pci=nocrs
>   below, but I couldn't get Bjorns debug patch to apply to 2.6.34-rc4,
>   was hoping maybe you had an updated patch I could try?
>
>   Anyhow thanks in advance! I was about to open a bugzilla CR, but I
>   wasn't sure how to generate a boot log, or whether this might be a
>   reopening of an existing bug.

Uh, oh.  We're getting very late in the cycle, and we don't have much
time to debug this.

  - These patches:
        https://patchwork.kernel.org/patch/90852/
        https://patchwork.kernel.org/patch/93704/
    are on their way upstream, but aren't there yet.  Please test them
    first, just in case they fix the problem.  If they do, we should
    go right out and buy some lottery tickets while our luck is good.

    But more likely, this is some new problem, and we'll have to debug
    it by collecting the information below.

  - The patch below applies to current upstream (c81eddb0e372).  If you
    can apply it, set CONFIG_ACPI_DEBUG=y, and boot with
    "acpi.debug_level=0x00010000 acpi.debug_layer=0x00000100" for all
    the tests below, that would be great.

  - Boot with controller set to non-AHCI.  This works, even though
    we're using _CRS.  Right?  Can you collect the dmesg log for this?

  - Boot with controller set to AHCI.  This fails, right?  Any log
    you can collect (e.g., boot with "ignore_loglevel" and use serial
    console, netconsole, digital video, photo, etc) would be helpful.

  - Boot with controller set to AHCI and "pci=nocrs".  This works, right?
    I'd like to see the complete dmesg log.
Comment 1 Andy Bailey 2010-04-23 12:27:47 UTC
Created attachment 26111 [details]
dmesg with sata controller in ahci mode, acpi debug + patches, crs disabled
Comment 2 Andy Bailey 2010-04-23 12:28:44 UTC
Created attachment 26112 [details]
dmesg with sata controller in ata mode, acpi debug + patches, crs enabled
Comment 3 Andy Bailey 2010-04-23 12:29:07 UTC
should be able to get you the abortive boot log this morning. My kingdom for a serial cable.
Comment 4 Andy Bailey 2010-04-23 13:32:17 UTC
Created attachment 26113 [details]
serial boot capture with ahci enabled, crs enabled
Comment 5 Bjorn Helgaas 2010-04-26 17:48:39 UTC
Thanks again for your help, Andy.  I'm going to resolve this as a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=15744 so we can keep all the future discussion in one place.

*** This bug has been marked as a duplicate of bug 15744 ***

Note You need to log in before you can comment on or make changes to this bug.