pci: clear bridge resource size if BIOS assign bad one

PATCH In review Yinghai Lu 4 participants 8 messages Jun 3, 2010 – Jun 11, 2010 5 messages not in the archive

Subsystems (4)

x86 PowerPC PCI Microblaze architecture

lore

Share & tools

lore

Yinghai Lu

author

2010-06-03 20:44 UTC #5 lore raw

PATCH 1/1 pci: clear bridge resource size if BIOS assign bad one

In reply to a message not in the archive

Make sure We can reject wrong size from BIOS.

https://bugzilla.kernel.org/show_bug.cgi?id=16009
Yannick found that video does not work with 2.6.34

the root cause:
BIOS assigned wrong range to pci bridge. and before 2.6.34 kernel will just get range that is needed.
for 2.6.34.
| d65245c PCI: don't shrink bridge resources
will try to range size is bigger than old one.
(used by boot stage multi-try to get big BAR size for pci bridge,
and pcie hotplug to get big range)

So try to 0 for old size for pci bridge in this boot stage case.

Reported-by Yannick <[email protected]>

Analyzed-by Bjorn Helgaas <[email protected]>

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/microblaze/pci/pci-common.c        |    1 +
 arch/mn10300/unit-asb2305/pci-asb2305.c |    1 +
 arch/powerpc/kernel/pci-common.c        |    1 +
 arch/x86/pci/i386.c                     |    1 +
 4 files changed, 4 insertions(+)

arch/x86/pci/i386.c +1 -0

Index: linux-2.6/arch/x86/pci/i386.c
===================================================================
@@ -136,6 +136,7 @@ static void __init pcibios_allocate_bus_
 					 * child resource allocations in this
 					 * range.
 					 */
+					r->start = r->end = 0;
 					r->flags = 0;
 				}
 			}

arch/microblaze/pci/pci-common.c +1 -0

Index: linux-2.6/arch/microblaze/pci/pci-common.c
===================================================================
@@ -1277,6 +1277,7 @@ void pcibios_allocate_bus_resources(stru
 		printk(KERN_WARNING "PCI: Cannot allocate resource region "
 		       "%d of PCI bridge %d, will remap\n", i, bus->number);
 clear_resource:
+		res->start = res->end = 0;
 		res->flags = 0;
 	}

arch/mn10300/unit-asb2305/pci-asb2305.c +1 -0

Index: linux-2.6/arch/mn10300/unit-asb2305/pci-asb2305.c
===================================================================
@@ -117,6 +117,7 @@ static void __init pcibios_allocate_bus_
 					 * Invalidate the resource to prevent
 					 * child resource allocations in this
 					 * range. */
+					r->start = r->end = 0;
 					r->flags = 0;
 				}
 			}

arch/powerpc/kernel/pci-common.c +1 -0

Index: linux-2.6/arch/powerpc/kernel/pci-common.c
===================================================================
@@ -1309,6 +1309,7 @@ void pcibios_allocate_bus_resources(stru
 		printk(KERN_WARNING "PCI: Cannot allocate resource region "
 		       "%d of PCI bridge %d, will remap\n", i, bus->number);
 clear_resource:
+		res->start = res->end = 0;
 		res->flags = 0;
 	}

Yannick Roehlly

2010-06-03 23:02 UTC #6 lore raw

Le Thursday 03 June 2010 22:43:03 Yinghai Lu, vous avez écrit :

Quoted 4 lines

Make sure We can reject wrong size from BIOS.
https://bugzilla.kernel.org/show_bug.cgi?id=16009
Yannick found that video does not work with 2.6.34

Hi Yinghai,

I tested the 2nd version of your patch. I still works.

Cheers,

Yannick

Jesse Barnes

2010-06-08 21:44 UTC #7 lore raw

In reply to Yinghai Lu

Quoted 15 lines · On Thu, 03 Jun 2010 13:43:03 -0700 Yinghai Lu <[email protected]> wrote:

Make sure We can reject wrong size from BIOS.
https://bugzilla.kernel.org/show_bug.cgi?id=16009
Yannick found that video does not work with 2.6.34
the root cause:
BIOS assigned wrong range to pci bridge. and before 2.6.34 kernel will just get range that is needed.
for 2.6.34.
| d65245c PCI: don't shrink bridge resources
will try to range size is bigger than old one.
(used by boot stage multi-try to get big BAR size for pci bridge,
and pcie hotplug to get big range)

Quoted 6 lines

So try to 0 for old size for pci bridge in this boot stage case.
Reported-by Yannick <[email protected]>
Analyzed-by Bjorn Helgaas <[email protected]>
Signed-off-by Yinghai Lu <[email protected]>

Bjorn, are you ok with this version? It would probably help to have some comments here too (I can add them), indicating that we'll try to reassign the resource later, rather than just ignoring it as the existing comment implies.

Signature · 1 line

Jesse Barnes, Intel Open Source Technology Center

Bjorn Helgaas

2010-06-08 22:49 UTC #8 lore raw

Quoted 25 lines · Jesse Barnes

Quoted 15 lines · On Thu, 03 Jun 2010 13:43:03 -0700 Yinghai Lu <[email protected]> wrote:
Make sure We can reject wrong size from BIOS.
https://bugzilla.kernel.org/show_bug.cgi?id=16009
Yannick found that video does not work with 2.6.34
the root cause:
BIOS assigned wrong range to pci bridge. and before 2.6.34 kernel will just get range that is needed.
for 2.6.34.
| d65245c PCI: don't shrink bridge resources
will try to range size is bigger than old one.
(used by boot stage multi-try to get big BAR size for pci bridge,
and pcie hotplug to get big range)
Quoted 6 lines
So try to 0 for old size for pci bridge in this boot stage case.
Reported-by Yannick <[email protected]>
Analyzed-by Bjorn Helgaas <[email protected]>
Signed-off-by Yinghai Lu <[email protected]>

Quoted 4 lines

Bjorn, are you ok with this version? It would probably help to have some comments here too (I can add them), indicating that we'll try to reassign the resource later, rather than just ignoring it as the existing comment implies.

I guess I'm ok with it. I can't make much sense out of the changelog, and I don't really understand how the reallocation stuff works.

In this case, the aperture *size* from the BIOS is actually OK, but the beginning of the aperture overlaps system memory. With Yinghai's patch, we reduce the size and move the start. Windows was able to just move the start of the aperture and preserve the original 0x20000000 size (but I think it had to move something else out of the way).

Bjorn

Yinghai Lu

author

2010-06-08 23:37 UTC #9 lore raw

Quoted 9 lines · Bjorn Helgaas

On Tuesday, June 08, 2010 03:43:50 pm Jesse Barnes wrote:
In this case, the aperture *size* from the BIOS is actually OK, but the beginning of the aperture overlaps system memory. With Yinghai's patch, we reduce the size and move the start. Windows was able to just move the start of the aperture and preserve the original 0x20000000 size (but I think it had to move something else out of the way).

are you sure? that looks more aggressive.

Yinghai

Bjorn Helgaas

2010-06-09 23:31 UTC #10 lore raw

Quoted 11 lines · Yinghai Lu

Quoted 8 lines · Bjorn Helgaas
On Tuesday, June 08, 2010 03:43:50 pm Jesse Barnes wrote:
In this case, the aperture *size* from the BIOS is actually OK, but the beginning of the aperture overlaps system memory. With Yinghai's patch, we reduce the size and move the start. Windows was able to just move the start of the aperture and preserve the original 0x20000000 size (but I think it had to move something else out of the way).
are you sure? that looks more aggressive.

I don't have the machine and can't be 100% sure, but based on what Yannic reported here: https://bugzilla.kernel.org/show_bug.cgi?id=16009#c11,
it looks like Windows moved that aperture.

I haven't used it myself, but possibly a program like SIV
(http://rh-software.com/) would give more detailed information about what Windows is doing.

Bjorn

Yannick Roehlly

2010-06-11 08:44 UTC #11 lore raw

Le Thursday 10 June 2010 01:30:31 Bjorn Helgaas, vous avez écrit :

Quoted 13 lines · Yinghai Lu

Quoted 11 lines · Bjorn Helgaas
Quoted 8 lines · Jesse Barnes
In this case, the aperture *size* from the BIOS is actually OK, but the beginning of the aperture overlaps system memory. With Yinghai's patch, we reduce the size and move the start. Windows was able to just move the start of the aperture and preserve the original 0x20000000 size (but I think it had to move something else out of the way).
are you sure? that looks more aggressive.

Quoted 8 lines

I don't have the machine and can't be 100% sure, but based on what Yannic reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=16009#c11, it looks like Windows moved that aperture.
I haven't used it myself, but possibly a program like SIV
(http://rh-software.com/) would give more detailed information about what Windows is doing.

Hi Bjorn,

I don't know if it's useful, but here some output of SIV concerning PCI and the Radeon card.

Yannick

[1 - 00 - 0] <- [PCI Bus] <- SIV64X - System Information Viewer V4.08 ASUS::Yannick

ATI Mobility Radeon HD 3400 Series - Vendor ID 1002-95C4-19D31043-00 size 0x1000 PCIe BAR 0x0000E0000000

Device Class             0x030000       VGA Controller
Command                  0x0507         I/O Access  Memory Access  Bus Master  System Errors
Status                   0x0010         Fast Timing  Has Capabilities List
Cache Line Size 8        2 ULONGs       Latency Timer 0 PCI clocks
Header Type 0x00         Prof IF 0x00   Built-in Self Test 0x00
Interrupt Line 0                        Interrupt Pin  0x01

BAR 0 (3.000GB)          0xC0000000     Alignment 0x40000000    1.000GB  ( Anywhere in 32-bit space, Prefetchable )
BAR 1 (I/O Port)         0x9000
BAR 2 (3.967GB)          0xFDDF0000     Alignment 0x00010000   64.000KB  ( Anywhere in 32-bit space )

Capabilities 0x50
Power Management Current D0 D0 - Device fully-operational, no power saving
Supports D1 - Device operational, minimum power saving
D2 - Device on standby, medium power saving

  PCI Express V2 Port 0  Device Type 1  Legacy PCI Express Endpoint  Interrupt Message Number 0
    DCAP  0x5C           0x012C8FA0     Max Payload 128 (Supported)  Power 75 W
    DCTL  0x60           0x0910         Max Payload 128  Max Read Request 128 (Current)
    LCTL  0x68           0x0000         Power Management Disabled
    LCAP  0x64           0x00000D01     Link Speed 2.5GT/s  Width x16  (Maximum)
    LSTS  0x6A           0x1101         Link Speed 2.5GT/s  Width x16  (Negotiated)
    SCAP  0x6C           0x00000000

Message Interrupt MSI Enabled Message Address 0x00000000FEE0300C

--------------------------------------------

[Dump] <- [1 - 00 - 0] <- [PCI Bus] <- SIV64X - System Information Viewer V4.08 ASUS::Yannick

ATI Mobility Radeon HD 3400 Series - Vendor ID 1002-95C4-19D31043-00 size 0x1000 PCIe BAR 0x0000E0000000

00 04 08 0C 10 14 18 1C 20 24 28 2C 30 34 38 3C

0000  95C41002  00100507  03000000  00000008  C0000008  00009001  FDDF0000  00000000  00000000  00000000  00000000  19D31043  00000000  00000050  00000000  00000100
0040  00000000  00000000  00000000  19D31043  06035801  00000000  0012A010  012C8FA0  00000910  00000D01  11010000  00000000  00000000  00000000  00000000  00000000
0080  00000000  00000000  00010001  00000000  00000000  00000000  00000000  00000000  00810005  FEE0300C  00000000  00004993  00000000  00000000  00000000  00000000
00C0  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000
0100  0001000B  01010001  00000000  00000000  00010002  00000000  00000000  00000000  00000001  800000FF  00000000  00000001  00000000  00020000  00000000  00000000
0140  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000

... repeated every 256 bytes
0F00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
...
0FC0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

--------------------------------------------

[PCI BAR Addresses] <- SIV64X - System Information Viewer V4.08 ASUS::Yannick

SIV64X - Physical Memory and PCI BARs on \\ASUS - Windows 7 x64 Ultimate V6.01 Build 7100

Physical Area Base Address about Limit Address about Size about Flags

1              0x000000001000       4.00KB 0x00000009B000     620.00KB 0x00000009A000     616.00KB 0x00000103
2              0x000000100000       1.00MB 0x0000BFFA0000       3.00GB 0x0000BFEA0000       3.00GB 0x00000103
3              0x000100000000       4.00GB 0x000140000000       5.00GB 0x000040000000       1.00GB 0x00000103
                                                                       0x0000FFF3A000       4.00GB

BAR Area Base Address about Usage PCI Location Size about

          0x0000C0000000    3.000GB TOLUD     [0 - 00 - 0]

1         0x0000C0000000    3.000GB BAR 0     [1 - 00 - 0]  0x20000000     512.000MB
2         0x0000E0000000    3.500GB PCIEXBAR  [0 - 00 - 0]  0x1DDF0000     477.938MB
3         0x0000FDDF0000    3.967GB BAR 2     [1 - 00 - 0]  0x000D0000     832.000KB
4         0x0000FDEC0000    3.968GB BAR 0     [2 - 00 - 0]  0x0013E000       1.242MB
5         0x0000FDFFE000    3.969GB BAR 0     [3 - 00 - 0]  0x00100000       1.000MB
6         0x0000FE0FE000    3.970GB BAR 5     [4 - 00 - 0]  0x008E2000       8.883MB
7         0x0000FE9E0000    3.978GB ROM       [8 - 00 - 0]  0x0001FC00     127.000KB
8         0x0000FE9FFC00    3.979GB BAR 0     [8 - 00 - 0]  0x000FF000    1020.000KB
9         0x0000FEAFEC00    3.979GB BAR 0     [9 - 01 - 3]  0x00000400       1.000KB
10        0x0000FEAFF000    3.979GB BAR 0     [9 - 01 - 2]  0x00000400       1.000KB
11        0x0000FEAFF400    3.979GB BAR 0     [9 - 01 - 1]  0x00000400       1.000KB
12        0x0000FEAFF800    3.979GB BAR 0     [9 - 01 - 0]  0x000F8800     994.000KB
13        0x0000FEBF8000    3.980GB BAR 0     [0 - 27 - 0]  0x00007000      28.000KB
14        0x0000FEBFF000    3.980GB BAR 0     [0 - 29 - 7]  0x00000400       1.000KB
15        0x0000FEBFF400    3.980GB BAR 0     [0 - 26 - 7]  0x00000400       1.000KB
16        0x0000FEBFF800    3.980GB BAR 5     [0 - 31 - 2]  0x00114800       1.080MB
17        0x0000FED14000    3.982GB MCHBAR    [0 - 00 - 0]  0x00004000      16.000KB
18        0x0000FED18000    3.982GB DMIBAR    [0 - 00 - 0]  0x00001000       4.000KB
19        0x0000FED19000    3.982GB EPBAR     [0 - 00 - 0]  0x012E7000      18.902MB
                                    Total                   0x40000000       1.000GB

Bjorn Helgaas

2010-06-11 22:45 UTC #12 lore raw

Quoted 19 lines · Yannick Roehlly

Le Thursday 10 June 2010 01:30:31 Bjorn Helgaas, vous avez écrit :
Quoted 18 lines · Yinghai Lu
Quoted 11 lines · Bjorn Helgaas
Quoted 8 lines · Jesse Barnes
In this case, the aperture *size* from the BIOS is actually OK, but the beginning of the aperture overlaps system memory. With Yinghai's patch, we reduce the size and move the start. Windows was able to just move the start of the aperture and preserve the original 0x20000000 size (but I think it had to move something else out of the way).
are you sure? that looks more aggressive.
I don't have the machine and can't be 100% sure, but based on what Yannic reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=16009#c11, it looks like Windows moved that aperture.

Quoted 8 lines

Quoted 3 lines
I haven't used it myself, but possibly a program like SIV
(http://rh-software.com/) would give more detailed information about what Windows is doing.
Hi Bjorn,
I don't know if it's useful, but here some output of SIV concerning PCI and the Radeon card.

Can SIV generate a big dump of similar output for all devices at once? Then I could avoid bugging you for "look at this, look at that," etc :-)

I'm particularly interested in the bridges (the PCIe root ports, in this case). I think Windows moved the 00:01.0 prefetchable aperture. We know from the Linux dmesg that the 00:01.0 bridge was initially configured like this:

pci 0000:00:01.0: PCI bridge to [bus 01-01]

  pci 0000:00:01.0:   bridge window [io  0x7000-0x9fff]
  pci 0000:00:01.0:   bridge window [mem 0xfdd00000-0xfddfffff]
  pci 0000:00:01.0:   bridge window [mem 0xbdf00000-0xddefffff 64bit pref]

Based on https://bugzilla.kernel.org/show_bug.cgi?id=16009#c11, I think Windows moved the prefetchable aperture:

Plage mémoire: 00000000FDD00000 - 00000000FDDFFFFF
Plage mémoire: 00000000C0000000 - 00000000DFFFFFFF <== moved
Plage d'E/S: 7000 - 9FFF

Note that the aperture size is still 0x20000000.

Since this new [mem 0xc0000000-0xdfffffff] aperture would conflict with this 00:1c.4 aperture:

pci 0000:00:1c.4: bridge window [mem 0xddf00000-0xdfefffff 64bit pref]

I think it's likely that Windows moved the 1c.4 aperture as well (or maybe even disabled it, since it leads to buses 06-07, and there are no devices on those buses).

Bjorn