Description of problem: The 5th (or more) SATA drive is not recognized after booting a 2.6.22 kernel found in Fedora 6 and Fedora 7. The motherboard is a Supermicro h8dce which can control 8 SATA drives. The driver used is sata_nv 3.4 for the 2.6.22 kernels. An error in the dmesg: sata_nv: probe of 0000:80:07.0 failed with error -16 ACPI: PCI Interrupt Link [LT2E] enabled at IRQ 46 ACPI: PCI Interrupt 0000:80:08.0[A] -> Link [LT2E] -> GSI 46 (level, low) -> IRQ 46 sata_nv 0000:80:08.0: Using ADMA mode PCI: Unable to reserve mem region #6:1000@dfefd000 for device 0000:80:08.0 ACPI: PCI interrupt for device 0000:80:08.0 disabled sata_nv: probe of 0000:80:08.0 failed with error -16 Version-Release number of selected component (if applicable): 2.6.22 kernels such as 2.6.22.1-32.fc6 2.6.22.1-41.fc7 How reproducible: Every time I boot a 2.6.22 kernel but not when I boot a 2.6.20 kernel. 2.6.20 kernels have no problem recognizing the 5th drive. Steps to Reproduce: 1. Use 2.6.22 kernel 2. Use 5 or more SATA drives on a Supermicro h8dce motherboad 3. Boot system and observe that 5th drive doesn't get recognized in /proc/partitions Actual results: Fail to load 5th SATA drive Expected results: Load 5th SATA drive Additional info:
Created attachment 188831 [details] /var/log/message from trying to boot a 2.6.22 kernel
Can you post the boot messages from 2.6.20?
Also, post output of 'lspci -vvxxx' from both new and old kernels.
Created attachment 189881 [details] lscpi -vvxxx of kernel 2.6.22.1-41.fc7 with problems recongizing 5th SATA drive
Created attachment 189891 [details] lscpi -vvxxx of kernel 2.6.20-1.2933.fc6 which can recognize 5th SATA drive
Created attachment 189901 [details] /var/log/message from booting a 2.6.20 kernel
The last BAR on the nForce4 ADMA controllers on this board are at 0xdfefe000 and 0xdfefd000. But it looks like PnP ACPI is also reserving those memory ranges: Aug 30 14:08:02 alcor kernel: pnp: 00:09: iomem range 0xdfefd000-0xdfefd3ff has been reserved Aug 30 14:08:02 alcor kernel: pnp: 00:09: iomem range 0xdfefe000-0xdfefe3ff has been reserved Which I very much doubt it should be doing, the BIOS doesn't need to reserve PCI BAR ranges in the ACPI tables. This sounds like a BIOS bug. You might want to check if there is an update from Supermicro.
Created attachment 192761 [details] dmesg output from booting 2.6.22 kernel after bios update dmesg from booting 2.6.22 kernel with bios update on motherboard to V1.1b Error in log shows: sata_nv 0000:80:07.0: Using ADMA mode PCI: Unable to reserve mem region #6:1000@dfefe000 for device 0000:80:07.0 ACPI: PCI interrupt for device 0000:80:07.0 disabled sata_nv: probe of 0000:80:07.0 failed with error -16
Created attachment 192771 [details] lspci -vvxxx with bios update
Disabling ADMA should work, then? Karl, try adding this line to /etc/modprobe.conf: options sata_nv adma=0 Then rebuild the initrd with mkinitrd.
Created attachment 192931 [details] dmesg with adma turned off (new mkinitrd) Kernel 2.6.22.1-41.fc7 with 1.1b bios and adma=0 in /etc/modprobe.conf Followed by /sbin/mkinitrd /boot/initrd-2.6.22.1-41.fc7.img 2.6.22.1-41.fc7 Reboot, and same failure. PCI: Unable to reserve mem region #6:1000@dfefe000 for device 0000:80:07.0 ACPI: PCI interrupt for device 0000:80:07.0 disabled sata_nv: probe of 0000:80:07.0 failed with error -16 From reading dmesg, it appears that the adma is not being used. Below I grepped for ADMA between booting without ADMA and with ADMA and it appears I did indeed boot without ADMA, but the problem persists. [kdb@alcor ~]$ grep ADMA alcor.dmesg.2.6.22.1-41.fc7.v1.1b.adma0.txt [kdb@alcor ~]$ grep ADMA alcor.dmesg.2.6.22.1-41.fc7.v1.1b.txt sata_nv 0000:00:07.0: Using ADMA mode sata_nv 0000:00:08.0: Using ADMA mode sata_nv 0000:80:07.0: Using ADMA mode sata_nv 0000:80:08.0: Using ADMA mode
Here are the greps for the problem: [kdb@alcor ~]$ grep "Unable" alcor.dmesg.2.6.22.1-41.fc7.v1.1b.adma0.txt PCI: Unable to reserve mem region #6:1000@dfefe000 for device 0000:80:07.0 PCI: Unable to reserve mem region #6:1000@dfefd000 for device 0000:80:08.0 [kdb@alcor ~]$ grep "Unable" alcor.dmesg.2.6.22.1-41.fc7.v1.1b.txt PCI: Unable to reserve mem region #6:1000@dfefe000 for device 0000:80:07.0 PCI: Unable to reserve mem region #6:1000@dfefd000 for device 0000:80:08.0
Just disabling ADMA won't help since the code still requests that memory region even if ADMA is disabled, since the code still wants to use that memory region on nForce4 even if ADMA is disabled. That behavior has not changed for a long time. It seems like what has changed is that we now honor the PnPACPI MMIO reservations that the BIOS provides whereas we didn't before? There's no sign of the PnPACPI subsystem reserving I/O regions on the 2.6.20 dmesg. In any case, however, I think this is still a cause to complain to Supermicro about why they are reserving this region. Working around this in sata_nv will at best result in using the controller in a quite sub-optimal mode (no NCQ support, etc.)
I emailed support and referenced this bug. I do have to say that sub-optimal mode is better than not having the drive recognized at all. Perhaps have a warning about the failure when you go into that mode.
Created attachment 194851 [details] dmesg output, testing new BIOS sent by Supermicro, no ADMA This is a new BIOS sent by Supermicro. It says version 1.1b but has a date of 9-12-07. ADMA is still turned off in the 2.6.22.1-41.fc7 kernel because I forgot to rerun mkinitrd. I don't think it matters. Same problem exists.
Is this BIOS supposed to fix this problem? It seems to still have the same bad iomem reservations as before.
Well...he didn't say..he just said try this beta BIOS and hoped it would fix it. I tried kernel-2.6.22.9-91.fc7 and it has the same trouble. I am still using a 2.6.20 kernel...
Len Brown on LKML suggested adding pnpacpi=off to the kernel command line and seeing if the problem goes away.
2.6.23 on the H8DCE initializes all 8 SATA disks using pnpacpi=off. (Without it, 2.6.23 has the same problem as the other post-2.6.20 kernels) What sort of performance implication does this have?
pnpacpi=off does make the problem go away with kernel 2.6.22.9-91.fc7 as well. ADMA mode seems to be available and I am not disabling it. sata_nv 0000:80:07.0: Using ADMA mode
This looks like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=313491. I added a patch there for testing.
pnpacpi=off doesn't have any performance implications - the only potential problem it causes is that it causes us to ignore all of the BIOS-reported reserved resources, so if we decide to map something at those locations we could run into problems..
Hello, 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? 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.
This problem hasn't been fixed (or rather, worked around) yet, however it is the same problem as bug 313491 and one of them should likely be marked as duplicate.
Though that bug has been resolved using: pnpacpi=off which I take it does not work for you? I'm attaching Bjoern's patch here and re-assigning so it can be reviewed and hopefully merged. Also adding SATA metabug as blocker... Cheers Chris
Created attachment 291534 [details] Bjorn Helgaas patch for supermicro board quirk
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.
Created attachment 297065 [details] current proposed PNP system quirk How did you solve this problem? There is a quirk in the current upstream kernel (2.6.25-rc3) that should work around it, at least on the H8DCE motherboard. However, there are similar problems on other systems, so I'm now thinking that the attached patch is a better approach. As far as the Windows question, I'm just interested in how Windows reports these resources in the Control Panel Device Manager. I expect the "Motherboard resources" item under "System devices" to show a memory range like 0xdfefd000-0xdfefd3ff. But maybe it has a note about a conflict with the PCI device? I'm also curious about what resources it reports for the SATA PCI device.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'. 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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 306040 [details] System resource allocation report under Windows XP. Sorry for being so late. I attach the Windows resource allocation report.
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 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.