Bug 280641

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: kernelAssignee: Jeff Garzik <jgarzik>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: 7CC: bjorn.helgaas, hancockrwd, peterm, skarsol, snecklifter, triage
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-16 22:20:39 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 172490    
Attachments:
Description Flags
/var/log/message from trying to boot a 2.6.22 kernel
none
lscpi -vvxxx of kernel 2.6.22.1-41.fc7 with problems recongizing 5th SATA drive
none
lscpi -vvxxx of kernel 2.6.20-1.2933.fc6 which can recognize 5th SATA drive
none
/var/log/message from booting a 2.6.20 kernel
none
dmesg output from booting 2.6.22 kernel after bios update
none
lspci -vvxxx with bios update
none
dmesg with adma turned off (new mkinitrd)
none
dmesg output, testing new BIOS sent by Supermicro, no ADMA
none
Bjorn Helgaas patch for supermicro board quirk
none
current proposed PNP system quirk
none
System resource allocation report under Windows XP. none

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
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:
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 2.6.22.1-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 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
Comment 12 Karl Bellve 2007-09-11 16:03:34 EDT
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
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 support@supermicro.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 2.6.22.1-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-2.6.22.9-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 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



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.