Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[PATCH] Failure to recognize 5th SATA drive due to PCI: Unable to reserve mem region|
|Product:||[Fedora] Fedora||Reporter:||Karl Bellve <karl.bellve>|
|Component:||kernel||Assignee:||Jeff Garzik <jgarzik>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||7||CC:||bjorn.helgaas, hancockrwd, peterm, skarsol, snecklifter, triage|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-06-16 22:20:39 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Karl Bellve 2007-09-06 10:38:37 EDT
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 188.8.131.52-32.fc6 184.108.40.206-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:
Comment 1 Karl Bellve 2007-09-06 10:38:37 EDT
Created attachment 188831 [details] /var/log/message from trying to boot a 2.6.22 kernel
Comment 2 Chuck Ebbert 2007-09-06 10:42:58 EDT
Can you post the boot messages from 2.6.20?
Comment 3 Chuck Ebbert 2007-09-06 18:05:32 EDT
Also, post output of 'lspci -vvxxx' from both new and old kernels.
Comment 4 Karl Bellve 2007-09-07 09:00:01 EDT
Created attachment 189881 [details] lscpi -vvxxx of kernel 220.127.116.11-41.fc7 with problems recongizing 5th SATA drive
Comment 5 Karl Bellve 2007-09-07 09:02:10 EDT
Created attachment 189891 [details] lscpi -vvxxx of kernel 2.6.20-1.2933.fc6 which can recognize 5th SATA drive
Comment 6 Karl Bellve 2007-09-07 09:13:31 EDT
Created attachment 189901 [details] /var/log/message from booting a 2.6.20 kernel
Comment 7 Robert Hancock 2007-09-10 21:43:11 EDT
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.
Comment 8 Karl Bellve 2007-09-11 14:01:53 EDT
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
Comment 9 Karl Bellve 2007-09-11 14:02:45 EDT
Created attachment 192771 [details] lspci -vvxxx with bios update
Comment 10 Chuck Ebbert 2007-09-11 15:16:06 EDT
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.
Comment 11 Karl Bellve 2007-09-11 16:00:56 EDT
Created attachment 192931 [details] dmesg with adma turned off (new mkinitrd) Kernel 18.104.22.168-41.fc7 with 1.1b bios and adma=0 in /etc/modprobe.conf Followed by /sbin/mkinitrd /boot/initrd-22.214.171.124-41.fc7.img 126.96.36.199-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.188.8.131.52-41.fc7.v1.1b.adma0.txt [kdb@alcor ~]$ grep ADMA alcor.dmesg.184.108.40.206-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
Comment 12 Karl Bellve 2007-09-11 16:03:34 EDT
Here are the greps for the problem: [kdb@alcor ~]$ grep "Unable" alcor.dmesg.220.127.116.11-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.18.104.22.168-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
Comment 13 Robert Hancock 2007-09-11 19:05:41 EDT
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.)
Comment 14 Karl Bellve 2007-09-12 09:10:41 EDT
I emailed email@example.com 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.
Comment 15 Karl Bellve 2007-09-13 14:18:18 EDT
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 22.214.171.124-41.fc7 kernel because I forgot to rerun mkinitrd. I don't think it matters. Same problem exists.
Comment 16 Robert Hancock 2007-09-13 20:38:58 EDT
Is this BIOS supposed to fix this problem? It seems to still have the same bad iomem reservations as before.
Comment 17 Karl Bellve 2007-10-10 13:24:04 EDT
Well...he didn't say..he just said try this beta BIOS and hoped it would fix it. I tried kernel-126.96.36.199-91.fc7 and it has the same trouble. I am still using a 2.6.20 kernel...
Comment 18 Robert Hancock 2007-10-10 20:19:25 EDT
Len Brown on LKML suggested adding pnpacpi=off to the kernel command line and seeing if the problem goes away.
Comment 19 Paul Ellis 2007-10-11 09:49:02 EDT
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?
Comment 20 Karl Bellve 2007-10-11 11:17:13 EDT
pnpacpi=off does make the problem go away with kernel 188.8.131.52-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
Comment 21 Bjorn Helgaas 2007-10-11 18:41:17 EDT
This looks like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=313491. I added a patch there for testing.
Comment 22 Robert Hancock 2007-11-02 00:22:39 EDT
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..
Comment 23 Christopher Brown 2008-01-13 18:00:31 EST
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.
Comment 24 Robert Hancock 2008-01-13 18:34:18 EST
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.
Comment 25 Christopher Brown 2008-01-13 21:35:24 EST
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
Comment 26 Christopher Brown 2008-01-13 21:37:38 EST
Created attachment 291534 [details] Bjorn Helgaas patch for supermicro board quirk
Comment 27 Bjorn Helgaas 2008-02-05 01:58:55 EST
Does anybody have Windows running on this Supermicro board? I'd like to see what the device manager says about these resources.
Comment 28 Emiliano De Simoni 2008-03-06 07:51:07 EST
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.
Comment 29 Bjorn Helgaas 2008-03-06 11:13:03 EST
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.
Comment 30 Bug Zapper 2008-05-14 10:15:44 EDT
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
Comment 31 Need Real Name 2008-05-19 21:10:09 EDT
Created attachment 306040 [details] System resource allocation report under Windows XP. Sorry for being so late. I attach the Windows resource allocation report.
Comment 32 Bug Zapper 2008-06-16 22:20:38 EDT
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.