Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 280641
Description
Karl Bellve
2007-09-06 14:38:37 UTC
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. |