Description of problem:
On my opteron server
the x86_64 kernel detects only two out of four SATA drives.
I have the same problem with Fedora 7, I yum-ed to it to have the new
apps, but I still run a FC6 kernel, which detects them just fine.
I have two WD360GD-00FL (sda, sdb) - detected by F8- and two
ST3300831AS (sdc,sdd) - _not_ detected by F8.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot f8 test 2 install dvd or rescue cd
only sda and sdb detected (see f8 dmesg attachment)
sda, sdb, sdc and sdd detected (see fc6 dmesg attachment)
lspci -vvxxx output and dmesg from boot for fc6 (good) - f7 (bad) -f8 (bad)
Created attachment 211981 [details]
dmesg booting fc6
Created attachment 211991 [details]
dmesg booting f7
Created attachment 212001 [details]
dmesg booting f8
Created attachment 212011 [details]
lspci -vvxxx on fc6
Created attachment 212021 [details]
lspci -vvxxx on f7
Created attachment 212031 [details]
lspci -vvxxx on f8
Created attachment 212041 [details]
Screenshot hardware browser showing the four SATA drives on fc6
System apparently has two SATA controllers and only one is recognized in kernel
2.6.22. Moving all the drives to the first controller should work, but we still
need to figure out why the second controller isn't found...
(In reply to comment #8)
> System apparently has two SATA controllers and only one is recognized in kernel
> 2.6.22. Moving all the drives to the first controller should work, but we still
> need to figure out why the second controller isn't found...
From a performance perspective I prefer not to move the drives.
Let me know if there's anything I can do to help debug why the second controller
Try editing /etc/modprobe.conf and adding this line:
options sata_nv adma=0
Then rebuild the initrd with mkinitrd to see if adma mode is causing this.
For convenience, I did so with the F7 kernel 220.127.116.11-76.fc7 since I have it
installed and it exhibits the same problem - I didn't upgrade to F8 test 2 yet,
I only ran it from CD, which makes it hard to update the initrd. I hope that's OK?
Unfortunately, it did not help. I'll attach the output from mkinitrd -v and the
dmesg from startup with adma=0.
Created attachment 213011 [details]
output of mkinitrd -v with options sata_nv adma=0
Created attachment 213021 [details]
dmesg booting f7 with options sata_nv adma=0
Can you post the contents of both /proc/ioports and /proc/iomem from the working
kernel and from the broken kernel booted with ADMA disabled?
Created attachment 213041 [details]
/proc/ioports for the working fc6 kernel
Created attachment 213051 [details]
/proc/iomem for the working fc6 kernel
Created attachment 213061 [details]
/proc/ioports for the troubled f7 kernel
Created attachment 213071 [details]
/proc/iomem for the troubled f7 kernel
Supermicro motherboard, right? This looks like a duplicate of bug 280641.
Essentially the Supermicro BIOS is doing stupid things and reserving the MMIO
memory region of the SATA controllers as ACPI motherboard resources, which
prevents the sata_nv driver from attaching to it properly. Previously the kernel
did not respect these MMIO reservations so it still worked.
Unless we add some system-specific quirk or something, or Supermicro fixes their
BIOS, likely the best we can do is allow the controller to still work in a
crippled mode (using PIO instead of MMIO, and no ADMA or NCQ) without this MMIO
(In reply to comment #19)
> Supermicro motherboard, right? This looks like a duplicate of bug 280641.
> Unless we add some system-specific quirk or something, or Supermicro fixes their
> BIOS, likely the best we can do is allow the controller to still work in a
> crippled mode (using PIO instead of MMIO, and no ADMA or NCQ) without this MMIO
Well, since I don't expect a bios fix to come through, a system-specific
work-around would have my preference. Or if I just knew which change between
2.6.22 and older kernels to revert out so sata_nv can grab the memory I'd roll
my own kernel.
Created attachment 224861 [details]
disable motherboard resources that overlap PCI BARs
As a temporary workaround, you can probably use "pnpacpi=off" (from bug
I agree that this looks like a BIOS issue. For debugging purposes, could you
try this patch? It should make PNP skip the resource that conflicts with the
BAR. I'm not completely comfortable with the approach, but if it works, maybe
we can figure out a cleaner way.
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel or did you try the patch above?
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
Your nudge motivated me to finally complete my upgrade to F8 (I had another
problem with that not related to this bugzilla) so I could confirm my workaround
before closing this bug.
One of the earlier posts suggested this might be a BIOS related issue, and that
does seem to be the case. Anyway, if I boot with "pnpacpi=off", all drives are
This got closed as "not a bug", but I think that is wrong.
"pnpacpi=off" isn't really a fix for this problem. We need a real fix in the
kernel so users don't have to use that boot argument.
Willem, can you try the patch in comment #21, report the result, and attach
the dmidecode for your system? If we need to make a system-specific
workaround, the dmidecode data will be needed.
The patch in comment #21 isn't system-specific, it just ignores any ACPI
reservation that overlaps with a PCI BAR as being bogus. I think that is the
I'll go ahead and re-open this, since Bjorn and Robert believe that this patch
should be integrated. I've also changed the subject.
Created attachment 291906 [details]
Supermicro H8DCE dmidecode
This dmidecode information was collected by Matthew Hall. His bug report
information is here:
Created attachment 291907 [details]
disable selected Supermicro H8DCE motherboard resources
This is a more specific patch than the one in comment #21. The general
approach taken in comment #21 would be nice, but it makes the assumption that
we know about PCI devices before the PNP motherboard driver initializes. I
don't think that safe, so I think this patch is a better approach.
I asked Matthew to test this patch. Willem, if you have a chance to test it as
well, that would be great.
I applied the latest patch to fc8 kernel 18.104.22.168-107 source and rebuilt the
x86_64 kernel, and confirmed that the result works for me. The only issue I had
is that to get the patch to take, I had to edit it as the fc8 kernel doesn't
seem to include kallsyms.h in quirks.c
(In reply to comment #28)
> Created an attachment (id=291907) 
> disable selected Supermicro H8DCE motherboard resources
Is this patch going upstream?
Does anybody have Windows running on this Supermicro board? I'd like to see
what the device manager says about these resources.
I solved this problem with a DELL PERC5i on a H8DCE MB.
What resources do you need? I try to see it in resource manager.
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.