Bug 560540

I assume this effects HP DL series systems.  Assigning to tcamuso.

P.

Tony - any update?  Any chance of this getting into RHEL5.5 and RHEL6?

Event posted on 02-19-2010 05:18pm EST by myron.stowe

The main scenarios where I see this is needed currently are PCI hotplug and
option ROM programming.  Obviously the OS needs to know what resources are
available under a given IOH in order to open bridge windows to accommodate
a
PCI device hotplugged into the system.  BIOS plays no part in actively
allocating resources for the device in this scenario.  For devices
installed
from boot, BIOS will program memory and I/O port resources, but does not
program PCI option ROMs.  Linux prefers to map ROMs into prefetchable
space and
will open up windows on the bridge to accommodate the device if needed. 
In a
multi-IOH system, resource routing considerations and consequences
increase.  Without this, Linux is only guessing which address might go to
which IOH and will sometimes get lucky, and other times not.  

In the hotplug case, incorrect guessing means the device probably doesn't
work
at all, in the option ROM case, it means the option ROM doesn't work (ie.
the
data read doesn't hit the card, so the return is probably -1).  An
improperly
programmed option may mean that device firmware required to make use of
the
card is inaccessible.  These cards may work in some slots, but not others,
and
may also be dependent on the resource usage of other cards in the system
as to
whether the option ROM gets mapped to a valid location.

With Intel's introduction of VT-d, the ramifications mentioned above are
magnified.  The address window containing the set of registers related to
VT-d is denoted by the VTBAR.  In Intel's chipset(s), the VTBAR must
reside within the system's Local MMIOL resource.  This introduces the
possibility that a range assigned by Linux for an option ROM may conflict
(overlap) with the VT-d window which is how we recently stumbled upon
this.  It is very hard to debug when a ROM gets mapped behind a VTBAR and
makes the device unusable in house.  When a customer encounters, and
reports such, it will be much harder to diagnose.

Without the patch mentioned, RHEL5.x is susceptible to these issues on any
vendor's Intel based x86 system that incorporates VT-d functionality. 
This is already true today with existing single IOH architectures.  With
multi-IOH systems that are now beginning to appear, the susceptibility to
these issues increases dramatically.


This event sent from IssueTracker by dwa 
 issue 537293

With respect to Prarit's comments in "Comment 1" - yes, it does effect HP systems but it is *not* limited to HP systems.  The issue will occur on any vendor's Intel based x86 system that incorporates VT-d (which I believe includes most, if not all, recent Intel based systems.

Repeating comment 3: any updates here.  Any chance this will get into 5.5 or 6.0?
The patch was incorporated upstream over three years ago.

Created attachment 435372 [details]
RHEL5 fix for this issue part 1

Created attachment 435373 [details]
RHEL5 fix for this issue part 2

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

in kernel-2.6.18-219.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.

pnp entries are present in /proc/iomem on 2.6.18-194.230.el5 kernel
[root@ibm-x3950m2-01 ~]# uname -a
Linux ibm-x3950m2-01.rhts.eng.bos.redhat.com 2.6.18-230.el5PAE #1 SMP Thu Oct 28 17:13:02 EDT 2010 i686 i686 i386 GNU/Linux
[root@ibm-x3950m2-01 ~]# cat /proc/iomem | grep pnp
00000400-000004ff : pnp 00:08
fda00000-fdbfffff : pnp 00:06
fde84000-fde843ff : pnp 00:0a
fde86000-fdf05fff : pnp 00:06
[root@ibm-x3950m2-01 ~]#

On unpatched kernel, no such entries
[root@ibm-x3950m2-01 ~]# uname -a
Linux ibm-x3950m2-01.rhts.eng.bos.redhat.com 2.6.18-194.el5PAE #1 SMP Tue Mar 16 22:00:21 EDT 2010 i686 i686 i386 GNU/Linux
[root@ibm-x3950m2-01 ~]#  cat /proc/iomem | grep pnp
[root@ibm-x3950m2-01 ~]#

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, system board iomem resources, which were enumerated using the PNP Motherboard resource descriptions, were not recognized and taken into consideration when gathering resource information. This could have caused MMIO-based requests to receive allocations that were not valid. With this update, system board iomem resources are correctly recognized when gathering resource information.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0017.html