Description of problem: On my opteron server http://smolt.fedoraproject.org/show?UUID=0fdd6288-6cb2-497e-a1a5-6459d9c8abde 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): 2.6.23-0.164.rc5.fc8 How reproducible: 100% Steps to Reproduce: 1. boot f8 test 2 install dvd or rescue cd 2. 3. Actual results: only sda and sdb detected (see f8 dmesg attachment) Expected results: sda, sdb, sdc and sdd detected (see fc6 dmesg attachment) Additional info: 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 isn't found.
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 2.6.22.5-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 region.
(In reply to comment #19) > Supermicro motherboard, right? This looks like a duplicate of bug 280641. Yes, supermicro. > 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 > region. 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 280641). 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. http://fedoraproject.org/wiki/KernelBugTriage 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 properly recognized.
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. Thanks!
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 better approach.
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: http://lkml.org/lkml/2008/1/9/449 http://thread.gmane.org/gmane.linux.acpi.devel/27312
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 2.6.23.14-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) [edit] > 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.