Bug 313491

Summary: [PATCH] ignore any ACPI reservation that overlaps with a PCI BAR as being bogus
Product: [Fedora] Fedora Reporter: Willem Riede <wriede>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: bjorn.helgaas, emiliano.desimoni, hancockrwd, jonstanley
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 02:17:45 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
dmesg booting fc6
none
dmesg booting f7
none
dmesg booting f8
none
lspci -vvxxx on fc6
none
lspci -vvxxx on f7
none
lspci -vvxxx on f8
none
Screenshot hardware browser showing the four SATA drives on fc6
none
output of mkinitrd -v with options sata_nv adma=0
none
dmesg booting f7 with options sata_nv adma=0
none
/proc/ioports for the working fc6 kernel
none
/proc/iomem for the working fc6 kernel
none
/proc/ioports for the troubled f7 kernel
none
/proc/iomem for the troubled f7 kernel
none
disable motherboard resources that overlap PCI BARs
none
Supermicro H8DCE dmidecode
none
disable selected Supermicro H8DCE motherboard resources none

Description Willem Riede 2007-10-01 00:27:48 EDT
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)
Comment 1 Willem Riede 2007-10-01 00:27:48 EDT
Created attachment 211981 [details]
dmesg booting fc6
Comment 2 Willem Riede 2007-10-01 00:28:53 EDT
Created attachment 211991 [details]
dmesg booting f7
Comment 3 Willem Riede 2007-10-01 00:29:25 EDT
Created attachment 212001 [details]
dmesg booting f8
Comment 4 Willem Riede 2007-10-01 00:29:58 EDT
Created attachment 212011 [details]
lspci -vvxxx on fc6
Comment 5 Willem Riede 2007-10-01 00:30:25 EDT
Created attachment 212021 [details]
lspci -vvxxx on f7
Comment 6 Willem Riede 2007-10-01 00:30:49 EDT
Created attachment 212031 [details]
lspci -vvxxx on f8
Comment 7 Willem Riede 2007-10-01 00:32:11 EDT
Created attachment 212041 [details]
Screenshot hardware browser showing the four SATA drives on fc6
Comment 8 Chuck Ebbert 2007-10-01 14:16:47 EDT
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...
Comment 9 Willem Riede 2007-10-01 14:31:25 EDT
(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.
Comment 10 Chuck Ebbert 2007-10-01 17:35:08 EDT
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.
Comment 11 Willem Riede 2007-10-01 18:56:44 EDT
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.
Comment 12 Willem Riede 2007-10-01 18:59:01 EDT
Created attachment 213011 [details]
output of mkinitrd -v with options sata_nv adma=0
Comment 13 Willem Riede 2007-10-01 19:00:00 EDT
Created attachment 213021 [details]
dmesg booting f7 with options sata_nv adma=0
Comment 14 Chuck Ebbert 2007-10-01 19:13:50 EDT
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?
Comment 15 Willem Riede 2007-10-01 19:23:02 EDT
Created attachment 213041 [details]
/proc/ioports for the working fc6 kernel
Comment 16 Willem Riede 2007-10-01 19:23:46 EDT
Created attachment 213051 [details]
/proc/iomem for the working fc6 kernel
Comment 17 Willem Riede 2007-10-01 19:33:31 EDT
Created attachment 213061 [details]
/proc/ioports for the troubled f7 kernel
Comment 18 Willem Riede 2007-10-01 19:34:11 EDT
Created attachment 213071 [details]
/proc/iomem for the troubled f7 kernel
Comment 19 Robert Hancock 2007-10-01 20:16:20 EDT
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.
Comment 20 Willem Riede 2007-10-01 21:12:12 EDT
(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.
Comment 21 Bjorn Helgaas 2007-10-11 18:37:53 EDT
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.
Comment 22 Jon Stanley 2007-12-30 00:50:14 EST
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.
Comment 23 Willem Riede 2008-01-02 13:53:11 EST
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.
Comment 24 Bjorn Helgaas 2008-01-14 18:55:37 EST
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!
Comment 25 Robert Hancock 2008-01-14 19:05:26 EST
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.
Comment 26 Jon Stanley 2008-01-14 22:17:50 EST
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.
Comment 27 Bjorn Helgaas 2008-01-16 17:46:31 EST
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
Comment 28 Bjorn Helgaas 2008-01-16 17:51:45 EST
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.
Comment 29 Willem Riede 2008-01-27 14:15:36 EST
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
Comment 30 Chuck Ebbert 2008-01-31 17:51:06 EST
(In reply to comment #28)
> Created an attachment (id=291907) [edit]
> disable selected Supermicro H8DCE motherboard resources
> 

Is this patch going upstream?
Comment 31 Bjorn Helgaas 2008-02-05 01:58:21 EST
Does anybody have Windows running on this Supermicro board?  I'd like to see 
what the device manager says about these resources.
Comment 32 Emiliano De Simoni 2008-03-06 08:04:08 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 33 Bug Zapper 2008-11-26 02:53:33 EST
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
Comment 34 Bug Zapper 2009-01-09 02:17:45 EST
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.