My latest pull from Linus's tree fails to boot. Bisection leads to the
commit entitled "x86/ACPI: Correct maximum allowed _CRS returned
resources and warn if exceeded" with hash
f9cde5ffed17bf74f6bef042d99edb0622f58576. I have been unable to
capture the first error message as it scrolls off the screen, but the
second hits the WARN_ON at drivers/ata/ahci.c:695 in routine
ahci_enable_ahci() because HOST_AHCI_EN is not set.
The modules involved in the disk driver are:
amd74xx 7152 0
ide_core 107120 2 ide_cd_mod,amd74xx
ahci 36992 7
libata 168764 1 ahci
scsi_mod 159392 4 usb_storage,sg,sd_mod,libata
Please let me know what other info is needed.
Larry
Larry Finger wrote:
> My latest pull from Linus's tree fails to boot. Bisection leads to the
> commit entitled "x86/ACPI: Correct maximum allowed _CRS returned
> resources and warn if exceeded" with hash
> f9cde5ffed17bf74f6bef042d99edb0622f58576. I have been unable to
> capture the first error message as it scrolls off the screen, but the
> second hits the WARN_ON at drivers/ata/ahci.c:695 in routine
> ahci_enable_ahci() because HOST_AHCI_EN is not set.
I have discovered a little more about this problem. Firstly, I applied
the following patch:
======================================================
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 16c3fda..5b05545 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -91,8 +91,10 @@ setup_resource(struct acpi_resource *acpi_res, void
*data)
res->end = res->start + addr.address_length - 1;
res->child = NULL;
- if (bus_has_transparent_bridge(info->bus))
+ if (bus_has_transparent_bridge(info->bus)) {
max_root_bus_resources -= 3;
+ printk(KERN_INFO "PCI: transparent bridge from %s for
%s\n", root->name, info->name);
+ }
if (info->res_num >= max_root_bus_resources) {
printk(KERN_WARNING "PCI: Failed to allocate 0x%lx-0x%lx "
"from %s for %s due to _CRS returning more than "
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d304ddf..117cac8 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -329,7 +329,7 @@ static inline void pci_add_saved_cap(struct
pci_dev *pci_dev,
}
#ifndef PCI_BUS_NUM_RESOURCES
-#define PCI_BUS_NUM_RESOURCES 16
+#define PCI_BUS_NUM_RESOURCES 24
#endif
#define PCI_REGION_FLAG_MASK 0x0fU /* These bits of resource
flags tell us the PCI region flags */
=========================================================
By increasing PCI_BUS_NUM_RESOURCES, I got the system to boot and I
have a chance to put in some debugging statements. Now in dmesg, I get
the following:
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:01.1: reg 10 io port: [0x3080-0x30bf]
pci 0000:00:01.1: reg 20 io port: [0x3040-0x307f]
pci 0000:00:01.1: reg 24 io port: [0x3000-0x303f]
pci 0000:00:01.1: PME# supported from D3hot D3cold
pci 0000:00:01.1: PME# disabled
pci 0000:00:01.3: reg 10 32bit mmio: [0xfc200000-0xfc27ffff]
pci 0000:00:02.0: reg 10 32bit mmio: [0xfc486000-0xfc486fff]
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.0: PME# disabled
pci 0000:00:02.1: reg 10 32bit mmio: [0xfc489000-0xfc4890ff]
pci 0000:00:02.1: supports D1 D2
pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.1: PME# disabled
pci 0000:00:04.0: reg 10 32bit mmio: [0xfc487000-0xfc487fff]
pci 0000:00:04.0: supports D1 D2
pci 0000:00:04.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:04.0: PME# disabled
pci 0000:00:04.1: reg 10 32bit mmio: [0xfc489400-0xfc4894ff]
pci 0000:00:04.1: supports D1 D2
pci 0000:00:04.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:04.1: PME# disabled
pci 0000:00:06.0: reg 20 io port: [0x30c0-0x30cf]
pci 0000:00:07.0: reg 10 32bit mmio: [0xfc480000-0xfc483fff]
pci 0000:00:07.0: PME# supported from D3hot D3cold
pci 0000:00:07.0: PME# disabled
pci 0000:00:09.0: reg 10 io port: [0x30f0-0x30f7]
pci 0000:00:09.0: reg 14 io port: [0x30e4-0x30e7]
pci 0000:00:09.0: reg 18 io port: [0x30e8-0x30ef]
pci 0000:00:09.0: reg 1c io port: [0x30e0-0x30e3]
pci 0000:00:09.0: reg 20 io port: [0x30d0-0x30df]
pci 0000:00:09.0: reg 24 32bit mmio: [0xfc484000-0xfc485fff]
pci 0000:00:0a.0: reg 10 32bit mmio: [0xfc488000-0xfc488fff]
pci 0000:00:0a.0: reg 14 io port: [0x30f8-0x30ff]
pci 0000:00:0a.0: reg 18 32bit mmio: [0xfc489c00-0xfc489cff]
pci 0000:00:0a.0: reg 1c 32bit mmio: [0xfc489800-0xfc48980f]
pci 0000:00:0a.0: supports D1 D2
pci 0000:00:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0a.0: PME# disabled
pci 0000:00:0c.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0c.0: PME# disabled
pci 0000:00:0d.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0d.0: PME# disabled
pci 0000:00:12.0: reg 10 32bit mmio: [0xf4000000-0xf4ffffff]
pci 0000:00:12.0: reg 14 64bit mmio: [0xd0000000-0xdfffffff]
pci 0000:00:12.0: reg 1c 64bit mmio: [0xf0000000-0xf0ffffff]
pci 0000:00:12.0: reg 30 32bit mmio: [0x000000-0x01ffff]
pci 0000:01:09.0: reg 10 32bit mmio: [0x000000-0x0007ff]
pci 0000:01:09.0: supports D1 D2
pci 0000:01:09.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.0: PME# disabled
pci 0000:01:09.1: reg 10 32bit mmio: [0xfc100800-0xfc1008ff]
pci 0000:01:09.1: supports D1 D2
pci 0000:01:09.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.1: PME# disabled
pci 0000:01:09.2: reg 10 32bit mmio: [0xfc100c00-0xfc100cff]
pci 0000:01:09.2: supports D1 D2
pci 0000:01:09.2: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.2: PME# disabled
pci 0000:01:09.3: reg 10 32bit mmio: [0xfc101000-0xfc1010ff]
pci 0000:01:09.3: supports D1 D2
pci 0000:01:09.3: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.3: PME# disabled
pci 0000:01:09.4: reg 10 32bit mmio: [0xfc101400-0xfc1014ff]
pci 0000:01:09.4: supports D1 D2
pci 0000:01:09.4: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.4: PME# disabled
pci 0000:00:08.0: transparent bridge
pci 0000:00:08.0: bridge 32bit mmio: [0xfc100000-0xfc1fffff]
pci 0000:00:0c.0: bridge io port: [0x4000-0x4fff]
pci 0000:00:0c.0: bridge 32bit mmio: [0xf8000000-0xfbffffff]
pci 0000:04:00.0: reg 10 32bit mmio: [0xfc000000-0xfc003fff]
pci 0000:04:00.0: supports D1 D2
pci 0000:00:0d.0: bridge 32bit mmio: [0xfc000000-0xfc0fffff]
PCI: transparent bridge from PCI IO for PCI Bus 0000:00
PCI: transparent bridge from PCI IO for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
PCI: transparent bridge from PCI mem for PCI Bus 0000:00
There is only a single transparent bridge at 0000:00:08.0; however, my
new printk in setup_resource() gets called a lot of times. Is this right?
The output of 'lspci' for this machine is
finger@larrylap:~/linux-2.6> lspci
00:00.0 RAM memory: nVidia Corporation MCP67 Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP67 ISA Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP67 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP67 Memory Controller (rev a2)
00:01.3 Co-processor: nVidia Corporation MCP67 Co-processor (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP67 OHCI USB 1.1
Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation MCP67 EHCI USB 2.0
Controller (rev a2)
00:04.0 USB Controller: nVidia Corporation MCP67 OHCI USB 1.1
Controller (rev a2)
00:04.1 USB Controller: nVidia Corporation MCP67 EHCI USB 2.0
Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation MCP67 IDE Controller (rev a1)
00:07.0 Audio device: nVidia Corporation MCP67 High Definition Audio
(rev a1)
00:08.0 PCI bridge: nVidia Corporation MCP67 PCI Bridge (rev a2)
00:09.0 IDE interface: nVidia Corporation MCP67 AHCI Controller (rev a2)
00:0a.0 Ethernet controller: nVidia Corporation MCP67 Ethernet (rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP67 PCI Express Bridge (rev a2)
00:0d.0 PCI bridge: nVidia Corporation MCP67 PCI Express Bridge (rev a2)
00:12.0 VGA compatible controller: nVidia Corporation GeForce 7150M
(rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
01:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
(rev 05)
01:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
Host Adapter (rev 22)
01:09.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller
(rev 12)
01:09.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host
Adapter (rev 12)
01:09.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller
(rev 12)
04:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g
(rev 01)
Larry
On Tue, 2009-06-23 at 20:33 -0500, Larry Finger wrote:
> My latest pull from Linus's tree fails to boot. Bisection leads to the
> commit entitled "x86/ACPI: Correct maximum allowed _CRS returned
> resources and warn if exceeded" with hash
> f9cde5ffed17bf74f6bef042d99edb0622f58576. I have been unable to
> capture the first error message as it scrolls off the screen, but the
> second hits the WARN_ON at drivers/ata/ahci.c:695 in routine
> ahci_enable_ahci() because HOST_AHCI_EN is not set.
>
This patch fixes boot failure on my AMD 64 laptop, can you please test
this patch:
[PATCH] x86: fix _CRS resources return handling
We need to check for info->res_num and only handle for < PCI_BUS_NUM_RESOURCES
Also set info->bus->resource[info->res_num] for _CRS resources return handling
Fixed boot failure on some machine.
Reported-by: Larry Finger <[email protected]>
Signed-off-by: Jaswinder Singh Rajput <[email protected]>
---
arch/x86/pci/acpi.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 16c3fda..0bc015f 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -69,6 +69,9 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
struct resource *root;
int max_root_bus_resources = PCI_BUS_NUM_RESOURCES;
+ if (info->res_num >= PCI_BUS_NUM_RESOURCES)
+ return AE_OK;
+
status = resource_to_addr(acpi_res, &addr);
if (!ACPI_SUCCESS(status))
return AE_OK;
@@ -94,17 +97,18 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
if (bus_has_transparent_bridge(info->bus))
max_root_bus_resources -= 3;
if (info->res_num >= max_root_bus_resources) {
- printk(KERN_WARNING "PCI: Failed to allocate 0x%lx-0x%lx "
- "from %s for %s due to _CRS returning more than "
- "%d resource descriptors\n", (unsigned long) res->start,
- (unsigned long) res->end, root->name, info->name,
- max_root_bus_resources);
+ pr_warning("PCI: Failed to allocate 0x%lx-0x%lx "
+ "from %s for %s due to _CRS returning more than "
+ "%d resource descriptors\n",
+ (unsigned long)res->start, (unsigned long)res->end,
+ root->name, info->name, max_root_bus_resources);
+ info->bus->resource[info->res_num] = res;
info->res_num++;
return AE_OK;
}
if (insert_resource(root, res)) {
- printk(KERN_ERR "PCI: Failed to allocate 0x%lx-0x%lx "
+ pr_err("PCI: Failed to allocate 0x%lx-0x%lx "
"from %s for %s\n", (unsigned long) res->start,
(unsigned long) res->end, root->name, info->name);
} else {
--
1.6.0.6
* Jaswinder Singh Rajput <[email protected]> wrote:
> On Tue, 2009-06-23 at 20:33 -0500, Larry Finger wrote:
> > My latest pull from Linus's tree fails to boot. Bisection leads to the
> > commit entitled "x86/ACPI: Correct maximum allowed _CRS returned
> > resources and warn if exceeded" with hash
> > f9cde5ffed17bf74f6bef042d99edb0622f58576. I have been unable to
> > capture the first error message as it scrolls off the screen, but the
> > second hits the WARN_ON at drivers/ata/ahci.c:695 in routine
> > ahci_enable_ahci() because HOST_AHCI_EN is not set.
> >
>
> This patch fixes boot failure on my AMD 64 laptop, can you please test
> this patch:
>
> [PATCH] x86: fix _CRS resources return handling
>
> We need to check for info->res_num and only handle for < PCI_BUS_NUM_RESOURCES
>
> Also set info->bus->resource[info->res_num] for _CRS resources return handling
>
> Fixed boot failure on some machine.
>
> Reported-by: Larry Finger <[email protected]>
> Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> ---
> arch/x86/pci/acpi.c | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
Ah, nice! I suspect it was this upstream commit causing it:
f9cde5f: x86/ACPI: Correct maximum allowed _CRS returned resources and warn if exceeded
right?
Jesse, you'll handle this, right? I'll apply it to tip:out-of-tree
(not-for-upstream) for testing.
Ingo
On Wed, 2009-06-24 at 14:22 +0200, Ingo Molnar wrote:
> * Jaswinder Singh Rajput <[email protected]> wrote:
>
> > On Tue, 2009-06-23 at 20:33 -0500, Larry Finger wrote:
> > > My latest pull from Linus's tree fails to boot. Bisection leads to the
> > > commit entitled "x86/ACPI: Correct maximum allowed _CRS returned
> > > resources and warn if exceeded" with hash
> > > f9cde5ffed17bf74f6bef042d99edb0622f58576. I have been unable to
> > > capture the first error message as it scrolls off the screen, but the
> > > second hits the WARN_ON at drivers/ata/ahci.c:695 in routine
> > > ahci_enable_ahci() because HOST_AHCI_EN is not set.
> > >
> >
> > This patch fixes boot failure on my AMD 64 laptop, can you please test
> > this patch:
> >
> > [PATCH] x86: fix _CRS resources return handling
> >
> > We need to check for info->res_num and only handle for < PCI_BUS_NUM_RESOURCES
> >
> > Also set info->bus->resource[info->res_num] for _CRS resources return handling
> >
> > Fixed boot failure on some machine.
> >
> > Reported-by: Larry Finger <[email protected]>
> > Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> > ---
> > arch/x86/pci/acpi.c | 16 ++++++++++------
> > 1 files changed, 10 insertions(+), 6 deletions(-)
>
> Ah, nice! I suspect it was this upstream commit causing it:
>
> f9cde5f: x86/ACPI: Correct maximum allowed _CRS returned resources and warn if exceeded
>
> right?
Yes :
git-bisect start
[jaswinder@hpdv5 linux-2.6-tip]$ git-bisect bad
[jaswinder@hpdv5 linux-2.6-tip]$ git-bisect good d06063cc221fdef
Bisecting: 612 revisions left to test after this
[59835e6e10a76865be52da556e76d77afb7c6bb6] Merge branch 'sched/urgent'
git-bisect good
Bisecting: 334 revisions left to test after this
[df36b439c5fedefe013d4449cb6a50d15e2f4d70] Merge branch 'for-2.6.31' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6
git-bisect bad
Bisecting: 167 revisions left to test after this
[59ef7a83f1127038a433464597df02e2dc9540e7] Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
git-bisect bad
Bisecting: 92 revisions left to test after this
[5165aece0efac6574fc3e32b6f1c2a964820d1c6] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
git-bisect good
Bisecting: 37 revisions left to test after this
[1eb3948716f68bdb71509d0175765295f1aca23d] PCI: use pci_is_root_bus() in pci_common_swizzle()
git-bisect good
Bisecting: 18 revisions left to test after this
[7d9a73f6dcf4390d256bf19330c81e91523a26d5] PCI PM: consistently use type bool for wake enable variable
git-bisect bad
Bisecting: 9 revisions left to test after this
[70298c6e6c1ba68346336b4ea54bd5c0abbf73c8] PCI AER: support Multiple Error Received and no error source id
git-bisect good
Bisecting: 4 revisions left to test after this
[f85876ba82281f15bc4da11e41b94243a8b2b5b4] PCI: support PM D0hot->D3 transition reset
git-bisect good
Bisecting: 2 revisions left to test after this
[d2abdf62882d982c58e7a6b09ecdcfcc28075e2e] PCI PM: Fix handling of devices without PM support by pci_target_state()
git-bisect good
Bisecting: 1 revisions left to test after this
[f9cde5ffed17bf74f6bef042d99edb0622f58576] x86/ACPI: Correct maximum allowed _CRS returned resources and warn if exceeded
git-bisect bad
Bisecting: 0 revisions left to test after this
[ab7de999a2c771482698efa6fe7c7b7fcb1d482a] PCI: remove invalid comment of msi_mask_irq()
git-bisect good
f9cde5ffed17bf74f6bef042d99edb0622f58576 is first bad commit
commit f9cde5ffed17bf74f6bef042d99edb0622f58576
Author: Gary Hade <[email protected]>
Date: Wed May 27 12:41:44 2009 -0700
x86/ACPI: Correct maximum allowed _CRS returned resources and warn if exceeded
Issue a warning if _CRS returns too many resource descriptors to be
accommodated by the fixed size resource array instances. If there is no
transparent bridge on the root bus "too many" is the
PCI_BUS_NUM_RESOURCES size of the resource array. Otherwise, the last 3
slots of the resource array must be excluded making the maximum
(PCI_BUS_NUM_RESOURCES - 3).
The current code:
- is silent when _CRS returns too many resource descriptors and
- incorrectly allows use of the last 3 slots of the resource array
for a root bus with a transparent bridge
Signed-off-by: Gary Hade <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
:040000 040000 b1b02b4085b3ebd774ed5bcbf166b2957312bdf5 b7e4d2681c8e2615378df21a6489c5dde22a1954 M arch
Thanks,
--
JSR
Jaswinder Singh Rajput wrote:
> On Tue, 2009-06-23 at 20:33 -0500, Larry Finger wrote:
>> My latest pull from Linus's tree fails to boot. Bisection leads to the
>> commit entitled "x86/ACPI: Correct maximum allowed _CRS returned
>> resources and warn if exceeded" with hash
>> f9cde5ffed17bf74f6bef042d99edb0622f58576. I have been unable to
>> capture the first error message as it scrolls off the screen, but the
>> second hits the WARN_ON at drivers/ata/ahci.c:695 in routine
>> ahci_enable_ahci() because HOST_AHCI_EN is not set.
>>
>
> This patch fixes boot failure on my AMD 64 laptop, can you please test
> this patch:
>
> [PATCH] x86: fix _CRS resources return handling
>
> We need to check for info->res_num and only handle for < PCI_BUS_NUM_RESOURCES
>
> Also set info->bus->resource[info->res_num] for _CRS resources return handling
>
> Fixed boot failure on some machine.
>
> Reported-by: Larry Finger <[email protected]>
> Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> ---
> arch/x86/pci/acpi.c | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
Tested-by: Larry Finger <[email protected]>
Thanks for the patch. With it, my machine boots with the latest
2.6.30-gitX.
For the record, the printout from the patch results in the following:
PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI Bus 0000:00
PCI: Failed to allocate 0xec000-0xeffff from PCI mem for PCI Bus
0000:00 due to _CRS returning more than 13 resource descriptors
PCI: Failed to allocate 0xf0000-0xfffff from PCI mem for PCI Bus
0000:00 due to _CRS returning more than 13 resource descriptors
PCI: Failed to allocate 0xc0000000-0xfebfffff from PCI mem for PCI Bus
0000:00 due to _CRS returning more than 13 resource descriptors
Larry
On Wed, Jun 24, 2009 at 02:22:09PM +0200, Ingo Molnar wrote:
>
> * Jaswinder Singh Rajput <[email protected]> wrote:
>
> > On Tue, 2009-06-23 at 20:33 -0500, Larry Finger wrote:
> > > My latest pull from Linus's tree fails to boot. Bisection leads to the
> > > commit entitled "x86/ACPI: Correct maximum allowed _CRS returned
> > > resources and warn if exceeded" with hash
> > > f9cde5ffed17bf74f6bef042d99edb0622f58576. I have been unable to
> > > capture the first error message as it scrolls off the screen, but the
> > > second hits the WARN_ON at drivers/ata/ahci.c:695 in routine
> > > ahci_enable_ahci() because HOST_AHCI_EN is not set.
> > >
> >
> > This patch fixes boot failure on my AMD 64 laptop, can you please test
> > this patch:
> >
> > [PATCH] x86: fix _CRS resources return handling
> >
> > We need to check for info->res_num and only handle for < PCI_BUS_NUM_RESOURCES
> >
> > Also set info->bus->resource[info->res_num] for _CRS resources return handling
> >
> > Fixed boot failure on some machine.
> >
> > Reported-by: Larry Finger <[email protected]>
> > Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> > ---
> > arch/x86/pci/acpi.c | 16 ++++++++++------
> > 1 files changed, 10 insertions(+), 6 deletions(-)
>
> Ah, nice! I suspect it was this upstream commit causing it:
>
> f9cde5f: x86/ACPI: Correct maximum allowed _CRS returned resources and warn if exceeded
>
> right?
This change was made in conjunction with the previous
"PCI: use ACPI _CRS data by default" 9e9f46c44e487af0a82eb61b624553e2f7118f5b
change to help expose systems that might be incompatible with
that change. See http://marc.info/?l=linux-pci&m=124345331521386&w=2
for more discussion on this.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wed, 24 Jun 2009, Jaswinder Singh Rajput wrote:
> Reported-by: Larry Finger <[email protected]>
> Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> ---
> arch/x86/pci/acpi.c | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 16c3fda..0bc015f 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -69,6 +69,9 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> struct resource *root;
> int max_root_bus_resources = PCI_BUS_NUM_RESOURCES;
>
> + if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> + return AE_OK;
> +
> status = resource_to_addr(acpi_res, &addr);
> if (!ACPI_SUCCESS(status))
> return AE_OK;
> @@ -94,17 +97,18 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> if (bus_has_transparent_bridge(info->bus))
> max_root_bus_resources -= 3;
> if (info->res_num >= max_root_bus_resources) {
> - printk(KERN_WARNING "PCI: Failed to allocate 0x%lx-0x%lx "
> - "from %s for %s due to _CRS returning more than "
> - "%d resource descriptors\n", (unsigned long) res->start,
> - (unsigned long) res->end, root->name, info->name,
> - max_root_bus_resources);
> + pr_warning("PCI: Failed to allocate 0x%lx-0x%lx "
> + "from %s for %s due to _CRS returning more than "
> + "%d resource descriptors\n",
> + (unsigned long)res->start, (unsigned long)res->end,
> + root->name, info->name, max_root_bus_resources);
Can you please avoid mixing cleanup patches with bug fixes ? I almost
did not see the line below.
> + info->bus->resource[info->res_num] = res;
Storing the resource in defeats the purpose of the original patch,
which makes sure that we do _NOT_ use the last 3 slots of the resource
array for a root bus with a transparent bridge.
> info->res_num++;
This is the real bug. info->res_num should not be incremented when we
run out of resources already.
> return AE_OK;
Thanks,
tglx
* Larry Finger <[email protected]> wrote:
> Jaswinder Singh Rajput wrote:
> > On Tue, 2009-06-23 at 20:33 -0500, Larry Finger wrote:
> >> My latest pull from Linus's tree fails to boot. Bisection leads to the
> >> commit entitled "x86/ACPI: Correct maximum allowed _CRS returned
> >> resources and warn if exceeded" with hash
> >> f9cde5ffed17bf74f6bef042d99edb0622f58576. I have been unable to
> >> capture the first error message as it scrolls off the screen, but the
> >> second hits the WARN_ON at drivers/ata/ahci.c:695 in routine
> >> ahci_enable_ahci() because HOST_AHCI_EN is not set.
> >>
> >
> > This patch fixes boot failure on my AMD 64 laptop, can you please test
> > this patch:
> >
> > [PATCH] x86: fix _CRS resources return handling
> >
> > We need to check for info->res_num and only handle for < PCI_BUS_NUM_RESOURCES
> >
> > Also set info->bus->resource[info->res_num] for _CRS resources return handling
> >
> > Fixed boot failure on some machine.
> >
> > Reported-by: Larry Finger <[email protected]>
> > Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> > ---
> > arch/x86/pci/acpi.c | 16 ++++++++++------
> > 1 files changed, 10 insertions(+), 6 deletions(-)
>
> Tested-by: Larry Finger <[email protected]>
>
> Thanks for the patch. With it, my machine boots with the latest
> 2.6.30-gitX.
Please note the comments from Yinghai and Thomas. The fix does
something weird after injecting unrelated cleanups and the changelog
does not cover that.
Ingo
Larry,
On Wed, 24 Jun 2009, Larry Finger wrote:
> For the record, the printout from the patch results in the following:
>
> PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI Bus 0000:00
> PCI: Failed to allocate 0xec000-0xeffff from PCI mem for PCI Bus
> 0000:00 due to _CRS returning more than 13 resource descriptors
> PCI: Failed to allocate 0xf0000-0xfffff from PCI mem for PCI Bus
> 0000:00 due to _CRS returning more than 13 resource descriptors
> PCI: Failed to allocate 0xc0000000-0xfebfffff from PCI mem for PCI Bus
> 0000:00 due to _CRS returning more than 13 resource descriptors
can you please the patch below instead of the other one ?
Thanks,
tglx
---
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 16c3fda..39a0cce 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -99,7 +99,6 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
"%d resource descriptors\n", (unsigned long) res->start,
(unsigned long) res->end, root->name, info->name,
max_root_bus_resources);
- info->res_num++;
return AE_OK;
}
Thomas,
Thomas Gleixner wrote:
> Larry,
>
>
> can you please the patch below instead of the other one ?
>
> Thanks,
>
> tglx
> ---
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 16c3fda..39a0cce 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -99,7 +99,6 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> "%d resource descriptors\n", (unsigned long) res->start,
> (unsigned long) res->end, root->name, info->name,
> max_root_bus_resources);
> - info->res_num++;
> return AE_OK;
> }
Sorry, this patch does not fix the problem.
Larry
On Wed, 2009-06-24 at 16:51 +0200, Thomas Gleixner wrote:
> On Wed, 24 Jun 2009, Jaswinder Singh Rajput wrote:
> > Reported-by: Larry Finger <[email protected]>
> > Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> > ---
> > arch/x86/pci/acpi.c | 16 ++++++++++------
> > 1 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > index 16c3fda..0bc015f 100644
> > --- a/arch/x86/pci/acpi.c
> > +++ b/arch/x86/pci/acpi.c
> > @@ -69,6 +69,9 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > struct resource *root;
> > int max_root_bus_resources = PCI_BUS_NUM_RESOURCES;
> >
> > + if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> > + return AE_OK;
> > +
We need to test this otherwise we will get another oops.
> > status = resource_to_addr(acpi_res, &addr);
> > if (!ACPI_SUCCESS(status))
> > return AE_OK;
> > @@ -94,17 +97,18 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > if (bus_has_transparent_bridge(info->bus))
> > max_root_bus_resources -= 3;
> > if (info->res_num >= max_root_bus_resources) {
> > - printk(KERN_WARNING "PCI: Failed to allocate 0x%lx-0x%lx "
> > - "from %s for %s due to _CRS returning more than "
> > - "%d resource descriptors\n", (unsigned long) res->start,
> > - (unsigned long) res->end, root->name, info->name,
> > - max_root_bus_resources);
> > + pr_warning("PCI: Failed to allocate 0x%lx-0x%lx "
> > + "from %s for %s due to _CRS returning more than "
> > + "%d resource descriptors\n",
> > + (unsigned long)res->start, (unsigned long)res->end,
> > + root->name, info->name, max_root_bus_resources);
>
> Can you please avoid mixing cleanup patches with bug fixes ? I almost
> did not see the line below.
>
> > + info->bus->resource[info->res_num] = res;
>
We need to set the resource even it is transparent bridge, otherwise pci
will fail and system will not able to boot.
> Storing the resource in defeats the purpose of the original patch,
> which makes sure that we do _NOT_ use the last 3 slots of the resource
> array for a root bus with a transparent bridge.
>
> > info->res_num++;
>
> This is the real bug. info->res_num should not be incremented when we
> run out of resources already.
>
No, you cannot remove it, otherwise you will get another oops.
You need all of the 3 things above otherwise system will not boot. Only
thing you can remove is cleanup ;-)
Or you need to revert f9cde5ffed17bf74f6bef
Thanks,
--
JSR
On Wed, Jun 24, 2009 at 04:51:48PM +0200, Thomas Gleixner wrote:
> On Wed, 24 Jun 2009, Jaswinder Singh Rajput wrote:
> > Reported-by: Larry Finger <[email protected]>
> > Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> > ---
> > arch/x86/pci/acpi.c | 16 ++++++++++------
> > 1 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > index 16c3fda..0bc015f 100644
> > --- a/arch/x86/pci/acpi.c
> > +++ b/arch/x86/pci/acpi.c
> > @@ -69,6 +69,9 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > struct resource *root;
> > int max_root_bus_resources = PCI_BUS_NUM_RESOURCES;
> >
> > + if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> > + return AE_OK;
> > +
> > status = resource_to_addr(acpi_res, &addr);
> > if (!ACPI_SUCCESS(status))
> > return AE_OK;
> > @@ -94,17 +97,18 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > if (bus_has_transparent_bridge(info->bus))
> > max_root_bus_resources -= 3;
> > if (info->res_num >= max_root_bus_resources) {
> > - printk(KERN_WARNING "PCI: Failed to allocate 0x%lx-0x%lx "
> > - "from %s for %s due to _CRS returning more than "
> > - "%d resource descriptors\n", (unsigned long) res->start,
> > - (unsigned long) res->end, root->name, info->name,
> > - max_root_bus_resources);
> > + pr_warning("PCI: Failed to allocate 0x%lx-0x%lx "
> > + "from %s for %s due to _CRS returning more than "
> > + "%d resource descriptors\n",
> > + (unsigned long)res->start, (unsigned long)res->end,
> > + root->name, info->name, max_root_bus_resources);
>
> Can you please avoid mixing cleanup patches with bug fixes ? I almost
> did not see the line below.
>
> > + info->bus->resource[info->res_num] = res;
>
> Storing the resource in defeats the purpose of the original patch,
> which makes sure that we do _NOT_ use the last 3 slots of the resource
> array for a root bus with a transparent bridge.
>
> > info->res_num++;
>
> This is the real bug. info->res_num should not be incremented when we
> run out of resources already.
This probably isn't needed but I don't think it is the cause of
the problem. It is just counting the number of _CRS returned
resources and I believe subsequent visits to setup_resource()
for additional returned resources will generate the same warning
as it also would if the instruction were removed and no longer
being used to keep an accurate count.
I suspect that the resource array is simply not large enough
for that system (and possibly others) and will have to be made
larger by increasing PCI_BUS_NUM_RESOURCES.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wed, 2009-06-24 at 17:19 +0200, Thomas Gleixner wrote:
> Larry,
>
> On Wed, 24 Jun 2009, Larry Finger wrote:
> > For the record, the printout from the patch results in the following:
> >
> > PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI Bus 0000:00
> > PCI: Failed to allocate 0xec000-0xeffff from PCI mem for PCI Bus
> > 0000:00 due to _CRS returning more than 13 resource descriptors
> > PCI: Failed to allocate 0xf0000-0xfffff from PCI mem for PCI Bus
> > 0000:00 due to _CRS returning more than 13 resource descriptors
> > PCI: Failed to allocate 0xc0000000-0xfebfffff from PCI mem for PCI Bus
> > 0000:00 due to _CRS returning more than 13 resource descriptors
>
> can you please the patch below instead of the other one ?
>
> Thanks,
>
> tglx
> ---
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 16c3fda..39a0cce 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -99,7 +99,6 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> "%d resource descriptors\n", (unsigned long) res->start,
> (unsigned long) res->end, root->name, info->name,
> max_root_bus_resources);
> - info->res_num++;
> return AE_OK;
> }
>
This fails and system does not boot, I already tested this patch 8 hours
ago.
Thanks,
--
JSR
On Wed, Jun 24, 2009 at 09:27:48PM +0530, Jaswinder Singh Rajput wrote:
> On Wed, 2009-06-24 at 17:19 +0200, Thomas Gleixner wrote:
> > Larry,
> >
> > On Wed, 24 Jun 2009, Larry Finger wrote:
> > > For the record, the printout from the patch results in the following:
> > >
> > > PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI Bus 0000:00
> > > PCI: Failed to allocate 0xec000-0xeffff from PCI mem for PCI Bus
> > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > PCI: Failed to allocate 0xf0000-0xfffff from PCI mem for PCI Bus
> > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > PCI: Failed to allocate 0xc0000000-0xfebfffff from PCI mem for PCI Bus
> > > 0000:00 due to _CRS returning more than 13 resource descriptors
> >
> > can you please the patch below instead of the other one ?
> >
> > Thanks,
> >
> > tglx
> > ---
> > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > index 16c3fda..39a0cce 100644
> > --- a/arch/x86/pci/acpi.c
> > +++ b/arch/x86/pci/acpi.c
> > @@ -99,7 +99,6 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > "%d resource descriptors\n", (unsigned long) res->start,
> > (unsigned long) res->end, root->name, info->name,
> > max_root_bus_resources);
> > - info->res_num++;
> > return AE_OK;
> > }
> >
>
> This fails and system does not boot, I already tested this patch 8 hours
> ago.
I think the resource array needs to be larger. Can you try
the below patch?
Gary
--- linux-2.6.30-rc8/include/linux/pci.h.ORIG 2009-06-24 09:03:41.000000000 -0700
+++ linux-2.6.30-rc8/include/linux/pci.h 2009-06-24 09:06:50.000000000 -0700
@@ -319,7 +319,7 @@ static inline void pci_add_saved_cap(str
}
#ifndef PCI_BUS_NUM_RESOURCES
-#define PCI_BUS_NUM_RESOURCES 16
+#define PCI_BUS_NUM_RESOURCES 20
#endif
#define PCI_REGION_FLAG_MASK 0x0fU /* These bits of resource flags tell us the PCI region flags */
On Wed, 2009-06-24 at 08:56 -0700, Gary Hade wrote:
> On Wed, Jun 24, 2009 at 04:51:48PM +0200, Thomas Gleixner wrote:
> > On Wed, 24 Jun 2009, Jaswinder Singh Rajput wrote:
> > > Reported-by: Larry Finger <[email protected]>
> > > Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> > > ---
> > > arch/x86/pci/acpi.c | 16 ++++++++++------
> > > 1 files changed, 10 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > index 16c3fda..0bc015f 100644
> > > --- a/arch/x86/pci/acpi.c
> > > +++ b/arch/x86/pci/acpi.c
> > > @@ -69,6 +69,9 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > > struct resource *root;
> > > int max_root_bus_resources = PCI_BUS_NUM_RESOURCES;
> > >
> > > + if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> > > + return AE_OK;
> > > +
> > > status = resource_to_addr(acpi_res, &addr);
> > > if (!ACPI_SUCCESS(status))
> > > return AE_OK;
> > > @@ -94,17 +97,18 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > > if (bus_has_transparent_bridge(info->bus))
> > > max_root_bus_resources -= 3;
> > > if (info->res_num >= max_root_bus_resources) {
> > > - printk(KERN_WARNING "PCI: Failed to allocate 0x%lx-0x%lx "
> > > - "from %s for %s due to _CRS returning more than "
> > > - "%d resource descriptors\n", (unsigned long) res->start,
> > > - (unsigned long) res->end, root->name, info->name,
> > > - max_root_bus_resources);
> > > + pr_warning("PCI: Failed to allocate 0x%lx-0x%lx "
> > > + "from %s for %s due to _CRS returning more than "
> > > + "%d resource descriptors\n",
> > > + (unsigned long)res->start, (unsigned long)res->end,
> > > + root->name, info->name, max_root_bus_resources);
> >
> > Can you please avoid mixing cleanup patches with bug fixes ? I almost
> > did not see the line below.
> >
> > > + info->bus->resource[info->res_num] = res;
> >
> > Storing the resource in defeats the purpose of the original patch,
> > which makes sure that we do _NOT_ use the last 3 slots of the resource
> > array for a root bus with a transparent bridge.
> >
> > > info->res_num++;
> >
> > This is the real bug. info->res_num should not be incremented when we
> > run out of resources already.
>
> This probably isn't needed but I don't think it is the cause of
> the problem. It is just counting the number of _CRS returned
> resources and I believe subsequent visits to setup_resource()
> for additional returned resources will generate the same warning
> as it also would if the instruction were removed and no longer
> being used to keep an accurate count.
>
Yes, this count is needed to avoid PCI failure.
Thanks,
--
JSR
On Wed, 24 Jun 2009, Jaswinder Singh Rajput wrote:
> On Wed, 2009-06-24 at 16:51 +0200, Thomas Gleixner wrote:
> > On Wed, 24 Jun 2009, Jaswinder Singh Rajput wrote:
> > > Reported-by: Larry Finger <[email protected]>
> > > Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> > > ---
> > > arch/x86/pci/acpi.c | 16 ++++++++++------
> > > 1 files changed, 10 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > index 16c3fda..0bc015f 100644
> > > --- a/arch/x86/pci/acpi.c
> > > +++ b/arch/x86/pci/acpi.c
> > > @@ -69,6 +69,9 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > > struct resource *root;
> > > int max_root_bus_resources = PCI_BUS_NUM_RESOURCES;
> > >
> > > + if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> > > + return AE_OK;
> > > +
>
> We need to test this otherwise we will get another oops.
Right, because you would store beyond the end of the array.
> > > status = resource_to_addr(acpi_res, &addr);
> > > if (!ACPI_SUCCESS(status))
> > > return AE_OK;
> > > @@ -94,17 +97,18 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > > if (bus_has_transparent_bridge(info->bus))
> > > max_root_bus_resources -= 3;
> > > if (info->res_num >= max_root_bus_resources) {
> > > - printk(KERN_WARNING "PCI: Failed to allocate 0x%lx-0x%lx "
> > > - "from %s for %s due to _CRS returning more than "
> > > - "%d resource descriptors\n", (unsigned long) res->start,
> > > - (unsigned long) res->end, root->name, info->name,
> > > - max_root_bus_resources);
> > > + pr_warning("PCI: Failed to allocate 0x%lx-0x%lx "
> > > + "from %s for %s due to _CRS returning more than "
> > > + "%d resource descriptors\n",
> > > + (unsigned long)res->start, (unsigned long)res->end,
> > > + root->name, info->name, max_root_bus_resources);
> >
> > Can you please avoid mixing cleanup patches with bug fixes ? I almost
> > did not see the line below.
> >
> > > + info->bus->resource[info->res_num] = res;
> >
>
> We need to set the resource even it is transparent bridge, otherwise pci
> will fail and system will not able to boot.
The fact that the system does boot with that patch is not making the
patch more correct. It fixes the boot problem at hand, but it does not
fix the root cause of the problem.
You stick the resource into the resource array, but it does not call
insert_resource(). Also you print a warning while the system seems to
be happy to use the device.
This is just inconsistent and the patch simply papers over the root
cause of the problem.
The reservation of the last 3 resources in the transparent case is
more likely the real reason as it reduces the number of available
slots in bus->resource[].
Can you please increase PCI_BUS_NUM_RESOURCES by at least 3 and test
with the one liner patch which removes the increment applied.
Also please provide the output of lspci on 2.6.30 (which does not have
f9cde5f applied).
Thanks,
tglx
On Wed, 24 Jun 2009 08:56:32 -0700
Gary Hade <[email protected]> wrote:
> On Wed, Jun 24, 2009 at 04:51:48PM +0200, Thomas Gleixner wrote:
> > On Wed, 24 Jun 2009, Jaswinder Singh Rajput wrote:
> > > Reported-by: Larry Finger <[email protected]>
> > > Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> > > ---
> > > arch/x86/pci/acpi.c | 16 ++++++++++------
> > > 1 files changed, 10 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > index 16c3fda..0bc015f 100644
> > > --- a/arch/x86/pci/acpi.c
> > > +++ b/arch/x86/pci/acpi.c
> > > @@ -69,6 +69,9 @@ setup_resource(struct acpi_resource *acpi_res,
> > > void *data) struct resource *root;
> > > int max_root_bus_resources = PCI_BUS_NUM_RESOURCES;
> > >
> > > + if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> > > + return AE_OK;
> > > +
> > > status = resource_to_addr(acpi_res, &addr);
> > > if (!ACPI_SUCCESS(status))
> > > return AE_OK;
> > > @@ -94,17 +97,18 @@ setup_resource(struct acpi_resource
> > > *acpi_res, void *data) if (bus_has_transparent_bridge(info->bus))
> > > max_root_bus_resources -= 3;
> > > if (info->res_num >= max_root_bus_resources) {
> > > - printk(KERN_WARNING "PCI: Failed to allocate
> > > 0x%lx-0x%lx "
> > > - "from %s for %s due to _CRS returning
> > > more than "
> > > - "%d resource descriptors\n", (unsigned
> > > long) res->start,
> > > - (unsigned long) res->end, root->name,
> > > info->name,
> > > - max_root_bus_resources);
> > > + pr_warning("PCI: Failed to allocate 0x%lx-0x%lx "
> > > + "from %s for %s due to _CRS returning
> > > more than "
> > > + "%d resource descriptors\n",
> > > + (unsigned long)res->start, (unsigned
> > > long)res->end,
> > > + root->name, info->name,
> > > max_root_bus_resources);
> >
> > Can you please avoid mixing cleanup patches with bug fixes ? I
> > almost did not see the line below.
> >
> > > + info->bus->resource[info->res_num] = res;
> >
> > Storing the resource in defeats the purpose of the original patch,
> > which makes sure that we do _NOT_ use the last 3 slots of the
> > resource array for a root bus with a transparent bridge.
> >
> > > info->res_num++;
> >
> > This is the real bug. info->res_num should not be incremented when
> > we run out of resources already.
>
> This probably isn't needed but I don't think it is the cause of
> the problem. It is just counting the number of _CRS returned
> resources and I believe subsequent visits to setup_resource()
> for additional returned resources will generate the same warning
> as it also would if the instruction were removed and no longer
> being used to keep an accurate count.
>
> I suspect that the resource array is simply not large enough
> for that system (and possibly others) and will have to be made
> larger by increasing PCI_BUS_NUM_RESOURCES.
Larry, have you been able to confirm that? Do we just need to bump the
PCI_BUS_NUM_RESOURCES on your machine?
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, Jun 24, 2009 at 09:45:00PM +0530, Jaswinder Singh Rajput wrote:
> On Wed, 2009-06-24 at 08:56 -0700, Gary Hade wrote:
> > On Wed, Jun 24, 2009 at 04:51:48PM +0200, Thomas Gleixner wrote:
> > > On Wed, 24 Jun 2009, Jaswinder Singh Rajput wrote:
> > > > Reported-by: Larry Finger <[email protected]>
> > > > Signed-off-by: Jaswinder Singh Rajput <[email protected]>
> > > > ---
> > > > arch/x86/pci/acpi.c | 16 ++++++++++------
> > > > 1 files changed, 10 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > > index 16c3fda..0bc015f 100644
> > > > --- a/arch/x86/pci/acpi.c
> > > > +++ b/arch/x86/pci/acpi.c
> > > > @@ -69,6 +69,9 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > > > struct resource *root;
> > > > int max_root_bus_resources = PCI_BUS_NUM_RESOURCES;
> > > >
> > > > + if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> > > > + return AE_OK;
> > > > +
> > > > status = resource_to_addr(acpi_res, &addr);
> > > > if (!ACPI_SUCCESS(status))
> > > > return AE_OK;
> > > > @@ -94,17 +97,18 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > > > if (bus_has_transparent_bridge(info->bus))
> > > > max_root_bus_resources -= 3;
> > > > if (info->res_num >= max_root_bus_resources) {
> > > > - printk(KERN_WARNING "PCI: Failed to allocate 0x%lx-0x%lx "
> > > > - "from %s for %s due to _CRS returning more than "
> > > > - "%d resource descriptors\n", (unsigned long) res->start,
> > > > - (unsigned long) res->end, root->name, info->name,
> > > > - max_root_bus_resources);
> > > > + pr_warning("PCI: Failed to allocate 0x%lx-0x%lx "
> > > > + "from %s for %s due to _CRS returning more than "
> > > > + "%d resource descriptors\n",
> > > > + (unsigned long)res->start, (unsigned long)res->end,
> > > > + root->name, info->name, max_root_bus_resources);
> > >
> > > Can you please avoid mixing cleanup patches with bug fixes ? I almost
> > > did not see the line below.
> > >
> > > > + info->bus->resource[info->res_num] = res;
> > >
> > > Storing the resource in defeats the purpose of the original patch,
> > > which makes sure that we do _NOT_ use the last 3 slots of the resource
> > > array for a root bus with a transparent bridge.
> > >
> > > > info->res_num++;
> > >
> > > This is the real bug. info->res_num should not be incremented when we
> > > run out of resources already.
> >
> > This probably isn't needed but I don't think it is the cause of
> > the problem. It is just counting the number of _CRS returned
> > resources and I believe subsequent visits to setup_resource()
> > for additional returned resources will generate the same warning
> > as it also would if the instruction were removed and no longer
> > being used to keep an accurate count.
> >
>
> Yes, this count is needed to avoid PCI failure.
With your proposed change that allows the last three slots
of the resource array to be populated, this is true. Without
your change I believe removal of this instriction is benign.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wed, 2009-06-24 at 09:13 -0700, Gary Hade wrote:
> On Wed, Jun 24, 2009 at 09:27:48PM +0530, Jaswinder Singh Rajput wrote:
> > On Wed, 2009-06-24 at 17:19 +0200, Thomas Gleixner wrote:
> > > Larry,
> > >
> > > On Wed, 24 Jun 2009, Larry Finger wrote:
> > > > For the record, the printout from the patch results in the following:
> > > >
> > > > PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI Bus 0000:00
> > > > PCI: Failed to allocate 0xec000-0xeffff from PCI mem for PCI Bus
> > > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > > PCI: Failed to allocate 0xf0000-0xfffff from PCI mem for PCI Bus
> > > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > > PCI: Failed to allocate 0xc0000000-0xfebfffff from PCI mem for PCI Bus
> > > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > >
> > > can you please the patch below instead of the other one ?
> > >
> > > Thanks,
> > >
> > > tglx
> > > ---
> > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > index 16c3fda..39a0cce 100644
> > > --- a/arch/x86/pci/acpi.c
> > > +++ b/arch/x86/pci/acpi.c
> > > @@ -99,7 +99,6 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > > "%d resource descriptors\n", (unsigned long) res->start,
> > > (unsigned long) res->end, root->name, info->name,
> > > max_root_bus_resources);
> > > - info->res_num++;
> > > return AE_OK;
> > > }
> > >
> >
> > This fails and system does not boot, I already tested this patch 8 hours
> > ago.
>
> I think the resource array needs to be larger. Can you try
> the below patch?
>
> Gary
>
> --- linux-2.6.30-rc8/include/linux/pci.h.ORIG 2009-06-24 09:03:41.000000000 -0700
> +++ linux-2.6.30-rc8/include/linux/pci.h 2009-06-24 09:06:50.000000000 -0700
> @@ -319,7 +319,7 @@ static inline void pci_add_saved_cap(str
> }
>
> #ifndef PCI_BUS_NUM_RESOURCES
> -#define PCI_BUS_NUM_RESOURCES 16
> +#define PCI_BUS_NUM_RESOURCES 20
> #endif
>
> #define PCI_REGION_FLAG_MASK 0x0fU /* These bits of resource flags tell us the PCI region flags */
Larry already suggested PCI_BUS_NUM_RESOURCES to 24 in his patch (check
first reply from him).
Then what is the point of removing last 3 and then adding 3 or more
resources, so patch f9cde5f lost its purpose, best case will be to
revert f9cde5f as it also removed :
if (info->res_num >= PCI_BUS_NUM_RESOURCES)
return AE_OK;
which is required in any case.
Thanks,
--
JSR
On Wed, 24 Jun 2009 22:03:39 +0530
Jaswinder Singh Rajput <[email protected]> wrote:
> On Wed, 2009-06-24 at 09:13 -0700, Gary Hade wrote:
> > On Wed, Jun 24, 2009 at 09:27:48PM +0530, Jaswinder Singh Rajput
> > wrote:
> > > On Wed, 2009-06-24 at 17:19 +0200, Thomas Gleixner wrote:
> > > > Larry,
> > > >
> > > > On Wed, 24 Jun 2009, Larry Finger wrote:
> > > > > For the record, the printout from the patch results in the
> > > > > following:
> > > > >
> > > > > PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI
> > > > > Bus 0000:00 PCI: Failed to allocate 0xec000-0xeffff from PCI
> > > > > mem for PCI Bus 0000:00 due to _CRS returning more than 13
> > > > > resource descriptors PCI: Failed to allocate 0xf0000-0xfffff
> > > > > from PCI mem for PCI Bus 0000:00 due to _CRS returning more
> > > > > than 13 resource descriptors PCI: Failed to allocate
> > > > > 0xc0000000-0xfebfffff from PCI mem for PCI Bus 0000:00 due to
> > > > > _CRS returning more than 13 resource descriptors
> > > >
> > > > can you please the patch below instead of the other one ?
> > > >
> > > > Thanks,
> > > >
> > > > tglx
> > > > ---
> > > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > > index 16c3fda..39a0cce 100644
> > > > --- a/arch/x86/pci/acpi.c
> > > > +++ b/arch/x86/pci/acpi.c
> > > > @@ -99,7 +99,6 @@ setup_resource(struct acpi_resource
> > > > *acpi_res, void *data) "%d resource descriptors\n", (unsigned
> > > > long) res->start, (unsigned long) res->end, root->name,
> > > > info->name, max_root_bus_resources);
> > > > - info->res_num++;
> > > > return AE_OK;
> > > > }
> > > >
> > >
> > > This fails and system does not boot, I already tested this patch
> > > 8 hours ago.
> >
> > I think the resource array needs to be larger. Can you try
> > the below patch?
> >
> > Gary
> >
> > --- linux-2.6.30-rc8/include/linux/pci.h.ORIG 2009-06-24
> > 09:03:41.000000000 -0700 +++
> > linux-2.6.30-rc8/include/linux/pci.h 2009-06-24
> > 09:06:50.000000000 -0700 @@ -319,7 +319,7 @@ static inline void
> > pci_add_saved_cap(str }
> > #ifndef PCI_BUS_NUM_RESOURCES
> > -#define PCI_BUS_NUM_RESOURCES 16
> > +#define PCI_BUS_NUM_RESOURCES 20
> > #endif
> >
> > #define PCI_REGION_FLAG_MASK 0x0fU /* These bits of
> > resource flags tell us the PCI region flags */
>
>
> Larry already suggested PCI_BUS_NUM_RESOURCES to 24 in his patch
> (check first reply from him).
>
> Then what is the point of removing last 3 and then adding 3 or more
> resources, so patch f9cde5f lost its purpose, best case will be to
> revert f9cde5f as it also removed :
>
> if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> return AE_OK;
>
> which is required in any case.
Yeah, I missed that too... Gary how do you feel about that as the real
fix? Would it be safe to make this a fairly high value like 64? Or
should we try to do something more flexible...
--
Jesse Barnes, Intel Open Source Technology Center
Gary Hade wrote:
> I think the resource array needs to be larger. Can you try
> the below patch?
>
> Gary
>
> --- linux-2.6.30-rc8/include/linux/pci.h.ORIG 2009-06-24 09:03:41.000000000 -0700
> +++ linux-2.6.30-rc8/include/linux/pci.h 2009-06-24 09:06:50.000000000 -0700
> @@ -319,7 +319,7 @@ static inline void pci_add_saved_cap(str
> }
>
> #ifndef PCI_BUS_NUM_RESOURCES
> -#define PCI_BUS_NUM_RESOURCES 16
> +#define PCI_BUS_NUM_RESOURCES 20
> #endif
>
> #define PCI_REGION_FLAG_MASK 0x0fU /* These bits of resource flags tell us the PCI region flags */
As noted, I had already tested and posted that increasing
PCI_BUS_NUM_RESOURCES from 16 to 24 "solves" the problem as does
increasing it to 20, but I wonder if that isn't just papering over the
bug, which will reoccur when there is a machine with even a more
complicated PCI bus structure even more complicated than mine. Of
course, increasing it to something as large as 64 might delay the
problem "forever".
Larry
On Wed, Jun 24, 2009 at 09:44:11AM -0700, Jesse Barnes wrote:
> On Wed, 24 Jun 2009 22:03:39 +0530
> Jaswinder Singh Rajput <[email protected]> wrote:
>
> > On Wed, 2009-06-24 at 09:13 -0700, Gary Hade wrote:
> > > On Wed, Jun 24, 2009 at 09:27:48PM +0530, Jaswinder Singh Rajput
> > > wrote:
> > > > On Wed, 2009-06-24 at 17:19 +0200, Thomas Gleixner wrote:
> > > > > Larry,
> > > > >
> > > > > On Wed, 24 Jun 2009, Larry Finger wrote:
> > > > > > For the record, the printout from the patch results in the
> > > > > > following:
> > > > > >
> > > > > > PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI
> > > > > > Bus 0000:00 PCI: Failed to allocate 0xec000-0xeffff from PCI
> > > > > > mem for PCI Bus 0000:00 due to _CRS returning more than 13
> > > > > > resource descriptors PCI: Failed to allocate 0xf0000-0xfffff
> > > > > > from PCI mem for PCI Bus 0000:00 due to _CRS returning more
> > > > > > than 13 resource descriptors PCI: Failed to allocate
> > > > > > 0xc0000000-0xfebfffff from PCI mem for PCI Bus 0000:00 due to
> > > > > > _CRS returning more than 13 resource descriptors
> > > > >
> > > > > can you please the patch below instead of the other one ?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > tglx
> > > > > ---
> > > > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > > > index 16c3fda..39a0cce 100644
> > > > > --- a/arch/x86/pci/acpi.c
> > > > > +++ b/arch/x86/pci/acpi.c
> > > > > @@ -99,7 +99,6 @@ setup_resource(struct acpi_resource
> > > > > *acpi_res, void *data) "%d resource descriptors\n", (unsigned
> > > > > long) res->start, (unsigned long) res->end, root->name,
> > > > > info->name, max_root_bus_resources);
> > > > > - info->res_num++;
> > > > > return AE_OK;
> > > > > }
> > > > >
> > > >
> > > > This fails and system does not boot, I already tested this patch
> > > > 8 hours ago.
> > >
> > > I think the resource array needs to be larger. Can you try
> > > the below patch?
> > >
> > > Gary
> > >
> > > --- linux-2.6.30-rc8/include/linux/pci.h.ORIG 2009-06-24
> > > 09:03:41.000000000 -0700 +++
> > > linux-2.6.30-rc8/include/linux/pci.h 2009-06-24
> > > 09:06:50.000000000 -0700 @@ -319,7 +319,7 @@ static inline void
> > > pci_add_saved_cap(str }
> > > #ifndef PCI_BUS_NUM_RESOURCES
> > > -#define PCI_BUS_NUM_RESOURCES 16
> > > +#define PCI_BUS_NUM_RESOURCES 20
> > > #endif
> > >
> > > #define PCI_REGION_FLAG_MASK 0x0fU /* These bits of
> > > resource flags tell us the PCI region flags */
> >
> >
> > Larry already suggested PCI_BUS_NUM_RESOURCES to 24 in his patch
> > (check first reply from him).
> >
> > Then what is the point of removing last 3 and then adding 3 or more
> > resources, so patch f9cde5f lost its purpose, best case will be to
> > revert f9cde5f as it also removed :
> >
> > if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> > return AE_OK;
> >
> > which is required in any case.
>
> Yeah, I missed that too... Gary how do you feel about that as the real
> fix? Would it be safe to make this a fairly high value like 64? Or
> should we try to do something more flexible...
Sorry I missed the 16->24 change and other good information
in Larry's earlier message. There were 17 occurrences of the
"PCI: transparent bridge..." message that Larry added which
indicates that _CRS returned 17 resources. This is 4 more
than the current 13 maximum which explains the problem.
I believe Larry's 8 slot increase (16->24) in the array size
provided 4 slots beyond what is needed for Larry's box but
an even higher ceiling would certainly feel more comfortable.
I was thinking 32 but 64 would be better if there aren't any
downsides elsewhere of making the array that big.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wed, 24 Jun 2009 10:55:13 -0700
Gary Hade <[email protected]> wrote:
> On Wed, Jun 24, 2009 at 09:44:11AM -0700, Jesse Barnes wrote:
> > On Wed, 24 Jun 2009 22:03:39 +0530
> > Jaswinder Singh Rajput <[email protected]> wrote:
> >
> > > On Wed, 2009-06-24 at 09:13 -0700, Gary Hade wrote:
> > > > On Wed, Jun 24, 2009 at 09:27:48PM +0530, Jaswinder Singh Rajput
> > > > wrote:
> > > > > On Wed, 2009-06-24 at 17:19 +0200, Thomas Gleixner wrote:
> > > > > > Larry,
> > > > > >
> > > > > > On Wed, 24 Jun 2009, Larry Finger wrote:
> > > > > > > For the record, the printout from the patch results in the
> > > > > > > following:
> > > > > > >
> > > > > > > PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for
> > > > > > > PCI Bus 0000:00 PCI: Failed to allocate 0xec000-0xeffff
> > > > > > > from PCI mem for PCI Bus 0000:00 due to _CRS returning
> > > > > > > more than 13 resource descriptors PCI: Failed to allocate
> > > > > > > 0xf0000-0xfffff from PCI mem for PCI Bus 0000:00 due to
> > > > > > > _CRS returning more than 13 resource descriptors PCI:
> > > > > > > Failed to allocate 0xc0000000-0xfebfffff from PCI mem for
> > > > > > > PCI Bus 0000:00 due to _CRS returning more than 13
> > > > > > > resource descriptors
> > > > > >
> > > > > > can you please the patch below instead of the other one ?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > tglx
> > > > > > ---
> > > > > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > > > > index 16c3fda..39a0cce 100644
> > > > > > --- a/arch/x86/pci/acpi.c
> > > > > > +++ b/arch/x86/pci/acpi.c
> > > > > > @@ -99,7 +99,6 @@ setup_resource(struct acpi_resource
> > > > > > *acpi_res, void *data) "%d resource descriptors\n",
> > > > > > (unsigned long) res->start, (unsigned long) res->end,
> > > > > > root->name, info->name, max_root_bus_resources);
> > > > > > - info->res_num++;
> > > > > > return AE_OK;
> > > > > > }
> > > > > >
> > > > >
> > > > > This fails and system does not boot, I already tested this
> > > > > patch 8 hours ago.
> > > >
> > > > I think the resource array needs to be larger. Can you try
> > > > the below patch?
> > > >
> > > > Gary
> > > >
> > > > --- linux-2.6.30-rc8/include/linux/pci.h.ORIG 2009-06-24
> > > > 09:03:41.000000000 -0700 +++
> > > > linux-2.6.30-rc8/include/linux/pci.h 2009-06-24
> > > > 09:06:50.000000000 -0700 @@ -319,7 +319,7 @@ static inline void
> > > > pci_add_saved_cap(str }
> > > > #ifndef PCI_BUS_NUM_RESOURCES
> > > > -#define PCI_BUS_NUM_RESOURCES 16
> > > > +#define PCI_BUS_NUM_RESOURCES 20
> > > > #endif
> > > >
> > > > #define PCI_REGION_FLAG_MASK 0x0fU /* These bits
> > > > of resource flags tell us the PCI region flags */
> > >
> > >
> > > Larry already suggested PCI_BUS_NUM_RESOURCES to 24 in his patch
> > > (check first reply from him).
> > >
> > > Then what is the point of removing last 3 and then adding 3 or
> > > more resources, so patch f9cde5f lost its purpose, best case will
> > > be to revert f9cde5f as it also removed :
> > >
> > > if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> > > return AE_OK;
> > >
> > > which is required in any case.
> >
> > Yeah, I missed that too... Gary how do you feel about that as the
> > real fix? Would it be safe to make this a fairly high value like
> > 64? Or should we try to do something more flexible...
>
> Sorry I missed the 16->24 change and other good information
> in Larry's earlier message. There were 17 occurrences of the
> "PCI: transparent bridge..." message that Larry added which
> indicates that _CRS returned 17 resources. This is 4 more
> than the current 13 maximum which explains the problem.
> I believe Larry's 8 slot increase (16->24) in the array size
> provided 4 slots beyond what is needed for Larry's box but
> an even higher ceiling would certainly feel more comfortable.
> I was thinking 32 but 64 would be better if there aren't any
> downsides elsewhere of making the array that big.
Just chatting with Len about this; apparently the PNPACPI layer ran
into something similar awhile back, and they had to go to a variable
sized list of resources, due to weird machines with huge numbers of
resources. Matthew says he's got an idea about how to fix this up; if
that doesn't work out I'll see about making the bus resource array into
a list instead.
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 24 Jun 2009, Jesse Barnes wrote:
> > I was thinking 32 but 64 would be better if there aren't any
> > downsides elsewhere of making the array that big.
>
> Just chatting with Len about this; apparently the PNPACPI layer ran
> into something similar awhile back, and they had to go to a variable
> sized list of resources, due to weird machines with huge numbers of
> resources. Matthew says he's got an idea about how to fix this up; if
> that doesn't work out I'll see about making the bus resource array into
> a list instead.
Can we just bring the limit check back and increase the number for now
until folks come up with a better solution ?
Thanks,
tglx
On Wed, Jun 24, 2009 at 10:03:39PM +0530, Jaswinder Singh Rajput wrote:
> On Wed, 2009-06-24 at 09:13 -0700, Gary Hade wrote:
> > On Wed, Jun 24, 2009 at 09:27:48PM +0530, Jaswinder Singh Rajput wrote:
> > > On Wed, 2009-06-24 at 17:19 +0200, Thomas Gleixner wrote:
> > > > Larry,
> > > >
> > > > On Wed, 24 Jun 2009, Larry Finger wrote:
> > > > > For the record, the printout from the patch results in the following:
> > > > >
> > > > > PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI Bus 0000:00
> > > > > PCI: Failed to allocate 0xec000-0xeffff from PCI mem for PCI Bus
> > > > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > > > PCI: Failed to allocate 0xf0000-0xfffff from PCI mem for PCI Bus
> > > > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > > > PCI: Failed to allocate 0xc0000000-0xfebfffff from PCI mem for PCI Bus
> > > > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > >
> > > > can you please the patch below instead of the other one ?
> > > >
> > > > Thanks,
> > > >
> > > > tglx
> > > > ---
> > > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > > index 16c3fda..39a0cce 100644
> > > > --- a/arch/x86/pci/acpi.c
> > > > +++ b/arch/x86/pci/acpi.c
> > > > @@ -99,7 +99,6 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > > > "%d resource descriptors\n", (unsigned long) res->start,
> > > > (unsigned long) res->end, root->name, info->name,
> > > > max_root_bus_resources);
> > > > - info->res_num++;
> > > > return AE_OK;
> > > > }
> > > >
> > >
> > > This fails and system does not boot, I already tested this patch 8 hours
> > > ago.
> >
> > I think the resource array needs to be larger. Can you try
> > the below patch?
> >
> > Gary
> >
> > --- linux-2.6.30-rc8/include/linux/pci.h.ORIG 2009-06-24 09:03:41.000000000 -0700
> > +++ linux-2.6.30-rc8/include/linux/pci.h 2009-06-24 09:06:50.000000000 -0700
> > @@ -319,7 +319,7 @@ static inline void pci_add_saved_cap(str
> > }
> >
> > #ifndef PCI_BUS_NUM_RESOURCES
> > -#define PCI_BUS_NUM_RESOURCES 16
> > +#define PCI_BUS_NUM_RESOURCES 20
> > #endif
> >
> > #define PCI_REGION_FLAG_MASK 0x0fU /* These bits of resource flags tell us the PCI region flags */
>
>
> Larry already suggested PCI_BUS_NUM_RESOURCES to 24 in his patch (check
> first reply from him).
Sorry I missed that.
>
> Then what is the point of removing last 3 and then adding 3 or more
> resources, so patch f9cde5f lost its purpose,
The reason for not populating the last 3 slots of the resource
array when there is a transparent bridge on the bus is to make
sure devices downstream of the transparent bridge get the resources
they need. Because of the offset of 3 between the transparent
bridge parent and child bus resource arrays established by
if (dev->transparent) {
dev_info(&dev->dev, "transparent bridge\n");
for(i = 3; i < PCI_BUS_NUM_RESOURCES; i++)
child->resource[i] = child->parent->resource[i - 3];
}
in pci_read_bridge_bases() [drivers/pci/probe.c] and refreshed by
similar in adjust_transparent_bridge_resources() [arch/x86/pci/acpi.c]
the transparent bridge child bus resource array will not reference
the resources in those last 3 slots.
> best case will be to
> revert f9cde5f as it also removed :
>
> if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> return AE_OK;
>
> which is required in any case.
In the case of a root bus without a transparent bridge,
this still exists (w/added warning and resource count increment) as
if (info->res_num >= max_root_bus_resources) {
< warn and increment resource count >
return AE_OK;
}
because max_root_bus_resources==PCI_BUS_NUM_RESOURCES
In the case were there is a transparent bridge on the root bus,
'max_root_bus_resources' needs to be 3 less than PCI_BUS_NUM_RESOURCES
to avoid populating the last 3 slots of the array that are not
visible below the transparent bridge.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wed, Jun 24, 2009 at 08:45:31PM +0200, Thomas Gleixner wrote:
> On Wed, 24 Jun 2009, Jesse Barnes wrote:
> > > I was thinking 32 but 64 would be better if there aren't any
> > > downsides elsewhere of making the array that big.
> >
> > Just chatting with Len about this; apparently the PNPACPI layer ran
> > into something similar awhile back, and they had to go to a variable
> > sized list of resources, due to weird machines with huge numbers of
> > resources. Matthew says he's got an idea about how to fix this up; if
> > that doesn't work out I'll see about making the bus resource array into
> > a list instead.
>
> Can we just bring the limit check back and increase the number for now
> until folks come up with a better solution ?
Another possible option is leaving in the limit check (still valid
IMO for correct behavior of previous 'pci=use_crs') and reverting
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9e9f46c44e487af0a82eb61b624553e2f7118f5b
until the better solution for the fixed size array issue is
available.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
Gary Hade wrote:
> On Wed, Jun 24, 2009 at 08:45:31PM +0200, Thomas Gleixner wrote:
>> Can we just bring the limit check back and increase the number for now
>> until folks come up with a better solution ?
>
> Another possible option is leaving in the limit check (still valid
> IMO for correct behavior of previous 'pci=use_crs') and reverting
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9e9f46c44e487af0a82eb61b624553e2f7118f5b
> until the better solution for the fixed size array issue is
> available.
Either increasing PCI_BUS_NUM_RESOURCES from 16 to 20 or 24 or
reverting f9cde5f will work for my system.
Larry
On Wed, Jun 24, 2009 at 03:05:12PM -0500, Larry Finger wrote:
> Gary Hade wrote:
> > On Wed, Jun 24, 2009 at 08:45:31PM +0200, Thomas Gleixner wrote:
> >> Can we just bring the limit check back and increase the number for now
> >> until folks come up with a better solution ?
> >
> > Another possible option is leaving in the limit check (still valid
> > IMO for correct behavior of previous 'pci=use_crs') and reverting
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9e9f46c44e487af0a82eb61b624553e2f7118f5b
> > until the better solution for the fixed size array issue is
> > available.
>
> Either increasing PCI_BUS_NUM_RESOURCES from 16 to 20 or 24
Yes, it looks to me like 20 might be the absolute minimum
that your system could tolerate. The big mystery is how much
to increase it so we don't see the same problem on other
systems where _CRS may return some unknown amount more that
the 17 resources that are being returned on your system.
> or reverting f9cde5f will work for my system.
This would not be good without also reverting
9e9f46c44e487af0a82eb61b624553e2f7118f5b since devices
below the transparent bridge on your's and other's systems
may have trouble getting the resources they need.
Removing the check would only hide possibly more insidious
and difficult to debug problems that could show up later.
This was the main reason I provided the patch. This kind
of check should have actually existed prior to
9e9f46c44e487af0a82eb61b624553e2f7118f5b when 'pci=use_crs'
was needed to enable use of the _CRS data.
Thanks,
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
please fix the whole boot log with debug.
need to make sure how many HT chain in your system.
YH
Yinghai Lu wrote:
> please fix the whole boot log with debug.
>
> need to make sure how many HT chain in your system.
Do you mean the output of dmesg? I'm not sure what you mean by "debug".
Larry
On Wed, Jun 24, 2009 at 2:42 PM, Larry Finger<[email protected]> wrote:
> Yinghai Lu wrote:
>> please fix the whole boot log with debug.
>>
>> need to make sure how many HT chain in your system.
>
> Do you mean the output of dmesg? I'm not sure what you mean by "debug".
>
put debug in your boot line of grub.conf
YH
Yinghai Lu wrote:
> On Wed, Jun 24, 2009 at 2:42 PM, Larry Finger<[email protected]> wrote:
>> Yinghai Lu wrote:
>>> please fix the whole boot log with debug.
>>>
>>> need to make sure how many HT chain in your system.
>> Do you mean the output of dmesg? I'm not sure what you mean by "debug".
>>
> put debug in your boot line of grub.conf
I hope this is what you wanted.
===============================
Linux version 2.6.30-Linus-08503-g4e8a237-dirty (finger@larrylap) (gcc
version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #155 SMP
Wed Jun 24 16:50:16 CDT 2009
Command line:
root=/dev/disk/by-id/scsi-SATA_TOSHIBA_MK2546G_18C2P0KCT-part8
resume=/dev/disk/by-id/ata-TOSHIBA_MK2546GSX_18C2P0KCT-part5
splash=silent vga=0x317 debug
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
Centaur CentaurHauls
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000d2000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000bbf50000 (usable)
BIOS-e820: 00000000bbf50000 - 00000000bbf65000 (ACPI data)
BIOS-e820: 00000000bbf65000 - 00000000bbf66000 (ACPI NVS)
BIOS-e820: 00000000bbf66000 - 00000000c0000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
DMI present.
last_pfn = 0xbbf50 max_arch_pfn = 0x400000000
MTRR default type: uncachable
MTRR fixed ranges enabled:
00000-9FFFF write-back
A0000-BFFFF uncachable
C0000-D3FFF write-protect
D4000-DBFFF uncachable
DC000-DFFFF write-protect
E0000-E3FFF uncachable
E4000-FFFFF write-protect
MTRR variable ranges enabled:
0 base 0000000000 mask FF80000000 write-back
1 base 0080000000 mask FFC0000000 write-back
2 disabled
3 disabled
4 disabled
5 disabled
6 disabled
7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
e820 update range: 0000000000001000 - 0000000000006000 (usable) ==>
(reserved)
Scanning 1 areas for low memory corruption
modified physical RAM map:
modified: 0000000000000000 - 0000000000001000 (usable)
modified: 0000000000001000 - 0000000000006000 (reserved)
modified: 0000000000006000 - 000000000009e000 (usable)
modified: 000000000009e000 - 00000000000a0000 (reserved)
modified: 00000000000d2000 - 0000000000100000 (reserved)
modified: 0000000000100000 - 00000000bbf50000 (usable)
modified: 00000000bbf50000 - 00000000bbf65000 (ACPI data)
modified: 00000000bbf65000 - 00000000bbf66000 (ACPI NVS)
modified: 00000000bbf66000 - 00000000c0000000 (reserved)
modified: 00000000e0000000 - 00000000f0000000 (reserved)
modified: 00000000fec00000 - 00000000fec10000 (reserved)
modified: 00000000fee00000 - 00000000fee01000 (reserved)
modified: 00000000fff80000 - 0000000100000000 (reserved)
initial memory mapped : 0 - 20000000
init_memory_mapping: 0000000000000000-00000000bbf50000
0000000000 - 00bbe00000 page 2M
00bbe00000 - 00bbf50000 page 4k
kernel direct mapping tables up to bbf50000 @ 8000-d000
RAMDISK: 37539000 - 37fef403
ACPI: RSDP 00000000000f80c0 00024 (v03 HPQOEM)
ACPI: XSDT 00000000bbf5d343 0006C (v01 HPQOEM SLIC-MPC 06040000 LTP
00000000)
ACPI: FACP 00000000bbf64874 000F4 (v03 HPQOEM SLIC-MPC 06040000 PTL_
000F4240)
ACPI: DSDT 00000000bbf5d3af 074C5 (v01 HPQOEM SLIC-MPC 06040000 MSFT
03000000)
ACPI: FACS 00000000bbf65fc0 00040
ACPI: SLIC 00000000bbf649dc 00176 (v01 HPQOEM SLIC-MPC 06040000 HPQ
00000001)
ACPI: WDAT 00000000bbf64b52 00104 (v01 PTLTD WDATTBL 06040000 LTP
00000001)
ACPI: SRAT 00000000bbf64c56 000A0 (v01 AMD HAMMER 06040000 AMD
00000001)
ACPI: MCFG 00000000bbf64cf6 0003C (v01 HPQOEM SLIC-MPC 06040000 LTP
00000000)
ACPI: HPET 00000000bbf64d32 00038 (v01 HPQOEM SLIC-MPC 06040000 LTP
00000001)
ACPI: APIC 00000000bbf64d6a 00068 (v01 HPQOEM SLIC-MPC 06040000 LTP
00000000)
ACPI: BOOT 00000000bbf64dd2 00028 (v01 HPQOEM SLIC-MPC 06040000 LTP
00000001)
ACPI: SSDT 00000000bbf64dfa 00206 (v01 HPQOEM SLIC-MPC 06040000 LTP
00000001)
ACPI: Local APIC address 0xfee00000
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: Node 0 PXM 0 0-a0000
SRAT: Node 0 PXM 0 100000-c0000000
NUMA: Allocated memnodemap from b000 - c840
NUMA: Using 20 for the hash shift.
Bootmem setup node 0 0000000000000000-00000000bbf50000
NODE_DATA [000000000000c840 - 000000000001183f]
bootmap [0000000000012000 - 00000000000297ef] pages 18
(8 early reservations) ==> bootmem [0000000000 - 00bbf50000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 -
0000001000]
#1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 -
0000008000]
#2 [0001000000 - 000209ed60] TEXT DATA BSS ==> [0001000000 -
000209ed60]
#3 [0037539000 - 0037fef403] RAMDISK ==> [0037539000 -
0037fef403]
#4 [000009e000 - 0000100000] BIOS reserved ==> [000009e000 -
0000100000]
#5 [000209f000 - 000209f188] BRK ==> [000209f000 -
000209f188]
#6 [0000008000 - 000000b000] PGTABLE ==> [0000008000 -
000000b000]
#7 [000000b000 - 000000c840] MEMNODEMAP ==> [000000b000 -
000000c840]
found SMP MP-table at [ffff8800000f8090] f8090
[ffffea0000000000-ffffea00041fffff] PMD ->
[ffff880002600000-ffff8800067fffff] on node 0
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal 0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
0: 0x00000000 -> 0x00000001
0: 0x00000006 -> 0x0000009e
0: 0x00000100 -> 0x000bbf50
On node 0 totalpages: 769769
DMA zone: 88 pages used for memmap
DMA zone: 105 pages reserved
DMA zone: 3800 pages, LIFO batch:0
DMA32 zone: 16453 pages used for memmap
DMA32 zone: 749323 pages, LIFO batch:31
Detected use of extended apic ids on hypertransport bus
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x10de8201 base: 0xfed00000
SMP: Allowing 2 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 24
Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)
NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:2 nr_node_ids:1
PERCPU: Embedded 24 pages at ffff8800020e4000, static data 69344 bytes
Built 1 zonelists in Node order, mobility grouping on. Total pages:
753123
Policy zone: DMA32
Kernel command line:
root=/dev/disk/by-id/scsi-SATA_TOSHIBA_MK2546G_18C2P0KCT-part8
resume=/dev/disk/by-id/ata-TOSHIBA_MK2546GSX_18C2P0KCT-part5
splash=silent vga=0x317 debug
PID hash table entries: 4096 (order: 12, 32768 bytes)
Initializing CPU#0
Checking aperture...
No AGP bridge found
Node 0: aperture @ 7000000000 size 32 MB
Aperture beyond 4GB. Ignoring.
Memory: 2982916k/3079488k available (2417k kernel code, 412k absent,
96160k reserved, 1789k data, 540k init)
NR_IRQS:4352
Extended CMOS year: 2000
Fast TSC calibration using PIT
Detected 2000.016 MHz processor.
spurious 8259A interrupt: IRQ7.
Console: colour dummy device 80x25
console [tty0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 48
... MAX_LOCKDEP_KEYS: 8191
... CLASSHASH_SIZE: 4096
... MAX_LOCKDEP_ENTRIES: 16384
... MAX_LOCKDEP_CHAINS: 32768
... CHAINHASH_SIZE: 16384
memory used by lock dependency info: 5695 kB
per task-struct memory footprint: 1920 bytes
hpet clockevent registered
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Calibrating delay loop (skipped), value calculated using timer
frequency.. 4000.03 BogoMIPS (lpj=8000064)
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0x0 -> Node 0
tseg: 00bbf80000
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 5 MCE banks
using C1E aware idle routine
ACPI: Core revision 20090521
Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: AMD Turion(tm) 64 X2 TL-60 stepping 02
lockdep: fixing up alternatives.
Booting processor 1 APIC 0x1 ip 0x6000
Initializing CPU#1
Calibrating delay using timer specific routine.. 4000.38 BogoMIPS
(lpj=8000763)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1/0x1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
mce: CPU supports 5 MCE banks
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: AMD Turion(tm) 64 X2 TL-60 stepping 02
Brought up 2 CPUs
Total of 2 processors activated (8000.41 BogoMIPS).
System has AMD C1E enabled
Switch to broadcast mode on CPU1
CPU0 attaching sched-domain:
domain 0: span 0-1 level CPU
groups: 0 1
CPU1 attaching sched-domain:
domain 0: span 0-1 level CPU
groups: 1 0
Switch to broadcast mode on CPU0
NET: Registered protocol family 16
node 0 link 0: io port [1000, fffff]
TOM: 00000000c0000000 aka 3072M
node 0 link 0: mmio [a0000, bffff]
node 0 link 0: mmio [c0000000, dfffffff]
node 0 link 0: mmio [e0000000, efffffff]
node 0 link 0: mmio [f0000000, fe0bffff]
bus: [00,ff] on node 0 link 0
bus: 00 index 0 io port: [0, ffff]
bus: 00 index 1 mmio: [a0000, bffff]
bus: 00 index 2 mmio: [c0000000, fcffffffff]
ACPI: bus type pci registered
PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 9
PCI: MCFG area at e0000000 reserved in E820
PCI: Using MMCONFIG at e0000000 - e09fffff
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: EC: Enabling special treatment for EC from MSI.
ACPI: EC: Look up EC in DSDT
ACPI: BIOS _OSI(Linux) query ignored
ACPI: EC: non-query interrupt received, switching to interrupt mode
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: EC: GPE = 0x2a, I/O: command/status = 0x66, data = 0x62
ACPI: EC: driver started in interrupt mode
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:01.1: reg 10 io port: [0x3080-0x30bf]
pci 0000:00:01.1: reg 20 io port: [0x3040-0x307f]
pci 0000:00:01.1: reg 24 io port: [0x3000-0x303f]
pci 0000:00:01.1: PME# supported from D3hot D3cold
pci 0000:00:01.1: PME# disabled
pci 0000:00:01.3: reg 10 32bit mmio: [0xfc200000-0xfc27ffff]
pci 0000:00:02.0: reg 10 32bit mmio: [0xfc486000-0xfc486fff]
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.0: PME# disabled
pci 0000:00:02.1: reg 10 32bit mmio: [0xfc489000-0xfc4890ff]
pci 0000:00:02.1: supports D1 D2
pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.1: PME# disabled
pci 0000:00:04.0: reg 10 32bit mmio: [0xfc487000-0xfc487fff]
pci 0000:00:04.0: supports D1 D2
pci 0000:00:04.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:04.0: PME# disabled
pci 0000:00:04.1: reg 10 32bit mmio: [0xfc489400-0xfc4894ff]
pci 0000:00:04.1: supports D1 D2
pci 0000:00:04.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:04.1: PME# disabled
pci 0000:00:06.0: reg 20 io port: [0x30c0-0x30cf]
pci 0000:00:07.0: reg 10 32bit mmio: [0xfc480000-0xfc483fff]
pci 0000:00:07.0: PME# supported from D3hot D3cold
pci 0000:00:07.0: PME# disabled
pci 0000:00:09.0: reg 10 io port: [0x30f0-0x30f7]
pci 0000:00:09.0: reg 14 io port: [0x30e4-0x30e7]
pci 0000:00:09.0: reg 18 io port: [0x30e8-0x30ef]
pci 0000:00:09.0: reg 1c io port: [0x30e0-0x30e3]
pci 0000:00:09.0: reg 20 io port: [0x30d0-0x30df]
pci 0000:00:09.0: reg 24 32bit mmio: [0xfc484000-0xfc485fff]
pci 0000:00:0a.0: reg 10 32bit mmio: [0xfc488000-0xfc488fff]
pci 0000:00:0a.0: reg 14 io port: [0x30f8-0x30ff]
pci 0000:00:0a.0: reg 18 32bit mmio: [0xfc489c00-0xfc489cff]
pci 0000:00:0a.0: reg 1c 32bit mmio: [0xfc489800-0xfc48980f]
pci 0000:00:0a.0: supports D1 D2
pci 0000:00:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0a.0: PME# disabled
pci 0000:00:0c.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0c.0: PME# disabled
pci 0000:00:0d.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0d.0: PME# disabled
pci 0000:00:12.0: reg 10 32bit mmio: [0xf4000000-0xf4ffffff]
pci 0000:00:12.0: reg 14 64bit mmio: [0xd0000000-0xdfffffff]
pci 0000:00:12.0: reg 1c 64bit mmio: [0xf0000000-0xf0ffffff]
pci 0000:00:12.0: reg 30 32bit mmio: [0x000000-0x01ffff]
pci 0000:01:09.0: reg 10 32bit mmio: [0x000000-0x0007ff]
pci 0000:01:09.0: supports D1 D2
pci 0000:01:09.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.0: PME# disabled
pci 0000:01:09.1: reg 10 32bit mmio: [0xfc100800-0xfc1008ff]
pci 0000:01:09.1: supports D1 D2
pci 0000:01:09.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.1: PME# disabled
pci 0000:01:09.2: reg 10 32bit mmio: [0xfc100c00-0xfc100cff]
pci 0000:01:09.2: supports D1 D2
pci 0000:01:09.2: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.2: PME# disabled
pci 0000:01:09.3: reg 10 32bit mmio: [0xfc101000-0xfc1010ff]
pci 0000:01:09.3: supports D1 D2
pci 0000:01:09.3: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.3: PME# disabled
pci 0000:01:09.4: reg 10 32bit mmio: [0xfc101400-0xfc1014ff]
pci 0000:01:09.4: supports D1 D2
pci 0000:01:09.4: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:09.4: PME# disabled
pci 0000:00:08.0: transparent bridge
pci 0000:00:08.0: bridge 32bit mmio: [0xfc100000-0xfc1fffff]
pci 0000:00:0c.0: bridge io port: [0x4000-0x4fff]
pci 0000:00:0c.0: bridge 32bit mmio: [0xf8000000-0xfbffffff]
pci 0000:04:00.0: reg 10 32bit mmio: [0xfc000000-0xfc003fff]
pci 0000:04:00.0: supports D1 D2
pci 0000:00:0d.0: bridge 32bit mmio: [0xfc000000-0xfc0fffff]
PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI Bus 0000:00
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XVR1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XVR2._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK2] (IRQs 5 7 *10 11 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 5 7 10 *11 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LK1E] (IRQs 19 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [LK2E] (IRQs 19 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [LK3E] (IRQs 19 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [LK4E] (IRQs 19 20 21 22 23) *10
ACPI: PCI Interrupt Link [LSMB] (IRQs 18) *10
ACPI: PCI Interrupt Link [LUS0] (IRQs 17) *11
ACPI: PCI Interrupt Link [LUS2] (IRQs 17) *7
ACPI: PCI Interrupt Link [LMAC] (IRQs 19 20 21 22 23) *11
ACPI: PCI Interrupt Link [LAZA] (IRQs 19 20 21 22 23) *10
ACPI: PCI Interrupt Link [LGPU] (IRQs 19 20 21 22 23) *10
ACPI: PCI Interrupt Link [LPID] (IRQs 19 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [LSI0] (IRQs 19 20 21 22 23) *5
ACPI: PCI Interrupt Link [Z012] (IRQs 16) *10
ACPI: PCI Interrupt Link [Z013] (IRQs 16) *11
ACPI: PCI Interrupt Link [LPMU] (IRQs 18) *11
PCI: Using ACPI for IRQ routing
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31
hpet0: 3 comparators, 32-bit 25.000000 MHz counter
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
system 00:00: iomem range 0xffc00000-0xffffffff could not be reserved
system 00:00: iomem range 0xfec00000-0xfec00fff has been reserved
system 00:00: iomem range 0xfee00000-0xfeefffff could not be reserved
system 00:00: iomem range 0xfec80000-0xfec80fff has been reserved
system 00:00: iomem range 0xfef00000-0xfef00fff has been reserved
system 00:03: iomem range 0xe0000000-0xefffffff has been reserved
system 00:04: ioport range 0x360-0x361 has been reserved
system 00:04: ioport range 0x4d0-0x4d1 has been reserved
system 00:0b: ioport range 0x1000-0x107f has been reserved
system 00:0b: ioport range 0x1080-0x10ff has been reserved
system 00:0b: ioport range 0x1400-0x147f has been reserved
system 00:0b: ioport range 0x1480-0x14ff has been reserved
system 00:0b: ioport range 0x1800-0x187f has been reserved
system 00:0b: ioport range 0x1880-0x18ff has been reserved
pci 0000:00:08.0: PCI bridge, secondary bus 0000:01
pci 0000:00:08.0: IO window: disabled
pci 0000:00:08.0: MEM window: 0xfc100000-0xfc1fffff
pci 0000:00:08.0: PREFETCH window: disabled
pci 0000:00:0c.0: PCI bridge, secondary bus 0000:06
pci 0000:00:0c.0: IO window: 0x4000-0x4fff
pci 0000:00:0c.0: MEM window: 0xf8000000-0xfbffffff
pci 0000:00:0c.0: PREFETCH window: disabled
pci 0000:00:0d.0: PCI bridge, secondary bus 0000:04
pci 0000:00:0d.0: IO window: disabled
pci 0000:00:0d.0: MEM window: 0xfc000000-0xfc0fffff
pci 0000:00:0d.0: PREFETCH window: disabled
pci 0000:00:08.0: setting latency timer to 64
pci 0000:00:0c.0: setting latency timer to 64
pci 0000:00:0d.0: setting latency timer to 64
pci_bus 0000:00: resource 0 io: [0x00-0xcf7]
pci_bus 0000:00: resource 1 io: [0xd00-0xffff]
pci_bus 0000:00: resource 2 mem: [0x0a0000-0x0bffff]
pci_bus 0000:00: resource 3 mem: [0x0c0000-0x0c3fff]
pci_bus 0000:00: resource 4 mem: [0x0c4000-0x0c7fff]
pci_bus 0000:00: resource 5 mem: [0x0c8000-0x0cbfff]
pci_bus 0000:00: resource 6 mem: [0x0cc000-0x0cffff]
pci_bus 0000:00: resource 7 mem: [0x0d4000-0x0d7fff]
pci_bus 0000:00: resource 8 mem: [0x0d8000-0x0dbfff]
pci_bus 0000:00: resource 9 mem: [0x0dc000-0x0dffff]
pci_bus 0000:00: resource 10 mem: [0x0e0000-0x0e3fff]
pci_bus 0000:00: resource 11 mem: [0x0e4000-0x0e7fff]
pci_bus 0000:00: resource 12 mem: [0x0e8000-0x0ebfff]
pci_bus 0000:00: resource 13 mem: [0x0ec000-0x0effff]
pci_bus 0000:00: resource 14 mem: [0x0f0000-0x0fffff]
pci_bus 0000:00: resource 15 mem: [0xc0000000-0xfebfffff]
pci_bus 0000:01: resource 1 mem: [0xfc100000-0xfc1fffff]
pci_bus 0000:01: resource 3 io: [0x00-0xcf7]
pci_bus 0000:01: resource 4 io: [0xd00-0xffff]
pci_bus 0000:01: resource 5 mem: [0x0a0000-0x0bffff]
pci_bus 0000:01: resource 6 mem: [0x0c0000-0x0c3fff]
pci_bus 0000:01: resource 7 mem: [0x0c4000-0x0c7fff]
pci_bus 0000:01: resource 8 mem: [0x0c8000-0x0cbfff]
pci_bus 0000:01: resource 9 mem: [0x0cc000-0x0cffff]
pci_bus 0000:01: resource 10 mem: [0x0d4000-0x0d7fff]
pci_bus 0000:01: resource 11 mem: [0x0d8000-0x0dbfff]
pci_bus 0000:01: resource 12 mem: [0x0dc000-0x0dffff]
pci_bus 0000:01: resource 13 mem: [0x0e0000-0x0e3fff]
pci_bus 0000:01: resource 14 mem: [0x0e4000-0x0e7fff]
pci_bus 0000:01: resource 15 mem: [0x0e8000-0x0ebfff]
pci_bus 0000:01: resource 16 mem: [0x0ec000-0x0effff]
pci_bus 0000:01: resource 17 mem: [0x0f0000-0x0fffff]
pci_bus 0000:01: resource 18 mem: [0xc0000000-0xfebfffff]
pci_bus 0000:06: resource 0 io: [0x4000-0x4fff]
pci_bus 0000:06: resource 1 mem: [0xf8000000-0xfbffffff]
pci_bus 0000:04: resource 1 mem: [0xfc000000-0xfc0fffff]
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
TCP bind hash table entries: 65536 (order: 9, 3670016 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
NET: Registered protocol family 1
Unpacking initramfs...
Freeing initrd memory: 10969k freed
Simple Boot Flag at 0x36 set to 0x1
Scanning for low memory corruption every 60 seconds
audit: initializing netlink socket (disabled)
type=2000 audit(1245862627.848:1): initialized
msgmni has been set to 5847
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci 0000:00:00.0: Found enabled HT MSI Mapping
pci 0000:00:00.0: Found enabled HT MSI Mapping
pci 0000:00:00.0: Found enabled HT MSI Mapping
pci 0000:00:00.0: Found enabled HT MSI Mapping
pci 0000:00:00.0: Found enabled HT MSI Mapping
pci 0000:00:00.0: Found enabled HT MSI Mapping
pci 0000:00:12.0: Boot video device
pcieport-driver 0000:00:0c.0: irq 24 for MSI/MSI-X
pcieport-driver 0000:00:0c.0: setting latency timer to 64
pcieport-driver 0000:00:0d.0: irq 25 for MSI/MSI-X
pcieport-driver 0000:00:0d.0: setting latency timer to 64
vesafb: framebuffer at 0xd0000000, mapped to 0xffffc90001d80000, using
3072k, total 65536k
vesafb: mode is 1024x768x16, linelength=2048, pages=1
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
Platform driver 'serial8250' needs updating - please use dev_pm_ops
PNP: PS/2 Controller [PNP0303:KBD0,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
Platform driver 'i8042' needs updating - please use dev_pm_ops
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
Platform driver 'pcspkr' needs updating - please use dev_pm_ops
input: PC Speaker as /class/input/input0
rtc_cmos 00:07: RTC can wake from S4
rtc_cmos: dev (254:0)
rtc_cmos 00:07: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one year, y3k, 114 bytes nvram, hpet irqs
cpuidle: using governor ladder
cpuidle: using governor menu
registered taskstats version 1
rtc_cmos 00:07: setting system clock to 2009-06-24 16:57:08 UTC
(1245862628)
Freeing unused kernel memory: 540k freed
ACPI: processor limited to max C-state 1
processor ACPI_CPU:00: registered as cooling_device0
processor ACPI_CPU:01: registered as cooling_device1
input: AT Translated Set 2 keyboard as /class/input/input1
thermal LNXTHERM:01: registered as thermal_zone0
ACPI: Thermal Zone [TZS0] (75 C)
thermal LNXTHERM:02: registered as thermal_zone1
ACPI: Thermal Zone [TZS1] (76 C)
SCSI subsystem initialized
libata version 3.00 loaded.
ahci 0000:00:09.0: version 3.0
ACPI: PCI Interrupt Link [LSI0] enabled at IRQ 23
ahci 0000:00:09.0: PCI INT A -> Link[LSI0] -> GSI 23 (level, low) ->
IRQ 23
ahci 0000:00:09.0: irq 26 for MSI/MSI-X
ahci 0000:00:09.0: controller can do NCQ, turning on CAP_NCQ
ahci 0000:00:09.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl IDE
mode
ahci 0000:00:09.0: flags: 64bit ncq sntf led clo pmp pio
ahci 0000:00:09.0: setting latency timer to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
ata1: SATA max UDMA/133 abar m8192@0xfc484000 port 0xfc484100 irq 26
ata2: SATA max UDMA/133 abar m8192@0xfc484000 port 0xfc484180 irq 26
ata3: SATA max UDMA/133 abar m8192@0xfc484000 port 0xfc484200 irq 26
ata4: SATA max UDMA/133 abar m8192@0xfc484000 port 0xfc484280 irq 26
input: PS/2 Mouse as /class/input/input2
input: AlpsPS/2 ALPS GlidePoint as /class/input/input3
ata2: SATA link down (SStatus 0 SControl 300)
ata3: SATA link down (SStatus 0 SControl 300)
ata4: SATA link down (SStatus 0 SControl 300)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-8: TOSHIBA MK2546GSX, LB014C, max UDMA/100
ata1.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK2546GS LB01 PQ: 0
ANSI: 5
Uniform Multi-Platform E-IDE driver
amd74xx 0000:00:06.0: UDMA133 controller
amd74xx 0000:00:06.0: IDE controller (0x10de:0x0560 rev 0xa1)
amd74xx 0000:00:06.0: IDE port disabled
amd74xx 0000:00:06.0: BIOS didn't set cable bits correctly. Enabling
workaround.
amd74xx 0000:00:06.0: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x30c0-0x30c7
Probing IDE interface ide0...
hda: Optiarc DVD RW AD-7561A, ATAPI CD/DVD-ROM drive
hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
hda: MWDMA2 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 17
ehci_hcd 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 17 (level, low)
-> IRQ 17
ehci_hcd 0000:00:02.1: setting latency timer to 64
ehci_hcd 0000:00:02.1: EHCI Host Controller
ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.1: debug port 1
ehci_hcd 0000:00:02.1: cache line size of 64 is not supported
ehci_hcd 0000:00:02.1: irq 17, io mem 0xfc489000
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ACPI: PCI Interrupt Link [Z013] enabled at IRQ 16
ehci_hcd 0000:00:04.1: PCI INT B -> Link[Z013] -> GSI 16 (level, low)
-> IRQ 16
ehci_hcd 0000:00:04.1: setting latency timer to 64
ehci_hcd 0000:00:04.1: EHCI Host Controller
ehci_hcd 0000:00:04.1: new USB bus registered, assigned bus number 2
ehci_hcd 0000:00:04.1: debug port 1
ehci_hcd 0000:00:04.1: cache line size of 64 is not supported
ehci_hcd 0000:00:04.1: irq 16, io mem 0xfc489400
ehci_hcd 0000:00:04.1: USB 2.0 started, EHCI 1.00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 5 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 17
ohci_hcd 0000:00:02.0: PCI INT A -> Link[LUS0] -> GSI 17 (level, low)
-> IRQ 17
ohci_hcd 0000:00:02.0: setting latency timer to 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:02.0: irq 17, io mem 0xfc486000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 5 ports detected
ACPI: PCI Interrupt Link [Z012] enabled at IRQ 16
ohci_hcd 0000:00:04.0: PCI INT A -> Link[Z012] -> GSI 16 (level, low)
-> IRQ 16
ohci_hcd 0000:00:04.0: setting latency timer to 64
ohci_hcd 0000:00:04.0: OHCI Host Controller
ohci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 4
ohci_hcd 0000:00:04.0: irq 16, io mem 0xfc487000
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 5 ports detected
udevd version 128 started
usb 1-4: new high speed USB device using ehci_hcd and address 2
usb 1-4: configuration #1 chosen from 1 choice
sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 > sda4
sd 0:0:0:0: [sda] Attached SCSI disk
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda8, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
udevd version 128 started
input: Power Button as /class/input/input4
ACPI: Power Button [PWRF]
input: Lid Switch as /class/input/input5
ACPI: Lid Switch [LID0]
input: Sleep Button as /class/input/input6
ACPI: Sleep Button [SLPB]
input: Power Button as /class/input/input7
ACPI: Power Button [PWRB]
sd 0:0:0:0: Attached scsi generic sg0 type 0
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 22
forcedeth 0000:00:0a.0: PCI INT A -> Link[LMAC] -> GSI 22 (level, low)
-> IRQ 22
forcedeth 0000:00:0a.0: setting latency timer to 64
forcedeth 0000:00:0a.0: ifname eth0, PHY OUI 0x5043 @ 1, addr
00:1d:72:4c:a5:52
forcedeth 0000:00:0a.0: highdma pwrctl mgmt lnktim msi desc-v3
i2c-adapter i2c-0: nForce2 SMBus adapter at 0x3040
i2c-adapter i2c-1: nForce2 SMBus adapter at 0x3000
ACPI: PCI Interrupt Link [LK4E] enabled at IRQ 21
b43-pci-bridge 0000:04:00.0: PCI INT A -> Link[LK4E] -> GSI 21 (level,
low) -> IRQ 21
b43-pci-bridge 0000:04:00.0: setting latency timer to 64
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243)
ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243)
ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243)
ssb: SPROM revision 2 detected.
ssb: Sonics Silicon Backplane found on PCI device 0000:04:00.0
k8temp 0000:00:18.3: Temperature readouts might be wrong - check
erratum #141
ide-cd driver 5.00
ide-cd: hda: ATAPI 24X DVD-ROM DVD-R/RAM CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
ACPI: Battery Slot [BAT0] (battery present)
ACPI: AC Adapter [ADP1] (on-line)
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: US
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: US
ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 20
HDA Intel 0000:00:07.0: PCI INT A -> Link[LAZA] -> GSI 20 (level, low)
-> IRQ 20
HDA Intel 0000:00:07.0: setting latency timer to 64
cfg80211: Regulatory domain changed to country: US
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (600 mBi, 1700 mBm)
(5250000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(5490000 KHz - 5710000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
b43-phy0: Broadcom 4311 WLAN found (core revision 10)
b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
phy0: Selected rate control algorithm 'minstrel'
Broadcom 43xx driver loaded [ Features: PL, Firmware-ID: FW13 ]
udev: renamed network interface wlan0 to eth1
Adding 2104444k swap on /dev/sda5. Priority:-1 extents:1 across:2104444k
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised:
[email protected]
loop: module loaded
EXT4-fs (sda1): barriers enabled
kjournald2 starting: pid 2150, dev sda1:8, commit interval 5 seconds
EXT4-fs (sda1): internal journal on sda1:8
EXT4-fs (sda1): delayed allocation enabled
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs (sda1): mounted filesystem with ordered data mode
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda2, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
fuse init (API version 7.11)
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
powernow-k8: Found 1 AMD Turion(tm) 64 X2 TL-60 processors (2 cpu
cores) (version 2.20.00)
powernow-k8: 0 : fid 0xc (2000 MHz), vid 0x11
powernow-k8: 1 : fid 0xa (1800 MHz), vid 0x12
powernow-k8: 2 : fid 0x8 (1600 MHz), vid 0x13
powernow-k8: 3 : fid 0x0 (800 MHz), vid 0x1e
Clocksource tsc unstable (delta = -68224792 ns)
vboxdrv: Trying to deactivate the NMI watchdog permanently...
vboxdrv: Successfully done.
vboxdrv: Found 2 processor cores.
VBoxDrv: dbg - g_abExecMemory=ffffffffa039a480
vboxdrv: fAsync=1 offMin=0x10ec88 offMax=0x10ec88
vboxdrv: TSC mode is 'asynchronous', kernel timer mode is 'normal'.
vboxdrv: Successfully loaded version 2.2.4 (interface 0x000a0009).
VBoxNetFlt: dbg - g_abExecMemory=ffffffffa05381c0
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
forcedeth 0000:00:0a.0: irq 27 for MSI/MSI-X
eth0: no link during initialization.
b43 ssb0:0: firmware: requesting b43/ucode5.fw
b43 ssb0:0: firmware: requesting b43/pcm5.fw
b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
b43-phy0 debug: Chip initialized
b43-phy0 debug: 32-bit DMA initialized
Registered led device: b43-phy0::tx
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
b43-phy0: Radio turned on by software
NET: Registered protocol family 17
eth1: authenticate with AP 00:1a:70:46:ba:b1
eth1: authenticated
eth1: associate with AP 00:1a:70:46:ba:b1
eth1: RX AssocResp from 00:1a:70:46:ba:b1 (capab=0x431 status=0 aid=1)
eth1: associated
b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
00:1a:70:46:ba:b1
b43-phy0 debug: Using hardware based encryption for keyidx: 2, mac:
ff:ff:ff:ff:ff:ff
On Wed, Jun 24, 2009 at 3:04 PM, Larry Finger<[email protected]> wrote:
> Yinghai Lu wrote:
> node 0 link 0: mmio [a0000, bffff]
> node 0 link 0: mmio [c0000000, dfffffff]
> node 0 link 0: mmio [e0000000, efffffff]
> node 0 link 0: mmio [f0000000, fe0bffff]
> bus: [00,ff] on node 0 link 0
> bus: 00 index 0 io port: [0, ffff]
> bus: 00 index 1 mmio: [a0000, bffff]
> bus: 00 index 2 mmio: [c0000000, fcffffffff]
that is read from pci config.
and only one HT chain is there. so there is no point to use _CRS for them.
please let me check if we could could have patch to deselect that.
YH
On Wed, Jun 24, 2009 at 02:24:24PM -0700, Gary Hade wrote:
> On Wed, Jun 24, 2009 at 03:05:12PM -0500, Larry Finger wrote:
> > Gary Hade wrote:
> > > On Wed, Jun 24, 2009 at 08:45:31PM +0200, Thomas Gleixner wrote:
> > >> Can we just bring the limit check back and increase the number for now
> > >> until folks come up with a better solution ?
> > >
> > > Another possible option is leaving in the limit check (still valid
> > > IMO for correct behavior of previous 'pci=use_crs') and reverting
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9e9f46c44e487af0a82eb61b624553e2f7118f5b
> > > until the better solution for the fixed size array issue is
> > > available.
> >
> > Either increasing PCI_BUS_NUM_RESOURCES from 16 to 20 or 24
>
> Yes, it looks to me like 20 might be the absolute minimum
> that your system could tolerate. The big mystery is how much
> to increase it so we don't see the same problem on other
> systems where _CRS may return some unknown amount more that
^^^^
than
> the 17 resources that are being returned on your system.
>
> > or reverting f9cde5f will work for my system.
>
> This would not be good without also reverting
> 9e9f46c44e487af0a82eb61b624553e2f7118f5b since devices
> below the transparent bridge on your's and other's systems
> may have trouble getting the resources they need.
>
> Removing the check would only hide possibly more insidious
> and difficult to debug problems that could show up later.
> This was the main reason I provided the patch. This kind
> of check should have actually existed prior to
> 9e9f46c44e487af0a82eb61b624553e2f7118f5b when 'pci=use_crs'
> was needed to enable use of the _CRS data.
One additional thing that is interesting about _CRS
returning 17 resources on your system is that even in
the absence of the transparent bridge constraint where
the last 3 slots of the resource array would be available,
there still isn't enough room in that 16 element array for
all 17 resources. Without the check that 17th resource
(apparently not needed for your current configuration)
would be silently ignored.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wed, Jun 24, 2009 at 3:11 PM, Yinghai Lu<[email protected]> wrote:
> On Wed, Jun 24, 2009 at 3:04 PM, Larry Finger<[email protected]> wrote:
>> Yinghai Lu wrote:
>> node 0 link 0: mmio [a0000, bffff]
>> node 0 link 0: mmio [c0000000, dfffffff]
>> node 0 link 0: mmio [e0000000, efffffff]
>> node 0 link 0: mmio [f0000000, fe0bffff]
>> bus: [00,ff] on node 0 link 0
>> bus: 00 index 0 io port: [0, ffff]
>> bus: 00 index 1 mmio: [a0000, bffff]
>> bus: 00 index 2 mmio: [c0000000, fcffffffff]
>
> that is read from pci config.
>
> and only one HT chain is there. so there is no point to use _CRS for them.
>
> please let me check if we could could have patch to deselect that.
>
please try the attached patches.
applying sequence:
fix_crs.patch
use_pci_crs_early.patch
only_one.patch
YH
Yinghai Lu wrote:
> On Wed, Jun 24, 2009 at 3:11 PM, Yinghai Lu<[email protected]> wrote:
>> On Wed, Jun 24, 2009 at 3:04 PM, Larry Finger<[email protected]> wrote:
>>> Yinghai Lu wrote:
>>> node 0 link 0: mmio [a0000, bffff]
>>> node 0 link 0: mmio [c0000000, dfffffff]
>>> node 0 link 0: mmio [e0000000, efffffff]
>>> node 0 link 0: mmio [f0000000, fe0bffff]
>>> bus: [00,ff] on node 0 link 0
>>> bus: 00 index 0 io port: [0, ffff]
>>> bus: 00 index 1 mmio: [a0000, bffff]
>>> bus: 00 index 2 mmio: [c0000000, fcffffffff]
>> that is read from pci config.
>>
>> and only one HT chain is there. so there is no point to use _CRS for them.
>>
>> please let me check if we could could have patch to deselect that.
>>
>
> please try the attached patches.
>
> applying sequence:
> fix_crs.patch
> use_pci_crs_early.patch
>
> only_one.patch
>From what I read in Linus's mails, it may be a moot point; however, my
system boots with these 3, and only these 3, patches applied.
I didn't see any of the new printk's in the dmesg output.
Larry
On Wed, 24 Jun 2009, Larry Finger wrote:
>
> From what I read in Linus's mails, it may be a moot point; however, my
> system boots with these 3, and only these 3, patches applied.
Well, it's definitely not moot. We want "use_crs" to work, whether it's
the default or not. I just doubt it should be the default (necessarily
ever).
The resources listed in the _CRS table may well be useful to make
decisions on (minimally: "is this a root bridge", but possibly also
scanning decisions). But I seriously doubt it makes any sense to insert
the _CRS resources into the bus resource list.
It might, for example, make sense to add them to the resource tree (after
scanning), the same way we add the e820 resources to the resource tree.
But judging from your dmesg:
pci_bus 0000:00: resource 0 io: [0x00-0xcf7]
pci_bus 0000:00: resource 1 io: [0xd00-0xffff]
pci_bus 0000:00: resource 2 mem: [0x0a0000-0x0bffff]
pci_bus 0000:00: resource 3 mem: [0x0c0000-0x0c3fff]
pci_bus 0000:00: resource 4 mem: [0x0c4000-0x0c7fff]
pci_bus 0000:00: resource 5 mem: [0x0c8000-0x0cbfff]
pci_bus 0000:00: resource 6 mem: [0x0cc000-0x0cffff]
pci_bus 0000:00: resource 7 mem: [0x0d4000-0x0d7fff]
pci_bus 0000:00: resource 8 mem: [0x0d8000-0x0dbfff]
pci_bus 0000:00: resource 9 mem: [0x0dc000-0x0dffff]
pci_bus 0000:00: resource 10 mem: [0x0e0000-0x0e3fff]
pci_bus 0000:00: resource 11 mem: [0x0e4000-0x0e7fff]
pci_bus 0000:00: resource 12 mem: [0x0e8000-0x0ebfff]
pci_bus 0000:00: resource 13 mem: [0x0ec000-0x0effff]
pci_bus 0000:00: resource 14 mem: [0x0f0000-0x0fffff]
pci_bus 0000:00: resource 15 mem: [0xc0000000-0xfebfffff]
pci_bus 0000:01: resource 1 mem: [0xfc100000-0xfc1fffff]
pci_bus 0000:01: resource 3 io: [0x00-0xcf7]
pci_bus 0000:01: resource 4 io: [0xd00-0xffff]
pci_bus 0000:01: resource 5 mem: [0x0a0000-0x0bffff]
pci_bus 0000:01: resource 6 mem: [0x0c0000-0x0c3fff]
pci_bus 0000:01: resource 7 mem: [0x0c4000-0x0c7fff]
pci_bus 0000:01: resource 8 mem: [0x0c8000-0x0cbfff]
pci_bus 0000:01: resource 9 mem: [0x0cc000-0x0cffff]
pci_bus 0000:01: resource 10 mem: [0x0d4000-0x0d7fff]
pci_bus 0000:01: resource 11 mem: [0x0d8000-0x0dbfff]
pci_bus 0000:01: resource 12 mem: [0x0dc000-0x0dffff]
pci_bus 0000:01: resource 13 mem: [0x0e0000-0x0e3fff]
pci_bus 0000:01: resource 14 mem: [0x0e4000-0x0e7fff]
pci_bus 0000:01: resource 15 mem: [0x0e8000-0x0ebfff]
pci_bus 0000:01: resource 16 mem: [0x0ec000-0x0effff]
pci_bus 0000:01: resource 17 mem: [0x0f0000-0x0fffff]
pci_bus 0000:01: resource 18 mem: [0xc0000000-0xfebfffff]
none of those look in any way like sensible "resources" to be put in the
device. Quite frankly, they look like total garbage to me.
Linus