* PCI resources above 4GB @ 2012-04-09 10:49 Steven Newbury 2012-04-10 0:51 ` Bjorn Helgaas 0 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-09 10:49 UTC (permalink / raw) To: bhelgaas; +Cc: linux-pci [-- Attachment #1: Type: text/plain, Size: 775 bytes --] Hi Bjorn, like many users here: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/342926 I've hit this bug: https://bugzilla.kernel.org/show_bug.cgi?id=10461 I was wondering whether an option to enable an algorithm which allocated all 64bit capable devices above 4GB would at least allow systems where the BIOS has not provided a sufficient PCI hole to initialise all PCI devices? I've been digging into the code, but I'm not yet comfortable to seriously attempt this myself, certainly not without guidance. It's a shame TJ seems to have disappeared, it would have been great to have had a look at his code, I'm sure many of these problems would have been resolved. Any help, workarounds, guidance or patches welcome! :) [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-09 10:49 PCI resources above 4GB Steven Newbury @ 2012-04-10 0:51 ` Bjorn Helgaas 2012-04-10 10:53 ` Steven Newbury 0 siblings, 1 reply; 94+ messages in thread From: Bjorn Helgaas @ 2012-04-10 0:51 UTC (permalink / raw) To: Steven Newbury; +Cc: linux-pci On Mon, Apr 9, 2012 at 4:49 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > Hi Bjorn, > > like many users here: > > https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/342926 > > I've hit this bug: > https://bugzilla.kernel.org/show_bug.cgi?id=10461 > > I was wondering whether an option to enable an algorithm which > allocated all 64bit capable devices above 4GB would at least allow > systems where the BIOS has not provided a sufficient PCI hole to > initialise all PCI devices? I've been digging into the code, but I'm > not yet comfortable to seriously attempt this myself, certainly not > without guidance. > > It's a shame TJ seems to have disappeared, it would have been great to > have had a look at his code, I'm sure many of these problems would have > been resolved. > > Any help, workarounds, guidance or patches welcome! :) Please attach complete dmesg logs with and without "pci=use_crs" to the bugzilla. Bjorn ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 0:51 ` Bjorn Helgaas @ 2012-04-10 10:53 ` Steven Newbury 2012-04-10 15:16 ` Yinghai Lu 0 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-10 10:53 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci On 10/04/12 01:51, Bjorn Helgaas wrote: > On Mon, Apr 9, 2012 at 4:49 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >> Hi Bjorn, >> >> like many users here: >> >> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/342926 >> >> I've hit this bug: >> https://bugzilla.kernel.org/show_bug.cgi?id=10461 >> >> I was wondering whether an option to enable an algorithm which >> allocated all 64bit capable devices above 4GB would at least allow >> systems where the BIOS has not provided a sufficient PCI hole to >> initialise all PCI devices? I've been digging into the code, but I'm >> not yet comfortable to seriously attempt this myself, certainly not >> without guidance. >> >> It's a shame TJ seems to have disappeared, it would have been great to >> have had a look at his code, I'm sure many of these problems would have >> been resolved. >> >> Any help, workarounds, guidance or patches welcome! :) > Please attach complete dmesg logs with and without "pci=use_crs" to > the bugzilla. > > dmesg logs attached to bug, for both pci=use_crs and pci=nocrs. In both cases assignment fails. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 10:53 ` Steven Newbury @ 2012-04-10 15:16 ` Yinghai Lu [not found] ` <4F8467AA.90305@snewbury.org.uk> 0 siblings, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-04-10 15:16 UTC (permalink / raw) To: Steven Newbury; +Cc: Bjorn Helgaas, linux-pci [-- Attachment #1: Type: text/plain, Size: 1426 bytes --] On Tue, Apr 10, 2012 at 3:53 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > On 10/04/12 01:51, Bjorn Helgaas wrote: >> On Mon, Apr 9, 2012 at 4:49 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >>> Hi Bjorn, >>> >>> like many users here: >>> >>> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/342926 >>> >>> I've hit this bug: >>> https://bugzilla.kernel.org/show_bug.cgi?id=10461 >>> >>> I was wondering whether an option to enable an algorithm which >>> allocated all 64bit capable devices above 4GB would at least allow >>> systems where the BIOS has not provided a sufficient PCI hole to >>> initialise all PCI devices? I've been digging into the code, but I'm >>> not yet comfortable to seriously attempt this myself, certainly not >>> without guidance. >>> >>> It's a shame TJ seems to have disappeared, it would have been great to >>> have had a look at his code, I'm sure many of these problems would have >>> been resolved. >>> >>> Any help, workarounds, guidance or patches welcome! :) >> Please attach complete dmesg logs with and without "pci=use_crs" to >> the bugzilla. >> >> > dmesg logs attached to bug, for both pci=use_crs and pci=nocrs. In both > cases assignment fails. Can you please try attached patches with pci=nocrs? for pci=use_crs, we need find safe place beyond _CRS, because your _CRS limit under 4g. Thanks Yinghai [-- Attachment #2: pref_mem_64_only.patch --] [-- Type: application/octet-stream, Size: 4537 bytes --] Subject: [PATCH] PCI: Try best to allocate pref mem 64 above 4g. If the bridge support pref mem 64, will only allocate that with pref mem64. for children resources if they only support pref mem 32, will allocate them from non pref mem instead. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/setup-bus.c | 41 +++++++++++++++++++++++++++++------------ drivers/pci/setup-res.c | 14 +++++++++++++- 2 files changed, 42 insertions(+), 13 deletions(-) Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -640,7 +640,7 @@ static struct resource *find_free_bus_re int i; struct resource *r; unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM | - IORESOURCE_PREFETCH; + IORESOURCE_PREFETCH | IORESOURCE_MEM_64; pci_bus_for_each_resource(bus, r, i) { if (r == &ioport_resource || r == &iomem_resource) @@ -772,9 +772,9 @@ static void pbus_size_io(struct pci_bus * guarantees that all child resources fit in this size. */ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, - unsigned long type, resource_size_t min_size, - resource_size_t add_size, - struct list_head *realloc_head) + unsigned long type, unsigned long type2, + resource_size_t min_size, resource_size_t add_size, + struct list_head *realloc_head) { struct pci_dev *dev; resource_size_t min_align, align, size, size0, size1; @@ -801,7 +801,8 @@ static int pbus_size_mem(struct pci_bus for_each_pci_dev_all_resource(dev, r, i) { resource_size_t r_size; - if (r->parent || (r->flags & mask) != type) + if (r->parent || ((r->flags & mask) != type && + (r->flags & mask) != type2)) continue; r_size = resource_size(r); #ifdef CONFIG_PCI_IOV @@ -984,8 +985,9 @@ static void __ref __pci_bus_size_bridges struct list_head *realloc_head, bool with_self) { struct pci_dev *dev; - unsigned long mask, prefmask; + unsigned long mask, prefmask, type2 = 0; resource_size_t additional_mem_size = 0, additional_io_size = 0; + struct resource *b_res; list_for_each_entry(dev, &bus->devices, bus_list) { struct pci_bus *b = dev->subordinate; @@ -1030,15 +1032,30 @@ static void __ref __pci_bus_size_bridges has already been allocated by arch code, try non-prefetchable range for both types of PCI memory resources. */ + b_res = &bus->self->resource[PCI_BRIDGE_RESOURCES]; mask = IORESOURCE_MEM; prefmask = IORESOURCE_MEM | IORESOURCE_PREFETCH; - if (pbus_size_mem(bus, prefmask, prefmask, + if (b_res[2].flags & IORESOURCE_MEM_64) { + prefmask |= IORESOURCE_MEM_64; + if (pbus_size_mem(bus, prefmask, prefmask, prefmask, realloc_head ? 0 : additional_mem_size, - additional_mem_size, realloc_head)) - mask = prefmask; /* Success, size non-prefetch only. */ - else - additional_mem_size += additional_mem_size; - pbus_size_mem(bus, mask, IORESOURCE_MEM, + additional_mem_size, realloc_head)) { + /* Success, size non-prefetch only. */ + mask = prefmask; + type2 = prefmask & ~IORESOURCE_MEM_64; + } + } + if (!type2) { + prefmask &= ~IORESOURCE_MEM_64; + if (pbus_size_mem(bus, prefmask, prefmask, prefmask, + realloc_head ? 0 : additional_mem_size, + additional_mem_size, realloc_head)) + mask = prefmask; /* Success, size non-prefetch only. */ + else + additional_mem_size += additional_mem_size; + type2 = IORESOURCE_MEM; + } + pbus_size_mem(bus, mask, IORESOURCE_MEM, type2, realloc_head ? 0 : additional_mem_size, additional_mem_size, realloc_head); break; Index: linux-2.6/drivers/pci/setup-res.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-res.c +++ linux-2.6/drivers/pci/setup-res.c @@ -154,9 +154,21 @@ static int __pci_assign_resource(struct /* First, try exact prefetching match.. */ ret = pci_bus_alloc_resource(bus, res, size, align, min, - IORESOURCE_PREFETCH, + IORESOURCE_PREFETCH | IORESOURCE_MEM_64, pcibios_align_resource, dev); + if (ret < 0 && + (res->flags & (IORESOURCE_PREFETCH | IORESOURCE_MEM_64))) { + /* + * That failed. + * + * Try below 4g pref + */ + ret = pci_bus_alloc_resource(bus, res, size, align, min, + IORESOURCE_PREFETCH, + pcibios_align_resource, dev); + } + if (ret < 0 && (res->flags & IORESOURCE_PREFETCH)) { /* * That failed. [-- Attachment #3: allocate_high_at_first.patch --] [-- Type: application/octet-stream, Size: 1328 bytes --] Subject: [PATCH] PCI: Try to allocate mem64 above 4G at first and will fall back to below 4g if it can not find any above 4g. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/bus.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) Index: linux-2.6/drivers/pci/bus.c =================================================================== --- linux-2.6.orig/drivers/pci/bus.c +++ linux-2.6/drivers/pci/bus.c @@ -124,13 +124,17 @@ pci_bus_alloc_resource(struct pci_bus *b int i, ret = -ENOMEM; struct resource *r; resource_size_t max = -1; + resource_size_t bottom = PCIBIOS_MAX_MEM_32 + 1ULL; type_mask |= IORESOURCE_IO | IORESOURCE_MEM; /* don't allocate too high if the pref mem doesn't support 64bit*/ - if (!(res->flags & IORESOURCE_MEM_64)) + if (!(res->flags & IORESOURCE_MEM_64)) { max = PCIBIOS_MAX_MEM_32; + bottom = 0; + } +again: pci_bus_for_each_resource(bus, r, i) { if (!r) continue; @@ -147,12 +151,18 @@ pci_bus_alloc_resource(struct pci_bus *b /* Ok, try it out.. */ ret = allocate_resource(r, res, size, - r->start ? : min, + max(bottom, r->start ? : min), max, align, alignf, alignf_data); if (ret == 0) - break; + return 0; + } + + if (bottom != 0) { + bottom = 0; + goto again; } + return ret; } ^ permalink raw reply [flat|nested] 94+ messages in thread
[parent not found: <4F8467AA.90305@snewbury.org.uk>]
* Re: PCI resources above 4GB [not found] ` <4F8467AA.90305@snewbury.org.uk> @ 2012-04-10 17:29 ` Steven Newbury 2012-04-10 18:40 ` Yinghai Lu 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-10 17:29 UTC (permalink / raw) To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/12 18:02, Steven Newbury wrote: > ... > > So far it has changed behaviour: > > Many devices now assigned above 4g. Looking more carefully, several of the PCI bridges have "Prefetchable memory behind bridge" >4gb, but I don't see any "devices". -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+EbgEACgkQGcb56gMuC63gLQCgwUTHdDqPTugqeVC1cXWhCQJH IaEAoK+A1B035nC0GKi2Y55OtVEOYQXN =JoAF -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB [not found] ` <4F8467AA.90305@snewbury.org.uk> 2012-04-10 17:29 ` Steven Newbury @ 2012-04-10 18:40 ` Yinghai Lu 2012-04-10 18:44 ` Steven Newbury 2012-04-10 19:00 ` Steven Newbury 1 sibling, 2 replies; 94+ messages in thread From: Yinghai Lu @ 2012-04-10 18:40 UTC (permalink / raw) To: Steven Newbury; +Cc: Bjorn Helgaas, linux-pci On Tue, Apr 10, 2012 at 10:02 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > >> >> Can you please try attached patches with pci=nocrs? >> >> for pci=use_crs, we need find safe place beyond _CRS, because your >> _CRS limit under 4g. >> .. > So far it has changed behaviour: > > Many devices now assigned above 4g. > > When booted while docked i915 fails to initialise, along with radeon as > before. > > When undocked i915 initialises, but radeon still fails when hot-docked. > > I've attached output of 'lspci -vvv', 'cat /proc/iomem', and "dmesg.log" > for the docked case. > > Also, "dmesg-hotplug.out" for hot docking after boot. looks good, please only apply allocate_high_at_first.patch Yinghai ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 18:40 ` Yinghai Lu @ 2012-04-10 18:44 ` Steven Newbury 2012-04-10 19:00 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-10 18:44 UTC (permalink / raw) To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/12 19:40, Yinghai Lu wrote: > On Tue, Apr 10, 2012 at 10:02 AM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> >>> >>> Can you please try attached patches with pci=nocrs? >>> >>> for pci=use_crs, we need find safe place beyond _CRS, because >>> your _CRS limit under 4g. >>> > .. >> So far it has changed behaviour: >> >> Many devices now assigned above 4g. >> >> When booted while docked i915 fails to initialise, along with >> radeon as before. >> >> When undocked i915 initialises, but radeon still fails when >> hot-docked. >> >> I've attached output of 'lspci -vvv', 'cat /proc/iomem', and >> "dmesg.log" for the docked case. >> >> Also, "dmesg-hotplug.out" for hot docking after boot. > > looks good, please only apply > > allocate_high_at_first.patch > > Yinghai Rebuilding... I will let you know in a few minutes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Ef5sACgkQGcb56gMuC62zLgCdFzqBa5sU88XIEG2BkSlJnIby qM8Ani2q1vYAWbx+SP5bYwt6/jQn72lc =cNKw -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 18:40 ` Yinghai Lu 2012-04-10 18:44 ` Steven Newbury @ 2012-04-10 19:00 ` Steven Newbury 2012-04-10 19:04 ` Steven Newbury 2012-04-10 19:16 ` Yinghai Lu 1 sibling, 2 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-10 19:00 UTC (permalink / raw) To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/12 19:40, Yinghai Lu wrote: > On Tue, Apr 10, 2012 at 10:02 AM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> >>> >>> Can you please try attached patches with pci=nocrs? >>> >>> for pci=use_crs, we need find safe place beyond _CRS, because >>> your _CRS limit under 4g. >>> > .. >> So far it has changed behaviour: >> >> Many devices now assigned above 4g. >> >> When booted while docked i915 fails to initialise, along with >> radeon as before. >> >> When undocked i915 initialises, but radeon still fails when >> hot-docked. >> >> I've attached output of 'lspci -vvv', 'cat /proc/iomem', and >> "dmesg.log" for the docked case. >> >> Also, "dmesg-hotplug.out" for hot docking after boot. > > looks good, please only apply > > allocate_high_at_first.patch > > Yinghai Seems to be exactly the same. When started docked (so I think both 'cards' try to claim the same preferred addresses) the integrated i965 GFX gets reassigned high: 120000000-12fffffff : 0000:00:02.0 But it's quite possible the i915 module doesn't currently handle this case and so fails to initialise. I'm not sure why the Radeon doesn't get assigned a high address when hot-plugged..? These are the only entries in /proc/iomem above 4GB: Booted UNDOCKED, then hot-docked 100000000-11fffffff : System RAM 120000000-1201fffff : PCI Bus 0000:0b 120200000-1203fffff : PCI Bus 0000:0c 120400000-1205fffff : PCI Bus 0000:09 Booted DOCKED 100000000-11fffffff : System RAM 120000000-12fffffff : 0000:00:02.0 130000000-1301fffff : PCI Bus 0000:0b 130200000-1303fffff : PCI Bus 0000:0c 130400000-1305fffff : PCI Bus 0000:0d 130600000-1307fffff : PCI Bus 0000:09 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Eg1cACgkQGcb56gMuC61hTgCeLIPkAEr1btlgzwmmGAqbnPZq /CEAn16oEFbgvWH0ifOL0FFiQTodBf1U =JBs3 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 19:00 ` Steven Newbury @ 2012-04-10 19:04 ` Steven Newbury 2012-04-10 19:16 ` Yinghai Lu 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-10 19:04 UTC (permalink / raw) To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/12 20:00, Steven Newbury wrote: > On 10/04/12 19:40, Yinghai Lu wrote: >> On Tue, Apr 10, 2012 at 10:02 AM, Steven Newbury >> <steve@snewbury.org.uk> wrote: >>> >>>> >>>> Can you please try attached patches with pci=nocrs? >>>> >>>> for pci=use_crs, we need find safe place beyond _CRS, >>>> because your _CRS limit under 4g. >>>> >> .. >>> So far it has changed behaviour: >>> >>> Many devices now assigned above 4g. >>> >>> When booted while docked i915 fails to initialise, along with >>> radeon as before. >>> >>> When undocked i915 initialises, but radeon still fails when >>> hot-docked. >>> >>> I've attached output of 'lspci -vvv', 'cat /proc/iomem', and >>> "dmesg.log" for the docked case. >>> >>> Also, "dmesg-hotplug.out" for hot docking after boot. > >> looks good, please only apply > >> allocate_high_at_first.patch > >> Yinghai > > Seems to be exactly the same. When started docked (so I think > both 'cards' try to claim the same preferred addresses) the > integrated i965 GFX gets reassigned high: 120000000-12fffffff : > 0000:00:02.0 > > But it's quite possible the i915 module doesn't currently handle > this case and so fails to initialise. > > I'm not sure why the Radeon doesn't get assigned a high address > when hot-plugged..? > > These are the only entries in /proc/iomem above 4GB: > > > Booted UNDOCKED, then hot-docked > > 100000000-11fffffff : System RAM 120000000-1201fffff : PCI Bus > 0000:0b 120200000-1203fffff : PCI Bus 0000:0c 120400000-1205fffff : > PCI Bus 0000:09 > > > Booted DOCKED > > 100000000-11fffffff : System RAM 120000000-12fffffff : > 0000:00:02.0 130000000-1301fffff : PCI Bus 0000:0b > 130200000-1303fffff : PCI Bus 0000:0c 130400000-1305fffff : PCI Bus > 0000:0d 130600000-1307fffff : PCI Bus 0000:09 Output of lspci -vt: - -[0000:00]-+-00.0 Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub +-02.0 Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) +-02.1 Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) +-1a.0 Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 +-1a.1 Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 +-1a.7 Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 +-1b.0 Intel Corporation 82801H (ICH8 Family) HD Audio Controller +-1c.0-[0b]-- +-1c.1-[0c]----00.0 Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection +-1c.3-[0d-0e]-- +-1c.5-[09]----00.0 Broadcom Corporation NetXtreme BCM5755M Gigabit Ethernet PCI Express +-1d.0 Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 +-1d.1 Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 +-1d.2 Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 +-1d.7 Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 +-1e.0-[03-08]--+-01.0 O2 Micro, Inc. Cardbus bridge | +-01.4 O2 Micro, Inc. Firewire (IEEE 1394) | \-08.0-[08]--+-00.0 Advanced Micro Devices [AMD] nee ATI Manhattan [Mobility Radeon HD 5430 Series] | \-00.1 Advanced Micro Devices [AMD] nee ATI Cedar HDMI Audio [Radeon HD 5400/6300 Series] +-1f.0 Intel Corporation 82801HM (ICH8M) LPC Interface Controller +-1f.1 Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) IDE Controller +-1f.2 Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] \-1f.3 Intel Corporation 82801H (ICH8 Family) SMBus Controller -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+EhDMACgkQGcb56gMuC60VawCgj4akSUCVNoYWTZqYRGeIwN5y CjUAnjhy23WmuxMnlA40ZXuYAq6cEN3E =zGsf -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 19:00 ` Steven Newbury 2012-04-10 19:04 ` Steven Newbury @ 2012-04-10 19:16 ` Yinghai Lu 2012-04-10 19:46 ` Steven Newbury 1 sibling, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-04-10 19:16 UTC (permalink / raw) To: Steven Newbury; +Cc: Bjorn Helgaas, linux-pci On Tue, Apr 10, 2012 at 12:00 PM, Steven Newbury <steve@snewbury.org.uk> wrote: > Seems to be exactly the same. When started docked (so I think both > 'cards' try to claim the same preferred addresses) the integrated i965 > GFX gets reassigned high: > 120000000-12fffffff : 0000:00:02.0 > > But it's quite possible the i915 module doesn't currently handle this > case and so fails to initialise. > > I'm not sure why the Radeon doesn't get assigned a high address when > hot-plugged..? bus layout with randon: 00:1e.0 03:01.0 03:01.4 03:08.0 05:00.0 the bridge 03:08.0 from PLX does not support 64bit pref mem So even 05.00.0 Radeon support that 64 pref mem, have to allocate 32bit mem range to it. the suitable range for that is 0xe0000000-0xefffffff. that is not bigger enough, because need to preallocate 64M optional for 03:01.0 the cardbus. but that is optional. We should get 05:00.0 get assigned to 0xe00000000 and 03:01.0 without assignment. > > These are the only entries in /proc/iomem above 4GB: > > > Booted UNDOCKED, then hot-docked > > 100000000-11fffffff : System RAM > 120000000-1201fffff : PCI Bus 0000:0b > 120200000-1203fffff : PCI Bus 0000:0c > 120400000-1205fffff : PCI Bus 0000:09 > > > Booted DOCKED > > 100000000-11fffffff : System RAM > 120000000-12fffffff : 0000:00:02.0 > 130000000-1301fffff : PCI Bus 0000:0b > 130200000-1303fffff : PCI Bus 0000:0c > 130400000-1305fffff : PCI Bus 0000:0d > 130600000-1307fffff : PCI Bus 0000:09 whole dmesg wht pci debug enabled please. Thanks Yinghai ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 19:16 ` Yinghai Lu @ 2012-04-10 19:46 ` Steven Newbury 2012-04-10 20:07 ` Yinghai Lu 0 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-10 19:46 UTC (permalink / raw) To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci [-- Attachment #1: Type: text/plain, Size: 2089 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/12 20:16, Yinghai Lu wrote: > On Tue, Apr 10, 2012 at 12:00 PM, Steven Newbury > <steve@snewbury.org.uk> wrote: > >> Seems to be exactly the same. When started docked (so I think >> both 'cards' try to claim the same preferred addresses) the >> integrated i965 GFX gets reassigned high: 120000000-12fffffff : >> 0000:00:02.0 >> >> But it's quite possible the i915 module doesn't currently handle >> this case and so fails to initialise. >> >> I'm not sure why the Radeon doesn't get assigned a high address >> when hot-plugged..? > > bus layout with randon: 00:1e.0 03:01.0 03:01.4 03:08.0 05:00.0 > > the bridge 03:08.0 from PLX does not support 64bit pref mem So even > 05.00.0 Radeon support that 64 pref mem, have to allocate 32bit mem > range to it. > I was afraid that'd be the case. > the suitable range for that is 0xe0000000-0xefffffff. that is not > bigger enough, because need to preallocate 64M optional for 03:01.0 > the cardbus. but that is optional. Maybe this is a stupid question, but is there any way of enlarging the PCI hole? > > We should get 05:00.0 get assigned to 0xe00000000 and 03:01.0 > without assignment. > > >> >> These are the only entries in /proc/iomem above 4GB: >> >> >> Booted UNDOCKED, then hot-docked >> >> 100000000-11fffffff : System RAM 120000000-1201fffff : PCI Bus >> 0000:0b 120200000-1203fffff : PCI Bus 0000:0c 120400000-1205fffff >> : PCI Bus 0000:09 >> >> >> Booted DOCKED >> >> 100000000-11fffffff : System RAM 120000000-12fffffff : >> 0000:00:02.0 130000000-1301fffff : PCI Bus 0000:0b >> 130200000-1303fffff : PCI Bus 0000:0c 130400000-1305fffff : PCI >> Bus 0000:0d 130600000-1307fffff : PCI Bus 0000:09 > > whole dmesg wht pci debug enabled please. CONFIG_PCI_DEBUG=y full DOCKED dmesg attached -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+EjhAACgkQGcb56gMuC61svgCdGWjxL5mbf4Hj9YeJMtj/H5Dz 3SsAnRaCvWeNoO9tIJogIIsmMBfuV849 =6fU6 -----END PGP SIGNATURE----- [-- Attachment #2: dmesg.docked --] [-- Type: text/plain, Size: 85787 bytes --] Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.4.0-rc2-wl-00219-g61fa1b5 (root@infinity) (gcc version 4.6.2 (Gentoo 4.6.2 p1.4, pie-0.5.0) ) #87 SMP Tue Apr 10 19:44:31 BST 2012 Command line: BOOT_IMAGE=/vmlinuz-3.4.0-rc2-wl-00219-g61fa1b5 root=UUID=d761a2db-f951-4e9c-bed4-cf2381bb1af4 ro rootflags=subvol=ROOT real_init=/bin/systemd real_root=LABEL=GENTOO real_rootflags=subvol=ROOT,compress=lzo,inode_cache,space_cache,ssd pcie_aspm=force i915.modeset=1 i915.lvds_downclock=1 i915.lvds_use_ssc=1 i915.powersave=1 i915.i915_enable_fbc=1 i915.i915_enable_rc6=1 ioapicreroute pci=realloc resume=UUID=ae0f88ec-9e17-41f2-b8b3-685cce36e496 pci=nocrs BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f000 (usable) BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) BIOS-e820: 0000000000100000 - 00000000df65a800 (usable) BIOS-e820: 00000000df65a800 - 00000000e0000000 (reserved) BIOS-e820: 00000000f8000000 - 00000000fc000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fed18000 - 00000000fed1c000 (reserved) BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved) BIOS-e820: 00000000feda0000 - 00000000feda6000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved) BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000120000000 (usable) NX (Execute Disable) protection: active DMI 2.4 present. DMI: Dell Inc. Latitude D830 /0HN341, BIOS A16 12/22/2011 e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) e820 remove range: 00000000000a0000 - 0000000000100000 (usable) No AGP bridge found last_pfn = 0x120000 max_arch_pfn = 0x400000000 MTRR default type: uncachable MTRR fixed ranges enabled: 00000-9FFFF write-back A0000-BFFFF uncachable C0000-CFFFF write-protect D0000-EFFFF uncachable F0000-FFFFF write-protect MTRR variable ranges enabled: 0 base 000000000 mask F80000000 write-back 1 base 080000000 mask FC0000000 write-back 2 base 0C0000000 mask FE0000000 write-back 3 base 100000000 mask FE0000000 write-back 4 base 0DF800000 mask FFF800000 uncachable 5 base 0DF700000 mask FFFF00000 uncachable 6 disabled 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 original variable MTRRs reg 0, base: 0GB, range: 2GB, type WB reg 1, base: 2GB, range: 1GB, type WB reg 2, base: 3GB, range: 512MB, type WB reg 3, base: 4GB, range: 512MB, type WB reg 4, base: 3576MB, range: 8MB, type UC reg 5, base: 3575MB, range: 1MB, type UC total RAM covered: 4087M Found optimal setting for mtrr clean up gran_size: 64K chunk_size: 1G num_reg: 5 lose cover RAM: 0G New variable MTRRs reg 0, base: 0GB, range: 4GB, type WB reg 1, base: 3575MB, range: 1MB, type UC reg 2, base: 3576MB, range: 8MB, type UC reg 3, base: 3584MB, range: 512MB, type UC reg 4, base: 4GB, range: 512MB, type WB e820 update range: 00000000df700000 - 0000000100000000 (usable) ==> (reserved) last_pfn = 0xdf65a max_arch_pfn = 0x400000000 initial memory mapped : 0 - 20000000 Base memory trampoline at [ffff88000009a000] 9a000 size 20480 init_memory_mapping: 0000000000000000-00000000df65a000 0000000000 - 00df600000 page 2M 00df600000 - 00df65a000 page 4k kernel direct mapping tables up to df65a000 @ 1fffa000-20000000 init_memory_mapping: 0000000100000000-0000000120000000 0100000000 - 0120000000 page 2M kernel direct mapping tables up to 120000000 @ df654000-df65a000 RAMDISK: 374c2000 - 37a59000 ACPI: RSDP 00000000000fbb10 00024 (v02 DELL ) ACPI: XSDT 00000000df65d200 0006C (v01 DELL M08 27DB0C16 ASL 00000061) ACPI: FACP 00000000df65d09c 000F4 (v04 DELL M08 27DB0C16 ASL 00000061) ACPI: DSDT 00000000df65d800 063B2 (v02 INT430 SYSFexxx 00001001 INTL 20050624) ACPI: FACS 00000000df66c000 00040 ACPI: HPET 00000000df65d300 00038 (v01 DELL M08 00000001 ASL 00000061) ACPI: APIC 00000000df65d400 00068 (v01 DELL M08 27DB0C16 ASL 00000047) ACPI: ASF! 00000000df65d000 0007E (v32 DELL M08 27DB0C16 ASL 00000061) ACPI: MCFG 00000000df65d3c0 0003E (v16 DELL M08 27DB0C16 ASL 00000061) ACPI: TCPA 00000000df65d700 00032 (v01 00000000 ASL 00000000) ACPI: SLIC 00000000df65d49c 00176 (v01 DELL M08 27DB0C16 ASL 00000061) ACPI: BOOT 00000000df65cfc0 00028 (v01 DELL M08 27DB0C16 ASL 00000061) ACPI: SSDT 00000000df65b982 004CC (v01 PmRef CpuPm 00003000 INTL 20050624) ACPI: Local APIC address 0xfee00000 [ffffea0000000000-ffffea00047fffff] PMD -> [ffff88011b600000-ffff88011f5fffff] on node 0 Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x00120000 Movable zone start PFN for each node Early memory PFN ranges 0: 0x00000010 -> 0x0000009f 0: 0x00000100 -> 0x000df65a 0: 0x00100000 -> 0x00120000 On node 0 totalpages: 1045993 DMA zone: 64 pages used for memmap DMA zone: 5 pages reserved DMA zone: 3914 pages, LIFO batch:0 DMA32 zone: 16320 pages used for memmap DMA32 zone: 894618 pages, LIFO batch:31 Normal zone: 2048 pages used for memmap Normal zone: 129024 pages, LIFO batch:31 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 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) 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: 0x8086a201 base: 0xfed00000 SMP: Allowing 2 CPUs, 0 hotplug CPUs nr_irqs_gsi: 40 PM: Registered nosave memory: 000000000009f000 - 00000000000a0000 PM: Registered nosave memory: 00000000000a0000 - 0000000000100000 PM: Registered nosave memory: 00000000df65a000 - 00000000df65b000 PM: Registered nosave memory: 00000000df65b000 - 00000000e0000000 PM: Registered nosave memory: 00000000e0000000 - 00000000f8000000 PM: Registered nosave memory: 00000000f8000000 - 00000000fc000000 PM: Registered nosave memory: 00000000fc000000 - 00000000fec00000 PM: Registered nosave memory: 00000000fec00000 - 00000000fec10000 PM: Registered nosave memory: 00000000fec10000 - 00000000fed18000 PM: Registered nosave memory: 00000000fed18000 - 00000000fed1c000 PM: Registered nosave memory: 00000000fed1c000 - 00000000fed20000 PM: Registered nosave memory: 00000000fed20000 - 00000000fed90000 PM: Registered nosave memory: 00000000fed90000 - 00000000feda0000 PM: Registered nosave memory: 00000000feda0000 - 00000000feda6000 PM: Registered nosave memory: 00000000feda6000 - 00000000fee00000 PM: Registered nosave memory: 00000000fee00000 - 00000000fee10000 PM: Registered nosave memory: 00000000fee10000 - 00000000ffe00000 PM: Registered nosave memory: 00000000ffe00000 - 0000000100000000 Allocating PCI resources starting at e0000000 (gap: e0000000:18000000) setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88011fc00000 s76608 r8192 d21696 u1048576 pcpu-alloc: s76608 r8192 d21696 u1048576 alloc=1*2097152 pcpu-alloc: [0] 0 1 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1027556 Kernel command line: BOOT_IMAGE=/vmlinuz-3.4.0-rc2-wl-00219-g61fa1b5 root=UUID=d761a2db-f951-4e9c-bed4-cf2381bb1af4 ro rootflags=subvol=ROOT real_init=/bin/systemd real_root=LABEL=GENTOO real_rootflags=subvol=ROOT,compress=lzo,inode_cache,space_cache,ssd pcie_aspm=force i915.modeset=1 i915.lvds_downclock=1 i915.lvds_use_ssc=1 i915.powersave=1 i915.i915_enable_fbc=1 i915.i915_enable_rc6=1 ioapicreroute pci=realloc resume=UUID=ae0f88ec-9e17-41f2-b8b3-685cce36e496 pci=nocrs PCIe ASPM is forcibly enabled PID hash table entries: 4096 (order: 3, 32768 bytes) Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking aperture... No AGP bridge found Memory: 4031780k/4718592k available (3506k kernel code, 534620k absent, 152192k reserved, 3218k data, 612k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Hierarchical RCU implementation. RCU dyntick-idle grace-period acceleration is enabled. NR_IRQS:4352 nr_irqs:512 16 Extended CMOS year: 2000 Console: colour VGA+ 80x25 console [tty0] enabled allocated 16777216 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups hpet clockevent registered Fast TSC calibration using PIT Detected 2394.026 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 4788.05 BogoMIPS (lpj=2394026) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 256 Initializing cgroup subsys debug Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio Initializing cgroup subsys perf_event CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 6 MCE banks CPU0: Thermal monitoring enabled (TM2) using mwait in idle threads. ACPI: Core revision 20120320 ftrace: allocating 16999 entries in 67 pages ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 CPU0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz stepping 0b Performance Events: PEBS fmt0+, 4-deep LBR, Core2 events, Intel PMU driver. PEBS disabled due to CPU errata. ... version: 2 ... bit width: 40 ... generic registers: 2 ... value mask: 000000ffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 0000000700000003 Testing tracer nop: PASSED Booting Node 0, Processors #1 Ok. Brought up 2 CPUs ---------------- | NMI testsuite: -------------------- remote IPI: ok | local IPI: ok | -------------------- Good, all 2 testcases passed! | --------------------------------- Total of 2 processors activated (9576.10 BogoMIPS). devtmpfs: initialized atomic64 test passed for x86-64 platform with CX8 and with SSE dummy: NET: Registered protocol family 16 ACPI: bus type pci registered dca service started, version 1.12.1 PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820 PCI: Using configuration type 1 for base access dmi type 0xB1 record - unknown flag bio: create slab <bio-0> at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: EC: Look up EC in DSDT [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored ACPI: SSDT 00000000df66c080 00043 (v01 LMPWR DELLLOM 00001001 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 00043 (v01 LMPWR DELLLOM 00001001 INTL 20050624) ACPI: SSDT 00000000df65c4b8 002C8 (v01 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 002C8 (v01 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: SSDT 00000000df65be4e 005E5 (v01 PmRef Cpu0Cst 00003001 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 005E5 (v01 PmRef Cpu0Cst 00003001 INTL 20050624) ACPI: SSDT 00000000df65c780 000C4 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 000C4 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: SSDT 00000000df65c433 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: ACPI Dock Station Driver: 3 docks/bays found PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored) pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xe0000000-0xf7ffffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfc000000-0xfebfffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfec10000-0xfecfffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfed1c000-0xfed1ffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfed90000-0xfed9ffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfed40000-0xfed44fff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfeda7000-0xfedfffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfee10000-0xff9fffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xffc00000-0xffdfffff] (ignored) PCI: root bus 00: using default resources PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0000-0xffff] pci_bus 0000:00: root bus resource [mem 0x00000000-0xfffffffff] pci_bus 0000:00: busn_res: [bus 00-ff] for root bus pci_bus 0000:00: root bus resource [bus 00-ff] pci_bus 0000:00: scanning bus pass 0 pci 0000:00:00.0: [8086:2a00] type 00 class 0x060000 pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0xa pci 0000:00:02.0: [8086:2a02] type 00 class 0x030000 pci 0000:00:02.0: reg 10: [mem 0xf6e00000-0xf6efffff 64bit] pci 0000:00:02.0: reg 18: [mem 0xc0000000-0xcfffffff 64bit pref] pci 0000:00:02.0: reg 20: [io 0xeff8-0xefff] pci 0000:00:02.1: [8086:2a03] type 00 class 0x038000 pci 0000:00:02.1: reg 10: [mem 0xf6f00000-0xf6ffffff 64bit] pci 0000:00:1a.0: [8086:2834] type 00 class 0x0c0300 pci 0000:00:1a.0: reg 20: [io 0x6f20-0x6f3f] pci 0000:00:1a.1: [8086:2835] type 00 class 0x0c0300 pci 0000:00:1a.1: reg 20: [io 0x6f00-0x6f1f] pci 0000:00:1a.7: [8086:283a] type 00 class 0x0c0320 pci 0000:00:1a.7: reg 10: [mem 0xfed1c400-0xfed1c7ff] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold pci 0000:00:1a.7: PME# disabled pci 0000:00:1b.0: [8086:284b] type 00 class 0x040300 pci 0000:00:1b.0: reg 10: [mem 0xf6dfc000-0xf6dfffff 64bit] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold pci 0000:00:1b.0: PME# disabled pci 0000:00:1c.0: [8086:283f] type 01 class 0x060400 pci 0000:00:1c.0: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold pci 0000:00:1c.0: PME# disabled pci 0000:00:1c.1: [8086:2841] type 01 class 0x060400 pci 0000:00:1c.1: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold pci 0000:00:1c.1: PME# disabled pci 0000:00:1c.3: [8086:2845] type 01 class 0x060400 pci 0000:00:1c.3: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold pci 0000:00:1c.3: PME# disabled pci 0000:00:1c.5: [8086:2849] type 01 class 0x060400 pci 0000:00:1c.5: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold pci 0000:00:1c.5: PME# disabled pci 0000:00:1d.0: [8086:2830] type 00 class 0x0c0300 pci 0000:00:1d.0: reg 20: [io 0x6f80-0x6f9f] pci 0000:00:1d.1: [8086:2831] type 00 class 0x0c0300 pci 0000:00:1d.1: reg 20: [io 0x6f60-0x6f7f] pci 0000:00:1d.2: [8086:2832] type 00 class 0x0c0300 pci 0000:00:1d.2: reg 20: [io 0x6f40-0x6f5f] pci 0000:00:1d.7: [8086:2836] type 00 class 0x0c0320 pci 0000:00:1d.7: reg 10: [mem 0xfed1c000-0xfed1c3ff] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold pci 0000:00:1d.7: PME# disabled pci 0000:00:1e.0: [8086:2448] type 01 class 0x060401 pci 0000:00:1e.0: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1f.0: [8086:2815] type 00 class 0x060100 pci 0000:00:1f.0: calling ich_force_enable_hpet+0x0/0x16f pci 0000:00:1f.0: calling quirk_ich7_lpc+0x0/0x62 pci 0000:00:1f.0: quirk: [io 0x1000-0x107f] claimed by ICH6 ACPI/GPIO/TCO pci 0000:00:1f.0: quirk: [io 0x1080-0x10bf] claimed by ICH6 GPIO pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0900 (mask 007f) pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0c80 (mask 003f) pci 0000:00:1f.1: [8086:2850] type 00 class 0x01018a pci 0000:00:1f.1: reg 10: [io 0x01f0-0x01f7] pci 0000:00:1f.1: reg 14: [io 0x03f4-0x03f7] pci 0000:00:1f.1: reg 18: [io 0x0170-0x0177] pci 0000:00:1f.1: reg 1c: [io 0x0374-0x0377] pci 0000:00:1f.1: reg 20: [io 0x6fa0-0x6faf] pci 0000:00:1f.2: [8086:2829] type 00 class 0x010601 pci 0000:00:1f.2: reg 10: [io 0x6eb0-0x6eb7] pci 0000:00:1f.2: reg 14: [io 0x6eb8-0x6ebb] pci 0000:00:1f.2: reg 18: [io 0x6ec0-0x6ec7] pci 0000:00:1f.2: reg 1c: [io 0x6ec8-0x6ecb] pci 0000:00:1f.2: reg 20: [io 0x6ee0-0x6eff] pci 0000:00:1f.2: reg 24: [mem 0xf6dfb800-0xf6dfbfff] pci 0000:00:1f.2: PME# supported from D3hot pci 0000:00:1f.2: PME# disabled pci 0000:00:1f.3: [8086:283e] type 00 class 0x0c0500 pci 0000:00:1f.3: reg 10: [mem 0xf6dfb700-0xf6dfb7ff] pci 0000:00:1f.3: reg 20: [io 0x10c0-0x10df] pci_bus 0000:00: fixups for bus pass 0 pci 0000:00:1c.0: scanning [bus 0b-0b] behind bridge, pass 0 pci 0000:00:1c.0: check if busn 0b-0b is in busn_res: [bus 00-ff] pci_bus 0000:0b: busn_res: [bus 0b] is inserted under [bus 00-ff] pci_bus 0000:0b: scanning bus pass 0 pci_bus 0000:0b: fixups for bus pass 0 pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] pci_bus 0000:0b: bus scan returning with max=0b pass 0 pci 0000:00:1c.1: scanning [bus 0c-0c] behind bridge, pass 0 pci 0000:00:1c.1: check if busn 0c-0c is in busn_res: [bus 00-ff] pci_bus 0000:0c: busn_res: [bus 0c] is inserted under [bus 00-ff] pci_bus 0000:0c: scanning bus pass 0 pci 0000:0c:00.0: [8086:4229] type 00 class 0x028000 pci 0000:0c:00.0: reg 10: [mem 0xf6cfe000-0xf6cfffff 64bit] pci 0000:0c:00.0: PME# supported from D0 D3hot D3cold pci 0000:0c:00.0: PME# disabled pci_bus 0000:0c: fixups for bus pass 0 pci 0000:00:1c.1: PCI bridge to [bus 0c-0c] pci 0000:00:1c.1: bridge window [mem 0xf6c00000-0xf6cfffff] pci_bus 0000:0c: bus scan returning with max=0c pass 0 pci 0000:00:1c.3: scanning [bus 0d-0e] behind bridge, pass 0 pci 0000:00:1c.3: check if busn 0d-0e is in busn_res: [bus 00-ff] pci_bus 0000:0d: busn_res: [bus 0d-0e] is inserted under [bus 00-ff] pci_bus 0000:0d: scanning bus pass 0 pci_bus 0000:0d: fixups for bus pass 0 pci 0000:00:1c.3: PCI bridge to [bus 0d-0e] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] pci 0000:00:1c.3: bridge window [mem 0xf6a00000-0xf6bfffff] pci 0000:00:1c.3: bridge window [mem 0xd0000000-0xd01fffff 64bit pref] pci_bus 0000:0d: bus scan returning with max=0d pass 0 pci 0000:00:1c.5: scanning [bus 09-09] behind bridge, pass 0 pci 0000:00:1c.5: check if busn 09-09 is in busn_res: [bus 00-ff] pci_bus 0000:09: busn_res: [bus 09] is inserted under [bus 00-ff] pci_bus 0000:09: scanning bus pass 0 pci 0000:09:00.0: [14e4:1673] type 00 class 0x020000 pci 0000:09:00.0: reg 10: [mem 0xf69f0000-0xf69fffff 64bit] pci 0000:09:00.0: PME# supported from D3hot D3cold pci 0000:09:00.0: PME# disabled pci_bus 0000:09: fixups for bus pass 0 pci 0000:00:1c.5: PCI bridge to [bus 09-09] pci 0000:00:1c.5: bridge window [mem 0xf6900000-0xf69fffff] pci_bus 0000:09: bus scan returning with max=09 pass 0 pci 0000:00:1e.0: scanning [bus 03-05] behind bridge, pass 0 pci 0000:00:1e.0: check if busn 03-05 is in busn_res: [bus 00-ff] pci_bus 0000:03: busn_res: [bus 03-05] is inserted under [bus 00-ff] pci_bus 0000:03: scanning bus pass 0 pci 0000:03:01.0: [1217:7135] type 02 class 0x060700 pci 0000:03:01.0: reg 10: [mem 0x00000000-0x00000fff] pci 0000:03:01.0: supports D1 D2 pci 0000:03:01.0: PME# supported from D0 D1 D2 D3hot D3cold pci 0000:03:01.0: PME# disabled pci 0000:03:01.4: [1217:00f7] type 00 class 0x0c0010 pci 0000:03:01.4: reg 10: [mem 0xf68ff000-0xf68fffff] pci 0000:03:01.4: reg 14: [mem 0xf68fe800-0xf68fefff] pci 0000:03:01.4: supports D1 D2 pci 0000:03:01.4: PME# supported from D0 D1 D2 D3hot D3cold pci 0000:03:01.4: PME# disabled pci 0000:03:08.0: [10b5:8112] type 01 class 0x060400 pci 0000:03:08.0: supports D1 pci 0000:03:08.0: PME# supported from D0 D1 D3hot pci 0000:03:08.0: PME# disabled pci_bus 0000:03: fixups for bus pass 0 pci 0000:00:1e.0: PCI bridge to [bus 03-05] (subtractive decode) pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] pci 0000:00:1e.0: bridge window [mem 0xf6600000-0xf68fffff] pci 0000:00:1e.0: bridge window [mem 0xd0200000-0xefffffff 64bit pref] pci 0000:00:1e.0: bridge window [io 0x0000-0xffff] (subtractive decode) pci 0000:00:1e.0: bridge window [mem 0x00000000-0xfffffffff] (subtractive decode) pci 0000:03:01.0: scanning [bus 04-04] behind bridge, pass 0 pci 0000:03:01.0: check if busn 04-04 is in busn_res: [bus 03-05] pci 0000:03:08.0: scanning [bus 05-05] behind bridge, pass 0 pci 0000:03:08.0: check if busn 05-05 is in busn_res: [bus 03-05] pci_bus 0000:05: busn_res: [bus 05] is inserted under [bus 03-05] pci_bus 0000:05: scanning bus pass 0 pci 0000:05:00.0: [1002:68e1] type 00 class 0x030000 pci 0000:05:00.0: reg 10: [mem 0xe0000000-0xefffffff 64bit pref] pci 0000:05:00.0: reg 18: [mem 0xf66e0000-0xf66fffff 64bit] pci 0000:05:00.0: reg 20: [io 0xce00-0xceff] pci 0000:05:00.0: reg 30: [mem 0xf6700000-0xf671ffff pref] pci 0000:05:00.0: supports D1 D2 pci 0000:05:00.1: [1002:aa68] type 00 class 0x040300 pci 0000:05:00.1: reg 10: [mem 0xf66dc000-0xf66dffff 64bit] pci 0000:05:00.1: supports D1 D2 pci_bus 0000:05: fixups for bus pass 0 pci 0000:03:08.0: PCI bridge to [bus 05-05] pci 0000:03:08.0: bridge window [io 0xc000-0xcfff] pci 0000:03:08.0: bridge window [mem 0xf6600000-0xf67fffff] pci 0000:03:08.0: bridge window [mem 0xd0200000-0xefffffff pref] pci_bus 0000:05: bus scan returning with max=05 pass 0 pci_bus 0000:03: bus scan returning with max=05 pass 0 pci_bus 0000:00: bus scan returning with max=0e pass 0 pci_bus 0000:00: scanning bus pass 1 pci 0000:00:1c.0: scanning [bus 0b-0b] behind bridge, pass 1 pci_bus 0000:0b: scanning bus pass 1 pci_bus 0000:0b: fixups for bus pass 1 pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] pci_bus 0000:0b: bus scan returning with max=0b pass 1 pci 0000:00:1c.1: scanning [bus 0c-0c] behind bridge, pass 1 pci_bus 0000:0c: scanning bus pass 1 pci_bus 0000:0c: fixups for bus pass 1 pci 0000:00:1c.1: PCI bridge to [bus 0c-0c] pci 0000:00:1c.1: bridge window [mem 0xf6c00000-0xf6cfffff] pci_bus 0000:0c: bus scan returning with max=0c pass 1 pci 0000:00:1c.3: scanning [bus 0d-0e] behind bridge, pass 1 pci_bus 0000:0d: scanning bus pass 1 pci_bus 0000:0d: fixups for bus pass 1 pci 0000:00:1c.3: PCI bridge to [bus 0d-0e] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] pci 0000:00:1c.3: bridge window [mem 0xf6a00000-0xf6bfffff] pci 0000:00:1c.3: bridge window [mem 0xd0000000-0xd01fffff 64bit pref] pci_bus 0000:0d: bus scan returning with max=0d pass 1 pci 0000:00:1c.5: scanning [bus 09-09] behind bridge, pass 1 pci_bus 0000:09: scanning bus pass 1 pci_bus 0000:09: fixups for bus pass 1 pci 0000:00:1c.5: PCI bridge to [bus 09-09] pci 0000:00:1c.5: bridge window [mem 0xf6900000-0xf69fffff] pci_bus 0000:09: bus scan returning with max=09 pass 1 pci 0000:00:1e.0: scanning [bus 03-05] behind bridge, pass 1 pci_bus 0000:03: scanning bus pass 1 pci_bus 0000:03: fixups for bus pass 1 pci 0000:00:1e.0: PCI bridge to [bus 03-05] (subtractive decode) pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] pci 0000:00:1e.0: bridge window [mem 0xf6600000-0xf68fffff] pci 0000:00:1e.0: bridge window [mem 0xd0200000-0xefffffff 64bit pref] pci 0000:00:1e.0: bridge window [io 0x0000-0xffff] (subtractive decode) pci 0000:00:1e.0: bridge window [mem 0x00000000-0xfffffffff] (subtractive decode) pci 0000:03:01.0: scanning [bus 04-04] behind bridge, pass 1 pci 0000:03:01.0: find free busn in res: [bus 03-05] pci 0000:03:01.0: found free busn 0 in res: [bus 03-05] top pci 0000:03:01.0: find free busn in res: [bus 03-05] pci 0000:03:01.0: found free busn 0 in res: [bus 03-05] top pci_bus 0000:03: busn_res: extended 03 to [bus 03-08] pci_bus 0000:06: busn_res: [bus 06-08] is updated under [bus 03-08] pci_bus 0000:06: busn_res: [bus 06-08] end updated to [bus 06-08] pci 0000:03:08.0: scanning [bus 05-05] behind bridge, pass 1 pci_bus 0000:05: scanning bus pass 1 pci_bus 0000:05: fixups for bus pass 1 pci 0000:03:08.0: PCI bridge to [bus 05-05] pci 0000:03:08.0: bridge window [io 0xc000-0xcfff] pci 0000:03:08.0: bridge window [mem 0xf6600000-0xf67fffff] pci 0000:03:08.0: bridge window [mem 0xd0200000-0xefffffff pref] pci_bus 0000:05: bus scan returning with max=05 pass 1 pci_bus 0000:03: bus scan returning with max=08 pass 1 pci_bus 0000:00: bus scan returning with max=0e pass 1 pci_bus 0000:00: on NUMA node 0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP04._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP06._PRT] pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d ACPI _OSC control for PCIe not granted, disabling ASPM ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *3 ACPI: PCI Interrupt Link [LNKC] (IRQs 9 *10 11) ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: device added: PCI:0000:05:00.0,decodes=io+mem,owns=none,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:05:00.0 vgaarb: no bridge control possible 0000:00:02.0 PCI: Using ACPI for IRQ routing PCI: pci_cache_line_size set to 64 bytes pci 0000:00:1c.3: address space collision: [mem 0xd0000000-0xd01fffff 64bit pref] conflicts with System RAM [mem 0x00100000-0xdf65a7ff] pci 0000:00:1e.0: address space collision: [mem 0xd0200000-0xefffffff 64bit pref] conflicts with System RAM [mem 0x00100000-0xdf65a7ff] pci 0000:03:08.0: address space collision: [mem 0xd0200000-0xefffffff pref] conflicts with System RAM [mem 0x00100000-0xdf65a7ff] pci 0000:00:02.0: BAR 0: reserving [mem 0xf6e00000-0xf6efffff flags 0x140204] (d=0, p=0) pci 0000:00:02.0: BAR 2: reserving [mem 0xc0000000-0xcfffffff flags 0x14220c] (d=0, p=0) pci 0000:00:02.0: address space collision: [mem 0xc0000000-0xcfffffff 64bit pref] conflicts with System RAM [mem 0x00100000-0xdf65a7ff] pci 0000:00:02.0: BAR 4: reserving [io 0xeff8-0xefff flags 0x40101] (d=0, p=0) pci 0000:00:02.1: BAR 0: reserving [mem 0xf6f00000-0xf6ffffff flags 0x140204] (d=0, p=0) pci 0000:00:1a.0: BAR 4: reserving [io 0x6f20-0x6f3f flags 0x40101] (d=0, p=0) pci 0000:00:1a.1: BAR 4: reserving [io 0x6f00-0x6f1f flags 0x40101] (d=0, p=0) pci 0000:00:1a.7: BAR 0: reserving [mem 0xfed1c400-0xfed1c7ff flags 0x40200] (d=0, p=0) pci 0000:00:1b.0: BAR 0: reserving [mem 0xf6dfc000-0xf6dfffff flags 0x140204] (d=0, p=0) pci 0000:00:1d.0: BAR 4: reserving [io 0x6f80-0x6f9f flags 0x40101] (d=0, p=0) pci 0000:00:1d.1: BAR 4: reserving [io 0x6f60-0x6f7f flags 0x40101] (d=0, p=0) pci 0000:00:1d.2: BAR 4: reserving [io 0x6f40-0x6f5f flags 0x40101] (d=0, p=0) pci 0000:00:1d.7: BAR 0: reserving [mem 0xfed1c000-0xfed1c3ff flags 0x40200] (d=0, p=0) pci 0000:00:1f.1: BAR 0: reserving [io 0x01f0-0x01f7 flags 0x110] (d=0, p=0) pci 0000:00:1f.1: BAR 1: reserving [io 0x03f6 flags 0x110] (d=0, p=0) pci 0000:00:1f.1: BAR 2: reserving [io 0x0170-0x0177 flags 0x110] (d=0, p=0) pci 0000:00:1f.1: BAR 3: reserving [io 0x0376 flags 0x110] (d=0, p=0) pci 0000:00:1f.1: BAR 4: reserving [io 0x6fa0-0x6faf flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 0: reserving [io 0x6eb0-0x6eb7 flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 1: reserving [io 0x6eb8-0x6ebb flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 2: reserving [io 0x6ec0-0x6ec7 flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 3: reserving [io 0x6ec8-0x6ecb flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 4: reserving [io 0x6ee0-0x6eff flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 5: reserving [mem 0xf6dfb800-0xf6dfbfff flags 0x40200] (d=0, p=0) pci 0000:00:1f.3: BAR 0: reserving [mem 0xf6dfb700-0xf6dfb7ff flags 0x40200] (d=0, p=0) pci 0000:00:1f.3: BAR 4: reserving [io 0x10c0-0x10df flags 0x40101] (d=0, p=0) pci 0000:0c:00.0: BAR 0: reserving [mem 0xf6cfe000-0xf6cfffff flags 0x140204] (d=0, p=0) pci 0000:09:00.0: BAR 0: reserving [mem 0xf69f0000-0xf69fffff flags 0x140204] (d=0, p=0) pci 0000:03:01.4: BAR 0: reserving [mem 0xf68ff000-0xf68fffff flags 0x40200] (d=0, p=0) pci 0000:03:01.4: BAR 1: reserving [mem 0xf68fe800-0xf68fefff flags 0x40200] (d=0, p=0) pci 0000:05:00.1: BAR 0: reserving [mem 0xf66dc000-0xf66dffff flags 0x140204] (d=0, p=0) pci 0000:05:00.0: BAR 0: reserving [mem 0xe0000000-0xefffffff flags 0x14220c] (d=1, p=1) pci 0000:05:00.0: no compatible bridge window for [mem 0xe0000000-0xefffffff 64bit pref] pci 0000:05:00.0: BAR 2: reserving [mem 0xf66e0000-0xf66fffff flags 0x140204] (d=1, p=1) pci 0000:05:00.0: BAR 4: reserving [io 0xce00-0xceff flags 0x40101] (d=1, p=1) reserve RAM buffer: 000000000009f000 - 000000000009ffff reserve RAM buffer: 00000000df65a800 - 00000000dfffffff HPET: 3 timers in total, 0 timers will be used for per-cpu timer hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 hpet0: 3 comparators, 64-bit 14.318180 MHz counter Switching to clocksource hpet pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:00: [bus 00-ff] pnp 00:00: [io 0x0000-0x0cf7 window] pnp 00:00: [io 0x0cf8-0x0cff] pnp 00:00: [io 0x0d00-0xffff window] pnp 00:00: [mem 0x000a0000-0x000bffff window] pnp 00:00: [mem 0x000d0000-0x000dffff window] pnp 00:00: [mem 0xe0000000-0xf7ffffff window] pnp 00:00: [mem 0xfc000000-0xfebfffff window] pnp 00:00: [mem 0xfec10000-0xfecfffff window] pnp 00:00: [mem 0xfed1c000-0xfed1ffff window] pnp 00:00: [mem 0xfed90000-0xfed9ffff window] pnp 00:00: [mem 0xfed40000-0xfed44fff window] pnp 00:00: [mem 0xfeda7000-0xfedfffff window] pnp 00:00: [mem 0xfee10000-0xff9fffff window] pnp 00:00: [mem 0xffc00000-0xffdfffff window] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active) pnp 00:01: [irq 12] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active) pnp 00:02: [io 0x0060] pnp 00:02: [io 0x0064] pnp 00:02: [io 0x0062] pnp 00:02: [io 0x0066] pnp 00:02: [irq 1] pnp 00:02: Plug and Play ACPI device, IDs PNP0303 (active) pnp 00:03: [io 0x0070-0x0071] pnp 00:03: [irq 8] pnp 00:03: [io 0x0072-0x0077] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) pnp 00:04: [io 0x0061] pnp 00:04: [io 0x0063] pnp 00:04: [io 0x0065] pnp 00:04: [io 0x0067] pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active) pnp 00:05: [io 0x002e-0x002f] pnp 00:05: [io 0x0c80-0x0caf] pnp 00:05: [io 0x0cc0-0x0cff] pnp 00:05: [io 0x004e-0x004f] system 00:05: [io 0x0c80-0x0caf] has been reserved system 00:05: [io 0x0cc0-0x0cff] could not be reserved system 00:05: Plug and Play ACPI device, IDs PNP0c01 (active) pnp 00:06: [dma 4] pnp 00:06: [io 0x0000-0x000f] pnp 00:06: [io 0x0080-0x0085] pnp 00:06: [io 0x0087-0x008f] pnp 00:06: [io 0x00c0-0x00df] pnp 00:06: [io 0x0010-0x001f] pnp 00:06: [io 0x0090-0x0091] pnp 00:06: [io 0x0093-0x009f] pnp 00:06: Plug and Play ACPI device, IDs PNP0200 (active) pnp 00:07: [io 0x00f0-0x00ff] pnp 00:07: [irq 13] pnp 00:07: Plug and Play ACPI device, IDs PNP0c04 (active) pnp 00:08: [mem 0xfed00000-0xfed003ff] system 00:08: [mem 0xfed00000-0xfed003ff] has been reserved system 00:08: Plug and Play ACPI device, IDs PNP0103 PNP0c01 (active) pnp 00:09: [irq 4] pnp 00:09: [io 0x03f8-0x03ff] pnp 00:09: Plug and Play ACPI device, IDs PNP0501 (active) pnp 00:0a: [dma 1] pnp 00:0a: [irq 7] pnp 00:0a: [io 0x0378-0x037f] pnp 00:0a: [io 0x0778-0x077b] pnp 00:0a: Plug and Play ACPI device, IDs PNP0401 (active) pnp 00:0b: [mem 0xfed40000-0xfed44fff] pnp 00:0b: [io 0x0cb0-0x0cbb] system 00:0b: [io 0x0cb0-0x0cbb] has been reserved system 00:0b: [mem 0xfed40000-0xfed44fff] has been reserved system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active) pnp 00:0c: [io 0x0900-0x097f] pnp 00:0c: [io 0x0092] pnp 00:0c: [io 0x00b2-0x00b3] pnp 00:0c: [io 0x0020-0x0021] pnp 00:0c: [io 0x00a0-0x00a1] pnp 00:0c: [irq 0 disabled] pnp 00:0c: [io 0x04d0-0x04d1] pnp 00:0c: [io 0x1000-0x1005] pnp 00:0c: [io 0x1008-0x100f] pnp 00:0c: disabling [io 0x1000-0x1005] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0c: disabling [io 0x1008-0x100f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] system 00:0c: [io 0x0900-0x097f] has been reserved system 00:0c: [io 0x04d0-0x04d1] has been reserved system 00:0c: Plug and Play ACPI device, IDs PNP0c01 (active) pnp 00:0d: [io 0xf400-0xf4fe] pnp 00:0d: [io 0x0086] pnp 00:0d: [io 0x1006-0x1007] pnp 00:0d: [io 0x100a-0x1059] pnp 00:0d: [io 0x1060-0x107f] pnp 00:0d: [io 0x1080-0x10bf] pnp 00:0d: [io 0x10c0-0x10df] pnp 00:0d: [io 0x1010-0x102f] pnp 00:0d: [io 0x0809] pnp 00:0d: disabling [io 0x1006-0x1007] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0d: disabling [io 0x100a-0x1059] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0d: disabling [io 0x1060-0x107f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0d: disabling [io 0x1010-0x102f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] system 00:0d: [io 0xf400-0xf4fe] has been reserved system 00:0d: [io 0x1080-0x10bf] has been reserved system 00:0d: [io 0x10c0-0x10df] has been reserved system 00:0d: [io 0x0809] has been reserved system 00:0d: Plug and Play ACPI device, IDs PNP0c01 (active) pnp 00:0e: [mem 0x00000000-0x0009efff] pnp 00:0e: [mem 0x0009f000-0x0009ffff] pnp 00:0e: [mem 0x000c0000-0x000cffff] pnp 00:0e: [mem 0x000e0000-0x000fffff] pnp 00:0e: [mem 0x00100000-0xdf65a7ff] pnp 00:0e: [mem 0xdf65a800-0xdf6fffff] pnp 00:0e: [mem 0xdf700000-0xdf7fffff] pnp 00:0e: [mem 0xdf700000-0xdfefffff] pnp 00:0e: [mem 0xffe00000-0xffffffff] pnp 00:0e: [mem 0xffa00000-0xffbfffff] pnp 00:0e: [mem 0xfec00000-0xfec0ffff] pnp 00:0e: [mem 0xfee00000-0xfee0ffff] pnp 00:0e: [mem 0xfed20000-0xfed3ffff] pnp 00:0e: [mem 0xfed45000-0xfed8ffff] pnp 00:0e: [mem 0xfeda0000-0xfeda3fff] pnp 00:0e: [mem 0xfeda4000-0xfeda4fff] pnp 00:0e: [mem 0xfeda5000-0xfeda5fff] pnp 00:0e: [mem 0xfeda6000-0xfeda6fff] pnp 00:0e: [mem 0xfed18000-0xfed1bfff] pnp 00:0e: [mem 0xf8000000-0xfbffffff] pnp 00:0e: disabling [mem 0x00000000-0x0009efff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x0009f000-0x0009ffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x000c0000-0x000cffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x000e0000-0x000fffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x00100000-0xdf65a7ff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x00000000-0x0009efff disabled] because it overlaps 0000:05:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x0009f000-0x0009ffff disabled] because it overlaps 0000:05:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x000c0000-0x000cffff disabled] because it overlaps 0000:05:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x000e0000-0x000fffff disabled] because it overlaps 0000:05:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x00100000-0xdf65a7ff disabled] because it overlaps 0000:05:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] system 00:0e: [mem 0xdf65a800-0xdf6fffff] has been reserved system 00:0e: [mem 0xdf700000-0xdf7fffff] has been reserved system 00:0e: [mem 0xdf700000-0xdfefffff] could not be reserved system 00:0e: [mem 0xffe00000-0xffffffff] has been reserved system 00:0e: [mem 0xffa00000-0xffbfffff] has been reserved system 00:0e: [mem 0xfec00000-0xfec0ffff] could not be reserved system 00:0e: [mem 0xfee00000-0xfee0ffff] has been reserved system 00:0e: [mem 0xfed20000-0xfed3ffff] has been reserved system 00:0e: [mem 0xfed45000-0xfed8ffff] has been reserved system 00:0e: [mem 0xfeda0000-0xfeda3fff] has been reserved system 00:0e: [mem 0xfeda4000-0xfeda4fff] has been reserved system 00:0e: [mem 0xfeda5000-0xfeda5fff] has been reserved system 00:0e: [mem 0xfeda6000-0xfeda6fff] has been reserved system 00:0e: [mem 0xfed18000-0xfed1bfff] has been reserved system 00:0e: [mem 0xf8000000-0xfbffffff] has been reserved system 00:0e: Plug and Play ACPI device, IDs PNP0c01 (active) pnp: PnP ACPI: found 15 devices ACPI: ACPI bus type pnp unregistered PCI: max bus depth: 2 pci_try_num: 3 pci 0000:00:02.0: BAR 2: assigned [mem 0x120000000-0x12fffffff 64bit pref] pci 0000:00:02.0: BAR 2: set to [mem 0x120000000-0x12fffffff 64bit pref] (PCI address [0x120000000-0x12fffffff]) pci 0000:00:1e.0: BAR 15: can't assign mem pref (size 0x18000000) pci 0000:00:1c.0: BAR 14: assigned [mem 0xe0000000-0xe01fffff] pci 0000:00:1c.0: BAR 15: assigned [mem 0x130000000-0x1301fffff 64bit pref] pci 0000:00:1c.1: BAR 15: assigned [mem 0x130200000-0x1303fffff 64bit pref] pci 0000:00:1c.3: BAR 15: assigned [mem 0x130400000-0x1305fffff 64bit pref] pci 0000:00:1c.5: BAR 15: assigned [mem 0x130600000-0x1307fffff 64bit pref] pci 0000:00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] pci 0000:00:1c.1: BAR 13: assigned [io 0x3000-0x3fff] pci 0000:00:1c.5: BAR 13: assigned [io 0x4000-0x4fff] pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] pci 0000:00:1c.0: bridge window [io 0x2000-0x2fff] pci 0000:00:1c.0: bridge window [mem 0xe0000000-0xe01fffff] pci 0000:00:1c.0: bridge window [mem 0x130000000-0x1301fffff 64bit pref] pci 0000:00:1c.1: PCI bridge to [bus 0c-0c] pci 0000:00:1c.1: bridge window [io 0x3000-0x3fff] pci 0000:00:1c.1: bridge window [mem 0xf6c00000-0xf6cfffff] pci 0000:00:1c.1: bridge window [mem 0x130200000-0x1303fffff 64bit pref] pci 0000:00:1c.3: PCI bridge to [bus 0d-0e] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] pci 0000:00:1c.3: bridge window [mem 0xf6a00000-0xf6bfffff] pci 0000:00:1c.3: bridge window [mem 0x130400000-0x1305fffff 64bit pref] pci 0000:00:1c.5: PCI bridge to [bus 09-09] pci 0000:00:1c.5: bridge window [io 0x4000-0x4fff] pci 0000:00:1c.5: bridge window [mem 0xf6900000-0xf69fffff] pci 0000:00:1c.5: bridge window [mem 0x130600000-0x1307fffff 64bit pref] pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x10000000) pci 0000:03:01.0: BAR 0: assigned [mem 0xe4000000-0xe4000fff] pci 0000:03:01.0: BAR 0: set to [mem 0xe4000000-0xe4000fff] (PCI address [0xe4000000-0xe4000fff]) pci 0000:03:01.0: BAR 15: assigned [mem 0xe8000000-0xebffffff pref] pci 0000:03:01.0: BAR 16: assigned [mem 0xec000000-0xefffffff] pci 0000:03:01.0: BAR 13: assigned [io 0x1400-0x14ff] pci 0000:03:01.0: BAR 14: assigned [io 0x1800-0x18ff] pci 0000:03:01.0: CardBus bridge to [bus 06-08] pci 0000:03:01.0: bridge window [io 0x1400-0x14ff] pci 0000:03:01.0: bridge window [io 0x1800-0x18ff] pci 0000:03:01.0: bridge window [mem 0xe8000000-0xebffffff pref] pci 0000:03:01.0: bridge window [mem 0xec000000-0xefffffff] pci 0000:05:00.0: BAR 0: can't assign mem pref (size 0x10000000) pci 0000:05:00.0: BAR 0: trying firmware assignment [mem 0xe0000000-0xefffffff 64bit pref] pci 0000:05:00.0: BAR 0: [mem 0xe0000000-0xefffffff 64bit pref] conflicts with PCI Bus 0000:0b [mem 0xe0000000-0xe01fffff] pci 0000:03:08.0: PCI bridge to [bus 05-05] pci 0000:03:08.0: bridge window [io 0xc000-0xcfff] pci 0000:03:08.0: bridge window [mem 0xf6600000-0xf67fffff] pci 0000:00:1e.0: PCI bridge to [bus 03-08] pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] pci 0000:00:1e.0: bridge window [mem 0xf6600000-0xf68fffff] PCI: No. 2 try to assign unassigned res pci 0000:00:1e.0: BAR 15: can't assign mem pref (size 0x10000000) pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] pci 0000:00:1c.0: bridge window [io 0x2000-0x2fff] pci 0000:00:1c.0: bridge window [mem 0xe0000000-0xe01fffff] pci 0000:00:1c.0: bridge window [mem 0x130000000-0x1301fffff 64bit pref] pci 0000:00:1c.1: PCI bridge to [bus 0c-0c] pci 0000:00:1c.1: bridge window [io 0x3000-0x3fff] pci 0000:00:1c.1: bridge window [mem 0xf6c00000-0xf6cfffff] pci 0000:00:1c.1: bridge window [mem 0x130200000-0x1303fffff 64bit pref] pci 0000:00:1c.3: PCI bridge to [bus 0d-0e] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] pci 0000:00:1c.3: bridge window [mem 0xf6a00000-0xf6bfffff] pci 0000:00:1c.3: bridge window [mem 0x130400000-0x1305fffff 64bit pref] pci 0000:00:1c.5: PCI bridge to [bus 09-09] pci 0000:00:1c.5: bridge window [io 0x4000-0x4fff] pci 0000:00:1c.5: bridge window [mem 0xf6900000-0xf69fffff] pci 0000:00:1c.5: bridge window [mem 0x130600000-0x1307fffff 64bit pref] pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x10000000) pci 0000:03:01.0: CardBus bridge to [bus 06-08] pci 0000:03:01.0: bridge window [io 0x1400-0x14ff] pci 0000:03:01.0: bridge window [io 0x1800-0x18ff] pci 0000:03:01.0: bridge window [mem 0xe8000000-0xebffffff pref] pci 0000:03:01.0: bridge window [mem 0xec000000-0xefffffff] pci 0000:05:00.0: BAR 0: can't assign mem pref (size 0x10000000) pci 0000:05:00.0: BAR 0: trying firmware assignment [mem 0xe0000000-0xefffffff 64bit pref] pci 0000:05:00.0: BAR 0: [mem 0xe0000000-0xefffffff 64bit pref] conflicts with PCI Bus 0000:0b [mem 0xe0000000-0xe01fffff] pci 0000:03:08.0: PCI bridge to [bus 05-05] pci 0000:03:08.0: bridge window [io 0xc000-0xcfff] pci 0000:03:08.0: bridge window [mem 0xf6600000-0xf67fffff] pci 0000:00:1e.0: PCI bridge to [bus 03-08] pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] pci 0000:00:1e.0: bridge window [mem 0xf6600000-0xf68fffff] PCI: No. 3 try to assign unassigned res pci 0000:00:1e.0: BAR 15: can't assign mem pref (size 0x10000000) pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] pci 0000:00:1c.0: bridge window [io 0x2000-0x2fff] pci 0000:00:1c.0: bridge window [mem 0xe0000000-0xe01fffff] pci 0000:00:1c.0: bridge window [mem 0x130000000-0x1301fffff 64bit pref] pci 0000:00:1c.1: PCI bridge to [bus 0c-0c] pci 0000:00:1c.1: bridge window [io 0x3000-0x3fff] pci 0000:00:1c.1: bridge window [mem 0xf6c00000-0xf6cfffff] pci 0000:00:1c.1: bridge window [mem 0x130200000-0x1303fffff 64bit pref] pci 0000:00:1c.3: PCI bridge to [bus 0d-0e] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] pci 0000:00:1c.3: bridge window [mem 0xf6a00000-0xf6bfffff] pci 0000:00:1c.3: bridge window [mem 0x130400000-0x1305fffff 64bit pref] pci 0000:00:1c.5: PCI bridge to [bus 09-09] pci 0000:00:1c.5: bridge window [io 0x4000-0x4fff] pci 0000:00:1c.5: bridge window [mem 0xf6900000-0xf69fffff] pci 0000:00:1c.5: bridge window [mem 0x130600000-0x1307fffff 64bit pref] pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x10000000) pci 0000:03:01.0: CardBus bridge to [bus 06-08] pci 0000:03:01.0: bridge window [io 0x1400-0x14ff] pci 0000:03:01.0: bridge window [io 0x1800-0x18ff] pci 0000:03:01.0: bridge window [mem 0xe8000000-0xebffffff pref] pci 0000:03:01.0: bridge window [mem 0xec000000-0xefffffff] pci 0000:05:00.0: BAR 0: can't assign mem pref (size 0x10000000) pci 0000:05:00.0: BAR 0: trying firmware assignment [mem 0xe0000000-0xefffffff 64bit pref] pci 0000:05:00.0: BAR 0: [mem 0xe0000000-0xefffffff 64bit pref] conflicts with PCI Bus 0000:0b [mem 0xe0000000-0xe01fffff] pci 0000:03:08.0: PCI bridge to [bus 05-05] pci 0000:03:08.0: bridge window [io 0xc000-0xcfff] pci 0000:03:08.0: bridge window [mem 0xf6600000-0xf67fffff] pci 0000:00:1e.0: PCI bridge to [bus 03-08] pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] pci 0000:00:1e.0: bridge window [mem 0xf6600000-0xf68fffff] pci 0000:00:1e.0: setting latency timer to 64 pci 0000:03:01.0: enabling device (0000 -> 0003) pci 0000:03:01.0: enabling bus mastering pci_bus 0000:00: resource 4 [io 0x0000-0xffff] pci_bus 0000:00: resource 5 [mem 0x00000000-0xfffffffff] pci_bus 0000:0b: resource 0 [io 0x2000-0x2fff] pci_bus 0000:0b: resource 1 [mem 0xe0000000-0xe01fffff] pci_bus 0000:0b: resource 2 [mem 0x130000000-0x1301fffff 64bit pref] pci_bus 0000:0c: resource 0 [io 0x3000-0x3fff] pci_bus 0000:0c: resource 1 [mem 0xf6c00000-0xf6cfffff] pci_bus 0000:0c: resource 2 [mem 0x130200000-0x1303fffff 64bit pref] pci_bus 0000:0d: resource 0 [io 0xd000-0xdfff] pci_bus 0000:0d: resource 1 [mem 0xf6a00000-0xf6bfffff] pci_bus 0000:0d: resource 2 [mem 0x130400000-0x1305fffff 64bit pref] pci_bus 0000:09: resource 0 [io 0x4000-0x4fff] pci_bus 0000:09: resource 1 [mem 0xf6900000-0xf69fffff] pci_bus 0000:09: resource 2 [mem 0x130600000-0x1307fffff 64bit pref] pci_bus 0000:03: resource 0 [io 0xc000-0xcfff] pci_bus 0000:03: resource 1 [mem 0xf6600000-0xf68fffff] pci_bus 0000:03: resource 4 [io 0x0000-0xffff] pci_bus 0000:03: resource 5 [mem 0x00000000-0xfffffffff] pci_bus 0000:06: resource 0 [io 0x1400-0x14ff] pci_bus 0000:06: resource 1 [io 0x1800-0x18ff] pci_bus 0000:06: resource 2 [mem 0xe8000000-0xebffffff pref] pci_bus 0000:06: resource 3 [mem 0xec000000-0xefffffff] pci_bus 0000:05: resource 0 [io 0xc000-0xcfff] pci_bus 0000:05: resource 1 [mem 0xf6600000-0xf67fffff] NET: Registered protocol family 2 IP route cache hash table entries: 131072 (order: 8, 1048576 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP: reno registered UDP hash table entries: 2048 (order: 4, 65536 bytes) UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) NET: Registered protocol family 1 pci 0000:00:02.0: calling pci_fixup_video+0x0/0x94 pci 0000:00:02.0: Boot video device pci 0000:00:1a.0: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1a.1: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1a.7: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1d.0: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1d.1: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1d.2: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1d.7: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:03:01.0: calling quirk_cardbus_legacy+0x0/0x17 pci 0000:05:00.0: calling pci_fixup_video+0x0/0x94 PCI: CLS 64 bytes, default 64 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 5724k freed PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing 64MB software IO TLB between ffff8800db654000 - ffff8800df654000 software IO TLB at phys 0xdb654000 - 0xdf654000 Simple Boot Flag at 0x79 set to 0x1 sha1_ssse3: Using SSSE3 optimized SHA-1 implementation audit: initializing netlink socket (disabled) type=2000 audit(1334090223.077:1): initialized Testing tracer function: PASSED Testing dynamic ftrace: PASSED Testing dynamic ftrace ops #1: (1 0 1 1 0) (1 1 2 1 0) (2 1 3 1 9) (2 2 4 1 159) PASSED Testing dynamic ftrace ops #2: (1 0 1 4 0) (1 1 2 139 0) (2 1 3 2 75) (2 2 4 156 228) PASSED Testing tracer wakeup: PASSED Testing tracer wakeup_rt: Refined TSC clocksource calibration: 2393.999 MHz. Switching to clocksource tsc PASSED Testing tracer function_graph: PASSED HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) msgmni has been set to 7885 alg: No test for snappy (snappy-generic) alg: No test for stdrng (krng) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler cfq registered (default) list_sort_test: start testing list_sort() crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64 crc32: self tests passed, processed 225944 bytes in 198667 nsec crc32c: CRC_LE_BITS = 64 crc32c: self tests passed, processed 225944 bytes in 99363 nsec pcieport 0000:00:1c.0: irq 40 for MSI/MSI-X pcieport 0000:00:1c.1: irq 41 for MSI/MSI-X pcieport 0000:00:1c.3: irq 42 for MSI/MSI-X pcieport 0000:00:1c.5: irq 43 for MSI/MSI-X pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp: PCI Express Hot Plug Controller Driver version: 0.4 cpcihp_zt5550: ZT5550 CompactPCI Hot Plug Driver version: 0.2 cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1 cpcihp_generic: not configured, disabling. shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 pci_bus 0000:03: dev 07, created physical slot 1 acpiphp: Slot [1] registered pci_bus 0000:03: dev 08, created physical slot 2 acpiphp: Slot [2] registered pci_bus 0000:0d: dev 00, created physical slot 1-1 acpiphp: Slot [1-1] registered acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed intel_idle: does not run on family 6 model 15 ACPI: AC Adapter [AC] (on-line) input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input0 ACPI: Lid Switch [LID] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1 ACPI: Power Button [PBTN] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2 ACPI: Sleep Button [SBTN] ACPI: Requesting acpi_cpufreq Monitor-Mwait will be used to enter C-1 state Monitor-Mwait will be used to enter C-2 state Monitor-Mwait will be used to enter C-3 state Marking TSC unstable due to TSC halts in idle ACPI: acpi_idle registered with cpuidle Switching to clocksource hpet thermal LNXTHERM:00: registered as thermal_zone0 ACPI: Thermal Zone [THM] (58 C) GHES: HEST is not enabled! ioatdma: Intel(R) QuickData Technology Driver 4.00 ACPI: Battery Slot [BAT0] (battery present) ACPI: Battery Slot [BAT1] (battery absent) brd: module loaded tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> i8042: PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice rtc_cmos 00:03: RTC can wake from S4 rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs i2c /dev entries driver iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07 iTCO_wdt: Found a ICH8M TCO device (Version=2, TCOBASE=0x1060) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) iTCO_vendor_support: vendor-support=0 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com cpuidle: using governor ladder cpuidle: using governor menu TCP: cubic registered NET: Registered protocol family 10 NET: Registered protocol family 17 sctp: Hash tables configured (established 65536 bind 65536) input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 Registering the dns_resolver key type PM: Checking hibernation image partition UUID=ae0f88ec-9e17-41f2-b8b3-685cce36e496 PM: Hibernation image not present or could not be loaded. registered taskstats version 1 Running tests on trace events: Testing event kfree_skb: OK Testing event consume_skb: OK Testing event skb_copy_datagram_iovec: OK Testing event net_dev_xmit: OK Testing event net_dev_queue: OK Testing event netif_receive_skb: OK Testing event netif_rx: OK Testing event napi_poll: OK Testing event sock_rcvqueue_full: OK Testing event sock_exceed_buf_limit: OK Testing event udp_fail_queue_rcv_skb: OK Testing event regmap_reg_write: OK Testing event regmap_reg_read: OK Testing event regmap_reg_read_cache: OK Testing event regmap_hw_read_start: OK Testing event regmap_hw_read_done: OK Testing event regmap_hw_write_start: OK Testing event regmap_hw_write_done: OK Testing event regcache_sync: OK Testing event regmap_cache_only: OK Testing event regmap_cache_bypass: OK Testing event regulator_enable: OK Testing event regulator_enable_delay: OK Testing event regulator_enable_complete: OK Testing event regulator_disable: OK Testing event regulator_disable_complete: OK Testing event regulator_set_voltage: OK Testing event regulator_set_voltage_complete: OK Testing event block_rq_abort: OK Testing event block_rq_requeue: OK Testing event block_rq_complete: OK Testing event block_rq_insert: OK Testing event block_rq_issue: OK Testing event block_bio_bounce: OK Testing event block_bio_complete: OK Testing event block_bio_backmerge: OK Testing event block_bio_frontmerge: OK Testing event block_bio_queue: OK Testing event block_getrq: OK Testing event block_sleeprq: OK Testing event block_plug: OK Testing event block_unplug: OK Testing event block_split: OK Testing event block_bio_remap: OK Testing event block_rq_remap: OK Testing event writeback_nothread: OK Testing event writeback_queue: OK Testing event writeback_exec: OK Testing event writeback_start: OK Testing event writeback_written: OK Testing event writeback_wait: OK Testing event writeback_pages_written: OK Testing event writeback_nowork: OK Testing event writeback_wake_background: OK Testing event writeback_wake_thread: OK Testing event writeback_wake_forker_thread: OK Testing event writeback_bdi_register: OK Testing event writeback_bdi_unregister: OK Testing event writeback_thread_start: OK Testing event writeback_thread_stop: OK Testing event wbc_writepage: OK Testing event writeback_queue_io: OK Testing event global_dirty_state: OK Testing event bdi_dirty_ratelimit: OK Testing event balance_dirty_pages: OK Testing event writeback_congestion_wait: OK Testing event writeback_wait_iff_congested: OK Testing event writeback_single_inode_requeue: OK Testing event writeback_single_inode: OK Testing event mm_compaction_isolate_migratepages: OK Testing event mm_compaction_isolate_freepages: OK Testing event mm_compaction_migratepages: OK Testing event kmalloc: OK Testing event kmem_cache_alloc: OK Testing event kmalloc_node: OK Testing event kmem_cache_alloc_node: OK Testing event kfree: OK Testing event kmem_cache_free: OK Testing event mm_page_free: OK Testing event mm_page_free_batched: OK Testing event mm_page_alloc: OK Testing event mm_page_alloc_zone_locked: OK Testing event mm_page_pcpu_drain: OK Testing event mm_page_alloc_extfrag: OK Testing event mm_vmscan_kswapd_sleep: OK Testing event mm_vmscan_kswapd_wake: OK Testing event mm_vmscan_wakeup_kswapd: OK Testing event mm_vmscan_direct_reclaim_begin: OK Testing event mm_vmscan_memcg_reclaim_begin: OK Testing event mm_vmscan_memcg_softlimit_reclaim_begin: OK Testing event mm_vmscan_direct_reclaim_end: OK Testing event mm_vmscan_memcg_reclaim_end: OK Testing event mm_vmscan_memcg_softlimit_reclaim_end: OK Testing event mm_shrink_slab_start: OK Testing event mm_shrink_slab_end: OK Testing event mm_vmscan_lru_isolate: OK Testing event mm_vmscan_memcg_isolate: OK Testing event mm_vmscan_writepage: OK Testing event mm_vmscan_lru_shrink_inactive: OK Testing event replace_swap_token: OK Testing event put_swap_token: OK Testing event disable_swap_token: OK Testing event update_swap_token_priority: OK Testing event oom_score_adj_update: OK Testing event rpm_suspend: OK Testing event rpm_resume: OK Testing event rpm_idle: OK Testing event rpm_return_int: OK Testing event cpu_idle: OK Testing event cpu_frequency: OK Testing event machine_suspend: OK Testing event clock_enable: OK Testing event clock_disable: OK Testing event clock_set_rate: OK Testing event power_domain_target: OK Testing event ftrace_test_filter: OK Testing event module_load: OK Testing event module_free: OK Testing event module_get: OK Testing event module_put: OK Testing event module_request: OK Testing event sched_kthread_stop: OK Testing event sched_kthread_stop_ret: OK Testing event sched_wakeup: OK Testing event sched_wakeup_new: OK Testing event sched_switch: OK Testing event sched_migrate_task: OK Testing event sched_process_free: OK Testing event sched_process_exit: OK Testing event sched_wait_task: OK Testing event sched_process_wait: OK Testing event sched_process_fork: OK Testing event sched_process_exec: OK Testing event sched_stat_wait: OK Testing event sched_stat_sleep: OK Testing event sched_stat_iowait: OK Testing event sched_stat_blocked: OK Testing event sched_stat_runtime: OK Testing event sched_pi_setprio: OK Testing event rcu_utilization: OK Testing event workqueue_queue_work: OK Testing event workqueue_activate_work: OK Testing event workqueue_execute_start: OK Testing event workqueue_execute_end: OK Testing event signal_generate: OK Testing event signal_deliver: OK Testing event timer_init: OK Testing event timer_start: OK Testing event timer_expire_entry: OK Testing event timer_expire_exit: OK Testing event timer_cancel: OK Testing event hrtimer_init: OK Testing event hrtimer_start: OK Testing event hrtimer_expire_entry: OK Testing event hrtimer_expire_exit: OK Testing event hrtimer_cancel: OK Testing event itimer_state: OK Testing event itimer_expire: OK Testing event irq_handler_entry: OK Testing event irq_handler_exit: OK Testing event softirq_entry: OK Testing event softirq_exit: OK Testing event softirq_raise: OK Testing event console: OK Testing event task_newtask: OK Testing event task_rename: OK Testing event mce_record: OK Testing event sys_enter: OK Testing event sys_exit: OK Testing event emulate_vsyscall: OK Running tests on trace event systems: Testing event system skb: OK Testing event system net: OK Testing event system napi: OK Testing event system sock: OK Testing event system udp: OK Testing event system regmap: OK Testing event system regulator: OK Testing event system block: OK Testing event system writeback: OK Testing event system compaction: OK Testing event system kmem: OK Testing event system vmscan: OK Testing event system oom: OK Testing event system rpm: OK Testing event system power: OK Testing event system test: OK Testing event system module: OK Testing event system sched: OK Testing event system rcu: OK Testing event system workqueue: OK Testing event system signal: OK Testing event system timer: OK Testing event system irq: OK Testing event system printk: OK Testing event system task: OK Testing event system mce: OK Testing event system raw_syscalls: OK Testing event system vsyscall: OK Testing event system syscalls: OK Running tests on all trace events: Testing all events: event trace: Could not enable event function OK Running tests again, along with the function tracer Running tests on trace events: Testing event kfree_skb: OK Testing event consume_skb: OK Testing event skb_copy_datagram_iovec: OK Testing event net_dev_xmit: OK Testing event net_dev_queue: OK Testing event netif_receive_skb: OK Testing event netif_rx: OK Testing event napi_poll: OK Testing event sock_rcvqueue_full: OK Testing event sock_exceed_buf_limit: OK Testing event udp_fail_queue_rcv_skb: OK Testing event regmap_reg_write: OK Testing event regmap_reg_read: OK Testing event regmap_reg_read_cache: OK Testing event regmap_hw_read_start: OK Testing event regmap_hw_read_done: OK Testing event regmap_hw_write_start: OK Testing event regmap_hw_write_done: OK Testing event regcache_sync: OK Testing event regmap_cache_only: OK Testing event regmap_cache_bypass: OK Testing event regulator_enable: OK Testing event regulator_enable_delay: OK Testing event regulator_enable_complete: OK Testing event regulator_disable: OK Testing event regulator_disable_complete: OK Testing event regulator_set_voltage: OK Testing event regulator_set_voltage_complete: OK Testing event block_rq_abort: OK Testing event block_rq_requeue: OK Testing event block_rq_complete: OK Testing event block_rq_insert: OK Testing event block_rq_issue: OK Testing event block_bio_bounce: OK Testing event block_bio_complete: OK Testing event block_bio_backmerge: OK Testing event block_bio_frontmerge: OK Testing event block_bio_queue: OK Testing event block_getrq: OK Testing event block_sleeprq: OK Testing event block_plug: OK Testing event block_unplug: OK Testing event block_split: OK Testing event block_bio_remap: OK Testing event block_rq_remap: OK Testing event writeback_nothread: OK Testing event writeback_queue: OK Testing event writeback_exec: OK Testing event writeback_start: OK Testing event writeback_written: OK Testing event writeback_wait: OK Testing event writeback_pages_written: OK Testing event writeback_nowork: OK Testing event writeback_wake_background: OK Testing event writeback_wake_thread: OK Testing event writeback_wake_forker_thread: OK Testing event writeback_bdi_register: OK Testing event writeback_bdi_unregister: OK Testing event writeback_thread_start: OK Testing event writeback_thread_stop: OK Testing event wbc_writepage: OK Testing event writeback_queue_io: OK Testing event global_dirty_state: OK Testing event bdi_dirty_ratelimit: OK Testing event balance_dirty_pages: OK Testing event writeback_congestion_wait: OK Testing event writeback_wait_iff_congested: OK Testing event writeback_single_inode_requeue: OK Testing event writeback_single_inode: OK Testing event mm_compaction_isolate_migratepages: OK Testing event mm_compaction_isolate_freepages: OK Testing event mm_compaction_migratepages: OK Testing event kmalloc: OK Testing event kmem_cache_alloc: OK Testing event kmalloc_node: OK Testing event kmem_cache_alloc_node: OK Testing event kfree: OK Testing event kmem_cache_free: OK Testing event mm_page_free: OK Testing event mm_page_free_batched: OK Testing event mm_page_alloc: OK Testing event mm_page_alloc_zone_locked: OK Testing event mm_page_pcpu_drain: OK Testing event mm_page_alloc_extfrag: OK Testing event mm_vmscan_kswapd_sleep: OK Testing event mm_vmscan_kswapd_wake: OK Testing event mm_vmscan_wakeup_kswapd: OK Testing event mm_vmscan_direct_reclaim_begin: OK Testing event mm_vmscan_memcg_reclaim_begin: OK Testing event mm_vmscan_memcg_softlimit_reclaim_begin: OK Testing event mm_vmscan_direct_reclaim_end: OK Testing event mm_vmscan_memcg_reclaim_end: OK Testing event mm_vmscan_memcg_softlimit_reclaim_end: OK Testing event mm_shrink_slab_start: OK Testing event mm_shrink_slab_end: OK Testing event mm_vmscan_lru_isolate: OK Testing event mm_vmscan_memcg_isolate: OK Testing event mm_vmscan_writepage: OK Testing event mm_vmscan_lru_shrink_inactive: OK Testing event replace_swap_token: OK Testing event put_swap_token: OK Testing event disable_swap_token: OK Testing event update_swap_token_priority: OK Testing event oom_score_adj_update: OK Testing event rpm_suspend: OK Testing event rpm_resume: OK Testing event rpm_idle: OK Testing event rpm_return_int: OK Testing event cpu_idle: OK Testing event cpu_frequency: OK Testing event machine_suspend: OK Testing event clock_enable: OK Testing event clock_disable: OK Testing event clock_set_rate: OK Testing event power_domain_target: OK Testing event ftrace_test_filter: OK Testing event module_load: OK Testing event module_free: OK Testing event module_get: OK Testing event module_put: OK Testing event module_request: OK Testing event sched_kthread_stop: OK Testing event sched_kthread_stop_ret: OK Testing event sched_wakeup: OK Testing event sched_wakeup_new: OK Testing event sched_switch: OK Testing event sched_migrate_task: OK Testing event sched_process_free: OK Testing event sched_process_exit: OK Testing event sched_wait_task: OK Testing event sched_process_wait: OK Testing event sched_process_fork: OK Testing event sched_process_exec: OK Testing event sched_stat_wait: OK Testing event sched_stat_sleep: OK Testing event sched_stat_iowait: OK Testing event sched_stat_blocked: OK Testing event sched_stat_runtime: OK Testing event sched_pi_setprio: OK Testing event rcu_utilization: OK Testing event workqueue_queue_work: OK Testing event workqueue_activate_work: OK Testing event workqueue_execute_start: OK Testing event workqueue_execute_end: OK Testing event signal_generate: OK Testing event signal_deliver: OK Testing event timer_init: OK Testing event timer_start: OK Testing event timer_expire_entry: OK Testing event timer_expire_exit: OK Testing event timer_cancel: OK Testing event hrtimer_init: OK Testing event hrtimer_start: OK Testing event hrtimer_expire_entry: OK Testing event hrtimer_expire_exit: OK Testing event hrtimer_cancel: OK Testing event itimer_state: OK Testing event itimer_expire: OK Testing event irq_handler_entry: OK Testing event irq_handler_exit: OK Testing event softirq_entry: OK Testing event softirq_exit: OK Testing event softirq_raise: OK Testing event console: OK Testing event task_newtask: OK Testing event task_rename: OK Testing event mce_record: OK Testing event sys_enter: OK Testing event sys_exit: OK Testing event emulate_vsyscall: OK Running tests on trace event systems: Testing event system skb: OK Testing event system net: OK Testing event system napi: OK Testing event system sock: OK Testing event system udp: OK Testing event system regmap: OK Testing event system regulator: OK Testing event system block: OK Testing event system writeback: OK Testing event system compaction: OK Testing event system kmem: OK Testing event system vmscan: OK Testing event system oom: OK Testing event system rpm: OK Testing event system power: OK Testing event system test: OK Testing event system module: OK Testing event system sched: OK Testing event system rcu: OK Testing event system workqueue: OK Testing event system signal: OK Testing event system timer: OK Testing event system irq: OK Testing event system printk: OK Testing event system task: OK Testing event system mce: OK Testing event system raw_syscalls: OK Testing event system vsyscall: OK Testing event system syscalls: OK Running tests on all trace events: Testing all events: event trace: Could not enable event function OK Testing ftrace filter: OK rtc_cmos 00:03: setting system clock to 2012-04-10 20:37:06 UTC (1334090226) Freeing unused kernel memory: 612k freed Write protecting the kernel read-only data: 6144k Freeing unused kernel memory: 572k freed Freeing unused kernel memory: 696k freed udevd[496]: starting version 182 Linux agpgart interface v0.103 [drm] Initialized drm 1.1.0 20060810 agpgart-intel 0000:00:00.0: Intel 965GM Chipset agpgart-intel 0000:00:00.0: detected gtt size: 524288K total, 262144K mappable agpgart-intel 0000:00:00.0: detected 8192K stolen memory agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0x20000000 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. i915 0000:00:02.0: setting latency timer to 64 radeon 0000:05:00.0: enabling device (0000 -> 0003) i915: probe of 0000:00:02.0 failed with error -5 radeon 0000:05:00.0: enabling bus mastering [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E1 0x1787:0x3000). [drm] register mmio base: 0xF66E0000 [drm] register mmio size: 131072 ATOM BIOS: B9127JMA.MFK [drm] GPU not posted. posting now... radeon 0000:05:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) radeon 0000:05:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF mtrr: zero sized request [drm] Detected VRAM RAM=512M, BAR=0M [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 2019692 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator radeon_bo_create:132 alloc size 0M bigger than 0Mb limit radeon 0000:05:00.0: Fatal error during GPU init [drm] radeon: finishing device. radeon 0000:05:00.0: no bo for sa manager [TTM] Trying to take down uninitialized memory manager type 1 [TTM] Finalizing pool allocator [TTM] Finalizing DMA pool allocator [TTM] Zone kernel: Used memory at exit: 0 kiB [drm] radeon: ttm finalized vga_switcheroo: disabled radeon: probe of 0000:05:00.0 failed with error -12 dracut: Starting plymouth daemon usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb uhci_hcd: USB Universal Host Controller Interface driver uhci_hcd 0000:00:1a.0: enabling bus mastering uhci_hcd 0000:00:1a.0: setting latency timer to 64 uhci_hcd 0000:00:1a.0: UHCI Host Controller uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1 uhci_hcd 0000:00:1a.0: irq 20, io base 0x00006f20 usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: UHCI Host Controller usb usb1: Manufacturer: Linux 3.4.0-rc2-wl-00219-g61fa1b5 uhci_hcd usb usb1: SerialNumber: 0000:00:1a.0 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected uhci_hcd 0000:00:1a.1: enabling bus mastering uhci_hcd 0000:00:1a.1: setting latency timer to 64 uhci_hcd 0000:00:1a.1: UHCI Host Controller uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 2 uhci_hcd 0000:00:1a.1: irq 21, io base 0x00006f00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: UHCI Host Controller usb usb2: Manufacturer: Linux 3.4.0-rc2-wl-00219-g61fa1b5 uhci_hcd usb usb2: SerialNumber: 0000:00:1a.1 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ehci_hcd 0000:00:1a.7: enabling bus mastering ehci_hcd 0000:00:1a.7: setting latency timer to 64 ehci_hcd 0000:00:1a.7: EHCI Host Controller ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:1a.7: debug port 1 yenta_cardbus 0000:03:01.0: CardBus bridge found [1028:01fe] yenta_cardbus 0000:03:01.0: O2: enabling read prefetch/write burst. If you experience problems or performance issues, use the yenta_socket parameter 'o2_speedup=off' ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported ehci_hcd 0000:00:1a.7: irq 22, io mem 0xfed1c400 SCSI subsystem initialized libata version 3.00 loaded. ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 3.4.0-rc2-wl-00219-g61fa1b5 ehci_hcd usb usb3: SerialNumber: 0000:00:1a.7 hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected ehci_hcd 0000:00:1d.7: enabling bus mastering ehci_hcd 0000:00:1d.7: setting latency timer to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4 ehci_hcd 0000:00:1d.7: debug port 1 ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported ehci_hcd 0000:00:1d.7: irq 20, io mem 0xfed1c000 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 usb usb4: New USB device found, idVendor=1d6b, idProduct=0002 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: EHCI Host Controller usb usb4: Manufacturer: Linux 3.4.0-rc2-wl-00219-g61fa1b5 ehci_hcd usb usb4: SerialNumber: 0000:00:1d.7 hub 4-0:1.0: USB hub found hub 4-0:1.0: 6 ports detected uhci_hcd 0000:00:1d.0: enabling bus mastering uhci_hcd 0000:00:1d.0: setting latency timer to 64 uhci_hcd 0000:00:1d.0: UHCI Host Controller uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5 uhci_hcd 0000:00:1d.0: irq 20, io base 0x00006f80 usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: UHCI Host Controller usb usb5: Manufacturer: Linux 3.4.0-rc2-wl-00219-g61fa1b5 uhci_hcd usb usb5: SerialNumber: 0000:00:1d.0 hub 5-0:1.0: USB hub found hub 5-0:1.0: 2 ports detected uhci_hcd 0000:00:1d.1: enabling bus mastering uhci_hcd 0000:00:1d.1: setting latency timer to 64 uhci_hcd 0000:00:1d.1: UHCI Host Controller uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6 uhci_hcd 0000:00:1d.1: irq 21, io base 0x00006f60 usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: UHCI Host Controller usb usb6: Manufacturer: Linux 3.4.0-rc2-wl-00219-g61fa1b5 uhci_hcd usb usb6: SerialNumber: 0000:00:1d.1 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected ata_piix 0000:00:1f.1: version 2.13 ata_piix 0000:00:1f.1: setting latency timer to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x6fa0 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x6fa8 irq 15 ahci 0000:00:1f.2: version 3.0 ahci 0000:00:1f.2: irq 44 for MSI/MSI-X ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x5 impl SATA mode ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc ems ahci 0000:00:1f.2: setting latency timer to 64 ata2: port disabled--ignoring scsi2 : ahci scsi3 : ahci scsi4 : ahci ata3: SATA max UDMA/133 abar m2048@0xf6dfb800 port 0xf6dfb900 irq 44 ata4: DUMMY ata5: SATA max UDMA/133 abar m2048@0xf6dfb800 port 0xf6dfba00 irq 44 uhci_hcd 0000:00:1d.2: enabling bus mastering uhci_hcd 0000:00:1d.2: setting latency timer to 64 uhci_hcd 0000:00:1d.2: UHCI Host Controller uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7 uhci_hcd 0000:00:1d.2: irq 22, io base 0x00006f40 usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: UHCI Host Controller usb usb7: Manufacturer: Linux 3.4.0-rc2-wl-00219-g61fa1b5 uhci_hcd usb usb7: SerialNumber: 0000:00:1d.2 hub 7-0:1.0: USB hub found hub 7-0:1.0: 2 ports detected yenta_cardbus 0000:03:01.0: ISA IRQ mask 0x0cb8, PCI irq 19 yenta_cardbus 0000:03:01.0: Socket status: 30000006 yenta_cardbus 0000:03:01.0: pcmcia: parent PCI bridge window: [io 0xc000-0xcfff] yenta_cardbus 0000:03:01.0: pcmcia: parent PCI bridge window: [mem 0xf6600000-0xf68fffff] pcmcia_socket pcmcia_socket0: cs: memory probe 0xf6600000-0xf68fffff: excluding 0xf6600000-0xf680ffff 0xf68d0000-0xf68fffff firewire_ohci 0000:03:01.4: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x10 ata1.00: ATA-7: ST980813AS, 3.ADB, max UDMA/133 ata1.00: 156301488 sectors, multi 8: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/100 scsi 0:0:0:0: Direct-Access ATA ST980813AS 3.AD PQ: 0 ANSI: 5 ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata5: SATA link down (SStatus 0 SControl 300) ata3.00: ATA-8: OCZ-AGILITY3, 2.13, max UDMA/133 ata3.00: 234441648 sectors, multi 8: LBA48 NCQ (depth 31/32), AA ata3.00: configured for UDMA/133 scsi 2:0:0:0: Direct-Access ATA OCZ-AGILITY3 2.13 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) sd 2:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 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 sdb: sdb1 sdb2 sdb3 sd 2:0:0:0: [sdb] Attached SCSI disk sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI disk Btrfs loaded device label GENTOO devid 1 transid 345262 /dev/sdb3 usb 3-3: new high-speed USB device number 3 using ehci_hcd usb 3-3: New USB device found, idVendor=413c, idProduct=0058 usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 3-3:1.0: USB hub found hub 3-3:1.0: 4 ports detected usb 4-2: new high-speed USB device number 2 using ehci_hcd firewire_core 0000:03:01.4: created device fw0: GUID 314fc00002643c70, S400 usb 4-2: New USB device found, idVendor=14cd, idProduct=125b usb 4-2: New USB device strings: Mfr=1, Product=3, SerialNumber=2 usb 4-2: Product: AutoRUN/Partition usb 4-2: Manufacturer: Generic usb 4-2: SerialNumber: 125B20100608 usbcore: registered new interface driver libusual Initializing USB Mass Storage driver... scsi5 : usb-storage 4-2:1.0 usbcore: registered new interface driver usb-storage USB Mass Storage support registered. dracut: Checking, if btrfs device complete device label GENTOO devid 1 transid 345262 /dev/sdb3 btrfs: disk space caching is enabled Btrfs detected SSD devices, enabling SSD mode dracut: Checking, if btrfs device complete device label GENTOO devid 1 transid 345262 /dev/sdb3 btrfs: disk space caching is enabled Btrfs detected SSD devices, enabling SSD mode dracut: Checking, if btrfs device complete device label GENTOO devid 1 transid 345262 /dev/sdb3 btrfs: disk space caching is enabled usb 1-2: new full-speed USB device number 2 using uhci_hcd Btrfs detected SSD devices, enabling SSD mode PM: Marking nosave pages: [mem 0x0009f000-0x000fffff] PM: Marking nosave pages: [mem 0xdf65a000-0xffffffff] PM: Basic memory bitmaps created PM: Basic memory bitmaps freed PM: Starting manual resume from disk PM: Hibernation image partition 8:18 present PM: Looking for hibernation image. PM: Image not found (code -22) PM: Hibernation image not present or could not be loaded. device label GENTOO devid 1 transid 345262 /dev/sdb3 btrfs: disk space caching is enabled Btrfs detected SSD devices, enabling SSD mode dracut: Checking btrfs: /dev/disk/by-uuid/d761a2db-f951-4e9c-bed4-cf2381bb1af4 dracut: trying to mount /dev/disk/by-uuid/d761a2db-f951-4e9c-bed4-cf2381bb1af4 device label GENTOO devid 1 transid 345262 /dev/sdb3 btrfs: disk space caching is enabled usb 1-2: New USB device found, idVendor=413c, idProduct=8140 usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Btrfs detected SSD devices, enabling SSD mode dracut: btrfs: /dev/disk/by-uuid/d761a2db-f951-4e9c-bed4-cf2381bb1af4 is clean usb 3-3.2: new high-speed USB device number 4 using ehci_hcd usb 3-3.2: New USB device found, idVendor=413c, idProduct=0058 usb 3-3.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 3-3.2:1.0: USB hub found hub 3-3.2:1.0: 4 ports detected usb 7-1: new full-speed USB device number 2 using uhci_hcd usb 7-1: New USB device found, idVendor=0b97, idProduct=7761 usb 7-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 7-1:1.0: USB hub found hub 7-1:1.0: 4 ports detected scsi 5:0:0:0: Direct-Access Mass Storage Device PQ: 0 ANSI: 0 CCS sd 5:0:0:0: [sdc] 31116287 512-byte logical blocks: (15.9 GB/14.8 GiB) sd 5:0:0:0: [sdc] Write Protect is off sd 5:0:0:0: [sdc] Mode Sense: 03 00 00 00 sd 5:0:0:0: [sdc] No Caching mode page present sd 5:0:0:0: [sdc] Assuming drive cache: write through sd 5:0:0:0: [sdc] No Caching mode page present sd 5:0:0:0: [sdc] Assuming drive cache: write through sdc: unknown partition table sd 5:0:0:0: [sdc] No Caching mode page present sd 5:0:0:0: [sdc] Assuming drive cache: write through sd 5:0:0:0: [sdc] Attached SCSI removable disk device label distfiles devid 1 transid 2378 /dev/sdc usb 7-1.2: new full-speed USB device number 3 using uhci_hcd usb 7-1.2: New USB device found, idVendor=0b97, idProduct=7772 usb 7-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 7-1.2: Product: O2Micro CCID SC Reader usb 7-1.2: Manufacturer: O2 btrfs bad tree block start 67108864 58720256 failed mirror was 1 btrfs read error corrected: ino 1 off 58720256 (dev /dev/sdb3 sector 131072) dracut: Remounting /dev/disk/by-uuid/d761a2db-f951-4e9c-bed4-cf2381bb1af4 with -o subvol=ROOT,ro device label GENTOO devid 1 transid 345265 /dev/sdb3 btrfs: disk space caching is enabled Btrfs detected SSD devices, enabling SSD mode dracut: Mounted root filesystem /dev/sdb3 dracut: Switching root btrfs: use lzo compression btrfs: enabling inode map caching btrfs: use ssd allocation scheme btrfs: disk space caching is enabled RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. FS-Cache: Loaded udevd[866]: starting version 182 NFS: Registering the id_resolver key type FS-Cache: Netfs 'nfs' registered for caching loop: module loaded Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled tg3.c:v3.123 (March 21, 2012) cfg80211: Calling CRDA to update world regulatory domain wmi: Mapper loaded parport_pc 00:0a: reported by Plug and Play ACPI parport0: PC-style at 0x378 (0x778), irq 7, dma 1 [PCSPP,TRISTATE tg3 0000:09:00.0: eth0: Tigon3 [partno(BCM95755m) rev a002] (PCI Express) MAC address 00:1d:09:bc:69:2c tg3 0000:09:00.0: eth0: attached PHY is 5755 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) tg3 0000:09:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] tg3 0000:09:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit] ,COMPAT,ECP,DMA] iwl4965: Intel(R) Wireless WiFi 4965 driver for Linux, in-tree: iwl4965: Copyright(c) 2003-2011 Intel Corporation iwl4965 0000:0c:00.0: Detected Intel(R) Wireless WiFi Link 4965AGN, REV=0x4 iwl4965 0000:0c:00.0: device EEPROM VER=0x36, CALIB=0x5 iwl4965 0000:0c:00.0: Tunable channels: 13 802.11bg, 19 802.11a channels iwl4965 0000:0c:00.0: irq 45 for MSI/MSI-X snd_hda_intel 0000:00:1b.0: irq 46 for MSI/MSI-X input: PC Speaker as /devices/platform/pcspkr/input/input4 Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 snd_hda_intel 0000:05:00.1: irq 47 for MSI/MSI-X usbcore: registered new interface driver btusb microcode: CPU0 sig=0x6fb, pf=0x80, revision=0xb3 WARNING! power/level is deprecated; use power/control instead HDMI status: Codec=0 Pin=3 Presence_Detect=0 ELD_Valid=0 input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1e.0/0000:03:08.0/0000:05:00.1/sound/card1/input7 dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) iwl4965 0000:0c:00.0: RF_KILL bit toggled to enable radio. serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A input: Dell WMI hotkeys as /devices/virtual/input/input8 microcode: CPU1 sig=0x6fb, pf=0x80, revision=0xb3 iwl4965 0000:0c:00.0: loaded firmware version 228.61.2.24 Registered led device: phy0-led cfg80211: World regulatory domain updated: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba device label distfiles devid 1 transid 2378 /dev/sdc ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs' btrfs: use zlib compression btrfs: enabling inode map caching btrfs: use ssd allocation scheme btrfs: disk space caching is enabled Adding 8005628k swap on /dev/sdb2. Priority:0 extents:1 across:8005628k SS PHC: Got new VIDs through sysfs VID interface. PHC: Got new VIDs through sysfs VID interface. PHC: Got new VIDs through sysfs VID interface. PHC: Got new VIDs through sysfs VID interface. input: DualPoint Stick as /devices/platform/i8042/serio1/input/input9 input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input10 ADDRCONF(NETDEV_UP): wlan0: link is not ready tg3 0000:09:00.0: irq 48 for MSI/MSI-X ADDRCONF(NETDEV_UP): eth0: link is not ready sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk tg3 0000:09:00.0: eth0: Link is up at 1000 Mbps, full duplex tg3 0000:09:00.0: eth0: Flow control is on for TX and on for RX ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready ata1.00: configured for UDMA/100 sd 0:0:0:0: [sda] Starting disk ata1.00: configured for UDMA/100 ata1: EH complete ata3.00: configured for UDMA/133 ata3: EH complete sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk uhci_hcd 0000:00:1a.1: enabling bus mastering uhci_hcd 0000:00:1a.1: setting latency timer to 64 uhci_hcd 0000:00:1d.0: enabling bus mastering uhci_hcd 0000:00:1d.0: setting latency timer to 64 uhci_hcd 0000:00:1d.1: enabling bus mastering uhci_hcd 0000:00:1d.1: setting latency timer to 64 wlan0: authenticate with e0:91:f5:04:7b:e8 wlan0: send auth to e0:91:f5:04:7b:e8 (try 1/3) wlan0: authenticated wlan0: associate with e0:91:f5:04:7b:e8 (try 1/3) wlan0: RX AssocResp from e0:91:f5:04:7b:e8 (capab=0x411 status=0 aid=2) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready cfg80211: Calling CRDA for country: GB cfg80211: Regulatory domain changed to country: GB cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm) cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm) cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm) ICMPv6 RA: ndisc_router_discovery() failed to add default route. ICMPv6 RA: ndisc_router_discovery() failed to add default route. [-- Attachment #3: dmesg.docked.sig --] [-- Type: application/pgp-signature, Size: 72 bytes --] ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 19:46 ` Steven Newbury @ 2012-04-10 20:07 ` Yinghai Lu 2012-04-10 20:26 ` Steven Newbury 0 siblings, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-04-10 20:07 UTC (permalink / raw) To: Steven Newbury; +Cc: Bjorn Helgaas, linux-pci On Tue, Apr 10, 2012 at 12:46 PM, Steven Newbury <steve@snewbury.org.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- >> the suitable range for that is 0xe0000000-0xefffffff. that is not >> bigger enough, because need to preallocate 64M optional for 03:01.0 >> the cardbus. but that is optional. > > Maybe this is a stupid question, but is there any way of enlarging the > PCI hole? Sane BIOS should have one option to increase that. or it should probe MMIO range it need to allocate for pci devices and hotplug. then set TOP_OF_LOW_MEM. Yinghai ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 20:07 ` Yinghai Lu @ 2012-04-10 20:26 ` Steven Newbury 2012-04-10 20:45 ` Yinghai Lu 0 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-10 20:26 UTC (permalink / raw) To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci On Tue, 10 Apr 2012, 21:07:02 BST, Yinghai Lu <yinghai@kernel.org> wrote: > On Tue, Apr 10, 2012 at 12:46 PM, Steven Newbury <steve@snewbury.org.uk> > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > > the suitable range for that is 0xe0000000-0xefffffff. that is not > > > bigger enough, because need to preallocate 64M optional for 03:01.0 > > > the cardbus. but that is optional. > > > > Maybe this is a stupid question, but is there any way of enlarging the > > PCI hole? > > Sane BIOS should have one option to increase that. > > or it should probe MMIO range it need to allocate for pci devices and > hotplug. then set TOP_OF_LOW_MEM. > So far I'm concluding the BIOS isn't sane. Is it possible to define a custom memory map from the linux boot cmdline to set TOP_OF_LOW_MEM? Obviously, I'd prefer getting everything allocated into the address space available, and working, but if it comes down to it I'd accept a hack like the above if there's no other way. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 20:26 ` Steven Newbury @ 2012-04-10 20:45 ` Yinghai Lu 2012-04-10 21:19 ` Steven Newbury 2012-04-11 11:43 ` Steven Newbury 0 siblings, 2 replies; 94+ messages in thread From: Yinghai Lu @ 2012-04-10 20:45 UTC (permalink / raw) To: Steven Newbury; +Cc: Bjorn Helgaas, linux-pci [-- Attachment #1: Type: text/plain, Size: 637 bytes --] On Tue, Apr 10, 2012 at 1:26 PM, Steven Newbury <steve@snewbury.org.uk> wrote: >> > So far I'm concluding the BIOS isn't sane. Is it possible to define a custom memory map from the linux boot cmdline to set TOP_OF_LOW_MEM? The BIOS have MMIO and memory overlapping... > > Obviously, I'd prefer getting everything allocated into the address space available, and working, but if it comes down to it I'd accept a hack like the above if there's no other way. Could try to reduce carbus preallocated size.... boot with pci=cbmemsize=16M Please apply attached patch in addtition to allocate_high_at_first Thanks Yinghai [-- Attachment #2: request_optional_failed.patch --] [-- Type: application/octet-stream, Size: 847 bytes --] Subject: [PATCH] PCI: Should add children device res to fail list We can stop according to try number now. So do need that as stop sign. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/setup-bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -281,7 +281,7 @@ static void assign_requested_resources_s idx = pci_dev_resource_idx(dev_res->dev, res); if (resource_size(res) && pci_assign_resource(dev_res->dev, idx)) { - if (fail_head && !pci_is_root_bus(dev_res->dev->bus)) { + if (fail_head) { /* * if the failed res is for ROM BAR, and it will * be enabled later, don't add it to the list ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 20:45 ` Yinghai Lu @ 2012-04-10 21:19 ` Steven Newbury 2012-04-11 3:37 ` Bjorn Helgaas 2012-04-12 0:57 ` Yinghai Lu 2012-04-11 11:43 ` Steven Newbury 1 sibling, 2 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-10 21:19 UTC (permalink / raw) To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/12 21:45, Yinghai Lu wrote: > On Tue, Apr 10, 2012 at 1:26 PM, Steven Newbury > <steve@snewbury.org.uk> wrote: >>> >> So far I'm concluding the BIOS isn't sane. Is it possible to >> define a custom memory map from the linux boot cmdline to set >> TOP_OF_LOW_MEM? > > The BIOS have MMIO and memory overlapping... > >> Another thought, normally the integrated graphics has an "AGP" aperture of 256M @0xe0000000, which is detected by agpgart-intel, this will need to be moved up above 4G to free up 0xe0000000 for the radeon, assuming the "agp_bridge" has a 64bit base register... I noticed in my docked dmesg, "AGP aperture is 256M @ 0x20000000", but the PCI base: "120000000-12fffffff : 0000:00:02.0" so only 32bits have been set in agpgart-intel. Explains why i915 wasn't initialised. >> Obviously, I'd prefer getting everything allocated into the >> address space available, and working, but if it comes down to it >> I'd accept a hack like the above if there's no other way. > > Could try to reduce carbus preallocated size.... boot with > pci=cbmemsize=16M > > Please apply attached patch in addtition to allocate_high_at_first > I'll try first thing tomorrow. I'm away from the docking station now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Eo+wACgkQGcb56gMuC60FOgCgoB9QFZPFKCXs8gG0qJIX9NK3 CacAn1q9D958ql7K+nZrKLNHB86fsnHQ =vRtc -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 21:19 ` Steven Newbury @ 2012-04-11 3:37 ` Bjorn Helgaas 2012-04-11 5:33 ` Steven Newbury 2012-04-11 14:33 ` Steven Newbury 2012-04-12 0:57 ` Yinghai Lu 1 sibling, 2 replies; 94+ messages in thread From: Bjorn Helgaas @ 2012-04-11 3:37 UTC (permalink / raw) To: Steven Newbury; +Cc: Yinghai Lu, linux-pci On Tue, Apr 10, 2012 at 3:19 PM, Steven Newbury <steve@snewbury.org.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/04/12 21:45, Yinghai Lu wrote: >> On Tue, Apr 10, 2012 at 1:26 PM, Steven Newbury >> <steve@snewbury.org.uk> wrote: >>>> >>> So far I'm concluding the BIOS isn't sane. Is it possible to >>> define a custom memory map from the linux boot cmdline to set >>> TOP_OF_LOW_MEM? >> >> The BIOS have MMIO and memory overlapping... >> >>> > Another thought, normally the integrated graphics has an "AGP" > aperture of 256M @0xe0000000, which is detected by agpgart-intel, this > will need to be moved up above 4G to free up 0xe0000000 for the > radeon, assuming the "agp_bridge" has a 64bit base register... I > noticed in my docked dmesg, "AGP aperture is 256M @ 0x20000000", but > the PCI base: "120000000-12fffffff : 0000:00:02.0" so only 32bits have > been set in agpgart-intel. Explains why i915 wasn't initialised. > >>> Obviously, I'd prefer getting everything allocated into the >>> address space available, and working, but if it comes down to it >>> I'd accept a hack like the above if there's no other way. >> >> Could try to reduce carbus preallocated size.... boot with >> pci=cbmemsize=16M >> >> Please apply attached patch in addtition to allocate_high_at_first >> > I'll try first thing tomorrow. I'm away from the docking station now. Why are we messing around with resources above 4G? The host bridge _CRS reports no apertures above 4G, and you can't just try random things and hope they work. If the host bridge has a _PRS with settings above 4G that we could enable, that might be worthwhile. I haven't seen _PRS on a host bridge yet, and Linux would ignore it if it existed, but that would be a plausible approach. (Turn on CONFIG_PNP_DEBUG_MESSAGES and boot with pnp.debug=1 to see if you have any _PRS.) I think it would be helpful to break this down and look at one issue at a time, e.g., by removing the dock/undock hotplug issues. In https://bugzilla.kernel.org/show_bug.cgi?id=10461#c12, I think the problem you're seeing is that when you boot while docked, the integrated i915 works, but the radeon in the dock does not. That makes sense to me because they each want 256M of space, and according to your _CRS info, there's only one possible location with that much space (0xe0000000). Do you happen to know what Windows does in that situation? Does the radeon work and the i915 not, or does it somehow make both work? Is there any way you could collect the device info under Windows, using AIDA64 (http://www.aida64.com/) or similar? Bjorn ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-11 3:37 ` Bjorn Helgaas @ 2012-04-11 5:33 ` Steven Newbury 2012-04-11 9:03 ` Steven Newbury 2012-04-11 14:33 ` Steven Newbury 1 sibling, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-11 5:33 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: Yinghai Lu, linux-pci On Wed, 11 Apr 2012, 04:37:21 BST, Bjorn Helgaas <bhelgaas@google.com> wrote: > On Tue, Apr 10, 2012 at 3:19 PM, Steven Newbury <steve@snewbury.org.uk> > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 10/04/12 21:45, Yinghai Lu wrote: > > > On Tue, Apr 10, 2012 at 1:26 PM, Steven Newbury > > > <steve@snewbury.org.uk> wrote: > > > > > > > > > So far I'm concluding the BIOS isn't sane. Is it possible to > > > > define a custom memory map from the linux boot cmdline to set > > > > TOP_OF_LOW_MEM? > > > > > > The BIOS have MMIO and memory overlapping... > > > > > > > > > Another thought, normally the integrated graphics has an "AGP" > > aperture of 256M @0xe0000000, which is detected by agpgart-intel, this > > will need to be moved up above 4G to free up 0xe0000000 for the > > radeon, assuming the "agp_bridge" has a 64bit base register... I > > noticed in my docked dmesg, "AGP aperture is 256M @ 0x20000000", but > > the PCI base: "120000000-12fffffff : 0000:00:02.0" so only 32bits have > > been set in agpgart-intel. Explains why i915 wasn't initialised. > > > > > > Obviously, I'd prefer getting everything allocated into the > > > > address space available, and working, but if it comes down to it > > > > I'd accept a hack like the above if there's no other way. > > > > > > Could try to reduce carbus preallocated size.... boot with > > > pci=cbmemsize=16M > > > > > > Please apply attached patch in addtition to allocate_high_at_first > > > > > I'll try first thing tomorrow. I'm away from the docking station now. > > Why are we messing around with resources above 4G? The host bridge > _CRS reports no apertures above 4G, and you can't just try random > things and hope they work. > The BIOS doesn't always know best, there's no reason to think Dell put any effort into 64bit OS support, the only supported OS options were WinXP (32bit), and (new at the time) Vista (32bit), as such they tried to minimize the PCI hole so most of the maximum supported 4GB is available, but severely limiting MMIO space for additional devices. Reproducing what the BIOS should have done may be the only option. > If the host bridge has a _PRS with settings above 4G that we could > enable, that might be worthwhile. I haven't seen _PRS on a host > bridge yet, and Linux would ignore it if it existed, but that would be > a plausible approach. (Turn on CONFIG_PNP_DEBUG_MESSAGES and boot > with pnp.debug=1 to see if you have any _PRS.) > I will try this, but I'll be surprised if it has anything useful. > I think it would be helpful to break this down and look at one issue > at a time, e.g., by removing the dock/undock hotplug issues. The hotplug detection of the card devices doesn't work on mainline, only the bridge device shows up, but it does work with Yinghai's for-pci-busn-alloc branch, but resource allocation does not. No different to booting docked. > > In https://bugzilla.kernel.org/show_bug.cgi?id=10461#c12, I think the > problem you're seeing is that when you boot while docked, the > integrated i915 works, but the radeon in the dock does not. That > makes sense to me because they each want 256M of space, and according > to your _CRS info, there's only one possible location with that much > space (0xe0000000). Do you happen to know what Windows does in that That's why I'm hoping to be able to reallocate the i915 aperture above 4GB, but this depends on what the chipset is capable of rather than what the BIOS exposes. > situation? Does the radeon work and the i915 not, or does it somehow > make both work? Is there any way you could collect the device info > under Windows, using AIDA64 (http://www.aida64.com/) or similar? > >From reading Microsoft documents, they always try putting PCI resources above 4GB on 64bit Windows since Vista, even using bounce buffers where necessary, and supported by the hardware, only falling back below 4GB when all else fails. I only have the 32bit Windows Vista shipped with the laptop to test on, and in that case it just fails badly, BSOD if booting docked, or unable to allocate resources just like Linux on hotplug. Despite this, the reason I bought this card is a positive report from a Windows user of success, most VGA cards don't work in the d/dock, and I was hoping to experiment with prime. :) ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-11 5:33 ` Steven Newbury @ 2012-04-11 9:03 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-11 9:03 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: Yinghai Lu, linux-pci -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/12 06:33, Steven Newbury wrote: >> In https://bugzilla.kernel.org/show_bug.cgi?id=10461#c12, I think >> the problem you're seeing is that when you boot while docked, >> the integrated i915 works, but the radeon in the dock does not. >> That makes sense to me because they each want 256M of space, and >> according to your _CRS info, there's only one possible location >> with that much space (0xe0000000). Do you happen to know what >> Windows does in that > > That's why I'm hoping to be able to reallocate the i915 aperture > above 4GB, but this depends on what the chipset is capable of > rather than what the BIOS exposes. I've been reading the datasheets for the 965 chipset, and I've discovered a few things (from "Intel 965 Express Family Datasheet"): Section 3.2.3: "Voids of physical addresses that are not accessible as general system memory and reside within system memory address range (< TOLUD) are created for SMM-mode and legacy VGA graphics compatibility. It is the responsibility of BIOS to properly initialize these regions. Table 3-5 details the location and attributes of the regions. Enabling/Disabling these ranges are described in the (G)MCH Control register (GCC register, device 0, offset 52h)." BIOS must initialise legacy regions < TOLUD (top of low usable DRAM), it doesn't mention any other strict requirements on memory mappings, but TOLUD itself, I would assume, is implicitly required to be configured by the BIOS for everything else to fall into place. ... Section 3.4 describes the memory reclaim configuration, which enables remapping of the range of physical memory overlapped by: • High BIOS • HSEG • TSEG • Graphics stolen • XAPIC • Local APIC • FSB Interrupts • Mbase/Mlimit • Memory-mapped I/O space that supports only 32B addressing It isn't specifically mentioned whether this is reconfigurable, but I remember reading in a Microsoft document that Windows since 64 bit Vista can freeze PCI devices and reassign PCI window ranges on device hot-plug. I'm not sure whether this comes into play, probably not... ... Section 3.7 is *particularly* interesting to me: Graphics Memory Address Ranges "These ranges can reside above the Top-of-Low-DRAM and below High BIOS and APIC address ranges or above Top of upper DRAM (TOUUD). They MUST reside above the top of memory (TOLUD) and below 4 GB _or_above_TOUUD_ so they do not steal any physical DRAM memory space." According to this section there's no reason the Graphics Aperture Base can not be above TOUUD. ... I guess I should read the PCIe specifications; I have read references to the claim the specifications were developed around Microsoft's requirements in their implementation since Longhorn (Vista), specifically removing the 4GB limit (where compatible) when used with 64 bit OSs. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+FSOYACgkQGcb56gMuC63bugCbBZXxiXzNtrC0/qpHyRd6Wwts Q+cAoLVDTezwPjTLuEpLDUO6ppGEOPI7 =x+g9 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-11 3:37 ` Bjorn Helgaas 2012-04-11 5:33 ` Steven Newbury @ 2012-04-11 14:33 ` Steven Newbury 2012-04-11 23:59 ` Bjorn Helgaas 1 sibling, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-11 14:33 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: Yinghai Lu, linux-pci [-- Attachment #1: Type: text/plain, Size: 2699 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/12 04:37, Bjorn Helgaas wrote: > On Tue, Apr 10, 2012 at 3:19 PM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 10/04/12 21:45, Yinghai Lu wrote: >>> On Tue, Apr 10, 2012 at 1:26 PM, Steven Newbury >>> <steve@snewbury.org.uk> wrote: >>>>> >>>> So far I'm concluding the BIOS isn't sane. Is it possible >>>> to define a custom memory map from the linux boot cmdline to >>>> set TOP_OF_LOW_MEM? >>> >>> The BIOS have MMIO and memory overlapping... >>> >>>> >> Another thought, normally the integrated graphics has an "AGP" >> aperture of 256M @0xe0000000, which is detected by agpgart-intel, >> this will need to be moved up above 4G to free up 0xe0000000 for >> the radeon, assuming the "agp_bridge" has a 64bit base >> register... I noticed in my docked dmesg, "AGP aperture is 256M >> @ 0x20000000", but the PCI base: "120000000-12fffffff : >> 0000:00:02.0" so only 32bits have been set in agpgart-intel. >> Explains why i915 wasn't initialised. >> >>>> Obviously, I'd prefer getting everything allocated into the >>>> address space available, and working, but if it comes down to >>>> it I'd accept a hack like the above if there's no other way. >>> >>> Could try to reduce carbus preallocated size.... boot with >>> pci=cbmemsize=16M >>> >>> Please apply attached patch in addtition to >>> allocate_high_at_first >>> >> I'll try first thing tomorrow. I'm away from the docking station >> now. > > Why are we messing around with resources above 4G? The host > bridge _CRS reports no apertures above 4G, and you can't just try > random things and hope they work. > > If the host bridge has a _PRS with settings above 4G that we could > enable, that might be worthwhile. I haven't seen _PRS on a host > bridge yet, and Linux would ignore it if it existed, but that would > be a plausible approach. (Turn on CONFIG_PNP_DEBUG_MESSAGES and > boot with pnp.debug=1 to see if you have any _PRS.) Attached dmesg with pnp.debug=1, also includes working radeon with cardbus disabled in BIOS. I haven't managed to get it working yet with cardbus enabled. I think it's probably because the cardbus controller ends up @0xe0000000, which prevents the Radeon 256M resource meeting its alignment constraints. The intel-agp driver needs to be patched to support >4G aperture location as mentioned previously. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+FlkYACgkQGcb56gMuC62suACeLpKC7uTs+gcldUgjNuLq0Eq6 fR8AoJcP86wMFbFjSN67pWtDwPKyn+kk =ejgL -----END PGP SIGNATURE----- [-- Attachment #2: dmesg.pnpdebug.radeon --] [-- Type: text/plain, Size: 85613 bytes --] Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.4.0-rc2-wl-00220-g2597a48 (root@infinity) (gcc version 4.6.2 (Gentoo 4.6.2 p1.4, pie-0.5.0) ) #89 SMP Wed Apr 11 14:47:59 BST 2012 Command line: BOOT_IMAGE=/vmlinuz-3.4.0-rc2-wl-00220-g2597a48 root=UUID=d761a2db-f951-4e9c-bed4-cf2381bb1af4 ro rootflags=subvol=ROOT real_init=/bin/systemd real_root=LABEL=GENTOO real_rootflags=subvol=ROOT,compress=lzo,inode_cache,space_cache,ssd pcie_aspm=force i915.modeset=1 i915.lvds_downclock=1 i915.lvds_use_ssc=1 i915.powersave=1 i915.i915_enable_fbc=1 i915.i915_enable_rc6=1 ioapicreroute pci=realloc resume=UUID=ae0f88ec-9e17-41f2-b8b3-685cce36e496 pci=nocrs pci=cbmemsize=16M pnp.debug=1 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f000 (usable) BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) BIOS-e820: 0000000000100000 - 00000000df65a800 (usable) BIOS-e820: 00000000df65a800 - 00000000e0000000 (reserved) BIOS-e820: 00000000f8000000 - 00000000fc000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fed18000 - 00000000fed1c000 (reserved) BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved) BIOS-e820: 00000000feda0000 - 00000000feda6000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved) BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000120000000 (usable) NX (Execute Disable) protection: active DMI 2.4 present. DMI: Dell Inc. Latitude D830 /0HN341, BIOS A16 12/22/2011 e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) e820 remove range: 00000000000a0000 - 0000000000100000 (usable) No AGP bridge found last_pfn = 0x120000 max_arch_pfn = 0x400000000 MTRR default type: uncachable MTRR fixed ranges enabled: 00000-9FFFF write-back A0000-BFFFF uncachable C0000-CFFFF write-protect D0000-EFFFF uncachable F0000-FFFFF write-protect MTRR variable ranges enabled: 0 base 000000000 mask F80000000 write-back 1 base 080000000 mask FC0000000 write-back 2 base 0C0000000 mask FE0000000 write-back 3 base 100000000 mask FE0000000 write-back 4 base 0DF800000 mask FFF800000 uncachable 5 base 0DF700000 mask FFFF00000 uncachable 6 disabled 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 original variable MTRRs reg 0, base: 0GB, range: 2GB, type WB reg 1, base: 2GB, range: 1GB, type WB reg 2, base: 3GB, range: 512MB, type WB reg 3, base: 4GB, range: 512MB, type WB reg 4, base: 3576MB, range: 8MB, type UC reg 5, base: 3575MB, range: 1MB, type UC total RAM covered: 4087M Found optimal setting for mtrr clean up gran_size: 64K chunk_size: 1G num_reg: 5 lose cover RAM: 0G New variable MTRRs reg 0, base: 0GB, range: 4GB, type WB reg 1, base: 3575MB, range: 1MB, type UC reg 2, base: 3576MB, range: 8MB, type UC reg 3, base: 3584MB, range: 512MB, type UC reg 4, base: 4GB, range: 512MB, type WB e820 update range: 00000000df700000 - 0000000100000000 (usable) ==> (reserved) last_pfn = 0xdf65a max_arch_pfn = 0x400000000 initial memory mapped : 0 - 20000000 Base memory trampoline at [ffff88000009a000] 9a000 size 20480 init_memory_mapping: 0000000000000000-00000000df65a000 0000000000 - 00df600000 page 2M 00df600000 - 00df65a000 page 4k kernel direct mapping tables up to df65a000 @ 1fffa000-20000000 init_memory_mapping: 0000000100000000-0000000120000000 0100000000 - 0120000000 page 2M kernel direct mapping tables up to 120000000 @ df654000-df65a000 RAMDISK: 3755e000 - 37aa7000 ACPI: RSDP 00000000000fbb10 00024 (v02 DELL ) ACPI: XSDT 00000000df65d200 0006C (v01 DELL M08 27DB0C16 ASL 00000061) ACPI: FACP 00000000df65d09c 000F4 (v04 DELL M08 27DB0C16 ASL 00000061) ACPI: DSDT 00000000df65d800 063B2 (v02 INT430 SYSFexxx 00001001 INTL 20050624) ACPI: FACS 00000000df66c000 00040 ACPI: HPET 00000000df65d300 00038 (v01 DELL M08 00000001 ASL 00000061) ACPI: APIC 00000000df65d400 00068 (v01 DELL M08 27DB0C16 ASL 00000047) ACPI: ASF! 00000000df65d000 0007E (v32 DELL M08 27DB0C16 ASL 00000061) ACPI: MCFG 00000000df65d3c0 0003E (v16 DELL M08 27DB0C16 ASL 00000061) ACPI: TCPA 00000000df65d700 00032 (v01 00000000 ASL 00000000) ACPI: SLIC 00000000df65d49c 00176 (v01 DELL M08 27DB0C16 ASL 00000061) ACPI: BOOT 00000000df65cfc0 00028 (v01 DELL M08 27DB0C16 ASL 00000061) ACPI: SSDT 00000000df65b982 004CC (v01 PmRef CpuPm 00003000 INTL 20050624) ACPI: Local APIC address 0xfee00000 [ffffea0000000000-ffffea00047fffff] PMD -> [ffff88011b600000-ffff88011f5fffff] on node 0 Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x00120000 Movable zone start PFN for each node Early memory PFN ranges 0: 0x00000010 -> 0x0000009f 0: 0x00000100 -> 0x000df65a 0: 0x00100000 -> 0x00120000 On node 0 totalpages: 1045993 DMA zone: 64 pages used for memmap DMA zone: 5 pages reserved DMA zone: 3914 pages, LIFO batch:0 DMA32 zone: 16320 pages used for memmap DMA32 zone: 894618 pages, LIFO batch:31 Normal zone: 2048 pages used for memmap Normal zone: 129024 pages, LIFO batch:31 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 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) 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: 0x8086a201 base: 0xfed00000 SMP: Allowing 2 CPUs, 0 hotplug CPUs nr_irqs_gsi: 40 PM: Registered nosave memory: 000000000009f000 - 00000000000a0000 PM: Registered nosave memory: 00000000000a0000 - 0000000000100000 PM: Registered nosave memory: 00000000df65a000 - 00000000df65b000 PM: Registered nosave memory: 00000000df65b000 - 00000000e0000000 PM: Registered nosave memory: 00000000e0000000 - 00000000f8000000 PM: Registered nosave memory: 00000000f8000000 - 00000000fc000000 PM: Registered nosave memory: 00000000fc000000 - 00000000fec00000 PM: Registered nosave memory: 00000000fec00000 - 00000000fec10000 PM: Registered nosave memory: 00000000fec10000 - 00000000fed18000 PM: Registered nosave memory: 00000000fed18000 - 00000000fed1c000 PM: Registered nosave memory: 00000000fed1c000 - 00000000fed20000 PM: Registered nosave memory: 00000000fed20000 - 00000000fed90000 PM: Registered nosave memory: 00000000fed90000 - 00000000feda0000 PM: Registered nosave memory: 00000000feda0000 - 00000000feda6000 PM: Registered nosave memory: 00000000feda6000 - 00000000fee00000 PM: Registered nosave memory: 00000000fee00000 - 00000000fee10000 PM: Registered nosave memory: 00000000fee10000 - 00000000ffe00000 PM: Registered nosave memory: 00000000ffe00000 - 0000000100000000 Allocating PCI resources starting at e0000000 (gap: e0000000:18000000) setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88011fc00000 s76608 r8192 d21696 u1048576 pcpu-alloc: s76608 r8192 d21696 u1048576 alloc=1*2097152 pcpu-alloc: [0] 0 1 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1027556 Kernel command line: BOOT_IMAGE=/vmlinuz-3.4.0-rc2-wl-00220-g2597a48 root=UUID=d761a2db-f951-4e9c-bed4-cf2381bb1af4 ro rootflags=subvol=ROOT real_init=/bin/systemd real_root=LABEL=GENTOO real_rootflags=subvol=ROOT,compress=lzo,inode_cache,space_cache,ssd pcie_aspm=force i915.modeset=1 i915.lvds_downclock=1 i915.lvds_use_ssc=1 i915.powersave=1 i915.i915_enable_fbc=1 i915.i915_enable_rc6=1 ioapicreroute pci=realloc resume=UUID=ae0f88ec-9e17-41f2-b8b3-685cce36e496 pci=nocrs pci=cbmemsize=16M pnp.debug=1 PCIe ASPM is forcibly enabled PID hash table entries: 4096 (order: 3, 32768 bytes) Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking aperture... No AGP bridge found Memory: 4032092k/4718592k available (3506k kernel code, 534620k absent, 151880k reserved, 3218k data, 612k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Hierarchical RCU implementation. RCU dyntick-idle grace-period acceleration is enabled. NR_IRQS:4352 nr_irqs:512 16 Extended CMOS year: 2000 Console: colour VGA+ 80x25 console [tty0] enabled allocated 16777216 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups hpet clockevent registered Fast TSC calibration using PIT Detected 2394.014 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 4788.02 BogoMIPS (lpj=2394014) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 256 Initializing cgroup subsys debug Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio Initializing cgroup subsys perf_event CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 6 MCE banks CPU0: Thermal monitoring enabled (TM2) using mwait in idle threads. ACPI: Core revision 20120320 ftrace: allocating 16999 entries in 67 pages ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 CPU0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz stepping 0b Performance Events: PEBS fmt0+, 4-deep LBR, Core2 events, Intel PMU driver. PEBS disabled due to CPU errata. ... version: 2 ... bit width: 40 ... generic registers: 2 ... value mask: 000000ffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 0000000700000003 Testing tracer nop: PASSED Booting Node 0, Processors #1 Ok. Brought up 2 CPUs ---------------- | NMI testsuite: -------------------- remote IPI: ok | local IPI: ok | -------------------- Good, all 2 testcases passed! | --------------------------------- Total of 2 processors activated (9576.05 BogoMIPS). devtmpfs: initialized atomic64 test passed for x86-64 platform with CX8 and with SSE dummy: NET: Registered protocol family 16 ACPI: bus type pci registered dca service started, version 1.12.1 PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820 PCI: Using configuration type 1 for base access dmi type 0xB1 record - unknown flag bio: create slab <bio-0> at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: EC: Look up EC in DSDT [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored ACPI: SSDT 00000000df66c080 00043 (v01 LMPWR DELLLOM 00001001 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 00043 (v01 LMPWR DELLLOM 00001001 INTL 20050624) ACPI: SSDT 00000000df65c4b8 002C8 (v01 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 002C8 (v01 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: SSDT 00000000df65be4e 005E5 (v01 PmRef Cpu0Cst 00003001 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 005E5 (v01 PmRef Cpu0Cst 00003001 INTL 20050624) ACPI: SSDT 00000000df65c780 000C4 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 000C4 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: SSDT 00000000df65c433 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: ACPI Dock Station Driver: 3 docks/bays found PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored) pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xe0000000-0xf7ffffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfc000000-0xfebfffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfec10000-0xfecfffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfed1c000-0xfed1ffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfed90000-0xfed9ffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfed40000-0xfed44fff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfeda7000-0xfedfffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xfee10000-0xff9fffff] (ignored) pci_root PNP0A03:00: host bridge window [mem 0xffc00000-0xffdfffff] (ignored) PCI: root bus 00: using default resources PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0000-0xffff] pci_bus 0000:00: root bus resource [mem 0x00000000-0xfffffffff] pci_bus 0000:00: busn_res: [bus 00-ff] for root bus pci_bus 0000:00: root bus resource [bus 00-ff] pci_bus 0000:00: scanning bus pass 0 pci 0000:00:00.0: [8086:2a00] type 00 class 0x060000 pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0xa pci 0000:00:02.0: [8086:2a02] type 00 class 0x030000 pci 0000:00:02.0: reg 10: [mem 0xf6e00000-0xf6efffff 64bit] pci 0000:00:02.0: reg 18: [mem 0xc0000000-0xcfffffff 64bit pref] pci 0000:00:02.0: reg 20: [io 0xeff8-0xefff] pci 0000:00:02.1: [8086:2a03] type 00 class 0x038000 pci 0000:00:02.1: reg 10: [mem 0xf6f00000-0xf6ffffff 64bit] pci 0000:00:1a.0: [8086:2834] type 00 class 0x0c0300 pci 0000:00:1a.0: reg 20: [io 0x6f20-0x6f3f] pci 0000:00:1a.1: [8086:2835] type 00 class 0x0c0300 pci 0000:00:1a.1: reg 20: [io 0x6f00-0x6f1f] pci 0000:00:1a.7: [8086:283a] type 00 class 0x0c0320 pci 0000:00:1a.7: reg 10: [mem 0xfed1c400-0xfed1c7ff] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold pci 0000:00:1a.7: PME# disabled pci 0000:00:1b.0: [8086:284b] type 00 class 0x040300 pci 0000:00:1b.0: reg 10: [mem 0xf6dfc000-0xf6dfffff 64bit] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold pci 0000:00:1b.0: PME# disabled pci 0000:00:1c.0: [8086:283f] type 01 class 0x060400 pci 0000:00:1c.0: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold pci 0000:00:1c.0: PME# disabled pci 0000:00:1c.1: [8086:2841] type 01 class 0x060400 pci 0000:00:1c.1: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold pci 0000:00:1c.1: PME# disabled pci 0000:00:1c.3: [8086:2845] type 01 class 0x060400 pci 0000:00:1c.3: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold pci 0000:00:1c.3: PME# disabled pci 0000:00:1c.5: [8086:2849] type 01 class 0x060400 pci 0000:00:1c.5: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold pci 0000:00:1c.5: PME# disabled pci 0000:00:1d.0: [8086:2830] type 00 class 0x0c0300 pci 0000:00:1d.0: reg 20: [io 0x6f80-0x6f9f] pci 0000:00:1d.1: [8086:2831] type 00 class 0x0c0300 pci 0000:00:1d.1: reg 20: [io 0x6f60-0x6f7f] pci 0000:00:1d.2: [8086:2832] type 00 class 0x0c0300 pci 0000:00:1d.2: reg 20: [io 0x6f40-0x6f5f] pci 0000:00:1d.7: [8086:2836] type 00 class 0x0c0320 pci 0000:00:1d.7: reg 10: [mem 0xfed1c000-0xfed1c3ff] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold pci 0000:00:1d.7: PME# disabled pci 0000:00:1e.0: [8086:2448] type 01 class 0x060401 pci 0000:00:1e.0: calling pci_fixup_transparent_bridge+0x0/0x1d pci 0000:00:1f.0: [8086:2815] type 00 class 0x060100 pci 0000:00:1f.0: calling ich_force_enable_hpet+0x0/0x16f pci 0000:00:1f.0: calling quirk_ich7_lpc+0x0/0x62 pci 0000:00:1f.0: quirk: [io 0x1000-0x107f] claimed by ICH6 ACPI/GPIO/TCO pci 0000:00:1f.0: quirk: [io 0x1080-0x10bf] claimed by ICH6 GPIO pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0900 (mask 007f) pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0c80 (mask 003f) pci 0000:00:1f.1: [8086:2850] type 00 class 0x01018a pci 0000:00:1f.1: reg 10: [io 0x01f0-0x01f7] pci 0000:00:1f.1: reg 14: [io 0x03f4-0x03f7] pci 0000:00:1f.1: reg 18: [io 0x0170-0x0177] pci 0000:00:1f.1: reg 1c: [io 0x0374-0x0377] pci 0000:00:1f.1: reg 20: [io 0x6fa0-0x6faf] pci 0000:00:1f.2: [8086:2829] type 00 class 0x010601 pci 0000:00:1f.2: reg 10: [io 0x6eb0-0x6eb7] pci 0000:00:1f.2: reg 14: [io 0x6eb8-0x6ebb] pci 0000:00:1f.2: reg 18: [io 0x6ec0-0x6ec7] pci 0000:00:1f.2: reg 1c: [io 0x6ec8-0x6ecb] pci 0000:00:1f.2: reg 20: [io 0x6ee0-0x6eff] pci 0000:00:1f.2: reg 24: [mem 0xf6dfb800-0xf6dfbfff] pci 0000:00:1f.2: PME# supported from D3hot pci 0000:00:1f.2: PME# disabled pci 0000:00:1f.3: [8086:283e] type 00 class 0x0c0500 pci 0000:00:1f.3: reg 10: [mem 0xf6dfb700-0xf6dfb7ff] pci 0000:00:1f.3: reg 20: [io 0x10c0-0x10df] pci_bus 0000:00: fixups for bus pass 0 pci 0000:00:1c.0: scanning [bus 0b-0b] behind bridge, pass 0 pci 0000:00:1c.0: check if busn 0b-0b is in busn_res: [bus 00-ff] pci_bus 0000:0b: busn_res: [bus 0b] is inserted under [bus 00-ff] pci_bus 0000:0b: scanning bus pass 0 pci_bus 0000:0b: fixups for bus pass 0 pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] pci_bus 0000:0b: bus scan returning with max=0b pass 0 pci 0000:00:1c.1: scanning [bus 0c-0c] behind bridge, pass 0 pci 0000:00:1c.1: check if busn 0c-0c is in busn_res: [bus 00-ff] pci_bus 0000:0c: busn_res: [bus 0c] is inserted under [bus 00-ff] pci_bus 0000:0c: scanning bus pass 0 pci 0000:0c:00.0: [8086:4229] type 00 class 0x028000 pci 0000:0c:00.0: reg 10: [mem 0xf6cfe000-0xf6cfffff 64bit] pci 0000:0c:00.0: PME# supported from D0 D3hot D3cold pci 0000:0c:00.0: PME# disabled pci_bus 0000:0c: fixups for bus pass 0 pci 0000:00:1c.1: PCI bridge to [bus 0c-0c] pci 0000:00:1c.1: bridge window [mem 0xf6c00000-0xf6cfffff] pci_bus 0000:0c: bus scan returning with max=0c pass 0 pci 0000:00:1c.3: scanning [bus 0d-0e] behind bridge, pass 0 pci 0000:00:1c.3: check if busn 0d-0e is in busn_res: [bus 00-ff] pci_bus 0000:0d: busn_res: [bus 0d-0e] is inserted under [bus 00-ff] pci_bus 0000:0d: scanning bus pass 0 pci_bus 0000:0d: fixups for bus pass 0 pci 0000:00:1c.3: PCI bridge to [bus 0d-0e] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] pci 0000:00:1c.3: bridge window [mem 0xf6a00000-0xf6bfffff] pci 0000:00:1c.3: bridge window [mem 0xd0000000-0xd01fffff 64bit pref] pci_bus 0000:0d: bus scan returning with max=0d pass 0 pci 0000:00:1c.5: scanning [bus 09-09] behind bridge, pass 0 pci 0000:00:1c.5: check if busn 09-09 is in busn_res: [bus 00-ff] pci_bus 0000:09: busn_res: [bus 09] is inserted under [bus 00-ff] pci_bus 0000:09: scanning bus pass 0 pci 0000:09:00.0: [14e4:1673] type 00 class 0x020000 pci 0000:09:00.0: reg 10: [mem 0xf69f0000-0xf69fffff 64bit] pci 0000:09:00.0: PME# supported from D3hot D3cold pci 0000:09:00.0: PME# disabled pci_bus 0000:09: fixups for bus pass 0 pci 0000:00:1c.5: PCI bridge to [bus 09-09] pci 0000:00:1c.5: bridge window [mem 0xf6900000-0xf69fffff] pci_bus 0000:09: bus scan returning with max=09 pass 0 pci 0000:00:1e.0: scanning [bus 03-04] behind bridge, pass 0 pci 0000:00:1e.0: check if busn 03-04 is in busn_res: [bus 00-ff] pci_bus 0000:03: busn_res: [bus 03-04] is inserted under [bus 00-ff] pci_bus 0000:03: scanning bus pass 0 pci 0000:03:08.0: [10b5:8112] type 01 class 0x060400 pci 0000:03:08.0: supports D1 pci 0000:03:08.0: PME# supported from D0 D1 D3hot pci 0000:03:08.0: PME# disabled pci_bus 0000:03: fixups for bus pass 0 pci 0000:00:1e.0: PCI bridge to [bus 03-04] (subtractive decode) pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] pci 0000:00:1e.0: bridge window [mem 0xf6700000-0xf68fffff] pci 0000:00:1e.0: bridge window [mem 0xd0200000-0xefffffff 64bit pref] pci 0000:00:1e.0: bridge window [io 0x0000-0xffff] (subtractive decode) pci 0000:00:1e.0: bridge window [mem 0x00000000-0xfffffffff] (subtractive decode) pci 0000:03:08.0: scanning [bus 04-04] behind bridge, pass 0 pci 0000:03:08.0: check if busn 04-04 is in busn_res: [bus 03-04] pci_bus 0000:04: busn_res: [bus 04] is inserted under [bus 03-04] pci_bus 0000:04: scanning bus pass 0 pci 0000:04:00.0: [1002:68e1] type 00 class 0x030000 pci 0000:04:00.0: reg 10: [mem 0xe0000000-0xefffffff 64bit pref] pci 0000:04:00.0: reg 18: [mem 0xf67e0000-0xf67fffff 64bit] pci 0000:04:00.0: reg 20: [io 0xce00-0xceff] pci 0000:04:00.0: reg 30: [mem 0xf6800000-0xf681ffff pref] pci 0000:04:00.0: supports D1 D2 pci 0000:04:00.1: [1002:aa68] type 00 class 0x040300 pci 0000:04:00.1: reg 10: [mem 0xf67dc000-0xf67dffff 64bit] pci 0000:04:00.1: supports D1 D2 pci_bus 0000:04: fixups for bus pass 0 pci 0000:03:08.0: PCI bridge to [bus 04-04] pci 0000:03:08.0: bridge window [io 0xc000-0xcfff] pci 0000:03:08.0: bridge window [mem 0xf6700000-0xf68fffff] pci 0000:03:08.0: bridge window [mem 0xd0200000-0xefffffff pref] pci_bus 0000:04: bus scan returning with max=04 pass 0 pci_bus 0000:03: bus scan returning with max=04 pass 0 pci_bus 0000:00: bus scan returning with max=0e pass 0 pci_bus 0000:00: scanning bus pass 1 pci 0000:00:1c.0: scanning [bus 0b-0b] behind bridge, pass 1 pci_bus 0000:0b: scanning bus pass 1 pci_bus 0000:0b: fixups for bus pass 1 pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] pci_bus 0000:0b: bus scan returning with max=0b pass 1 pci 0000:00:1c.1: scanning [bus 0c-0c] behind bridge, pass 1 pci_bus 0000:0c: scanning bus pass 1 pci_bus 0000:0c: fixups for bus pass 1 pci 0000:00:1c.1: PCI bridge to [bus 0c-0c] pci 0000:00:1c.1: bridge window [mem 0xf6c00000-0xf6cfffff] pci_bus 0000:0c: bus scan returning with max=0c pass 1 pci 0000:00:1c.3: scanning [bus 0d-0e] behind bridge, pass 1 pci_bus 0000:0d: scanning bus pass 1 pci_bus 0000:0d: fixups for bus pass 1 pci 0000:00:1c.3: PCI bridge to [bus 0d-0e] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] pci 0000:00:1c.3: bridge window [mem 0xf6a00000-0xf6bfffff] pci 0000:00:1c.3: bridge window [mem 0xd0000000-0xd01fffff 64bit pref] pci_bus 0000:0d: bus scan returning with max=0d pass 1 pci 0000:00:1c.5: scanning [bus 09-09] behind bridge, pass 1 pci_bus 0000:09: scanning bus pass 1 pci_bus 0000:09: fixups for bus pass 1 pci 0000:00:1c.5: PCI bridge to [bus 09-09] pci 0000:00:1c.5: bridge window [mem 0xf6900000-0xf69fffff] pci_bus 0000:09: bus scan returning with max=09 pass 1 pci 0000:00:1e.0: scanning [bus 03-04] behind bridge, pass 1 pci_bus 0000:03: scanning bus pass 1 pci_bus 0000:03: fixups for bus pass 1 pci 0000:00:1e.0: PCI bridge to [bus 03-04] (subtractive decode) pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] pci 0000:00:1e.0: bridge window [mem 0xf6700000-0xf68fffff] pci 0000:00:1e.0: bridge window [mem 0xd0200000-0xefffffff 64bit pref] pci 0000:00:1e.0: bridge window [io 0x0000-0xffff] (subtractive decode) pci 0000:00:1e.0: bridge window [mem 0x00000000-0xfffffffff] (subtractive decode) pci 0000:03:08.0: scanning [bus 04-04] behind bridge, pass 1 pci_bus 0000:04: scanning bus pass 1 pci_bus 0000:04: fixups for bus pass 1 pci 0000:03:08.0: PCI bridge to [bus 04-04] pci 0000:03:08.0: bridge window [io 0xc000-0xcfff] pci 0000:03:08.0: bridge window [mem 0xf6700000-0xf68fffff] pci 0000:03:08.0: bridge window [mem 0xd0200000-0xefffffff pref] pci_bus 0000:04: bus scan returning with max=04 pass 1 pci_bus 0000:03: bus scan returning with max=04 pass 1 pci_bus 0000:00: bus scan returning with max=0e pass 1 pci_bus 0000:00: on NUMA node 0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP04._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP06._PRT] pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d ACPI _OSC control for PCIe not granted, disabling ASPM ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *3 ACPI: PCI Interrupt Link [LNKC] (IRQs 9 *10 11) ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: device added: PCI:0000:04:00.0,decodes=io+mem,owns=none,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:04:00.0 vgaarb: no bridge control possible 0000:00:02.0 PCI: Using ACPI for IRQ routing PCI: pci_cache_line_size set to 64 bytes pci 0000:00:1c.3: address space collision: [mem 0xd0000000-0xd01fffff 64bit pref] conflicts with System RAM [mem 0x00100000-0xdf65a7ff] pci 0000:00:1e.0: address space collision: [mem 0xd0200000-0xefffffff 64bit pref] conflicts with System RAM [mem 0x00100000-0xdf65a7ff] pci 0000:03:08.0: address space collision: [mem 0xd0200000-0xefffffff pref] conflicts with System RAM [mem 0x00100000-0xdf65a7ff] pci 0000:00:02.0: BAR 0: reserving [mem 0xf6e00000-0xf6efffff flags 0x140204] (d=0, p=0) pci 0000:00:02.0: BAR 2: reserving [mem 0xc0000000-0xcfffffff flags 0x14220c] (d=0, p=0) pci 0000:00:02.0: address space collision: [mem 0xc0000000-0xcfffffff 64bit pref] conflicts with System RAM [mem 0x00100000-0xdf65a7ff] pci 0000:00:02.0: BAR 4: reserving [io 0xeff8-0xefff flags 0x40101] (d=0, p=0) pci 0000:00:02.1: BAR 0: reserving [mem 0xf6f00000-0xf6ffffff flags 0x140204] (d=0, p=0) pci 0000:00:1a.0: BAR 4: reserving [io 0x6f20-0x6f3f flags 0x40101] (d=0, p=0) pci 0000:00:1a.1: BAR 4: reserving [io 0x6f00-0x6f1f flags 0x40101] (d=0, p=0) pci 0000:00:1a.7: BAR 0: reserving [mem 0xfed1c400-0xfed1c7ff flags 0x40200] (d=0, p=0) pci 0000:00:1b.0: BAR 0: reserving [mem 0xf6dfc000-0xf6dfffff flags 0x140204] (d=0, p=0) pci 0000:00:1d.0: BAR 4: reserving [io 0x6f80-0x6f9f flags 0x40101] (d=0, p=0) pci 0000:00:1d.1: BAR 4: reserving [io 0x6f60-0x6f7f flags 0x40101] (d=0, p=0) pci 0000:00:1d.2: BAR 4: reserving [io 0x6f40-0x6f5f flags 0x40101] (d=0, p=0) pci 0000:00:1d.7: BAR 0: reserving [mem 0xfed1c000-0xfed1c3ff flags 0x40200] (d=0, p=0) pci 0000:00:1f.1: BAR 0: reserving [io 0x01f0-0x01f7 flags 0x110] (d=0, p=0) pci 0000:00:1f.1: BAR 1: reserving [io 0x03f6 flags 0x110] (d=0, p=0) pci 0000:00:1f.1: BAR 2: reserving [io 0x0170-0x0177 flags 0x110] (d=0, p=0) pci 0000:00:1f.1: BAR 3: reserving [io 0x0376 flags 0x110] (d=0, p=0) pci 0000:00:1f.1: BAR 4: reserving [io 0x6fa0-0x6faf flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 0: reserving [io 0x6eb0-0x6eb7 flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 1: reserving [io 0x6eb8-0x6ebb flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 2: reserving [io 0x6ec0-0x6ec7 flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 3: reserving [io 0x6ec8-0x6ecb flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 4: reserving [io 0x6ee0-0x6eff flags 0x40101] (d=0, p=0) pci 0000:00:1f.2: BAR 5: reserving [mem 0xf6dfb800-0xf6dfbfff flags 0x40200] (d=0, p=0) pci 0000:00:1f.3: BAR 0: reserving [mem 0xf6dfb700-0xf6dfb7ff flags 0x40200] (d=0, p=0) pci 0000:00:1f.3: BAR 4: reserving [io 0x10c0-0x10df flags 0x40101] (d=0, p=0) pci 0000:0c:00.0: BAR 0: reserving [mem 0xf6cfe000-0xf6cfffff flags 0x140204] (d=0, p=0) pci 0000:09:00.0: BAR 0: reserving [mem 0xf69f0000-0xf69fffff flags 0x140204] (d=0, p=0) pci 0000:04:00.1: BAR 0: reserving [mem 0xf67dc000-0xf67dffff flags 0x140204] (d=0, p=0) pci 0000:04:00.0: BAR 0: reserving [mem 0xe0000000-0xefffffff flags 0x14220c] (d=1, p=1) pci 0000:04:00.0: no compatible bridge window for [mem 0xe0000000-0xefffffff 64bit pref] pci 0000:04:00.0: BAR 2: reserving [mem 0xf67e0000-0xf67fffff flags 0x140204] (d=1, p=1) pci 0000:04:00.0: BAR 4: reserving [io 0xce00-0xceff flags 0x40101] (d=1, p=1) reserve RAM buffer: 000000000009f000 - 000000000009ffff reserve RAM buffer: 00000000df65a800 - 00000000dfffffff HPET: 3 timers in total, 0 timers will be used for per-cpu timer hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 hpet0: 3 comparators, 64-bit 14.318180 MHz counter Switching to clocksource hpet pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:00: parse allocated resources pnp 00:00: [bus 00-ff] pnp 00:00: [io 0x0000-0x0cf7 window] pnp 00:00: [io 0x0cf8-0x0cff] pnp 00:00: [io 0x0d00-0xffff window] pnp 00:00: [mem 0x000a0000-0x000bffff window] pnp 00:00: [mem 0x000d0000-0x000dffff window] pnp 00:00: [mem 0xe0000000-0xf7ffffff window] pnp 00:00: [mem 0xfc000000-0xfebfffff window] pnp 00:00: [mem 0xfec10000-0xfecfffff window] pnp 00:00: [mem 0xfed1c000-0xfed1ffff window] pnp 00:00: [mem 0xfed90000-0xfed9ffff window] pnp 00:00: [mem 0xfed40000-0xfed44fff window] pnp 00:00: [mem 0xfeda7000-0xfedfffff window] pnp 00:00: [mem 0xfee10000-0xff9fffff window] pnp 00:00: [mem 0xffc00000-0xffdfffff window] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active) pnp 00:01: parse allocated resources pnp 00:01: [irq 12] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active) pnp 00:02: parse allocated resources pnp 00:02: [io 0x0060] pnp 00:02: [io 0x0064] pnp 00:02: [io 0x0062] pnp 00:02: [io 0x0066] pnp 00:02: [irq 1] pnp 00:02: Plug and Play ACPI device, IDs PNP0303 (active) pnp 00:03: parse allocated resources pnp 00:03: [io 0x0070-0x0071] pnp 00:03: [irq 8] pnp 00:03: [io 0x0072-0x0077] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) pnp 00:04: parse allocated resources pnp 00:04: [io 0x0061] pnp 00:04: [io 0x0063] pnp 00:04: [io 0x0065] pnp 00:04: [io 0x0067] pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active) pnp 00:05: parse allocated resources pnp 00:05: [io 0x002e-0x002f] pnp 00:05: [io 0x0c80-0x0caf] pnp 00:05: [io 0x0cc0-0x0cff] pnp 00:05: [io 0x004e-0x004f] pnp 00:05: PNP0c01: calling quirk_system_pci_resources+0x0/0x146 pnp 00:05: PNP0c01: calling quirk_amd_mmconfig_area+0x0/0xc3 system 00:05: [io 0x0c80-0x0caf] has been reserved system 00:05: [io 0x0cc0-0x0cff] could not be reserved system 00:05: Plug and Play ACPI device, IDs PNP0c01 (active) pnp 00:06: parse allocated resources pnp 00:06: [dma 4] pnp 00:06: [io 0x0000-0x000f] pnp 00:06: [io 0x0080-0x0085] pnp 00:06: [io 0x0087-0x008f] pnp 00:06: [io 0x00c0-0x00df] pnp 00:06: [io 0x0010-0x001f] pnp 00:06: [io 0x0090-0x0091] pnp 00:06: [io 0x0093-0x009f] pnp 00:06: Plug and Play ACPI device, IDs PNP0200 (active) pnp 00:07: parse allocated resources pnp 00:07: [io 0x00f0-0x00ff] pnp 00:07: [irq 13] pnp 00:07: Plug and Play ACPI device, IDs PNP0c04 (active) pnp 00:08: parse allocated resources pnp 00:08: [mem 0xfed00000-0xfed003ff] pnp 00:08: PNP0c01: calling quirk_system_pci_resources+0x0/0x146 pnp 00:08: PNP0c01: calling quirk_amd_mmconfig_area+0x0/0xc3 system 00:08: [mem 0xfed00000-0xfed003ff] has been reserved system 00:08: Plug and Play ACPI device, IDs PNP0103 PNP0c01 (active) pnp 00:09: parse allocated resources pnp 00:09: [irq 4] pnp 00:09: [io 0x03f8-0x03ff] pnp 00:09: parse resource options pnp 00:09: dependent set 0 (acceptable) irq 3 4 6 12 flags 0x11 pnp 00:09: dependent set 0 (acceptable) io min 0x3f8 max 0x3f8 align 8 size 8 flags 0x1 pnp 00:09: dependent set 1 (acceptable) irq 3 4 6 12 flags 0x11 pnp 00:09: dependent set 1 (acceptable) io min 0x2f8 max 0x2f8 align 8 size 8 flags 0x1 pnp 00:09: dependent set 2 (acceptable) irq 3 4 6 12 flags 0x11 pnp 00:09: dependent set 2 (acceptable) io min 0x3e8 max 0x3e8 align 8 size 8 flags 0x1 pnp 00:09: dependent set 3 (acceptable) irq 3 4 6 12 flags 0x11 pnp 00:09: dependent set 3 (acceptable) io min 0x2e8 max 0x2e8 align 8 size 8 flags 0x1 pnp 00:09: Plug and Play ACPI device, IDs PNP0501 (active) pnp 00:0a: parse allocated resources pnp 00:0a: [dma 1] pnp 00:0a: [irq 7] pnp 00:0a: [io 0x0378-0x037f] pnp 00:0a: [io 0x0778-0x077b] pnp 00:0a: parse resource options pnp 00:0a: dependent set 0 (acceptable) dma <none> (bitmask 0x0) flags 0x0 pnp 00:0a: dependent set 0 (acceptable) irq 3 4 5 7 flags 0x1 pnp 00:0a: dependent set 0 (acceptable) io min 0x378 max 0x378 align 8 size 8 flags 0x1 pnp 00:0a: dependent set 0 (acceptable) io min 0x778 max 0x778 align 8 size 4 flags 0x1 pnp 00:0a: dependent set 1 (acceptable) dma 1 2 3 (bitmask 0xe) flags 0x0 pnp 00:0a: dependent set 1 (acceptable) irq 7 flags 0x1 pnp 00:0a: dependent set 1 (acceptable) io min 0x378 max 0x378 align 8 size 8 flags 0x1 pnp 00:0a: dependent set 1 (acceptable) io min 0x778 max 0x778 align 8 size 4 flags 0x1 pnp 00:0a: dependent set 2 (acceptable) dma <none> (bitmask 0x0) flags 0x0 pnp 00:0a: dependent set 2 (acceptable) irq 3 4 5 7 flags 0x1 pnp 00:0a: dependent set 2 (acceptable) io min 0x278 max 0x278 align 8 size 8 flags 0x1 pnp 00:0a: dependent set 2 (acceptable) io min 0x678 max 0x678 align 8 size 4 flags 0x1 pnp 00:0a: dependent set 3 (acceptable) dma 1 2 3 (bitmask 0xe) flags 0x0 pnp 00:0a: dependent set 3 (acceptable) irq 3 4 5 7 flags 0x1 pnp 00:0a: dependent set 3 (acceptable) io min 0x278 max 0x278 align 8 size 8 flags 0x1 pnp 00:0a: dependent set 3 (acceptable) io min 0x678 max 0x678 align 8 size 4 flags 0x1 pnp 00:0a: dependent set 4 (acceptable) dma <none> (bitmask 0x0) flags 0x0 pnp 00:0a: dependent set 4 (acceptable) irq 3 4 5 7 flags 0x1 pnp 00:0a: dependent set 4 (acceptable) io min 0x3bc max 0x3bc align 4 size 4 flags 0x1 pnp 00:0a: dependent set 4 (acceptable) io min 0x7bc max 0x7bc align 4 size 4 flags 0x1 pnp 00:0a: dependent set 5 (acceptable) dma 1 2 3 (bitmask 0xe) flags 0x0 pnp 00:0a: dependent set 5 (acceptable) irq 3 4 5 7 flags 0x1 pnp 00:0a: dependent set 5 (acceptable) io min 0x3bc max 0x3bc align 4 size 4 flags 0x1 pnp 00:0a: dependent set 5 (acceptable) io min 0x7bc max 0x7bc align 4 size 4 flags 0x1 pnp 00:0a: dependent set 6 (acceptable) dma <none> (bitmask 0x0) flags 0x0 pnp 00:0a: dependent set 6 (acceptable) irq <none> flags 0x1 pnp 00:0a: dependent set 6 (acceptable) io min 0x378 max 0x378 align 8 size 8 flags 0x1 pnp 00:0a: dependent set 6 (acceptable) io min 0x778 max 0x778 align 8 size 4 flags 0x1 pnp 00:0a: dependent set 7 (acceptable) dma <none> (bitmask 0x0) flags 0x0 pnp 00:0a: dependent set 7 (acceptable) irq <none> flags 0x1 pnp 00:0a: dependent set 7 (acceptable) io min 0x278 max 0x278 align 8 size 8 flags 0x1 pnp 00:0a: dependent set 7 (acceptable) io min 0x678 max 0x678 align 8 size 4 flags 0x1 pnp 00:0a: dependent set 8 (acceptable) dma <none> (bitmask 0x0) flags 0x0 pnp 00:0a: dependent set 8 (acceptable) irq <none> flags 0x1 pnp 00:0a: dependent set 8 (acceptable) io min 0x3bc max 0x3bc align 4 size 4 flags 0x1 pnp 00:0a: dependent set 8 (acceptable) io min 0x7bc max 0x7bc align 4 size 4 flags 0x1 pnp 00:0a: Plug and Play ACPI device, IDs PNP0401 (active) pnp 00:0b: parse allocated resources pnp 00:0b: [mem 0xfed40000-0xfed44fff] pnp 00:0b: [io 0x0cb0-0x0cbb] pnp 00:0b: PNP0c01: calling quirk_system_pci_resources+0x0/0x146 pnp 00:0b: PNP0c01: calling quirk_amd_mmconfig_area+0x0/0xc3 system 00:0b: [io 0x0cb0-0x0cbb] has been reserved system 00:0b: [mem 0xfed40000-0xfed44fff] has been reserved system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active) pnp 00:0c: parse allocated resources pnp 00:0c: [io 0x0900-0x097f] pnp 00:0c: [io 0x0092] pnp 00:0c: [io 0x00b2-0x00b3] pnp 00:0c: [io 0x0020-0x0021] pnp 00:0c: [io 0x00a0-0x00a1] pnp 00:0c: [irq 0 disabled] pnp 00:0c: [io 0x04d0-0x04d1] pnp 00:0c: [io 0x1000-0x1005] pnp 00:0c: [io 0x1008-0x100f] pnp 00:0c: PNP0c01: calling quirk_system_pci_resources+0x0/0x146 pnp 00:0c: disabling [io 0x1000-0x1005] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0c: disabling [io 0x1008-0x100f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0c: PNP0c01: calling quirk_amd_mmconfig_area+0x0/0xc3 system 00:0c: [io 0x0900-0x097f] has been reserved system 00:0c: [io 0x04d0-0x04d1] has been reserved system 00:0c: Plug and Play ACPI device, IDs PNP0c01 (active) pnp 00:0d: parse allocated resources pnp 00:0d: [io 0xf400-0xf4fe] pnp 00:0d: [io 0x0086] pnp 00:0d: [io 0x1006-0x1007] pnp 00:0d: [io 0x100a-0x1059] pnp 00:0d: [io 0x1060-0x107f] pnp 00:0d: [io 0x1080-0x10bf] pnp 00:0d: [io 0x10c0-0x10df] pnp 00:0d: [io 0x1010-0x102f] pnp 00:0d: [io 0x0809] pnp 00:0d: PNP0c01: calling quirk_system_pci_resources+0x0/0x146 pnp 00:0d: disabling [io 0x1006-0x1007] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0d: disabling [io 0x100a-0x1059] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0d: disabling [io 0x1060-0x107f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0d: disabling [io 0x1010-0x102f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] pnp 00:0d: PNP0c01: calling quirk_amd_mmconfig_area+0x0/0xc3 system 00:0d: [io 0xf400-0xf4fe] has been reserved system 00:0d: [io 0x1080-0x10bf] has been reserved system 00:0d: [io 0x10c0-0x10df] has been reserved system 00:0d: [io 0x0809] has been reserved system 00:0d: Plug and Play ACPI device, IDs PNP0c01 (active) pnp 00:0e: parse allocated resources pnp 00:0e: [mem 0x00000000-0x0009efff] pnp 00:0e: [mem 0x0009f000-0x0009ffff] pnp 00:0e: [mem 0x000c0000-0x000cffff] pnp 00:0e: [mem 0x000e0000-0x000fffff] pnp 00:0e: [mem 0x00100000-0xdf65a7ff] pnp 00:0e: [mem 0xdf65a800-0xdf6fffff] pnp 00:0e: [mem 0xdf700000-0xdf7fffff] pnp 00:0e: [mem 0xdf700000-0xdfefffff] pnp 00:0e: [mem 0xffe00000-0xffffffff] pnp 00:0e: [mem 0xffa00000-0xffbfffff] pnp 00:0e: [mem 0xfec00000-0xfec0ffff] pnp 00:0e: [mem 0xfee00000-0xfee0ffff] pnp 00:0e: [mem 0xfed20000-0xfed3ffff] pnp 00:0e: [mem 0xfed45000-0xfed8ffff] pnp 00:0e: [mem 0xfeda0000-0xfeda3fff] pnp 00:0e: [mem 0xfeda4000-0xfeda4fff] pnp 00:0e: [mem 0xfeda5000-0xfeda5fff] pnp 00:0e: [mem 0xfeda6000-0xfeda6fff] pnp 00:0e: [mem 0xfed18000-0xfed1bfff] pnp 00:0e: [mem 0xf8000000-0xfbffffff] pnp 00:0e: PNP0c01: calling quirk_system_pci_resources+0x0/0x146 pnp 00:0e: disabling [mem 0x00000000-0x0009efff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x0009f000-0x0009ffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x000c0000-0x000cffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x000e0000-0x000fffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x00100000-0xdf65a7ff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x00000000-0x0009efff disabled] because it overlaps 0000:04:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x0009f000-0x0009ffff disabled] because it overlaps 0000:04:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x000c0000-0x000cffff disabled] because it overlaps 0000:04:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x000e0000-0x000fffff disabled] because it overlaps 0000:04:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: disabling [mem 0x00100000-0xdf65a7ff disabled] because it overlaps 0000:04:00.0 BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] pnp 00:0e: PNP0c01: calling quirk_amd_mmconfig_area+0x0/0xc3 system 00:0e: [mem 0xdf65a800-0xdf6fffff] has been reserved system 00:0e: [mem 0xdf700000-0xdf7fffff] has been reserved system 00:0e: [mem 0xdf700000-0xdfefffff] could not be reserved system 00:0e: [mem 0xffe00000-0xffffffff] has been reserved system 00:0e: [mem 0xffa00000-0xffbfffff] has been reserved system 00:0e: [mem 0xfec00000-0xfec0ffff] could not be reserved system 00:0e: [mem 0xfee00000-0xfee0ffff] has been reserved system 00:0e: [mem 0xfed20000-0xfed3ffff] has been reserved system 00:0e: [mem 0xfed45000-0xfed8ffff] has been reserved system 00:0e: [mem 0xfeda0000-0xfeda3fff] has been reserved system 00:0e: [mem 0xfeda4000-0xfeda4fff] has been reserved system 00:0e: [mem 0xfeda5000-0xfeda5fff] has been reserved system 00:0e: [mem 0xfeda6000-0xfeda6fff] has been reserved system 00:0e: [mem 0xfed18000-0xfed1bfff] has been reserved system 00:0e: [mem 0xf8000000-0xfbffffff] has been reserved system 00:0e: Plug and Play ACPI device, IDs PNP0c01 (active) pnp: PnP ACPI: found 15 devices ACPI: ACPI bus type pnp unregistered PCI: max bus depth: 2 pci_try_num: 3 pci 0000:00:02.0: BAR 2: assigned [mem 0x120000000-0x12fffffff 64bit pref] pci 0000:00:02.0: BAR 2: set to [mem 0x120000000-0x12fffffff 64bit pref] (PCI address [0x120000000-0x12fffffff]) pci 0000:00:1e.0: BAR 15: assigned [mem 0xe0000000-0xefffffff pref] pci 0000:00:1c.0: BAR 14: assigned [mem 0xf0000000-0xf01fffff] pci 0000:00:1c.0: BAR 15: assigned [mem 0x130000000-0x1301fffff 64bit pref] pci 0000:00:1c.1: BAR 15: assigned [mem 0x130200000-0x1303fffff 64bit pref] pci 0000:00:1c.3: BAR 15: assigned [mem 0x130400000-0x1305fffff 64bit pref] pci 0000:00:1c.5: BAR 15: assigned [mem 0x130600000-0x1307fffff 64bit pref] pci 0000:00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] pci 0000:00:1c.1: BAR 13: assigned [io 0x3000-0x3fff] pci 0000:00:1c.5: BAR 13: assigned [io 0x4000-0x4fff] pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] pci 0000:00:1c.0: bridge window [io 0x2000-0x2fff] pci 0000:00:1c.0: bridge window [mem 0xf0000000-0xf01fffff] pci 0000:00:1c.0: bridge window [mem 0x130000000-0x1301fffff 64bit pref] pci 0000:00:1c.1: PCI bridge to [bus 0c-0c] pci 0000:00:1c.1: bridge window [io 0x3000-0x3fff] pci 0000:00:1c.1: bridge window [mem 0xf6c00000-0xf6cfffff] pci 0000:00:1c.1: bridge window [mem 0x130200000-0x1303fffff 64bit pref] pci 0000:00:1c.3: PCI bridge to [bus 0d-0e] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] pci 0000:00:1c.3: bridge window [mem 0xf6a00000-0xf6bfffff] pci 0000:00:1c.3: bridge window [mem 0x130400000-0x1305fffff 64bit pref] pci 0000:00:1c.5: PCI bridge to [bus 09-09] pci 0000:00:1c.5: bridge window [io 0x4000-0x4fff] pci 0000:00:1c.5: bridge window [mem 0xf6900000-0xf69fffff] pci 0000:00:1c.5: bridge window [mem 0x130600000-0x1307fffff 64bit pref] pci 0000:03:08.0: BAR 15: assigned [mem 0xe0000000-0xefffffff pref] pci 0000:04:00.0: BAR 0: assigned [mem 0xe0000000-0xefffffff 64bit pref] pci 0000:04:00.0: BAR 0: set to [mem 0xe0000000-0xefffffff 64bit pref] (PCI address [0xe0000000-0xefffffff]) pci 0000:03:08.0: PCI bridge to [bus 04-04] pci 0000:03:08.0: bridge window [io 0xc000-0xcfff] pci 0000:03:08.0: bridge window [mem 0xf6700000-0xf68fffff] pci 0000:03:08.0: bridge window [mem 0xe0000000-0xefffffff pref] pci 0000:00:1e.0: PCI bridge to [bus 03-04] pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] pci 0000:00:1e.0: bridge window [mem 0xf6700000-0xf68fffff] pci 0000:00:1e.0: bridge window [mem 0xe0000000-0xefffffff pref] pci 0000:00:1e.0: setting latency timer to 64 pci_bus 0000:00: resource 4 [io 0x0000-0xffff] pci_bus 0000:00: resource 5 [mem 0x00000000-0xfffffffff] pci_bus 0000:0b: resource 0 [io 0x2000-0x2fff] pci_bus 0000:0b: resource 1 [mem 0xf0000000-0xf01fffff] pci_bus 0000:0b: resource 2 [mem 0x130000000-0x1301fffff 64bit pref] pci_bus 0000:0c: resource 0 [io 0x3000-0x3fff] pci_bus 0000:0c: resource 1 [mem 0xf6c00000-0xf6cfffff] pci_bus 0000:0c: resource 2 [mem 0x130200000-0x1303fffff 64bit pref] pci_bus 0000:0d: resource 0 [io 0xd000-0xdfff] pci_bus 0000:0d: resource 1 [mem 0xf6a00000-0xf6bfffff] pci_bus 0000:0d: resource 2 [mem 0x130400000-0x1305fffff 64bit pref] pci_bus 0000:09: resource 0 [io 0x4000-0x4fff] pci_bus 0000:09: resource 1 [mem 0xf6900000-0xf69fffff] pci_bus 0000:09: resource 2 [mem 0x130600000-0x1307fffff 64bit pref] pci_bus 0000:03: resource 0 [io 0xc000-0xcfff] pci_bus 0000:03: resource 1 [mem 0xf6700000-0xf68fffff] pci_bus 0000:03: resource 2 [mem 0xe0000000-0xefffffff pref] pci_bus 0000:03: resource 4 [io 0x0000-0xffff] pci_bus 0000:03: resource 5 [mem 0x00000000-0xfffffffff] pci_bus 0000:04: resource 0 [io 0xc000-0xcfff] pci_bus 0000:04: resource 1 [mem 0xf6700000-0xf68fffff] pci_bus 0000:04: resource 2 [mem 0xe0000000-0xefffffff pref] NET: Registered protocol family 2 IP route cache hash table entries: 131072 (order: 8, 1048576 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP: reno registered UDP hash table entries: 2048 (order: 4, 65536 bytes) UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) NET: Registered protocol family 1 pci 0000:00:02.0: calling pci_fixup_video+0x0/0x94 pci 0000:00:02.0: Boot video device pci 0000:00:1a.0: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1a.1: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1a.7: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1d.0: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1d.1: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1d.2: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:00:1d.7: calling quirk_usb_early_handoff+0x0/0x5f8 pci 0000:04:00.0: calling pci_fixup_video+0x0/0x94 PCI: CLS 64 bytes, default 64 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 5412k freed PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing 64MB software IO TLB between ffff8800db654000 - ffff8800df654000 software IO TLB at phys 0xdb654000 - 0xdf654000 Simple Boot Flag at 0x79 set to 0x1 sha1_ssse3: Using SSSE3 optimized SHA-1 implementation audit: initializing netlink socket (disabled) type=2000 audit(1334157463.008:1): initialized Testing tracer function: PASSED Testing dynamic ftrace: PASSED Testing dynamic ftrace ops #1: (1 0 1 1 0) (1 1 2 1 0) (2 1 3 1 7) (2 2 4 1 145) PASSED Testing dynamic ftrace ops #2: (1 0 1 6 0) (1 1 2 121 0) (2 1 3 1 4) (2 2 4 140 143) PASSED Testing tracer wakeup: PASSED Testing tracer wakeup_rt: Refined TSC clocksource calibration: 2393.999 MHz. Switching to clocksource tsc PASSED Testing tracer function_graph: PASSED HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) msgmni has been set to 7885 alg: No test for snappy (snappy-generic) alg: No test for stdrng (krng) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler cfq registered (default) list_sort_test: start testing list_sort() crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64 crc32: self tests passed, processed 225944 bytes in 198641 nsec crc32c: CRC_LE_BITS = 64 crc32c: self tests passed, processed 225944 bytes in 99368 nsec pcieport 0000:00:1c.0: irq 40 for MSI/MSI-X pcieport 0000:00:1c.1: irq 41 for MSI/MSI-X pcieport 0000:00:1c.3: irq 42 for MSI/MSI-X pcieport 0000:00:1c.5: irq 43 for MSI/MSI-X pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp: PCI Express Hot Plug Controller Driver version: 0.4 cpcihp_zt5550: ZT5550 CompactPCI Hot Plug Driver version: 0.2 cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1 cpcihp_generic: not configured, disabling. shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 pci_bus 0000:03: dev 07, created physical slot 1 acpiphp: Slot [1] registered pci_bus 0000:03: dev 08, created physical slot 2 acpiphp: Slot [2] registered pci_bus 0000:0d: dev 00, created physical slot 1-1 acpiphp: Slot [1-1] registered acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed intel_idle: does not run on family 6 model 15 ACPI: AC Adapter [AC] (on-line) input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input0 ACPI: Lid Switch [LID] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1 ACPI: Power Button [PBTN] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2 ACPI: Sleep Button [SBTN] ACPI: Requesting acpi_cpufreq Monitor-Mwait will be used to enter C-1 state Monitor-Mwait will be used to enter C-2 state Monitor-Mwait will be used to enter C-3 state Marking TSC unstable due to TSC halts in idle ACPI: acpi_idle registered with cpuidle Switching to clocksource hpet thermal LNXTHERM:00: registered as thermal_zone0 ACPI: Thermal Zone [THM] (63 C) GHES: HEST is not enabled! ioatdma: Intel(R) QuickData Technology Driver 4.00 ACPI: Battery Slot [BAT0] (battery present) ACPI: Battery Slot [BAT1] (battery absent) brd: module loaded tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> i8042: PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice rtc_cmos 00:03: RTC can wake from S4 rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs i2c /dev entries driver iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07 iTCO_wdt: Found a ICH8M TCO device (Version=2, TCOBASE=0x1060) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) iTCO_vendor_support: vendor-support=0 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com cpuidle: using governor ladder cpuidle: using governor menu TCP: cubic registered NET: Registered protocol family 10 NET: Registered protocol family 17 input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 sctp: Hash tables configured (established 65536 bind 65536) Registering the dns_resolver key type PM: Checking hibernation image partition UUID=ae0f88ec-9e17-41f2-b8b3-685cce36e496 PM: Hibernation image not present or could not be loaded. registered taskstats version 1 Running tests on trace events: Testing event kfree_skb: OK Testing event consume_skb: OK Testing event skb_copy_datagram_iovec: OK Testing event net_dev_xmit: OK Testing event net_dev_queue: OK Testing event netif_receive_skb: OK Testing event netif_rx: OK Testing event napi_poll: OK Testing event sock_rcvqueue_full: OK Testing event sock_exceed_buf_limit: OK Testing event udp_fail_queue_rcv_skb: OK Testing event regmap_reg_write: OK Testing event regmap_reg_read: OK Testing event regmap_reg_read_cache: OK Testing event regmap_hw_read_start: OK Testing event regmap_hw_read_done: OK Testing event regmap_hw_write_start: OK Testing event regmap_hw_write_done: OK Testing event regcache_sync: OK Testing event regmap_cache_only: OK Testing event regmap_cache_bypass: OK Testing event regulator_enable: OK Testing event regulator_enable_delay: OK Testing event regulator_enable_complete: OK Testing event regulator_disable: OK Testing event regulator_disable_complete: OK Testing event regulator_set_voltage: OK Testing event regulator_set_voltage_complete: OK Testing event block_rq_abort: OK Testing event block_rq_requeue: OK Testing event block_rq_complete: OK Testing event block_rq_insert: OK Testing event block_rq_issue: OK Testing event block_bio_bounce: OK Testing event block_bio_complete: OK Testing event block_bio_backmerge: OK Testing event block_bio_frontmerge: OK Testing event block_bio_queue: OK Testing event block_getrq: OK Testing event block_sleeprq: OK Testing event block_plug: OK Testing event block_unplug: OK Testing event block_split: OK Testing event block_bio_remap: OK Testing event block_rq_remap: OK Testing event writeback_nothread: OK Testing event writeback_queue: OK Testing event writeback_exec: OK Testing event writeback_start: OK Testing event writeback_written: OK Testing event writeback_wait: OK Testing event writeback_pages_written: OK Testing event writeback_nowork: OK Testing event writeback_wake_background: OK Testing event writeback_wake_thread: OK Testing event writeback_wake_forker_thread: OK Testing event writeback_bdi_register: OK Testing event writeback_bdi_unregister: OK Testing event writeback_thread_start: OK Testing event writeback_thread_stop: OK Testing event wbc_writepage: OK Testing event writeback_queue_io: OK Testing event global_dirty_state: OK Testing event bdi_dirty_ratelimit: OK Testing event balance_dirty_pages: OK Testing event writeback_congestion_wait: OK Testing event writeback_wait_iff_congested: OK Testing event writeback_single_inode_requeue: OK Testing event writeback_single_inode: OK Testing event mm_compaction_isolate_migratepages: OK Testing event mm_compaction_isolate_freepages: OK Testing event mm_compaction_migratepages: OK Testing event kmalloc: OK Testing event kmem_cache_alloc: OK Testing event kmalloc_node: OK Testing event kmem_cache_alloc_node: OK Testing event kfree: OK Testing event kmem_cache_free: OK Testing event mm_page_free: OK Testing event mm_page_free_batched: OK Testing event mm_page_alloc: OK Testing event mm_page_alloc_zone_locked: OK Testing event mm_page_pcpu_drain: OK Testing event mm_page_alloc_extfrag: OK Testing event mm_vmscan_kswapd_sleep: OK Testing event mm_vmscan_kswapd_wake: OK Testing event mm_vmscan_wakeup_kswapd: OK Testing event mm_vmscan_direct_reclaim_begin: OK Testing event mm_vmscan_memcg_reclaim_begin: OK Testing event mm_vmscan_memcg_softlimit_reclaim_begin: OK Testing event mm_vmscan_direct_reclaim_end: OK Testing event mm_vmscan_memcg_reclaim_end: OK Testing event mm_vmscan_memcg_softlimit_reclaim_end: OK Testing event mm_shrink_slab_start: OK Testing event mm_shrink_slab_end: OK Testing event mm_vmscan_lru_isolate: OK Testing event mm_vmscan_memcg_isolate: OK Testing event mm_vmscan_writepage: OK Testing event mm_vmscan_lru_shrink_inactive: OK Testing event replace_swap_token: OK Testing event put_swap_token: OK Testing event disable_swap_token: OK Testing event update_swap_token_priority: OK Testing event oom_score_adj_update: OK Testing event rpm_suspend: OK Testing event rpm_resume: OK Testing event rpm_idle: OK Testing event rpm_return_int: OK Testing event cpu_idle: OK Testing event cpu_frequency: OK Testing event machine_suspend: OK Testing event clock_enable: OK Testing event clock_disable: OK Testing event clock_set_rate: OK Testing event power_domain_target: OK Testing event ftrace_test_filter: OK Testing event module_load: OK Testing event module_free: OK Testing event module_get: OK Testing event module_put: OK Testing event module_request: OK Testing event sched_kthread_stop: OK Testing event sched_kthread_stop_ret: OK Testing event sched_wakeup: OK Testing event sched_wakeup_new: OK Testing event sched_switch: OK Testing event sched_migrate_task: OK Testing event sched_process_free: OK Testing event sched_process_exit: OK Testing event sched_wait_task: OK Testing event sched_process_wait: OK Testing event sched_process_fork: OK Testing event sched_process_exec: OK Testing event sched_stat_wait: OK Testing event sched_stat_sleep: OK Testing event sched_stat_iowait: OK Testing event sched_stat_blocked: OK Testing event sched_stat_runtime: OK Testing event sched_pi_setprio: OK Testing event rcu_utilization: OK Testing event workqueue_queue_work: OK Testing event workqueue_activate_work: OK Testing event workqueue_execute_start: OK Testing event workqueue_execute_end: OK Testing event signal_generate: OK Testing event signal_deliver: OK Testing event timer_init: OK Testing event timer_start: OK Testing event timer_expire_entry: OK Testing event timer_expire_exit: OK Testing event timer_cancel: OK Testing event hrtimer_init: OK Testing event hrtimer_start: OK Testing event hrtimer_expire_entry: OK Testing event hrtimer_expire_exit: OK Testing event hrtimer_cancel: OK Testing event itimer_state: OK Testing event itimer_expire: OK Testing event irq_handler_entry: OK Testing event irq_handler_exit: OK Testing event softirq_entry: OK Testing event softirq_exit: OK Testing event softirq_raise: OK Testing event console: OK Testing event task_newtask: OK Testing event task_rename: OK Testing event mce_record: OK Testing event sys_enter: OK Testing event sys_exit: OK Testing event emulate_vsyscall: OK Running tests on trace event systems: Testing event system skb: OK Testing event system net: OK Testing event system napi: OK Testing event system sock: OK Testing event system udp: OK Testing event system regmap: OK Testing event system regulator: OK Testing event system block: OK Testing event system writeback: OK Testing event system compaction: OK Testing event system kmem: OK Testing event system vmscan: OK Testing event system oom: OK Testing event system rpm: OK Testing event system power: OK Testing event system test: OK Testing event system module: OK Testing event system sched: OK Testing event system rcu: OK Testing event system workqueue: OK Testing event system signal: OK Testing event system timer: OK Testing event system irq: OK Testing event system printk: OK Testing event system task: OK Testing event system mce: OK Testing event system raw_syscalls: OK Testing event system vsyscall: OK Testing event system syscalls: OK Running tests on all trace events: Testing all events: event trace: Could not enable event function OK Running tests again, along with the function tracer Running tests on trace events: Testing event kfree_skb: OK Testing event consume_skb: OK Testing event skb_copy_datagram_iovec: OK Testing event net_dev_xmit: OK Testing event net_dev_queue: OK Testing event netif_receive_skb: OK Testing event netif_rx: OK Testing event napi_poll: OK Testing event sock_rcvqueue_full: OK Testing event sock_exceed_buf_limit: OK Testing event udp_fail_queue_rcv_skb: OK Testing event regmap_reg_write: OK Testing event regmap_reg_read: OK Testing event regmap_reg_read_cache: OK Testing event regmap_hw_read_start: OK Testing event regmap_hw_read_done: OK Testing event regmap_hw_write_start: OK Testing event regmap_hw_write_done: OK Testing event regcache_sync: OK Testing event regmap_cache_only: OK Testing event regmap_cache_bypass: OK Testing event regulator_enable: OK Testing event regulator_enable_delay: OK Testing event regulator_enable_complete: OK Testing event regulator_disable: OK Testing event regulator_disable_complete: OK Testing event regulator_set_voltage: OK Testing event regulator_set_voltage_complete: OK Testing event block_rq_abort: OK Testing event block_rq_requeue: OK Testing event block_rq_complete: OK Testing event block_rq_insert: OK Testing event block_rq_issue: OK Testing event block_bio_bounce: OK Testing event block_bio_complete: OK Testing event block_bio_backmerge: OK Testing event block_bio_frontmerge: OK Testing event block_bio_queue: OK Testing event block_getrq: OK Testing event block_sleeprq: OK Testing event block_plug: OK Testing event block_unplug: OK Testing event block_split: OK Testing event block_bio_remap: OK Testing event block_rq_remap: OK Testing event writeback_nothread: OK Testing event writeback_queue: OK Testing event writeback_exec: OK Testing event writeback_start: OK Testing event writeback_written: OK Testing event writeback_wait: OK Testing event writeback_pages_written: OK Testing event writeback_nowork: OK Testing event writeback_wake_background: OK Testing event writeback_wake_thread: OK Testing event writeback_wake_forker_thread: OK Testing event writeback_bdi_register: OK Testing event writeback_bdi_unregister: OK Testing event writeback_thread_start: OK Testing event writeback_thread_stop: OK Testing event wbc_writepage: OK Testing event writeback_queue_io: OK Testing event global_dirty_state: OK Testing event bdi_dirty_ratelimit: OK Testing event balance_dirty_pages: OK Testing event writeback_congestion_wait: OK Testing event writeback_wait_iff_congested: OK Testing event writeback_single_inode_requeue: OK Testing event writeback_single_inode: OK Testing event mm_compaction_isolate_migratepages: OK Testing event mm_compaction_isolate_freepages: OK Testing event mm_compaction_migratepages: OK Testing event kmalloc: OK Testing event kmem_cache_alloc: OK Testing event kmalloc_node: OK Testing event kmem_cache_alloc_node: OK Testing event kfree: OK Testing event kmem_cache_free: OK Testing event mm_page_free: OK Testing event mm_page_free_batched: OK Testing event mm_page_alloc: OK Testing event mm_page_alloc_zone_locked: OK Testing event mm_page_pcpu_drain: OK Testing event mm_page_alloc_extfrag: OK Testing event mm_vmscan_kswapd_sleep: OK Testing event mm_vmscan_kswapd_wake: OK Testing event mm_vmscan_wakeup_kswapd: OK Testing event mm_vmscan_direct_reclaim_begin: OK Testing event mm_vmscan_memcg_reclaim_begin: OK Testing event mm_vmscan_memcg_softlimit_reclaim_begin: OK Testing event mm_vmscan_direct_reclaim_end: OK Testing event mm_vmscan_memcg_reclaim_end: OK Testing event mm_vmscan_memcg_softlimit_reclaim_end: OK Testing event mm_shrink_slab_start: OK Testing event mm_shrink_slab_end: OK Testing event mm_vmscan_lru_isolate: OK Testing event mm_vmscan_memcg_isolate: OK Testing event mm_vmscan_writepage: OK Testing event mm_vmscan_lru_shrink_inactive: OK Testing event replace_swap_token: OK Testing event put_swap_token: OK Testing event disable_swap_token: OK Testing event update_swap_token_priority: OK Testing event oom_score_adj_update: OK Testing event rpm_suspend: OK Testing event rpm_resume: OK Testing event rpm_idle: OK Testing event rpm_return_int: OK Testing event cpu_idle: OK Testing event cpu_frequency: OK Testing event machine_suspend: OK Testing event clock_enable: OK Testing event clock_disable: OK Testing event clock_set_rate: OK Testing event power_domain_target: OK Testing event ftrace_test_filter: OK Testing event module_load: OK Testing event module_free: OK Testing event module_get: OK Testing event module_put: OK Testing event module_request: OK Testing event sched_kthread_stop: OK Testing event sched_kthread_stop_ret: OK Testing event sched_wakeup: OK Testing event sched_wakeup_new: OK Testing event sched_switch: OK Testing event sched_migrate_task: OK Testing event sched_process_free: OK Testing event sched_process_exit: OK Testing event sched_wait_task: OK Testing event sched_process_wait: OK Testing event sched_process_fork: OK Testing event sched_process_exec: OK Testing event sched_stat_wait: OK Testing event sched_stat_sleep: OK Testing event sched_stat_iowait: OK Testing event sched_stat_blocked: OK Testing event sched_stat_runtime: OK Testing event sched_pi_setprio: OK Testing event rcu_utilization: OK Testing event workqueue_queue_work: OK Testing event workqueue_activate_work: OK Testing event workqueue_execute_start: OK Testing event workqueue_execute_end: OK Testing event signal_generate: OK Testing event signal_deliver: OK Testing event timer_init: OK Testing event timer_start: OK Testing event timer_expire_entry: OK Testing event timer_expire_exit: OK Testing event timer_cancel: OK Testing event hrtimer_init: OK Testing event hrtimer_start: OK Testing event hrtimer_expire_entry: OK Testing event hrtimer_expire_exit: OK Testing event hrtimer_cancel: OK Testing event itimer_state: OK Testing event itimer_expire: OK Testing event irq_handler_entry: OK Testing event irq_handler_exit: OK Testing event softirq_entry: OK Testing event softirq_exit: OK Testing event softirq_raise: OK Testing event console: OK Testing event task_newtask: OK Testing event task_rename: OK Testing event mce_record: OK Testing event sys_enter: OK Testing event sys_exit: OK Testing event emulate_vsyscall: OK Running tests on trace event systems: Testing event system skb: OK Testing event system net: OK Testing event system napi: OK Testing event system sock: OK Testing event system udp: OK Testing event system regmap: OK Testing event system regulator: OK Testing event system block: OK Testing event system writeback: OK Testing event system compaction: OK Testing event system kmem: OK Testing event system vmscan: OK Testing event system oom: OK Testing event system rpm: OK Testing event system power: OK Testing event system test: OK Testing event system module: OK Testing event system sched: OK Testing event system rcu: OK Testing event system workqueue: OK Testing event system signal: OK Testing event system timer: OK Testing event system irq: OK Testing event system printk: OK Testing event system task: OK Testing event system mce: OK Testing event system raw_syscalls: OK Testing event system vsyscall: OK Testing event system syscalls: OK Running tests on all trace events: Testing all events: event trace: Could not enable event function OK Testing ftrace filter: OK rtc_cmos 00:03: setting system clock to 2012-04-11 15:17:47 UTC (1334157467) Freeing unused kernel memory: 612k freed Write protecting the kernel read-only data: 6144k Freeing unused kernel memory: 572k freed Freeing unused kernel memory: 696k freed udevd[497]: starting version 182 Linux agpgart interface v0.103 [drm] Initialized drm 1.1.0 20060810 agpgart-intel 0000:00:00.0: Intel 965GM Chipset agpgart-intel 0000:00:00.0: detected gtt size: 524288K total, 262144K mappable agpgart-intel 0000:00:00.0: detected 8192K stolen memory agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0x20000000 i915 0000:00:02.0: setting latency timer to 64 i915: probe of 0000:00:02.0 failed with error -5 dracut: Starting plymouth daemon usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb uhci_hcd: USB Universal Host Controller Interface driver ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd 0000:00:1a.7: enabling bus mastering ehci_hcd 0000:00:1a.7: setting latency timer to 64 ehci_hcd 0000:00:1a.7: EHCI Host Controller ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:1a.7: debug port 1 ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported ehci_hcd 0000:00:1a.7: irq 22, io mem 0xfed1c400 SCSI subsystem initialized libata version 3.00 loaded. ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.4.0-rc2-wl-00220-g2597a48 ehci_hcd usb usb1: SerialNumber: 0000:00:1a.7 hub 1-0:1.0: USB hub found hub 1-0:1.0: 4 ports detected uhci_hcd 0000:00:1a.0: enabling bus mastering uhci_hcd 0000:00:1a.0: setting latency timer to 64 uhci_hcd 0000:00:1a.0: UHCI Host Controller uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 2 uhci_hcd 0000:00:1a.0: irq 20, io base 0x00006f20 usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: UHCI Host Controller usb usb2: Manufacturer: Linux 3.4.0-rc2-wl-00220-g2597a48 uhci_hcd usb usb2: SerialNumber: 0000:00:1a.0 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ata_piix 0000:00:1f.1: version 2.13 ata_piix 0000:00:1f.1: setting latency timer to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x6fa0 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x6fa8 irq 15 ahci 0000:00:1f.2: version 3.0 ahci 0000:00:1f.2: irq 44 for MSI/MSI-X ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x5 impl SATA mode ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc ems ahci 0000:00:1f.2: setting latency timer to 64 ata2: port disabled--ignoring scsi2 : ahci scsi3 : ahci scsi4 : ahci ata3: SATA max UDMA/133 abar m2048@0xf6dfb800 port 0xf6dfb900 irq 44 ata4: DUMMY ata5: SATA max UDMA/133 abar m2048@0xf6dfb800 port 0xf6dfba00 irq 44 uhci_hcd 0000:00:1a.1: enabling bus mastering uhci_hcd 0000:00:1a.1: setting latency timer to 64 uhci_hcd 0000:00:1a.1: UHCI Host Controller uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 3 uhci_hcd 0000:00:1a.1: irq 21, io base 0x00006f00 usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: UHCI Host Controller usb usb3: Manufacturer: Linux 3.4.0-rc2-wl-00220-g2597a48 uhci_hcd usb usb3: SerialNumber: 0000:00:1a.1 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected uhci_hcd 0000:00:1d.0: enabling bus mastering uhci_hcd 0000:00:1d.0: setting latency timer to 64 uhci_hcd 0000:00:1d.0: UHCI Host Controller uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 4 uhci_hcd 0000:00:1d.0: irq 20, io base 0x00006f80 usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: UHCI Host Controller usb usb4: Manufacturer: Linux 3.4.0-rc2-wl-00220-g2597a48 uhci_hcd usb usb4: SerialNumber: 0000:00:1d.0 hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected ehci_hcd 0000:00:1d.7: enabling bus mastering ehci_hcd 0000:00:1d.7: setting latency timer to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5 ehci_hcd 0000:00:1d.7: debug port 1 ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported ehci_hcd 0000:00:1d.7: irq 20, io mem 0xfed1c000 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 usb usb5: New USB device found, idVendor=1d6b, idProduct=0002 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: EHCI Host Controller usb usb5: Manufacturer: Linux 3.4.0-rc2-wl-00220-g2597a48 ehci_hcd usb usb5: SerialNumber: 0000:00:1d.7 hub 5-0:1.0: USB hub found hub 5-0:1.0: 6 ports detected uhci_hcd 0000:00:1d.1: enabling bus mastering uhci_hcd 0000:00:1d.1: setting latency timer to 64 uhci_hcd 0000:00:1d.1: UHCI Host Controller uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6 uhci_hcd 0000:00:1d.1: irq 21, io base 0x00006f60 usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: UHCI Host Controller usb usb6: Manufacturer: Linux 3.4.0-rc2-wl-00220-g2597a48 uhci_hcd usb usb6: SerialNumber: 0000:00:1d.1 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected uhci_hcd 0000:00:1d.2: enabling bus mastering uhci_hcd 0000:00:1d.2: setting latency timer to 64 uhci_hcd 0000:00:1d.2: UHCI Host Controller uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7 uhci_hcd 0000:00:1d.2: irq 22, io base 0x00006f40 usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: UHCI Host Controller usb usb7: Manufacturer: Linux 3.4.0-rc2-wl-00220-g2597a48 uhci_hcd usb usb7: SerialNumber: 0000:00:1d.2 hub 7-0:1.0: USB hub found hub 7-0:1.0: 2 ports detected ata1.00: ATA-7: ST980813AS, 3.ADB, max UDMA/133 ata1.00: 156301488 sectors, multi 8: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/100 scsi 0:0:0:0: Direct-Access ATA ST980813AS 3.AD PQ: 0 ANSI: 5 ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata5: SATA link down (SStatus 0 SControl 300) ata3.00: ATA-8: OCZ-AGILITY3, 2.13, max UDMA/133 ata3.00: 234441648 sectors, multi 8: LBA48 NCQ (depth 31/32), AA ata3.00: configured for UDMA/133 scsi 2:0:0:0: Direct-Access ATA OCZ-AGILITY3 2.13 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) sd 2:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 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 sdb: sdb1 sdb2 sdb3 sd 2:0:0:0: [sdb] Attached SCSI disk sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI disk Btrfs loaded device label GENTOO devid 1 transid 346294 /dev/sdb3 usb 1-3: new high-speed USB device number 3 using ehci_hcd usb 1-3: New USB device found, idVendor=413c, idProduct=0058 usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-3:1.0: USB hub found hub 1-3:1.0: 4 ports detected usb 2-2: new full-speed USB device number 2 using uhci_hcd dracut: Checking, if btrfs device complete device label GENTOO devid 1 transid 346294 /dev/sdb3 btrfs: disk space caching is enabled Btrfs detected SSD devices, enabling SSD mode dracut: Checking, if btrfs device complete device label GENTOO devid 1 transid 346294 /dev/sdb3 btrfs: disk space caching is enabled usb 2-2: New USB device found, idVendor=413c, idProduct=8140 usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Btrfs detected SSD devices, enabling SSD mode dracut: Checking, if btrfs device complete device label GENTOO devid 1 transid 346294 /dev/sdb3 btrfs: disk space caching is enabled usb 5-2: new high-speed USB device number 2 using ehci_hcd Btrfs detected SSD devices, enabling SSD mode PM: Marking nosave pages: [mem 0x0009f000-0x000fffff] PM: Marking nosave pages: [mem 0xdf65a000-0xffffffff] PM: Basic memory bitmaps created PM: Basic memory bitmaps freed PM: Starting manual resume from disk PM: Hibernation image partition 8:18 present PM: Looking for hibernation image. PM: Image not found (code -22) PM: Hibernation image not present or could not be loaded. device label GENTOO devid 1 transid 346294 /dev/sdb3 btrfs: disk space caching is enabled usb 5-2: New USB device found, idVendor=14cd, idProduct=125b usb 5-2: New USB device strings: Mfr=1, Product=3, SerialNumber=2 usb 5-2: Product: AutoRUN/Partition usb 5-2: Manufacturer: Generic usb 5-2: SerialNumber: 125B20100608 usbcore: registered new interface driver uas usbcore: registered new interface driver libusual Initializing USB Mass Storage driver... scsi5 : usb-storage 5-2:1.0 usbcore: registered new interface driver usb-storage USB Mass Storage support registered. Btrfs detected SSD devices, enabling SSD mode dracut: Checking btrfs: /dev/disk/by-uuid/d761a2db-f951-4e9c-bed4-cf2381bb1af4 dracut: trying to mount /dev/disk/by-uuid/d761a2db-f951-4e9c-bed4-cf2381bb1af4 device label GENTOO devid 1 transid 346294 /dev/sdb3 btrfs: disk space caching is enabled Btrfs detected SSD devices, enabling SSD mode dracut: btrfs: /dev/disk/by-uuid/d761a2db-f951-4e9c-bed4-cf2381bb1af4 is clean btrfs bad tree block start 67108864 58720256 failed mirror was 1 btrfs read error corrected: ino 1 off 58720256 (dev /dev/sdb3 sector 131072) usb 7-1: new full-speed USB device number 2 using uhci_hcd usb 7-1: New USB device found, idVendor=0b97, idProduct=7761 usb 7-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 7-1:1.0: USB hub found hub 7-1:1.0: 4 ports detected usb 1-3.2: new high-speed USB device number 4 using ehci_hcd usb 1-3.2: New USB device found, idVendor=413c, idProduct=0058 usb 1-3.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-3.2:1.0: USB hub found hub 1-3.2:1.0: 4 ports detected dracut: Remounting /dev/disk/by-uuid/d761a2db-f951-4e9c-bed4-cf2381bb1af4 with -o subvol=ROOT,ro device label GENTOO devid 1 transid 346297 /dev/sdb3 btrfs: disk space caching is enabled usb 7-1.2: new full-speed USB device number 3 using uhci_hcd Btrfs detected SSD devices, enabling SSD mode dracut: Mounted root filesystem /dev/sdb3 dracut: Switching root usb 7-1.2: New USB device found, idVendor=0b97, idProduct=7772 usb 7-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 7-1.2: Product: O2Micro CCID SC Reader usb 7-1.2: Manufacturer: O2 scsi 5:0:0:0: Direct-Access Mass Storage Device PQ: 0 ANSI: 0 CCS btrfs: use lzo compression btrfs: enabling inode map caching btrfs: use ssd allocation scheme btrfs: disk space caching is enabled sd 5:0:0:0: [sdc] 31116287 512-byte logical blocks: (15.9 GB/14.8 GiB) sd 5:0:0:0: [sdc] Write Protect is off sd 5:0:0:0: [sdc] Mode Sense: 03 00 00 00 sd 5:0:0:0: [sdc] No Caching mode page present sd 5:0:0:0: [sdc] Assuming drive cache: write through sd 5:0:0:0: [sdc] No Caching mode page present sd 5:0:0:0: [sdc] Assuming drive cache: write through sdc: unknown partition table sd 5:0:0:0: [sdc] No Caching mode page present sd 5:0:0:0: [sdc] Assuming drive cache: write through sd 5:0:0:0: [sdc] Attached SCSI removable disk RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. FS-Cache: Loaded NFS: Registering the id_resolver key type FS-Cache: Netfs 'nfs' registered for caching loop: module loaded udevd[835]: starting version 182 btrfs bad tree block start 67108864 58720256 btrfs bad tree block start 67108864 58720256 failed mirror was 1 btrfs read error corrected: ino 1 off 58720256 (dev /dev/sdb3 sector 131072) Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled parport_pc 00:0a: reported by Plug and Play ACPI parport0: PC-style at 0x378 (0x778), irq 7, dma 1 [PCSPP,TRISTATE,COMPAT,ECP,DMA] wmi: Mapper loaded tg3.c:v3.123 (March 21, 2012) cfg80211: Calling CRDA to update world regulatory domain tg3 0000:09:00.0: eth0: Tigon3 [partno(BCM95755m) rev a002] (PCI Express) MAC address 00:1d:09:bc:69:2c tg3 0000:09:00.0: eth0: attached PHY is 5755 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) tg3 0000:09:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] tg3 0000:09:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit] snd_hda_intel 0000:00:1b.0: irq 45 for MSI/MSI-X [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:04:00.0: enabling device (0000 -> 0003) radeon 0000:04:00.0: enabling bus mastering [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E1 0x1787:0x3000). [drm] register mmio base: 0xF67E0000 [drm] register mmio size: 131072 input: PC Speaker as /devices/platform/pcspkr/input/input4 Adding 8005628k swap on /dev/sdb2. Priority:0 extents:1 across:8005628k SS microcode: CPU0 sig=0x6fb, pf=0x80, revision=0xb3 Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized usbcore: registered new interface driver btusb dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) WARNING! power/level is deprecated; use power/control instead serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ATOM BIOS: B9127JMA.MFK [drm] GPU not posted. posting now... radeon 0000:04:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) radeon 0000:04:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining [drm] Detected VRAM RAM=512M, BAR=256M [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 2019692 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 512M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. radeon 0000:04:00.0: irq 46 for MSI/MSI-X radeon 0000:04:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: ib pool ready. [drm] Loading CEDAR Microcode iwl4965: Intel(R) Wireless WiFi 4965 driver for Linux, in-tree: iwl4965: Copyright(c) 2003-2011 Intel Corporation iwl4965 0000:0c:00.0: Detected Intel(R) Wireless WiFi Link 4965AGN, REV=0x4 input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 input: Dell WMI hotkeys as /devices/virtual/input/input7 iwl4965 0000:0c:00.0: device EEPROM VER=0x36, CALIB=0x5 iwl4965 0000:0c:00.0: Tunable channels: 13 802.11bg, 19 802.11a channels iwl4965 0000:0c:00.0: irq 47 for MSI/MSI-X microcode: CPU1 sig=0x6fb, pf=0x80, revision=0xb3 PHC: Got new VIDs through sysfs VID interface. PHC: Got new VIDs through sysfs VID interface. PHC: Got new VIDs through sysfs VID interface. PHC: Got new VIDs through sysfs VID interface. microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba iwl4965 0000:0c:00.0: loaded firmware version 228.61.2.24 Registered led device: phy0-led cfg80211: World regulatory domain updated: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). radeon 0000:04:00.0: WB enabled [drm] fence driver on ring 0 use gpu addr 0x20000c00 and cpu addr 0xffff880116326c00 [drm] ring test on 0 succeeded in 5 usecs [drm] ib test on ring 0 succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] HDMI-A [drm] HPD1 [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY1 [drm] Connector 1: [drm] DVI-I [drm] HPD4 [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 2: [drm] VGA [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [drm] Encoders: [drm] CRT2: INTERNAL_KLDSCP_DAC2 ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs' [drm] Internal thermal controller with fan control [drm] radeon: power management initialized No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768 [drm] fb mappable at 0xE0142000 [drm] vram apper at 0xE0000000 [drm] size 3145728 [drm] fb depth is 24 [drm] pitch is 4096 fb0: radeondrmfb frame buffer device drm: registered panic notifier [drm] Initialized radeon 2.15.0 20080528 for 0000:04:00.0 on minor 0 snd_hda_intel 0000:04:00.1: irq 48 for MSI/MSI-X HDMI status: Codec=0 Pin=3 Presence_Detect=0 ELD_Valid=0 input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1e.0/0000:03:08.0/0000:04:00.1/sound/card1/input8 input: DualPoint Stick as /devices/platform/i8042/serio1/input/input9 Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Bluetooth: BNEP filters: protocol multicast input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input10 Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 device label distfiles devid 1 transid 2470 /dev/sdc btrfs: use zlib compression btrfs: enabling inode map caching btrfs: use ssd allocation scheme btrfs: disk space caching is enabled ADDRCONF(NETDEV_UP): wlan0: link is not ready tg3 0000:09:00.0: irq 49 for MSI/MSI-X ADDRCONF(NETDEV_UP): eth0: link is not ready sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk tg3 0000:09:00.0: eth0: Link is up at 1000 Mbps, full duplex tg3 0000:09:00.0: eth0: Flow control is on for TX and on for RX ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready ata1.00: configured for UDMA/100 sd 0:0:0:0: [sda] Starting disk ata1.00: configured for UDMA/100 ata1: EH complete ata3.00: configured for UDMA/133 ata3: EH complete sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk uhci_hcd 0000:00:1a.1: enabling bus mastering uhci_hcd 0000:00:1a.1: setting latency timer to 64 uhci_hcd 0000:00:1d.0: enabling bus mastering uhci_hcd 0000:00:1d.0: setting latency timer to 64 uhci_hcd 0000:00:1d.1: enabling bus mastering uhci_hcd 0000:00:1d.1: setting latency timer to 64 wlan0: authenticate with e0:91:f5:04:7b:ea wlan0: send auth to e0:91:f5:04:7b:ea (try 1/3) wlan0: authenticated wlan0: associate with e0:91:f5:04:7b:ea (try 1/3) wlan0: RX AssocResp from e0:91:f5:04:7b:ea (capab=0x11 status=0 aid=1) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready cfg80211: Calling CRDA for country: GB cfg80211: Regulatory domain changed to country: GB cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm) cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm) cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm) ICMPv6 RA: ndisc_router_discovery() failed to add default route. wlan0: authenticate with e0:91:f5:04:7b:e8 wlan0: direct probe to e0:91:f5:04:7b:e8 (try 1/3) wlan0: send auth to e0:91:f5:04:7b:e8 (try 2/3) wlan0: authenticated wlan0: associate with e0:91:f5:04:7b:e8 (try 1/3) wlan0: RX AssocResp from e0:91:f5:04:7b:e8 (capab=0x411 status=0 aid=2) wlan0: associated ICMPv6 RA: ndisc_router_discovery() failed to add default route. [-- Attachment #3: dmesg.pnpdebug.radeon.sig --] [-- Type: application/pgp-signature, Size: 72 bytes --] ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-11 14:33 ` Steven Newbury @ 2012-04-11 23:59 ` Bjorn Helgaas 2012-04-12 11:39 ` Steven Newbury 0 siblings, 1 reply; 94+ messages in thread From: Bjorn Helgaas @ 2012-04-11 23:59 UTC (permalink / raw) To: Steven Newbury; +Cc: Yinghai Lu, linux-pci On Wed, Apr 11, 2012 at 8:33 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > On 11/04/12 04:37, Bjorn Helgaas wrote: >> If the host bridge has a _PRS with settings above 4G that we could >> enable, that might be worthwhile. I haven't seen _PRS on a host >> bridge yet, and Linux would ignore it if it existed, but that would >> be a plausible approach. (Turn on CONFIG_PNP_DEBUG_MESSAGES and >> boot with pnp.debug=1 to see if you have any _PRS.) > > Attached dmesg with pnp.debug=1, also includes working radeon with > cardbus disabled in BIOS. As expected, your host bridge doesn't have a _PRS method, so there's no good way to change its apertures. >> Do you happen to know what Windows does in that > That's why I'm hoping to be able to reallocate the i915 aperture > above 4GB, but this depends on what the chipset is capable of > rather than what the BIOS exposes. We don't have native drivers in Linux for every chipset. For example, to my knowledge, Linux doesn't know anything about the Intel 965 spec ifics you mentioned. Therefore, we do rely on the abstract information the BIOS exposes. Sometimes that we can't exploit every hardware feature. That's part of the tradeoff between having a generic kernel vs. having to write new code for every new machine. >> situation? Does the radeon work and the i915 not, or does it somehow >> make both work? Is there any way you could collect the device info >> under Windows, using AIDA64 (http://www.aida64.com/) or similar? > From reading Microsoft documents, they always try putting PCI > resources above 4GB on 64bit Windows since Vista, even > using bounce buffers where necessary, and supported by the > hardware, only falling back below 4GB when all else fails. I don't doubt that Windows tries to put PCI resources above 4GB, but I suspect it does so only when it can place them inside a host bridge aperture reported via _CRS. I'd be very surprised if 64-bit Windows assigned >4GB PCI resources on this machine. Here's the basic problem: when we hot-add a PCI device, we have to know what resources can possibly be assigned to it. When we have more than one host bridge, we have to know the apertures of each host bridge so we can allocate from the correct ones. That's what _CRS tells us. So the short answer is that by default Linux uses _CRS, and it won't work any better than Windows in this case. If you want to make some tweaks and just live with the fact of always having to use "pci=nocrs", that's fine. I don't personally have time to mess with that, and I don't know whether it would make sense to push those tweaks upstream, but you can likely make it work somehow. Bjorn ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-11 23:59 ` Bjorn Helgaas @ 2012-04-12 11:39 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-12 11:39 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: Yinghai Lu, linux-pci On Thu, 12 Apr 2012, 00:59:24 BST, Bjorn Helgaas <bhelgaas@google.com> wrote: > I don't doubt that Windows tries to put PCI resources above 4GB, but I > suspect it does so only when it can place them inside a host bridge > aperture reported via _CRS. I'd be very surprised if 64-bit Windows > assigned >4GB PCI resources on this machine. > I don't know. I'd try it if I had a copy. As I understand Windows PCI/PnP is one of its better capablities. > Here's the basic problem: when we hot-add a PCI device, we have to > know what resources can possibly be assigned to it. When we have more > than one host bridge, we have to know the apertures of each host > bridge so we can allocate from the correct ones. That's what _CRS > tells us. > > So the short answer is that by default Linux uses _CRS, and it won't > work any better than Windows in this case. > Given 32-bit Vista BSODs on me, I'd say it's already doing better! :) > If you want to make some tweaks and just live with the fact of always > having to use "pci=nocrs", that's fine. I don't personally have time > to mess with that, and I don't know whether it would make sense to > push those tweaks upstream, but you can likely make it work somehow. Okay, fair enough, although I feel most of this is pretty generic PCI resource management (if an extreme example), it would be nice if BIOSes were better and provided the needed information, but sadly that's not the case, certainly not on older machines, probably laptops especially. I'm pleased to have got as far as getting it to boot with both video devices now working when docked. I'm going to keep going and try to get hot-plug working too, but that means some more agressive tweaking as mentioned in my other email. Hopefully something generally useful comes out of this. At the least there must be a few people out there with similar hardware. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 21:19 ` Steven Newbury 2012-04-11 3:37 ` Bjorn Helgaas @ 2012-04-12 0:57 ` Yinghai Lu 2012-04-12 11:22 ` Steven Newbury 1 sibling, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-04-12 0:57 UTC (permalink / raw) To: Steven Newbury, Barnes, Jesse, Dave Airlie Cc: Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 644 bytes --] On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury <steve@snewbury.org.uk> wrote: > Another thought, normally the integrated graphics has an "AGP" > aperture of 256M @0xe0000000, which is detected by agpgart-intel, this > will need to be moved up above 4G to free up 0xe0000000 for the > radeon, assuming the "agp_bridge" has a 64bit base register... I > noticed in my docked dmesg, "AGP aperture is 256M @ 0x20000000", but > the PCI base: "120000000-12fffffff : 0000:00:02.0" so only 32bits have > been set in agpgart-intel. Explains why i915 wasn't initialised. Attached patch should fix that high 32bit missing problem. Yinghai [-- Attachment #2: fix_i915_gma_bus_addr.patch --] [-- Type: application/octet-stream, Size: 1217 bytes --] Subject: [PATCH] intel-gtt: Read 64bit for gmar_bus_addr That bar could be 64bit pref mem. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/char/agp/intel-gtt.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) Index: linux-2.6/drivers/char/agp/intel-gtt.c =================================================================== --- linux-2.6.orig/drivers/char/agp/intel-gtt.c +++ linux-2.6/drivers/char/agp/intel-gtt.c @@ -770,16 +770,22 @@ static void i830_write_entry(dma_addr_t static bool intel_enable_gtt(void) { u32 gma_addr; + u32 addr_hi = 0; u8 __iomem *reg; + int pos; if (INTEL_GTT_GEN <= 2) - pci_read_config_dword(intel_private.pcidev, I810_GMADDR, - &gma_addr); + pos = I810_GMADDR; else - pci_read_config_dword(intel_private.pcidev, I915_GMADDR, - &gma_addr); + pos = I915_GMADDR; + + pci_read_config_dword(intel_private.pcidev, pos, &gma_addr); + + if (gma_addr & PCI_BASE_ADDRESS_MEM_TYPE_64) + pci_read_config_dword(intel_private.pcidev, pos + 4, &addr_hi); intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK); + intel_private.gma_bus_addr |= (u64)addr_hi << 32; if (INTEL_GTT_GEN >= 6) return true; ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-12 0:57 ` Yinghai Lu @ 2012-04-12 11:22 ` Steven Newbury 2012-04-12 16:07 ` Yinghai Lu 2012-04-12 16:29 ` Steven Newbury 0 siblings, 2 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-12 11:22 UTC (permalink / raw) To: Yinghai Lu, Barnes, Jesse, Dave Airlie Cc: Bjorn Helgaas, linux-pci, DRI mailing list On Thu, 12 Apr 2012, 01:57:17 BST, Yinghai Lu <yinghai@kernel.org> wrote: > On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury <steve@snewbury.org.uk> > wrote: > > Another thought, normally the integrated graphics has an "AGP" > > aperture of 256M @0xe0000000, which is detected by agpgart-intel, this > > will need to be moved up above 4G to free up 0xe0000000 for the > > radeon, assuming the "agp_bridge" has a 64bit base register... I > > noticed in my docked dmesg, "AGP aperture is 256M @ 0x20000000", but > > the PCI base: "120000000-12fffffff : 0000:00:02.0" so only 32bits have > > been set in agpgart-intel. Explains why i915 wasn't initialised. > > Attached patch should fix that high 32bit missing problem. Thanks, that fixed it! :) I had a similar patch I've been working on but I had my fix in the wrong place! In the working case, initially the BIOS has set GMA to within the low system DRAM 0xC0000000 obviously invalid. This conflict is detected and it's relallocated to 0x12000000. I've attempted to modify probe.c to disable 64-bit BARs not allocated above 4G so they get reallocated above when possible later. It seemed to work, but again broke GMA despite the BAR originally containing an invalid address as mentioned above, it seems for some reason something is different when the conflict is detected and rellocated, compared to disabling it early then allocating a valid value..? It would be useful to preserve as much low PCI memory address space as possible for hotplug devices (like my Radeon), but the other problem is small regions get allocated at the bottom, resulting in the inability to find large aligned regions later on. I see code to default to top-down allocation was reverted, I guess I'm going to have to dig into the archive to find out why... Thanks for all your help so far, I've been learning a lot over the last few days. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-12 11:22 ` Steven Newbury @ 2012-04-12 16:07 ` Yinghai Lu 2012-04-12 16:40 ` Steven Newbury 2012-04-12 16:29 ` Steven Newbury 1 sibling, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-04-12 16:07 UTC (permalink / raw) To: Steven Newbury Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > Thanks, that fixed it! :) I had a similar patch I've been working on but I had my fix in the wrong place! > > In the working case, initially the BIOS has set GMA to within the low system DRAM 0xC0000000 obviously invalid. This conflict is detected and it's relallocated to 0x12000000. > > I've attempted to modify probe.c to disable 64-bit BARs not allocated above 4G so they get reallocated above when possible later. It seemed to work, but again broke GMA despite the BAR originally containing an invalid address as mentioned above, it seems for some reason something is different when the conflict is detected and rellocated, compared to disabling it early then allocating a valid value..? > > It would be useful to preserve as much low PCI memory address space as possible for hotplug devices (like my Radeon), but the other problem is small regions get allocated at the bottom, resulting in the inability to find large aligned regions later on. I see code to default to top-down allocation was reverted, I guess I'm going to have to dig into the archive to find out why... for hotplug case, You can work around like: after hotplug add, 1. use lspci and /proc/iomem to find out offending device and bridge. 2. use /sys/.../unbind etc to stop driver for those devices. 3. use setpci to clear related BAR 4. use /sys/devices/pci000..../remove to remove those devices 5. echo 1 > /sys/bus/pci/rescan then it should work... Yinghai ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-12 16:07 ` Yinghai Lu @ 2012-04-12 16:40 ` Steven Newbury 2012-04-13 8:26 ` Yinghai Lu 2012-04-14 17:37 ` Steven Newbury 0 siblings, 2 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-12 16:40 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu <yinghai@kernel.org> wrote: > On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury <steve@snewbury.org.uk> > wrote: > > Thanks, that fixed it! :) I had a similar patch I've been working on > > but I had my fix in the wrong place! > > > > In the working case, initially the BIOS has set GMA to within the low > > system DRAM 0xC0000000 obviously invalid. This conflict is detected > > and it's relallocated to 0x12000000. > > > > I've attempted to modify probe.c to disable 64-bit BARs not allocated > > above 4G so they get reallocated above when possible later. It seemed > > to work, but again broke GMA despite the BAR originally containing an > > invalid address as mentioned above, it seems for some reason something > > is different when the conflict is detected and rellocated, compared to > > disabling it early then allocating a valid value..? > > > > It would be useful to preserve as much low PCI memory address space as > > possible for hotplug devices (like my Radeon), but the other problem > > is small regions get allocated at the bottom, resulting in the > > inability to find large aligned regions later on. I see code to > > default to top-down allocation was reverted, I guess I'm going to have > > to dig into the archive to find out why... > > for hotplug case, You can work around like: > after hotplug add, > 1. use lspci and /proc/iomem to find out offending device and bridge. > 2. use /sys/.../unbind etc to stop driver for those devices. > 3. use setpci to clear related BAR > 4. use /sys/devices/pci000..../remove to remove those devices > 5. echo 1 > /sys/bus/pci/rescan > > then it should work... > Good idea, I can easily hook that up into the dock event. Is it possible to disable the auto bus scan on hotplug, then trigger it manually as above? But it still leaves me needing to have at least the Intel GMA cleanly reallocated high from boot. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-12 16:40 ` Steven Newbury @ 2012-04-13 8:26 ` Yinghai Lu 2012-04-13 8:34 ` Steven Newbury 2012-04-13 11:45 ` Steven Newbury 2012-04-14 17:37 ` Steven Newbury 1 sibling, 2 replies; 94+ messages in thread From: Yinghai Lu @ 2012-04-13 8:26 UTC (permalink / raw) To: Steven Newbury Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 1149 bytes --] On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >> > >> > It would be useful to preserve as much low PCI memory address space as >> > possible for hotplug devices (like my Radeon), but the other problem >> > is small regions get allocated at the bottom, resulting in the >> > inability to find large aligned regions later on. I see code to >> > default to top-down allocation was reverted, I guess I'm going to have >> > to dig into the archive to find out why... Please check attached patches that will find_resource with fit. It may leave space for your hotplug devices. PCI: Should add children device res to fail list PCI: Try to allocate mem64 above 4G at first intel-gtt: Read 64bit for gmar_bus_addr PCI: Make sure assign same align with large size resource at first resource: make find_resource could return just fit resource PCI: Don't allocate small resource in big empty space. resource: only return range with needed align You can get them from git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-res-alloc Thanks Yinghai [-- Attachment #2: assign_sorting.patch --] [-- Type: application/octet-stream, Size: 1260 bytes --] Subject: [PATCH] PCI: Make sure assign same align with large size resource at first When sorting them, put the one with large size before small size. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/setup-bus.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -128,7 +128,7 @@ static void pdev_sort_resources(struct p for_each_pci_dev_all_resource(dev, r, i) { struct pci_dev_resource *dev_res, *tmp; - resource_size_t r_align; + resource_size_t r_align, r_size; struct list_head *n; if (r->flags & IORESOURCE_PCI_FIXED) @@ -143,6 +143,7 @@ static void pdev_sort_resources(struct p i, r); continue; } + r_size = resource_size(r); tmp = kzalloc(sizeof(*tmp), GFP_KERNEL); if (!tmp) @@ -159,7 +160,9 @@ static void pdev_sort_resources(struct p align = pci_resource_alignment(dev_res->dev, dev_res->res); - if (r_align > align) { + if (r_align > align || + (r_align == align && + r_size > resource_size(dev_res->res))) { n = &dev_res->list; break; } [-- Attachment #3: find_one_just_fit_1.patch --] [-- Type: application/octet-stream, Size: 2804 bytes --] Subject: [PATCH] resource: make find_resource could return just fit resource Find all suitable empty slots and pick one just fit, so we could spare the big slot for needed ones later. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- kernel/resource.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 56 insertions(+), 4 deletions(-) Index: linux-2.6/kernel/resource.c =================================================================== --- linux-2.6.orig/kernel/resource.c +++ linux-2.6/kernel/resource.c @@ -435,7 +435,7 @@ static int __find_resource(struct resour alloc.end = alloc.start + size - 1; if (resource_contains(&avail, &alloc)) { new->start = alloc.start; - new->end = alloc.end; + new->end = !old ? avail.end : alloc.end; return 0; } } @@ -450,14 +450,66 @@ next: if (!this || this->end == root->e return -EBUSY; } +struct avail_resource { + struct list_head list; + struct resource res; +}; /* * Find empty slot in the resource tree given range and alignment. */ static int find_resource(struct resource *root, struct resource *new, resource_size_t size, - struct resource_constraint *constraint) + struct resource_constraint *constraint, bool fit) { - return __find_resource(root, NULL, new, size, constraint); + int ret = -1; + LIST_HEAD(head); + struct avail_resource *avail, *tmp; + resource_size_t avail_start = 0, avail_size = -1ULL; + + if (!fit) { + ret = __find_resource(root, NULL, new, size, constraint); + if (!ret) + new->end = new->start + size - 1; + return ret; + } + +again: + /* find all suitable ones */ + avail = kzalloc(sizeof(*avail), GFP_KERNEL); + if (!avail) + goto out; + + avail->res.start = new->start; + avail->res.end = new->end; + avail->res.flags = new->flags; + ret = __find_resource(root, NULL, &avail->res, size, constraint); + if (ret || __request_resource(root, &avail->res)) { + ret = -EBUSY; + kfree(avail); + goto out; + } + /* add to the list */ + list_add(&avail->list, &head); + goto again; + +out: + /* pick up the smallest one and delete the list */ + list_for_each_entry_safe(avail, tmp, &head, list) { + if (resource_size(&avail->res) < avail_size) { + avail_size = resource_size(&avail->res); + avail_start = avail->res.start; + ret = 0; + } + list_del(&avail->list); + __release_resource(&avail->res); + kfree(avail); + } + + if (!ret) { + new->start = avail_start; + new->end = new->start + size - 1; + } + return ret; } /** @@ -550,7 +602,7 @@ static int __allocate_resource(struct re if (lock) write_lock(&resource_lock); - err = find_resource(root, new, size, &constraint); + err = find_resource(root, new, size, &constraint, false); if (err >= 0 && __request_resource(root, new)) err = -EBUSY; if (lock) [-- Attachment #4: find_one_just_fit_2.patch --] [-- Type: application/octet-stream, Size: 11857 bytes --] Subject: [PATCH] PCI: Don't allocate small resource in big empty space. Use updated find_resource to return matched resource instead using head of bigger range. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/bus.c | 22 ++++++++++++++++++---- drivers/pci/setup-bus.c | 12 ++++++++---- drivers/pci/setup-res.c | 28 ++++++++++++++++++---------- include/linux/ioport.h | 8 ++++++++ include/linux/pci.h | 10 ++++++++++ kernel/resource.c | 23 ++++++++++++++++++----- 6 files changed, 80 insertions(+), 23 deletions(-) Index: linux-2.6/kernel/resource.c =================================================================== --- linux-2.6.orig/kernel/resource.c +++ linux-2.6/kernel/resource.c @@ -580,7 +580,7 @@ static int __allocate_resource(struct re const struct resource *, resource_size_t, resource_size_t), - void *alignf_data, bool lock) + void *alignf_data, bool lock, bool fit) { int err; struct resource_constraint constraint; @@ -602,13 +602,26 @@ static int __allocate_resource(struct re if (lock) write_lock(&resource_lock); - err = find_resource(root, new, size, &constraint, false); + err = find_resource(root, new, size, &constraint, fit); if (err >= 0 && __request_resource(root, new)) err = -EBUSY; if (lock) write_unlock(&resource_lock); return err; } +int allocate_resource_fit(struct resource *root, struct resource *new, + resource_size_t size, resource_size_t min, + resource_size_t max, resource_size_t align, + resource_size_t (*alignf)(void *, + const struct resource *, + resource_size_t, + resource_size_t), + void *alignf_data, bool fit) +{ + return __allocate_resource(root, new, size, min, max, align, + alignf, alignf_data, true, fit); +} + int allocate_resource(struct resource *root, struct resource *new, resource_size_t size, resource_size_t min, resource_size_t max, resource_size_t align, @@ -619,7 +632,7 @@ int allocate_resource(struct resource *r void *alignf_data) { return __allocate_resource(root, new, size, min, max, align, - alignf, alignf_data, true); + alignf, alignf_data, true, false); } EXPORT_SYMBOL(allocate_resource); @@ -1073,7 +1086,7 @@ static resource_size_t __find_res_top_fr ret = __allocate_resource(res, &tmp_res, n_size, res->end - n_size + 1, res->end, - 1, NULL, NULL, false); + 1, NULL, NULL, false, false); if (ret == 0) { __release_resource(&tmp_res); break; @@ -1133,7 +1146,7 @@ again: ret = __allocate_resource(parent_res, busn_res, needed_size - n_size, tmp, tmp + needed_size - n_size - 1, - 1, NULL, NULL, false); + 1, NULL, NULL, false, false); if (!ret) { /* save parent_res, we need it as stopper later */ *p = parent_res; Index: linux-2.6/drivers/pci/bus.c =================================================================== --- linux-2.6.orig/drivers/pci/bus.c +++ linux-2.6/drivers/pci/bus.c @@ -112,14 +112,14 @@ void __weak pcibios_resource_survey_bus( * for a specific device resource. */ int -pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res, +pci_bus_alloc_resource_fit(struct pci_bus *bus, struct resource *res, resource_size_t size, resource_size_t align, resource_size_t min, unsigned int type_mask, resource_size_t (*alignf)(void *, const struct resource *, resource_size_t, resource_size_t), - void *alignf_data) + void *alignf_data, bool fit) { int i, ret = -ENOMEM; struct resource *r; @@ -150,10 +150,10 @@ again: continue; /* Ok, try it out.. */ - ret = allocate_resource(r, res, size, + ret = allocate_resource_fit(r, res, size, max(bottom, r->start ? : min), max, align, - alignf, alignf_data); + alignf, alignf_data, fit); if (ret == 0) return 0; } @@ -166,6 +166,20 @@ again: return ret; } +int +pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res, + resource_size_t size, resource_size_t align, + resource_size_t min, unsigned int type_mask, + resource_size_t (*alignf)(void *, + const struct resource *, + resource_size_t, + resource_size_t), + void *alignf_data) +{ + return pci_bus_alloc_resource_fit(bus, res, size, align, min, type_mask, + alignf, alignf_data, false); +} + /** * pci_bus_add_device - add a single device * @dev: device to add Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -273,7 +273,7 @@ out: * requests that could not satisfied to the failed_list. */ static void assign_requested_resources_sorted(struct list_head *head, - struct list_head *fail_head) + struct list_head *fail_head, bool fit) { struct resource *res; struct pci_dev_resource *dev_res; @@ -283,7 +283,7 @@ static void assign_requested_resources_s res = dev_res->res; idx = pci_dev_resource_idx(dev_res->dev, res); if (resource_size(res) && - pci_assign_resource(dev_res->dev, idx)) { + pci_assign_resource_fit(dev_res->dev, idx, fit)) { if (fail_head) { /* * if the failed res is for ROM BAR, and it will @@ -318,6 +318,7 @@ static void __assign_resources_sorted(st LIST_HEAD(local_fail_head); struct pci_dev_resource *save_res; struct pci_dev_resource *dev_res; + bool fit = true; /* Check if optional add_size is there */ if (!realloc_head || list_empty(realloc_head)) @@ -337,7 +338,7 @@ static void __assign_resources_sorted(st dev_res->res); /* Try updated head list with add_size added */ - assign_requested_resources_sorted(head, &local_fail_head); + assign_requested_resources_sorted(head, &local_fail_head, fit); /* all assigned with add_size ? */ if (list_empty(&local_fail_head)) { @@ -364,9 +365,12 @@ static void __assign_resources_sorted(st } free_list(&save_head); + /* will need to expand later, so not use fit */ + fit = false; + requested_and_reassign: /* Satisfy the must-have resource requests */ - assign_requested_resources_sorted(head, fail_head); + assign_requested_resources_sorted(head, fail_head, fit); /* Try to satisfy any additional optional resource requests */ Index: linux-2.6/drivers/pci/setup-res.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-res.c +++ linux-2.6/drivers/pci/setup-res.c @@ -140,7 +140,8 @@ void pci_disable_bridge_window(struct pc } static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev, - int resno, resource_size_t size, resource_size_t align) + int resno, resource_size_t size, resource_size_t align, + bool fit) { struct resource *res = pci_dev_resource_n(dev, resno); resource_size_t min; @@ -149,9 +150,9 @@ static int __pci_assign_resource(struct min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM; /* First, try exact prefetching match.. */ - ret = pci_bus_alloc_resource(bus, res, size, align, min, + ret = pci_bus_alloc_resource_fit(bus, res, size, align, min, IORESOURCE_PREFETCH, - pcibios_align_resource, dev); + pcibios_align_resource, dev, fit); if (ret < 0 && (res->flags & IORESOURCE_PREFETCH)) { /* @@ -160,8 +161,8 @@ static int __pci_assign_resource(struct * But a prefetching area can handle a non-prefetching * window (it will just not perform as well). */ - ret = pci_bus_alloc_resource(bus, res, size, align, min, 0, - pcibios_align_resource, dev); + ret = pci_bus_alloc_resource_fit(bus, res, size, align, min, 0, + pcibios_align_resource, dev, fit); } return ret; } @@ -218,7 +219,8 @@ static int pci_revert_fw_address(struct return ret; } -static int _pci_assign_resource(struct pci_dev *dev, int resno, int size, resource_size_t min_align) +static int _pci_assign_resource(struct pci_dev *dev, int resno, int size, + resource_size_t min_align, bool fit) { struct resource *res = pci_dev_resource_n(dev, resno); struct pci_bus *bus; @@ -226,7 +228,8 @@ static int _pci_assign_resource(struct p char *type; bus = dev->bus; - while ((ret = __pci_assign_resource(bus, dev, resno, size, min_align))) { + while ((ret = __pci_assign_resource(bus, dev, resno, size, + min_align, fit))) { if (!bus->parent || !bus->self->transparent) break; bus = bus->parent; @@ -265,7 +268,7 @@ int pci_reassign_resource(struct pci_dev /* already aligned with min_align */ new_size = resource_size(res) + addsize; - ret = _pci_assign_resource(dev, resno, new_size, min_align); + ret = _pci_assign_resource(dev, resno, new_size, min_align, false); if (!ret) { res->flags &= ~IORESOURCE_STARTALIGN; dev_info(&dev->dev, "BAR %d: reassigned %pR\n", resno, res); @@ -275,7 +278,7 @@ int pci_reassign_resource(struct pci_dev return ret; } -int pci_assign_resource(struct pci_dev *dev, int resno) +int pci_assign_resource_fit(struct pci_dev *dev, int resno, bool fit) { struct resource *res = pci_dev_resource_n(dev, resno); resource_size_t align, size; @@ -291,7 +294,7 @@ int pci_assign_resource(struct pci_dev * bus = dev->bus; size = resource_size(res); - ret = _pci_assign_resource(dev, resno, size, align); + ret = _pci_assign_resource(dev, resno, size, align, fit); /* * If we failed to assign anything, let's try the address @@ -310,6 +313,11 @@ int pci_assign_resource(struct pci_dev * return ret; } +int pci_assign_resource(struct pci_dev *dev, int resno) +{ + return pci_assign_resource_fit(dev, resno, false); +} + int pci_enable_resources(struct pci_dev *dev, int mask) { u16 cmd, old_cmd; Index: linux-2.6/include/linux/ioport.h =================================================================== --- linux-2.6.orig/include/linux/ioport.h +++ linux-2.6/include/linux/ioport.h @@ -156,6 +156,14 @@ extern int allocate_resource(struct reso resource_size_t, resource_size_t), void *alignf_data); +int allocate_resource_fit(struct resource *root, struct resource *new, + resource_size_t size, resource_size_t min, + resource_size_t max, resource_size_t align, + resource_size_t (*alignf)(void *, + const struct resource *, + resource_size_t, + resource_size_t), + void *alignf_data, bool fit); void resource_shrink_parents_top(struct resource *b_res, long size, struct resource *parent_res); struct device; Index: linux-2.6/include/linux/pci.h =================================================================== --- linux-2.6.orig/include/linux/pci.h +++ linux-2.6/include/linux/pci.h @@ -914,6 +914,7 @@ int __pci_reset_function_locked(struct p int pci_reset_function(struct pci_dev *dev); void pci_update_resource(struct pci_dev *dev, int resno); int __must_check pci_assign_resource(struct pci_dev *dev, int i); +int __must_check pci_assign_resource_fit(struct pci_dev *dev, int i, bool fit); int __must_check pci_reassign_resource(struct pci_dev *dev, int i, resource_size_t add_size, resource_size_t align); int pci_select_bars(struct pci_dev *dev, unsigned long flags); @@ -1032,6 +1033,15 @@ int __must_check pci_bus_alloc_resource( resource_size_t, resource_size_t), void *alignf_data); +int __must_check pci_bus_alloc_resource_fit(struct pci_bus *bus, + struct resource *res, resource_size_t size, + resource_size_t align, resource_size_t min, + unsigned int type_mask, + resource_size_t (*alignf)(void *, + const struct resource *, + resource_size_t, + resource_size_t), + void *alignf_data, bool fit); void pci_enable_bridges(struct pci_bus *bus); /* Proper probing supporting hot-pluggable devices */ [-- Attachment #5: save_big_align.patch --] [-- Type: application/octet-stream, Size: 1097 bytes --] Subject: [PATCH] resource: only return range with needed align Compare align between put range in head and tail, pick small one to leave big one for future user. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- kernel/resource.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) Index: linux-2.6/kernel/resource.c =================================================================== --- linux-2.6.orig/kernel/resource.c +++ linux-2.6/kernel/resource.c @@ -506,8 +506,20 @@ out: } if (!ret) { - new->start = avail_start; + /* compare which one have max order */ + new->start = round_down(avail_start + avail_size - size, + constraint->align); + new->end = avail_start + avail_size - 1; + new->start = constraint->alignf(constraint->alignf_data, new, + size, constraint->align); new->end = new->start + size - 1; + + if (new->start < avail_start || + new->end > (avail_start + avail_size - 1) || + __ffs64(new->start) >= __ffs64(avail_start)) { + new->start = avail_start; + new->end = new->start + size - 1; + } } return ret; } ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-13 8:26 ` Yinghai Lu @ 2012-04-13 8:34 ` Steven Newbury 2012-04-13 11:45 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 8:34 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu <yinghai@kernel.org> wrote: > On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury <steve@snewbury.org.uk> > wrote: > > > > > > > > It would be useful to preserve as much low PCI memory address > > > > space as possible for hotplug devices (like my Radeon), but the > > > > other problem is small regions get allocated at the bottom, > > > > resulting in the inability to find large aligned regions later on. > > > > I see code to default to top-down allocation was reverted, I > > > > guess I'm going to have to dig into the archive to find out why... > > Please check attached patches that will find_resource with fit. It may > leave space for your hotplug devices. > > PCI: Should add children device res to fail list > PCI: Try to allocate mem64 above 4G at first > intel-gtt: Read 64bit for gmar_bus_addr > PCI: Make sure assign same align with large size resource at first > resource: make find_resource could return just fit resource > PCI: Don't allocate small resource in big empty space. > resource: only return range with needed align > > You can get them from > > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-pci-res-alloc > Thanks Yinghai, I'll give it a spin. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-13 8:26 ` Yinghai Lu 2012-04-13 8:34 ` Steven Newbury @ 2012-04-13 11:45 ` Steven Newbury 2012-04-13 11:58 ` Steven Newbury 1 sibling, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-13 11:45 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 1830 bytes --] On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu <yinghai@kernel.org> wrote: > On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury <steve@snewbury.org.uk> > wrote: > > > > > > > > It would be useful to preserve as much low PCI memory address > > > > space as possible for hotplug devices (like my Radeon), but the > > > > other problem is small regions get allocated at the bottom, > > > > resulting in the inability to find large aligned regions later on. > > > > I see code to default to top-down allocation was reverted, I > > > > guess I'm going to have to dig into the archive to find out why... > > Please check attached patches that will find_resource with fit. It may > leave space for your hotplug devices. > > PCI: Should add children device res to fail list > PCI: Try to allocate mem64 above 4G at first > intel-gtt: Read 64bit for gmar_bus_addr > PCI: Make sure assign same align with large size resource at first > resource: make find_resource could return just fit resource > PCI: Don't allocate small resource in big empty space. > resource: only return range with needed align > > You can get them from > > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-pci-res-alloc I pulled this in on top of a branch with any of the prior PCI patches since they conflict anyway. It's not stable, crashes soon after GMA comes up. (Could be unrelated breakage in linus/master? Probably not but I will verify.) I noticed the high allocations are occuring from the top of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of virtual addressing. Could that be why..? Also, when not docked GMA still isn't mapped high so there's no room for the 256M radeon pref mem. Attached /proc/iomem output for docked and undocked. [-- Attachment #2: iomem.undocked --] [-- Type: text/plain, Size: 2051 bytes --] 00000000-0000ffff : reserved 00010000-0009efff : System RAM 0009f000-0009ffff : reserved 000c0000-000c7fff : Video ROM 000cf000-000cffff : Adapter ROM 000f0000-000fffff : System ROM 00100000-df65a7ff : System RAM 01000000-0136ddbd : Kernel code 0136ddbe-0169127f : Kernel data 0172f000-01809fff : Kernel bss df65a800-dfffffff : reserved df65a800-df6fffff : pnp 00:0d df700000-df7fffff : pnp 00:0d e0000000-efffffff : 0000:00:02.0 f0000000-f01fffff : PCI Bus 0000:0d f0200000-f0200fff : Intel Flush Page f6900000-f69fffff : PCI Bus 0000:09 f69f0000-f69fffff : 0000:09:00.0 f69f0000-f69fffff : tg3 f6a00000-f6bfffff : PCI Bus 0000:0d f6c00000-f6cfffff : PCI Bus 0000:0c f6cfe000-f6cfffff : 0000:0c:00.0 f6cfe000-f6cfffff : iwl4965 f6dfb700-f6dfb7ff : 0000:00:1f.3 f6dfb800-f6dfbfff : 0000:00:1f.2 f6dfb800-f6dfbfff : ahci f6dfc000-f6dfffff : 0000:00:1b.0 f6dfc000-f6dfffff : ICH HD audio f6e00000-f6efffff : 0000:00:02.0 f6f00000-f6ffffff : 0000:00:02.1 f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f] f8000000-fbffffff : reserved f8000000-fbffffff : pnp 00:0d fec00000-fec0ffff : reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:08 fed18000-fed1bfff : reserved fed18000-fed1bfff : pnp 00:0d fed1c000-fed1c3ff : 0000:00:1d.7 fed1c000-fed1c3ff : ehci_hcd fed1c400-fed1c7ff : 0000:00:1a.7 fed1c400-fed1c7ff : ehci_hcd fed20000-fed8ffff : reserved fed20000-fed3ffff : pnp 00:0d fed40000-fed44fff : pnp 00:0a fed45000-fed8ffff : pnp 00:0d feda0000-feda5fff : reserved feda0000-feda3fff : pnp 00:0d feda4000-feda4fff : pnp 00:0d feda5000-feda5fff : pnp 00:0d feda6000-feda6fff : pnp 00:0d fee00000-fee0ffff : reserved fee00000-fee0ffff : pnp 00:0d fee00000-fee00fff : Local APIC ffa00000-ffbfffff : pnp 00:0d ffc00000-ffdfffff : PCI Bus 0000:0b ffe00000-ffffffff : reserved ffe00000-ffffffff : pnp 00:0d 100000000-11fffffff : System RAM fffa00000-fffbfffff : PCI Bus 0000:09 fffc00000-fffdfffff : PCI Bus 0000:0c fffe00000-fffffffff : PCI Bus 0000:0b [-- Attachment #3: iomem.test --] [-- Type: text/plain, Size: 2390 bytes --] 00000000-0000ffff : reserved 00010000-0009efff : System RAM 0009f000-0009ffff : reserved 000c0000-000c7fff : Video ROM 000cf000-000cffff : Adapter ROM 000f0000-000fffff : System ROM 00100000-df65a7ff : System RAM 01000000-0136ddbd : Kernel code 0136ddbe-0169127f : Kernel data 0172f000-01809fff : Kernel bss df65a800-dfffffff : reserved df65a800-df6fffff : pnp 00:0e df700000-df7fffff : pnp 00:0e e0000000-efffffff : PCI Bus 0000:03 e0000000-efffffff : PCI Bus 0000:04 e0000000-efffffff : 0000:04:00.0 f0000000-f0000fff : Intel Flush Page f6700000-f68fffff : PCI Bus 0000:03 f6700000-f68fffff : PCI Bus 0000:04 f67dc000-f67dffff : 0000:04:00.1 f67dc000-f67dffff : ICH HD audio f67e0000-f67fffff : 0000:04:00.0 f6800000-f681ffff : 0000:04:00.0 f6900000-f69fffff : PCI Bus 0000:09 f69f0000-f69fffff : 0000:09:00.0 f69f0000-f69fffff : tg3 f6a00000-f6bfffff : PCI Bus 0000:0d f6c00000-f6cfffff : PCI Bus 0000:0c f6cfe000-f6cfffff : 0000:0c:00.0 f6cfe000-f6cfffff : iwl4965 f6dfb700-f6dfb7ff : 0000:00:1f.3 f6dfb800-f6dfbfff : 0000:00:1f.2 f6dfb800-f6dfbfff : ahci f6dfc000-f6dfffff : 0000:00:1b.0 f6dfc000-f6dfffff : ICH HD audio f6e00000-f6efffff : 0000:00:02.0 f6f00000-f6ffffff : 0000:00:02.1 f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f] f8000000-fbffffff : reserved f8000000-fbffffff : pnp 00:0e fec00000-fec0ffff : reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:08 fed18000-fed1bfff : reserved fed18000-fed1bfff : pnp 00:0e fed1c000-fed1c3ff : 0000:00:1d.7 fed1c000-fed1c3ff : ehci_hcd fed1c400-fed1c7ff : 0000:00:1a.7 fed1c400-fed1c7ff : ehci_hcd fed20000-fed8ffff : reserved fed20000-fed3ffff : pnp 00:0e fed40000-fed44fff : pnp 00:0b fed45000-fed8ffff : pnp 00:0e feda0000-feda5fff : reserved feda0000-feda3fff : pnp 00:0e feda4000-feda4fff : pnp 00:0e feda5000-feda5fff : pnp 00:0e feda6000-feda6fff : pnp 00:0e fee00000-fee0ffff : reserved fee00000-fee0ffff : pnp 00:0e fee00000-fee00fff : Local APIC ffa00000-ffbfffff : pnp 00:0e ffc00000-ffdfffff : PCI Bus 0000:0b ffe00000-ffffffff : reserved ffe00000-ffffffff : pnp 00:0e 100000000-11fffffff : System RAM fef800000-fef9fffff : PCI Bus 0000:09 fefa00000-fefbfffff : PCI Bus 0000:0d fefc00000-fefdfffff : PCI Bus 0000:0c fefe00000-fefffffff : PCI Bus 0000:0b ff0000000-fffffffff : 0000:00:02.0 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-13 11:45 ` Steven Newbury @ 2012-04-13 11:58 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 11:58 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 12:45, Steven Newbury wrote: > On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu <yinghai@kernel.org> > wrote: > >> On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury >> <steve@snewbury.org.uk> wrote: >>>>> >>>>> It would be useful to preserve as much low PCI memory >>>>> address space as possible for hotplug devices (like my >>>>> Radeon), but the other problem is small regions get >>>>> allocated at the bottom, resulting in the inability to find >>>>> large aligned regions later on. I see code to default to >>>>> top-down allocation was reverted, I guess I'm going to have >>>>> to dig into the archive to find out why... >> >> Please check attached patches that will find_resource with fit. >> It may leave space for your hotplug devices. >> >> PCI: Should add children device res to fail list PCI: Try to >> allocate mem64 above 4G at first intel-gtt: Read 64bit for >> gmar_bus_addr PCI: Make sure assign same align with large size >> resource at first resource: make find_resource could return just >> fit resource PCI: Don't allocate small resource in big empty >> space. resource: only return range with needed align >> >> You can get them from >> >> >> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git >> >> for-pci-res-alloc > > I pulled this in on top of a branch with any of the prior PCI > patches since they conflict anyway. > > It's not stable, crashes soon after GMA comes up. (Could be > unrelated breakage in linus/master? Probably not but I will > verify.) I noticed the high allocations are occuring from the top > of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of > virtual addressing. Could that be why..? To reply to myself again, I should have said crashes shortly after Xorg initialises using the intel driver, in both cases! I'm building a kernel now without the patch set to see if it's unrelated. If it still dies I'll try applying your patch set to a branch without the changes from linus/master... (should have done that anyway...) > > Also, when not docked GMA still isn't mapped high so there's no > room for the 256M radeon pref mem. > > Attached /proc/iomem output for docked and undocked. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IFPcACgkQGcb56gMuC61f9ACfQc9AqY5YVMEDAvdufMkSpg9b cbsAnRm6sA7VGfmzTyOldSJfV6Qt6ea8 =RGn5 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-13 11:58 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 11:58 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 12:45, Steven Newbury wrote: > On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu <yinghai@kernel.org> > wrote: > >> On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury >> <steve@snewbury.org.uk> wrote: >>>>> >>>>> It would be useful to preserve as much low PCI memory >>>>> address space as possible for hotplug devices (like my >>>>> Radeon), but the other problem is small regions get >>>>> allocated at the bottom, resulting in the inability to find >>>>> large aligned regions later on. I see code to default to >>>>> top-down allocation was reverted, I guess I'm going to have >>>>> to dig into the archive to find out why... >> >> Please check attached patches that will find_resource with fit. >> It may leave space for your hotplug devices. >> >> PCI: Should add children device res to fail list PCI: Try to >> allocate mem64 above 4G at first intel-gtt: Read 64bit for >> gmar_bus_addr PCI: Make sure assign same align with large size >> resource at first resource: make find_resource could return just >> fit resource PCI: Don't allocate small resource in big empty >> space. resource: only return range with needed align >> >> You can get them from >> >> >> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git >> >> for-pci-res-alloc > > I pulled this in on top of a branch with any of the prior PCI > patches since they conflict anyway. > > It's not stable, crashes soon after GMA comes up. (Could be > unrelated breakage in linus/master? Probably not but I will > verify.) I noticed the high allocations are occuring from the top > of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of > virtual addressing. Could that be why..? To reply to myself again, I should have said crashes shortly after Xorg initialises using the intel driver, in both cases! I'm building a kernel now without the patch set to see if it's unrelated. If it still dies I'll try applying your patch set to a branch without the changes from linus/master... (should have done that anyway...) > > Also, when not docked GMA still isn't mapped high so there's no > room for the 256M radeon pref mem. > > Attached /proc/iomem output for docked and undocked. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IFPcACgkQGcb56gMuC61f9ACfQc9AqY5YVMEDAvdufMkSpg9b cbsAnRm6sA7VGfmzTyOldSJfV6Qt6ea8 =RGn5 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-13 11:58 ` Steven Newbury @ 2012-04-13 12:49 ` Steven Newbury -1 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 12:49 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 12:58, Steven Newbury wrote: >> It's not stable, crashes soon after GMA comes up. (Could be >> unrelated breakage in linus/master? Probably not but I will >> verify.) I noticed the high allocations are occuring from the >> top of 64-bit address-space, whilst /proc/cpuinfo shows only 48 >> bits of virtual addressing. Could that be why..? > To reply to myself again, I should have said crashes shortly after > Xorg initialises using the intel driver, in both cases! I'm > building a kernel now without the patch set to see if it's > unrelated. If it still dies I'll try applying your patch set to a > branch without the changes from linus/master... (should have done > that anyway...) > Okay, I instead created a branch from an older 3.4-rc1+ kernel tree, running it now, and it seems to be stable. Something perhaps in the newer tree not playing nicely. I'll see if I can bisect it, or at least base of rc2 if that works... (I'm a little wary of crashing the system too much and losing my btrfs filesystem...) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IIPAACgkQGcb56gMuC62tVQCgmCXiVuGmHa5wNbWHA6FRG8Sy AJEAn3n+92rMqzSINTh8b4AWnpDSGYew =opYH -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-13 12:49 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 12:49 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 12:58, Steven Newbury wrote: >> It's not stable, crashes soon after GMA comes up. (Could be >> unrelated breakage in linus/master? Probably not but I will >> verify.) I noticed the high allocations are occuring from the >> top of 64-bit address-space, whilst /proc/cpuinfo shows only 48 >> bits of virtual addressing. Could that be why..? > To reply to myself again, I should have said crashes shortly after > Xorg initialises using the intel driver, in both cases! I'm > building a kernel now without the patch set to see if it's > unrelated. If it still dies I'll try applying your patch set to a > branch without the changes from linus/master... (should have done > that anyway...) > Okay, I instead created a branch from an older 3.4-rc1+ kernel tree, running it now, and it seems to be stable. Something perhaps in the newer tree not playing nicely. I'll see if I can bisect it, or at least base of rc2 if that works... (I'm a little wary of crashing the system too much and losing my btrfs filesystem...) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IIPAACgkQGcb56gMuC62tVQCgmCXiVuGmHa5wNbWHA6FRG8Sy AJEAn3n+92rMqzSINTh8b4AWnpDSGYew =opYH -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-13 12:49 ` Steven Newbury @ 2012-04-13 13:26 ` Steven Newbury -1 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 13:26 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 13:49, Steven Newbury wrote: > On 13/04/12 12:58, Steven Newbury wrote: > >>> It's not stable, crashes soon after GMA comes up. (Could be >>> unrelated breakage in linus/master? Probably not but I will >>> verify.) I noticed the high allocations are occuring from the >>> top of 64-bit address-space, whilst /proc/cpuinfo shows only >>> 48 bits of virtual addressing. Could that be why..? >> To reply to myself again, I should have said crashes shortly >> after Xorg initialises using the intel driver, in both cases! >> I'm building a kernel now without the patch set to see if it's >> unrelated. If it still dies I'll try applying your patch set to >> a branch without the changes from linus/master... (should have >> done that anyway...) > > Okay, I instead created a branch from an older 3.4-rc1+ kernel > tree, running it now, and it seems to be stable. Something perhaps > in the newer tree not playing nicely. I'll see if I can bisect it, > or at least base of rc2 if that works... (I'm a little wary of > crashing the system too much and losing my btrfs filesystem...) rc2 is fine as well. Not sure what happened there, I need to be more careful about keeping a clean tree to work from. Any idea about how to force the GMA >4G when the BIOS hasn't put it into the middle of SystemRAM? (as it does when docked) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IKXsACgkQGcb56gMuC62+gACeLDg30iJiukq1pSfu2M1GJzZj xGQAn0DekMqnLcrKXXn7rMwGFgRzJrsC =k+WB -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-13 13:26 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 13:26 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 13:49, Steven Newbury wrote: > On 13/04/12 12:58, Steven Newbury wrote: > >>> It's not stable, crashes soon after GMA comes up. (Could be >>> unrelated breakage in linus/master? Probably not but I will >>> verify.) I noticed the high allocations are occuring from the >>> top of 64-bit address-space, whilst /proc/cpuinfo shows only >>> 48 bits of virtual addressing. Could that be why..? >> To reply to myself again, I should have said crashes shortly >> after Xorg initialises using the intel driver, in both cases! >> I'm building a kernel now without the patch set to see if it's >> unrelated. If it still dies I'll try applying your patch set to >> a branch without the changes from linus/master... (should have >> done that anyway...) > > Okay, I instead created a branch from an older 3.4-rc1+ kernel > tree, running it now, and it seems to be stable. Something perhaps > in the newer tree not playing nicely. I'll see if I can bisect it, > or at least base of rc2 if that works... (I'm a little wary of > crashing the system too much and losing my btrfs filesystem...) rc2 is fine as well. Not sure what happened there, I need to be more careful about keeping a clean tree to work from. Any idea about how to force the GMA >4G when the BIOS hasn't put it into the middle of SystemRAM? (as it does when docked) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IKXsACgkQGcb56gMuC62+gACeLDg30iJiukq1pSfu2M1GJzZj xGQAn0DekMqnLcrKXXn7rMwGFgRzJrsC =k+WB -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* drm-next i915 regression? ( was: Re: PCI resources above 4GB) 2012-04-13 13:26 ` Steven Newbury (?) @ 2012-04-13 13:52 ` Steven Newbury 2012-04-13 14:08 ` Steven Newbury -1 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-13 13:52 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury <steve@snewbury.org.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 13/04/12 13:49, Steven Newbury wrote: > > On 13/04/12 12:58, Steven Newbury wrote: > > > > > > It's not stable, crashes soon after GMA comes up. (Could be > > > > unrelated breakage in linus/master? Probably not but I will > > > > verify.) I noticed the high allocations are occuring from the > > > > top of 64-bit address-space, whilst /proc/cpuinfo shows only > > > > 48 bits of virtual addressing. Could that be why..? > > > To reply to myself again, I should have said crashes shortly > > > after Xorg initialises using the intel driver, in both cases! > > > I'm building a kernel now without the patch set to see if it's > > > unrelated. If it still dies I'll try applying your patch set to > > > a branch without the changes from linus/master... (should have > > > done that anyway...) > > > > Okay, I instead created a branch from an older 3.4-rc1+ kernel > > tree, running it now, and it seems to be stable. Something perhaps > > in the newer tree not playing nicely. I'll see if I can bisect it, > > or at least base of rc2 if that works... (I'm a little wary of > > crashing the system too much and losing my btrfs filesystem...) > rc2 is fine as well. Not sure what happened there, I need to be more > careful about keeping a clean tree to work from. I'm pretty sure the crash was a from a drm-next regression. I'll try bisecting it.... ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) 2012-04-13 13:52 ` drm-next i915 regression? ( was: Re: PCI resources above 4GB) Steven Newbury @ 2012-04-13 14:08 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 14:08 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 14:52, Steven Newbury wrote: > On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury > <steve@snewbury.org.uk> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 13/04/12 13:49, Steven Newbury wrote: >>> On 13/04/12 12:58, Steven Newbury wrote: >>> >>>>> It's not stable, crashes soon after GMA comes up. (Could be >>>>> unrelated breakage in linus/master? Probably not but I >>>>> will verify.) I noticed the high allocations are occuring >>>>> from the top of 64-bit address-space, whilst /proc/cpuinfo >>>>> shows only 48 bits of virtual addressing. Could that be >>>>> why..? >>>> To reply to myself again, I should have said crashes shortly >>>> after Xorg initialises using the intel driver, in both >>>> cases! I'm building a kernel now without the patch set to see >>>> if it's unrelated. If it still dies I'll try applying your >>>> patch set to a branch without the changes from >>>> linus/master... (should have done that anyway...) >>> >>> Okay, I instead created a branch from an older 3.4-rc1+ kernel >>> tree, running it now, and it seems to be stable. Something >>> perhaps in the newer tree not playing nicely. I'll see if I >>> can bisect it, or at least base of rc2 if that works... (I'm a >>> little wary of crashing the system too much and losing my btrfs >>> filesystem...) >> rc2 is fine as well. Not sure what happened there, I need to be >> more careful about keeping a clean tree to work from. > I'm pretty sure the crash was a from a drm-next regression. I'll > try bisecting it.... Sorry, posted too soon! Almost as I clicked on send it froze again (using rc2 + for-pci-res-alloc ). I had problems with the earlier patches re. X/i915 stability. Strange. I'll see if I can track it down. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IM2QACgkQGcb56gMuC63IqACgpvN/bOqt/DWR45Kq00D4T2m0 tGoAn0cSN1eNxiHSF1eIRJgkGT/VmJy4 =/wQF -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) @ 2012-04-13 14:08 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 14:08 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 14:52, Steven Newbury wrote: > On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury > <steve@snewbury.org.uk> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 13/04/12 13:49, Steven Newbury wrote: >>> On 13/04/12 12:58, Steven Newbury wrote: >>> >>>>> It's not stable, crashes soon after GMA comes up. (Could be >>>>> unrelated breakage in linus/master? Probably not but I >>>>> will verify.) I noticed the high allocations are occuring >>>>> from the top of 64-bit address-space, whilst /proc/cpuinfo >>>>> shows only 48 bits of virtual addressing. Could that be >>>>> why..? >>>> To reply to myself again, I should have said crashes shortly >>>> after Xorg initialises using the intel driver, in both >>>> cases! I'm building a kernel now without the patch set to see >>>> if it's unrelated. If it still dies I'll try applying your >>>> patch set to a branch without the changes from >>>> linus/master... (should have done that anyway...) >>> >>> Okay, I instead created a branch from an older 3.4-rc1+ kernel >>> tree, running it now, and it seems to be stable. Something >>> perhaps in the newer tree not playing nicely. I'll see if I >>> can bisect it, or at least base of rc2 if that works... (I'm a >>> little wary of crashing the system too much and losing my btrfs >>> filesystem...) >> rc2 is fine as well. Not sure what happened there, I need to be >> more careful about keeping a clean tree to work from. > I'm pretty sure the crash was a from a drm-next regression. I'll > try bisecting it.... Sorry, posted too soon! Almost as I clicked on send it froze again (using rc2 + for-pci-res-alloc ). I had problems with the earlier patches re. X/i915 stability. Strange. I'll see if I can track it down. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IM2QACgkQGcb56gMuC63IqACgpvN/bOqt/DWR45Kq00D4T2m0 tGoAn0cSN1eNxiHSF1eIRJgkGT/VmJy4 =/wQF -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) 2012-04-13 14:08 ` Steven Newbury (?) @ 2012-04-13 14:13 ` Daniel Vetter 2012-04-13 14:19 ` Steven Newbury -1 siblings, 1 reply; 94+ messages in thread From: Daniel Vetter @ 2012-04-13 14:13 UTC (permalink / raw) To: Steven Newbury Cc: linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas, Yinghai Lu On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 13/04/12 14:52, Steven Newbury wrote: > > On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury > > <steve@snewbury.org.uk> wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> > >> On 13/04/12 13:49, Steven Newbury wrote: > >>> On 13/04/12 12:58, Steven Newbury wrote: > >>> > >>>>> It's not stable, crashes soon after GMA comes up. (Could be > >>>>> unrelated breakage in linus/master? Probably not but I > >>>>> will verify.) I noticed the high allocations are occuring > >>>>> from the top of 64-bit address-space, whilst /proc/cpuinfo > >>>>> shows only 48 bits of virtual addressing. Could that be > >>>>> why..? > >>>> To reply to myself again, I should have said crashes shortly > >>>> after Xorg initialises using the intel driver, in both > >>>> cases! I'm building a kernel now without the patch set to see > >>>> if it's unrelated. If it still dies I'll try applying your > >>>> patch set to a branch without the changes from > >>>> linus/master... (should have done that anyway...) > >>> > >>> Okay, I instead created a branch from an older 3.4-rc1+ kernel > >>> tree, running it now, and it seems to be stable. Something > >>> perhaps in the newer tree not playing nicely. I'll see if I > >>> can bisect it, or at least base of rc2 if that works... (I'm a > >>> little wary of crashing the system too much and losing my btrfs > >>> filesystem...) > >> rc2 is fine as well. Not sure what happened there, I need to be > >> more careful about keeping a clean tree to work from. > > I'm pretty sure the crash was a from a drm-next regression. I'll > > try bisecting it.... > Sorry, posted too soon! Almost as I clicked on send it froze again > (using rc2 + for-pci-res-alloc ). I had problems with the earlier > patches re. X/i915 stability. Strange. I'll see if I can track it down. Please upgrade to the latest version of Linus' upstream git. A few fixes for regressions in drm/i915 just landed there for -rc3. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) 2012-04-13 14:13 ` Daniel Vetter @ 2012-04-13 14:19 ` Steven Newbury 2012-04-13 15:23 ` Steven Newbury 0 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-13 14:19 UTC (permalink / raw) To: Daniel Vetter Cc: linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas, Yinghai Lu -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 15:13, Daniel Vetter wrote: > On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 13/04/12 14:52, Steven Newbury wrote: >>> On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury >>> <steve@snewbury.org.uk> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 13/04/12 13:49, Steven Newbury wrote: >>>>> On 13/04/12 12:58, Steven Newbury wrote: >>>>> >>>>>>> It's not stable, crashes soon after GMA comes up. >>>>>>> (Could be unrelated breakage in linus/master? Probably >>>>>>> not but I will verify.) I noticed the high >>>>>>> allocations are occuring from the top of 64-bit >>>>>>> address-space, whilst /proc/cpuinfo shows only 48 bits >>>>>>> of virtual addressing. Could that be why..? >>>>>> To reply to myself again, I should have said crashes >>>>>> shortly after Xorg initialises using the intel driver, in >>>>>> both cases! I'm building a kernel now without the patch >>>>>> set to see if it's unrelated. If it still dies I'll try >>>>>> applying your patch set to a branch without the changes >>>>>> from linus/master... (should have done that anyway...) >>>>> >>>>> Okay, I instead created a branch from an older 3.4-rc1+ >>>>> kernel tree, running it now, and it seems to be stable. >>>>> Something perhaps in the newer tree not playing nicely. >>>>> I'll see if I can bisect it, or at least base of rc2 if >>>>> that works... (I'm a little wary of crashing the system too >>>>> much and losing my btrfs filesystem...) >>>> rc2 is fine as well. Not sure what happened there, I need >>>> to be more careful about keeping a clean tree to work from. >>> I'm pretty sure the crash was a from a drm-next regression. >>> I'll try bisecting it.... >> Sorry, posted too soon! Almost as I clicked on send it froze >> again (using rc2 + for-pci-res-alloc ). I had problems with the >> earlier patches re. X/i915 stability. Strange. I'll see if I >> can track it down. > > Please upgrade to the latest version of Linus' upstream git. A few > fixes for regressions in drm/i915 just landed there for -rc3. > -Daniel Okay. I'll try clean latest linus + for-pci-res-alloc. Will report back. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+INg4ACgkQGcb56gMuC60pJgCfS/g2k3mzIqU34de/Y4wTvfCP +hwAmQEEdgQ/y0QvDbPffNZ6izqs2Dce =EGwB -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) 2012-04-13 14:19 ` Steven Newbury @ 2012-04-13 15:23 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 15:23 UTC (permalink / raw) To: Daniel Vetter Cc: linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas, Yinghai Lu [-- Attachment #1: Type: text/plain, Size: 2748 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 15:19, Steven Newbury wrote: > On 13/04/12 15:13, Daniel Vetter wrote: >> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 13/04/12 14:52, Steven Newbury wrote: >>>> On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury >>>> <steve@snewbury.org.uk> wrote: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> >>>>> On 13/04/12 13:49, Steven Newbury wrote: >>>>>> On 13/04/12 12:58, Steven Newbury wrote: >>>>>> >>>>>>>> It's not stable, crashes soon after GMA comes up. >>>>>>>> (Could be unrelated breakage in linus/master? >>>>>>>> Probably not but I will verify.) I noticed the >>>>>>>> high allocations are occuring from the top of 64-bit >>>>>>>> address-space, whilst /proc/cpuinfo shows only 48 >>>>>>>> bits of virtual addressing. Could that be why..? >>>>>>> To reply to myself again, I should have said crashes >>>>>>> shortly after Xorg initialises using the intel driver, >>>>>>> in both cases! I'm building a kernel now without the >>>>>>> patch set to see if it's unrelated. If it still dies >>>>>>> I'll try applying your patch set to a branch without >>>>>>> the changes from linus/master... (should have done that >>>>>>> anyway...) >>>>>> >>>>>> Okay, I instead created a branch from an older 3.4-rc1+ >>>>>> kernel tree, running it now, and it seems to be stable. >>>>>> Something perhaps in the newer tree not playing nicely. >>>>>> I'll see if I can bisect it, or at least base of rc2 if >>>>>> that works... (I'm a little wary of crashing the system >>>>>> too much and losing my btrfs filesystem...) >>>>> rc2 is fine as well. Not sure what happened there, I >>>>> need to be more careful about keeping a clean tree to work >>>>> from. >>>> I'm pretty sure the crash was a from a drm-next regression. >>>> I'll try bisecting it.... >>> Sorry, posted too soon! Almost as I clicked on send it froze >>> again (using rc2 + for-pci-res-alloc ). I had problems with >>> the earlier patches re. X/i915 stability. Strange. I'll see >>> if I can track it down. > >> Please upgrade to the latest version of Linus' upstream git. A >> few fixes for regressions in drm/i915 just landed there for -rc3. >> -Daniel > > Okay. I'll try clean latest linus + for-pci-res-alloc. Will > report back. > Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IROAACgkQGcb56gMuC63hFQCguhdhV6AUoNKHnasgD0zjqJXt AwkAoKh8Rdrj3PqzuYUXpUkvyw3TujZV =XiAW -----END PGP SIGNATURE----- [-- Attachment #2: oops --] [-- Type: text/plain, Size: 8355 bytes --] Apr 13 15:10:02 infinity kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Apr 13 15:10:02 infinity kernel: IP: [<ffffffffa02778d0>] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: PGD 7bfb2067 PUD d8978067 PMD 0 Apr 13 15:10:02 infinity kernel: Oops: 0000 [#1] SMP Apr 13 15:10:02 infinity kernel: CPU 1 Apr 13 15:10:02 infinity kernel: Modules linked in: cryptd aes_x86_64 aes_generic fuse fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font tileblit joydev arc4 dell_wmi sparse_keymap 8250_pnp dell_laptop dcdbas btusb bluetooth snd_hda_codec_idt crc16 microcode psmouse pcspkr iwl4965 iwlegacy snd_hda_intel mac80211 snd_hda_codec snd_hwdep tg3 snd_pcm cfg80211 snd_page_alloc snd_timer snd soundcore wmi 8250 serial_core evdev smsc47m192 hwmon_vid tpm_tis tpm tpm_bios rfkill loop nfs nfs_acl auth_rpcgss fscache lockd sunrpc phc_intel mperf coretemp hwmon autofs4 usb_storage usb_libusual uas btrfs zlib_deflate sd_mod pata_acpi ahci libahci ata_piix libata scsi_mod ehci_hcd uhci_hcd usbcore usb_common i915 video intel_agp intel_gtt cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight drm_kms_helper drm agpgart Apr 13 15:10:02 infinity kernel: Apr 13 15:10:02 infinity kernel: Pid: 2591, comm: btrfs-endio-2 Not tainted 3.4.0-rc2-wl-00669-g502ad46 #110 Dell Inc. Latitude D830 /0HN341 Apr 13 15:10:02 infinity kernel: RIP: 0010:[<ffffffffa02778d0>] [<ffffffffa02778d0>] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: RSP: 0018:ffff880078e7fcc0 EFLAGS: 00010207 Apr 13 15:10:02 infinity kernel: RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffff88007bde9000 Apr 13 15:10:02 infinity kernel: RDX: ffffffffa029d500 RSI: dead000000200200 RDI: ffffffffa029d4f6 Apr 13 15:10:02 infinity kernel: RBP: ffff880078e7fd50 R08: 0000000000000008 R09: 0000000000004000 Apr 13 15:10:02 infinity kernel: R10: 0000000000000200 R11: 0000000000000200 R12: ffff880078e7fcf8 Apr 13 15:10:02 infinity kernel: R13: ffffffffa029d504 R14: ffffffffa029d4f6 R15: ffff880078e7fd10 Apr 13 15:10:02 infinity kernel: FS: 0000000000000000(0000) GS:ffff88011fd00000(0000) knlGS:0000000000000000 Apr 13 15:10:02 infinity kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Apr 13 15:10:02 infinity kernel: CR2: 0000000000000000 CR3: 000000007bfe6000 CR4: 00000000000007e0 Apr 13 15:10:02 infinity kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Apr 13 15:10:02 infinity kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Apr 13 15:10:02 infinity kernel: Process btrfs-endio-2 (pid: 2591, threadinfo ffff880078e7e000, task ffff880119880000) Apr 13 15:10:02 infinity kernel: Stack: Apr 13 15:10:02 infinity kernel: ffff880078e7fcd0 ffffffff810bcacf ffff880119880000 ffffffffa029d500 Apr 13 15:10:02 infinity kernel: 0000000200000003 ffffffffa029d548 ffff880078e7fd00 ffffffff811a1060 Apr 13 15:10:02 infinity kernel: ffff880078e7fd20 ffffffff811764f9 0000000000000200 ffff880078e7fd40 Apr 13 15:10:02 infinity kernel: Call Trace: Apr 13 15:10:02 infinity kernel: [<ffffffff810bcacf>] ? mempool_free_slab+0x17/0x19 Apr 13 15:10:02 infinity kernel: [<ffffffff811a1060>] ? __crc32c_le+0x10/0x12 Apr 13 15:10:02 infinity kernel: [<ffffffff811764f9>] ? chksum_update+0x19/0x24 Apr 13 15:10:02 infinity kernel: [<ffffffffa02785ee>] btrfs_decompress_biovec+0x2b/0x7c [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffffa027874e>] end_compressed_bio_read+0x10f/0x19d [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffff81123ccd>] bio_endio+0x2d/0x2f Apr 13 15:10:02 infinity kernel: [<ffffffffa023beb2>] end_workqueue_fn+0x38/0x3d [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffffa02696f8>] worker_loop+0x16e/0x4a2 [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffffa026958a>] ? btrfs_queue_worker+0x281/0x281 [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffff8104c0e6>] kthread+0x8b/0x93 Apr 13 15:10:02 infinity kernel: [<ffffffff8136b734>] kernel_thread_helper+0x4/0x10 Apr 13 15:10:02 infinity kernel: [<ffffffff8104c05b>] ? kthread_freezable_should_stop+0x48/0x48 Apr 13 15:10:02 infinity kernel: [<ffffffff8136b730>] ? gs_change+0xb/0xb Apr 13 15:10:02 infinity kernel: Code: 65 48 8b 04 25 80 b8 00 00 48 89 45 80 4c 89 f7 e8 be 20 0f e1 48 8b 55 88 48 8b 02 48 39 d0 74 3d 48 be 00 02 20 00 00 00 ad de <48> 8b 08 48 8b 50 08 48 89 51 08 48 89 0a 48 b9 00 01 10 00 00 Apr 13 15:10:02 infinity kernel: RIP [<ffffffffa02778d0>] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: RSP <ffff880078e7fcc0> Apr 13 15:10:02 infinity kernel: CR2: 0000000000000000 Apr 13 15:10:02 infinity kernel: ---[ end trace 2e6b178742035e68 ]--- Apr 13 15:10:07 infinity kernel: ICMPv6 RA: ndisc_router_discovery() failed to add default route. Apr 13 15:10:17 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:10:22 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:10:22 infinity NetworkManager[1019]: <info> Clearing nscd hosts cache. Apr 13 15:10:22 infinity NetworkManager[1019]: <info> Clearing nscd hosts cache. Apr 13 15:10:22 infinity NetworkManager[1019]: <info> Policy set 'snewbury.org.uk' (wlan0) as default for IPv4 routing and DNS. Apr 13 15:10:22 infinity NetworkManager[1019]: <info> Policy set 'snewbury.org.uk' (wlan0) as default for IPv6 routing and DNS. Apr 13 15:10:22 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:10:41 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:10:47 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:11:03 infinity kernel: INFO: rcu_sched self-detected stall on CPU { 1} (t=60000 jiffies) Apr 13 15:11:03 infinity kernel: Pid: 819, comm: btrfs-endio-2 Tainted: G D 3.4.0-rc2-wl-00669-g502ad46 #110 Apr 13 15:11:03 infinity kernel: Call Trace: Apr 13 15:11:03 infinity kernel: <IRQ> [<ffffffff81093d0f>] __rcu_pending+0xc2/0x3c4 Apr 13 15:11:03 infinity kernel: [<ffffffff8109403a>] rcu_pending+0x29/0x5a Apr 13 15:11:03 infinity kernel: [<ffffffff81094686>] rcu_check_callbacks+0x57/0x76 Apr 13 15:11:03 infinity kernel: [<ffffffff8103e5a1>] update_process_times+0x3f/0x76 Apr 13 15:11:03 infinity kernel: [<ffffffff8106ed0f>] tick_sched_timer+0x70/0x90 Apr 13 15:11:03 infinity kernel: [<ffffffff8104f401>] __run_hrtimer+0xad/0x151 Apr 13 15:11:03 infinity kernel: [<ffffffff8106ec9f>] ? tick_nohz_handler+0xce/0xce Apr 13 15:11:03 infinity kernel: [<ffffffff8104fb6c>] hrtimer_interrupt+0xe0/0x19d Apr 13 15:11:03 infinity kernel: [<ffffffff8136bf7c>] smp_apic_timer_interrupt+0x77/0x8a Apr 13 15:11:03 infinity kernel: [<ffffffff8136b0c7>] apic_timer_interrupt+0x67/0x70 Apr 13 15:11:03 infinity kernel: <EOI> [<ffffffff81073e3f>] ? do_raw_spin_lock+0x17/0x1d Apr 13 15:11:03 infinity kernel: [<ffffffff81369986>] _raw_spin_lock+0xe/0x10 Apr 13 15:11:03 infinity kernel: [<ffffffffa02778ba>] find_workspace+0x7c/0x190 [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffff811a1060>] ? __crc32c_le+0x10/0x12 Apr 13 15:11:03 infinity kernel: [<ffffffff811764f9>] ? chksum_update+0x19/0x24 Apr 13 15:11:03 infinity kernel: [<ffffffffa02785ee>] btrfs_decompress_biovec+0x2b/0x7c [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffffa027874e>] end_compressed_bio_read+0x10f/0x19d [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffff81123ccd>] bio_endio+0x2d/0x2f Apr 13 15:11:03 infinity kernel: [<ffffffffa023beb2>] end_workqueue_fn+0x38/0x3d [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffffa02696f8>] worker_loop+0x16e/0x4a2 [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffffa026958a>] ? btrfs_queue_worker+0x281/0x281 [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffff8104c0e6>] kthread+0x8b/0x93 Apr 13 15:11:03 infinity kernel: [<ffffffff8136b734>] kernel_thread_helper+0x4/0x10 Apr 13 15:11:03 infinity kernel: [<ffffffff8104c05b>] ? kthread_freezable_should_stop+0x48/0x48 Apr 13 15:11:03 infinity kernel: [<ffffffff8136b730>] ? gs_change+0xb/0xb ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) @ 2012-04-13 15:23 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 15:23 UTC (permalink / raw) To: Daniel Vetter Cc: linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas, Yinghai Lu [-- Attachment #1: Type: text/plain, Size: 2748 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 15:19, Steven Newbury wrote: > On 13/04/12 15:13, Daniel Vetter wrote: >> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 13/04/12 14:52, Steven Newbury wrote: >>>> On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury >>>> <steve@snewbury.org.uk> wrote: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> >>>>> On 13/04/12 13:49, Steven Newbury wrote: >>>>>> On 13/04/12 12:58, Steven Newbury wrote: >>>>>> >>>>>>>> It's not stable, crashes soon after GMA comes up. >>>>>>>> (Could be unrelated breakage in linus/master? >>>>>>>> Probably not but I will verify.) I noticed the >>>>>>>> high allocations are occuring from the top of 64-bit >>>>>>>> address-space, whilst /proc/cpuinfo shows only 48 >>>>>>>> bits of virtual addressing. Could that be why..? >>>>>>> To reply to myself again, I should have said crashes >>>>>>> shortly after Xorg initialises using the intel driver, >>>>>>> in both cases! I'm building a kernel now without the >>>>>>> patch set to see if it's unrelated. If it still dies >>>>>>> I'll try applying your patch set to a branch without >>>>>>> the changes from linus/master... (should have done that >>>>>>> anyway...) >>>>>> >>>>>> Okay, I instead created a branch from an older 3.4-rc1+ >>>>>> kernel tree, running it now, and it seems to be stable. >>>>>> Something perhaps in the newer tree not playing nicely. >>>>>> I'll see if I can bisect it, or at least base of rc2 if >>>>>> that works... (I'm a little wary of crashing the system >>>>>> too much and losing my btrfs filesystem...) >>>>> rc2 is fine as well. Not sure what happened there, I >>>>> need to be more careful about keeping a clean tree to work >>>>> from. >>>> I'm pretty sure the crash was a from a drm-next regression. >>>> I'll try bisecting it.... >>> Sorry, posted too soon! Almost as I clicked on send it froze >>> again (using rc2 + for-pci-res-alloc ). I had problems with >>> the earlier patches re. X/i915 stability. Strange. I'll see >>> if I can track it down. > >> Please upgrade to the latest version of Linus' upstream git. A >> few fixes for regressions in drm/i915 just landed there for -rc3. >> -Daniel > > Okay. I'll try clean latest linus + for-pci-res-alloc. Will > report back. > Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IROAACgkQGcb56gMuC63hFQCguhdhV6AUoNKHnasgD0zjqJXt AwkAoKh8Rdrj3PqzuYUXpUkvyw3TujZV =XiAW -----END PGP SIGNATURE----- [-- Attachment #2: oops --] [-- Type: text/plain, Size: 8357 bytes --] Apr 13 15:10:02 infinity kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Apr 13 15:10:02 infinity kernel: IP: [<ffffffffa02778d0>] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: PGD 7bfb2067 PUD d8978067 PMD 0 Apr 13 15:10:02 infinity kernel: Oops: 0000 [#1] SMP Apr 13 15:10:02 infinity kernel: CPU 1 Apr 13 15:10:02 infinity kernel: Modules linked in: cryptd aes_x86_64 aes_generic fuse fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font tileblit joydev arc4 dell_wmi sparse_keymap 8250_pnp dell_laptop dcdbas btusb bluetooth snd_hda_codec_idt crc16 microcode psmouse pcspkr iwl4965 iwlegacy snd_hda_intel mac80211 snd_hda_codec snd_hwdep tg3 snd_pcm cfg80211 snd_page_alloc snd_timer snd soundcore wmi 8250 serial_core evdev smsc47m192 hwmon_vid tpm_tis tpm tpm_bios rfkill loop nfs nfs_acl auth_rpcgss fscache lockd sunrpc phc_intel mperf coretemp hwmon autofs4 usb_storage usb_libusual uas btrfs zlib_deflate sd_mod pata_acpi ahci libahci ata_piix libata scsi_mod ehci_hcd uhci_hcd usbcore usb_common i915 video intel_agp intel_gtt cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bi t backlight drm_kms_helper drm agpgart Apr 13 15:10:02 infinity kernel: Apr 13 15:10:02 infinity kernel: Pid: 2591, comm: btrfs-endio-2 Not tainted 3.4.0-rc2-wl-00669-g502ad46 #110 Dell Inc. Latitude D830 /0HN341 Apr 13 15:10:02 infinity kernel: RIP: 0010:[<ffffffffa02778d0>] [<ffffffffa02778d0>] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: RSP: 0018:ffff880078e7fcc0 EFLAGS: 00010207 Apr 13 15:10:02 infinity kernel: RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffff88007bde9000 Apr 13 15:10:02 infinity kernel: RDX: ffffffffa029d500 RSI: dead000000200200 RDI: ffffffffa029d4f6 Apr 13 15:10:02 infinity kernel: RBP: ffff880078e7fd50 R08: 0000000000000008 R09: 0000000000004000 Apr 13 15:10:02 infinity kernel: R10: 0000000000000200 R11: 0000000000000200 R12: ffff880078e7fcf8 Apr 13 15:10:02 infinity kernel: R13: ffffffffa029d504 R14: ffffffffa029d4f6 R15: ffff880078e7fd10 Apr 13 15:10:02 infinity kernel: FS: 0000000000000000(0000) GS:ffff88011fd00000(0000) knlGS:0000000000000000 Apr 13 15:10:02 infinity kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Apr 13 15:10:02 infinity kernel: CR2: 0000000000000000 CR3: 000000007bfe6000 CR4: 00000000000007e0 Apr 13 15:10:02 infinity kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Apr 13 15:10:02 infinity kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Apr 13 15:10:02 infinity kernel: Process btrfs-endio-2 (pid: 2591, threadinfo ffff880078e7e000, task ffff880119880000) Apr 13 15:10:02 infinity kernel: Stack: Apr 13 15:10:02 infinity kernel: ffff880078e7fcd0 ffffffff810bcacf ffff880119880000 ffffffffa029d500 Apr 13 15:10:02 infinity kernel: 0000000200000003 ffffffffa029d548 ffff880078e7fd00 ffffffff811a1060 Apr 13 15:10:02 infinity kernel: ffff880078e7fd20 ffffffff811764f9 0000000000000200 ffff880078e7fd40 Apr 13 15:10:02 infinity kernel: Call Trace: Apr 13 15:10:02 infinity kernel: [<ffffffff810bcacf>] ? mempool_free_slab+0x17/0x19 Apr 13 15:10:02 infinity kernel: [<ffffffff811a1060>] ? __crc32c_le+0x10/0x12 Apr 13 15:10:02 infinity kernel: [<ffffffff811764f9>] ? chksum_update+0x19/0x24 Apr 13 15:10:02 infinity kernel: [<ffffffffa02785ee>] btrfs_decompress_biovec+0x2b/0x7c [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffffa027874e>] end_compressed_bio_read+0x10f/0x19d [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffff81123ccd>] bio_endio+0x2d/0x2f Apr 13 15:10:02 infinity kernel: [<ffffffffa023beb2>] end_workqueue_fn+0x38/0x3d [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffffa02696f8>] worker_loop+0x16e/0x4a2 [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffffa026958a>] ? btrfs_queue_worker+0x281/0x281 [btrfs] Apr 13 15:10:02 infinity kernel: [<ffffffff8104c0e6>] kthread+0x8b/0x93 Apr 13 15:10:02 infinity kernel: [<ffffffff8136b734>] kernel_thread_helper+0x4/0x10 Apr 13 15:10:02 infinity kernel: [<ffffffff8104c05b>] ? kthread_freezable_should_stop+0x48/0x48 Apr 13 15:10:02 infinity kernel: [<ffffffff8136b730>] ? gs_change+0xb/0xb Apr 13 15:10:02 infinity kernel: Code: 65 48 8b 04 25 80 b8 00 00 48 89 45 80 4c 89 f7 e8 be 20 0f e1 48 8b 55 88 48 8b 02 48 39 d0 74 3d 48 be 00 02 20 00 00 00 ad de <48> 8b 08 48 8b 50 08 48 89 51 08 48 89 0a 48 b9 00 01 10 00 00 Apr 13 15:10:02 infinity kernel: RIP [<ffffffffa02778d0>] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: RSP <ffff880078e7fcc0> Apr 13 15:10:02 infinity kernel: CR2: 0000000000000000 Apr 13 15:10:02 infinity kernel: ---[ end trace 2e6b178742035e68 ]--- Apr 13 15:10:07 infinity kernel: ICMPv6 RA: ndisc_router_discovery() failed to add default route. Apr 13 15:10:17 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:10:22 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:10:22 infinity NetworkManager[1019]: <info> Clearing nscd hosts cache. Apr 13 15:10:22 infinity NetworkManager[1019]: <info> Clearing nscd hosts cache. Apr 13 15:10:22 infinity NetworkManager[1019]: <info> Policy set 'snewbury.org.uk' (wlan0) as default for IPv4 routing and DNS. Apr 13 15:10:22 infinity NetworkManager[1019]: <info> Policy set 'snewbury.org.uk' (wlan0) as default for IPv6 routing and DNS. Apr 13 15:10:22 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:10:41 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:10:47 infinity NetworkManager[1019]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed Apr 13 15:11:03 infinity kernel: INFO: rcu_sched self-detected stall on CPU { 1} (t=60000 jiffies) Apr 13 15:11:03 infinity kernel: Pid: 819, comm: btrfs-endio-2 Tainted: G D 3.4.0-rc2-wl-00669-g502ad46 #110 Apr 13 15:11:03 infinity kernel: Call Trace: Apr 13 15:11:03 infinity kernel: <IRQ> [<ffffffff81093d0f>] __rcu_pending+0xc2/0x3c4 Apr 13 15:11:03 infinity kernel: [<ffffffff8109403a>] rcu_pending+0x29/0x5a Apr 13 15:11:03 infinity kernel: [<ffffffff81094686>] rcu_check_callbacks+0x57/0x76 Apr 13 15:11:03 infinity kernel: [<ffffffff8103e5a1>] update_process_times+0x3f/0x76 Apr 13 15:11:03 infinity kernel: [<ffffffff8106ed0f>] tick_sched_timer+0x70/0x90 Apr 13 15:11:03 infinity kernel: [<ffffffff8104f401>] __run_hrtimer+0xad/0x151 Apr 13 15:11:03 infinity kernel: [<ffffffff8106ec9f>] ? tick_nohz_handler+0xce/0xce Apr 13 15:11:03 infinity kernel: [<ffffffff8104fb6c>] hrtimer_interrupt+0xe0/0x19d Apr 13 15:11:03 infinity kernel: [<ffffffff8136bf7c>] smp_apic_timer_interrupt+0x77/0x8a Apr 13 15:11:03 infinity kernel: [<ffffffff8136b0c7>] apic_timer_interrupt+0x67/0x70 Apr 13 15:11:03 infinity kernel: <EOI> [<ffffffff81073e3f>] ? do_raw_spin_lock+0x17/0x1d Apr 13 15:11:03 infinity kernel: [<ffffffff81369986>] _raw_spin_lock+0xe/0x10 Apr 13 15:11:03 infinity kernel: [<ffffffffa02778ba>] find_workspace+0x7c/0x190 [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffff811a1060>] ? __crc32c_le+0x10/0x12 Apr 13 15:11:03 infinity kernel: [<ffffffff811764f9>] ? chksum_update+0x19/0x24 Apr 13 15:11:03 infinity kernel: [<ffffffffa02785ee>] btrfs_decompress_biovec+0x2b/0x7c [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffffa027874e>] end_compressed_bio_read+0x10f/0x19d [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffff81123ccd>] bio_endio+0x2d/0x2f Apr 13 15:11:03 infinity kernel: [<ffffffffa023beb2>] end_workqueue_fn+0x38/0x3d [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffffa02696f8>] worker_loop+0x16e/0x4a2 [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffffa026958a>] ? btrfs_queue_worker+0x281/0x281 [btrfs] Apr 13 15:11:03 infinity kernel: [<ffffffff8104c0e6>] kthread+0x8b/0x93 Apr 13 15:11:03 infinity kernel: [<ffffffff8136b734>] kernel_thread_helper+0x4/0x10 Apr 13 15:11:03 infinity kernel: [<ffffffff8104c05b>] ? kthread_freezable_should_stop+0x48/0x48 Apr 13 15:11:03 infinity kernel: [<ffffffff8136b730>] ? gs_change+0xb/0xb ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) 2012-04-13 15:23 ` Steven Newbury (?) @ 2012-04-13 15:49 ` Steven Newbury 2012-04-13 16:17 ` Yinghai Lu -1 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-13 15:49 UTC (permalink / raw) To: Daniel Vetter Cc: linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas, Yinghai Lu -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 16:23, Steven Newbury wrote: > On 13/04/12 15:19, Steven Newbury wrote: >> On 13/04/12 15:13, Daniel Vetter wrote: >>> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury >>> wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 13/04/12 14:52, Steven Newbury wrote: >>>>> On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury >>>>> <steve@snewbury.org.uk> wrote: >>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> >>>>>> On 13/04/12 13:49, Steven Newbury wrote: >>>>>>> On 13/04/12 12:58, Steven Newbury wrote: >>>>>>> >>>>>>>>> It's not stable, crashes soon after GMA comes up. >>>>>>>>> (Could be unrelated breakage in linus/master? >>>>>>>>> Probably not but I will verify.) I noticed the >>>>>>>>> high allocations are occuring from the top of >>>>>>>>> 64-bit address-space, whilst /proc/cpuinfo shows >>>>>>>>> only 48 bits of virtual addressing. Could that be >>>>>>>>> why..? >>>>>>>> To reply to myself again, I should have said crashes >>>>>>>> shortly after Xorg initialises using the intel >>>>>>>> driver, in both cases! I'm building a kernel now >>>>>>>> without the patch set to see if it's unrelated. If >>>>>>>> it still dies I'll try applying your patch set to a >>>>>>>> branch without the changes from linus/master... >>>>>>>> (should have done that anyway...) >>>>>>> >>>>>>> Okay, I instead created a branch from an older 3.4-rc1+ >>>>>>> kernel tree, running it now, and it seems to be >>>>>>> stable. Something perhaps in the newer tree not playing >>>>>>> nicely. I'll see if I can bisect it, or at least base >>>>>>> of rc2 if that works... (I'm a little wary of crashing >>>>>>> the system too much and losing my btrfs filesystem...) >>>>>> rc2 is fine as well. Not sure what happened there, I >>>>>> need to be more careful about keeping a clean tree to >>>>>> work from. >>>>> I'm pretty sure the crash was a from a drm-next regression. >>>>> I'll try bisecting it.... >>>> Sorry, posted too soon! Almost as I clicked on send it froze >>>> again (using rc2 + for-pci-res-alloc ). I had problems with >>>> the earlier patches re. X/i915 stability. Strange. I'll >>>> see if I can track it down. > >>> Please upgrade to the latest version of Linus' upstream git. A >>> few fixes for regressions in drm/i915 just landed there for >>> -rc3. -Daniel > >> Okay. I'll try clean latest linus + for-pci-res-alloc. Will >> report back. > > Looks like either a btrfs regression or bad interaction with > for-pci-res-alloc. Oops attached. Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried earlier so it's not definitely something new in the btrfs code. Seems like it's a 64/32bit pointer issue?? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ISyEACgkQGcb56gMuC63uRwCcCLm8yx1YVnTBSvT/9jx/IqEb WcYAoJh5iceqZvDDGdJHV88YwEyEnM32 =jfup -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) 2012-04-13 15:49 ` Steven Newbury @ 2012-04-13 16:17 ` Yinghai Lu 2012-04-13 17:12 ` btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)] Steven Newbury 2012-04-13 17:38 ` drm-next i915 regression? ( was: Re: PCI resources above 4GB) Steven Newbury 0 siblings, 2 replies; 94+ messages in thread From: Yinghai Lu @ 2012-04-13 16:17 UTC (permalink / raw) To: Steven Newbury Cc: Daniel Vetter, linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas >> Looks like either a btrfs regression or bad interaction with >> for-pci-res-alloc. Oops attached. > Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried > earlier so it's not definitely something new in the btrfs code. Seems > like it's a 64/32bit pointer issue?? for-pci-res-alloc include for-pci-hostbridge-cleanup for-pci-busn-alloc for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 patches. maybe there is some problem with for-pci-for-each-res-addon. just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please check if the problem still there. Thanks Yinghai ^ permalink raw reply [flat|nested] 94+ messages in thread
* btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)] 2012-04-13 16:17 ` Yinghai Lu @ 2012-04-13 17:12 ` Steven Newbury 2012-04-13 17:38 ` drm-next i915 regression? ( was: Re: PCI resources above 4GB) Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 17:12 UTC (permalink / raw) To: Yinghai Lu Cc: Daniel Vetter, linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 17:17, Yinghai Lu wrote: >>> Looks like either a btrfs regression or bad interaction with >>> for-pci-res-alloc. Oops attached. >> Just hit the same oops on the rc1+for-pci-res-alloc kernel I >> tried earlier so it's not definitely something new in the btrfs >> code. Seems like it's a 64/32bit pointer issue?? > > for-pci-res-alloc include > > for-pci-hostbridge-cleanup for-pci-busn-alloc > for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 > patches. > > maybe there is some problem with for-pci-for-each-res-addon. > > just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please > check if the problem still there. > > Thanks > > Yinghai BTW, previously, I was based on your for-pci-busn-alloc branch, didn't see any problems there. Recompiling now with a clean merge of updated for-pci-res-alloc on top of my linus tracking branch... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IXpEACgkQGcb56gMuC63ubwCgkyr2d4Xp/4OpLo4ehIYrabtO /SgAoKDaYPOxX9qRznUjUIoYAmPF3thA =s+mx -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) 2012-04-13 16:17 ` Yinghai Lu 2012-04-13 17:12 ` btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)] Steven Newbury @ 2012-04-13 17:38 ` Steven Newbury 2012-04-13 18:12 ` Steven Newbury 1 sibling, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-13 17:38 UTC (permalink / raw) To: Yinghai Lu Cc: Daniel Vetter, linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 17:17, Yinghai Lu wrote: >>> Looks like either a btrfs regression or bad interaction with >>> for-pci-res-alloc. Oops attached. >> Just hit the same oops on the rc1+for-pci-res-alloc kernel I >> tried earlier so it's not definitely something new in the btrfs >> code. Seems like it's a 64/32bit pointer issue?? > > for-pci-res-alloc include > > for-pci-hostbridge-cleanup for-pci-busn-alloc > for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 > patches. > > maybe there is some problem with for-pci-for-each-res-addon. > > just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please > check if the problem still there. > Still Oopses. I'm going to try linus/master. Perhaps it's a filesystem corruption triggering it? I do find it a little suspicious that it occurs in "btrfs:find_workspace" though, code which deals with memory allocations... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IZHsACgkQGcb56gMuC62WhQCgkVBccCKKLqjL1S7f+4wzXnT7 DbsAn2wQNiQLGo95Q3W9bWu6n5Q3xqr8 =Rtn+ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB) 2012-04-13 17:38 ` drm-next i915 regression? ( was: Re: PCI resources above 4GB) Steven Newbury @ 2012-04-13 18:12 ` Steven Newbury 2012-04-13 21:51 ` Btrfs corruption Oops " Steven Newbury 0 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-04-13 18:12 UTC (permalink / raw) To: Yinghai Lu Cc: Daniel Vetter, linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 18:38, Steven Newbury wrote: > On 13/04/12 17:17, Yinghai Lu wrote: >>>> Looks like either a btrfs regression or bad interaction with >>>> for-pci-res-alloc. Oops attached. >>> Just hit the same oops on the rc1+for-pci-res-alloc kernel I >>> tried earlier so it's not definitely something new in the >>> btrfs code. Seems like it's a 64/32bit pointer issue?? > >> for-pci-res-alloc include > >> for-pci-hostbridge-cleanup for-pci-busn-alloc >> for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 >> patches. > >> maybe there is some problem with for-pci-for-each-res-addon. > >> just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please >> check if the problem still there. > > Still Oopses. I'm going to try linus/master. Perhaps it's a > filesystem corruption triggering it? I do find it a little > suspicious that it occurs in "btrfs:find_workspace" though, code > which deals with memory allocations... Damn. It still oopses with my linus tracking branch! I'm going to restore from backup and see if it still happens. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IbJ8ACgkQGcb56gMuC60bVQCfbIQEd+kpJBrXdeiz/sfJOCC2 f9oAnA4DYSOD1ApvbMl937dxG2i6SYDv =uZ3A -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Btrfs corruption Oops ( was: Re: PCI resources above 4GB) 2012-04-13 18:12 ` Steven Newbury @ 2012-04-13 21:51 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-13 21:51 UTC (permalink / raw) To: Yinghai Lu Cc: Daniel Vetter, linux-pci, DRI mailing list, Barnes, Jesse, Bjorn Helgaas -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/12 19:12, Steven Newbury wrote: > On 13/04/12 18:38, Steven Newbury wrote: >> On 13/04/12 17:17, Yinghai Lu wrote: >>>>> Looks like either a btrfs regression or bad interaction >>>>> with for-pci-res-alloc. Oops attached. >>>> Just hit the same oops on the rc1+for-pci-res-alloc kernel I >>>> tried earlier so it's not definitely something new in the >>>> btrfs code. Seems like it's a 64/32bit pointer issue?? > >>> for-pci-res-alloc include > >>> for-pci-hostbridge-cleanup for-pci-busn-alloc >>> for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 >>> patches. > >>> maybe there is some problem with for-pci-for-each-res-addon. > >>> just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. >>> Please check if the problem still there. > >> Still Oopses. I'm going to try linus/master. Perhaps it's a >> filesystem corruption triggering it? I do find it a little >> suspicious that it occurs in "btrfs:find_workspace" though, code >> which deals with memory allocations... > Damn. It still oopses with my linus tracking branch! I'm going to > restore from backup and see if it still happens. It was filesystem corruption. Running rsync triggered it on a couple of files. Strangely btrfs scrub found no errors. I'll forward the oops to the btrfs list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+In/EACgkQGcb56gMuC60OdwCfTxJXzutYj6MGO7itU7ZSi5et lvgAoKBfJk3Z3Kn4UJBq5Zlg2PvqM6Oi =1Rqu -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-12 16:40 ` Steven Newbury @ 2012-04-14 17:37 ` Steven Newbury 2012-04-14 17:37 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 17:37 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 3545 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/12 17:40, Steven Newbury wrote: > On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu <yinghai@kernel.org> > wrote: > >> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >> <steve@snewbury.org.uk> wrote: >>> Thanks, that fixed it! :) I had a similar patch I've been >>> working on but I had my fix in the wrong place! >>> >>> In the working case, initially the BIOS has set GMA to within >>> the low system DRAM 0xC0000000 obviously invalid. This >>> conflict is detected and it's relallocated to 0x12000000. >>> >>> I've attempted to modify probe.c to disable 64-bit BARs not >>> allocated above 4G so they get reallocated above when possible >>> later. It seemed to work, but again broke GMA despite the BAR >>> originally containing an invalid address as mentioned above, it >>> seems for some reason something is different when the conflict >>> is detected and rellocated, compared to disabling it early then >>> allocating a valid value..? >>> I've created a new quirk utilising an extra PCI resource flag to force reallocation of the resource. It's the first approach I've had any success at. It does work. Only "Intel Page Flush" now gets allocated @0xe0000000! 00000000-0000ffff : reserved 00010000-0009efff : System RAM 0009f000-0009ffff : reserved 000c0000-000c7fff : Video ROM 000cf000-000cffff : Adapter ROM 000f0000-000fffff : System ROM 00100000-df65a7ff : System RAM 01000000-0136defd : Kernel code 0136defe-0169127f : Kernel data 0172f000-01809fff : Kernel bss df65a800-dfffffff : reserved df65a800-df6fffff : pnp 00:0d df700000-df7fffff : pnp 00:0d e0000000-e0000fff : Intel Flush Page f0000000-f01fffff : PCI Bus 0000:0d f6900000-f69fffff : PCI Bus 0000:09 f69f0000-f69fffff : 0000:09:00.0 f69f0000-f69fffff : tg3 f6a00000-f6bfffff : PCI Bus 0000:0d f6c00000-f6cfffff : PCI Bus 0000:0c f6cfe000-f6cfffff : 0000:0c:00.0 f6cfe000-f6cfffff : iwl4965 f6dfb700-f6dfb7ff : 0000:00:1f.3 f6dfb800-f6dfbfff : 0000:00:1f.2 f6dfb800-f6dfbfff : ahci f6dfc000-f6dfffff : 0000:00:1b.0 f6dfc000-f6dfffff : ICH HD audio f6e00000-f6efffff : 0000:00:02.0 f6f00000-f6ffffff : 0000:00:02.1 f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f] f8000000-fbffffff : reserved f8000000-fbffffff : pnp 00:0d fec00000-fec0ffff : reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:08 fed18000-fed1bfff : reserved fed18000-fed1bfff : pnp 00:0d fed1c000-fed1c3ff : 0000:00:1d.7 fed1c000-fed1c3ff : ehci_hcd fed1c400-fed1c7ff : 0000:00:1a.7 fed1c400-fed1c7ff : ehci_hcd fed20000-fed8ffff : reserved fed20000-fed3ffff : pnp 00:0d fed40000-fed44fff : pnp 00:0a fed45000-fed8ffff : pnp 00:0d feda0000-feda5fff : reserved feda0000-feda3fff : pnp 00:0d feda4000-feda4fff : pnp 00:0d feda5000-feda5fff : pnp 00:0d feda6000-feda6fff : pnp 00:0d fee00000-fee0ffff : reserved fee00000-fee0ffff : pnp 00:0d fee00000-fee00fff : Local APIC ffa00000-ffbfffff : pnp 00:0d ffc00000-ffdfffff : PCI Bus 0000:0b ffe00000-ffffffff : reserved ffe00000-ffffffff : pnp 00:0d 100000000-11fffffff : System RAM fefa00000-fefbfffff : PCI Bus 0000:09 fefc00000-fefdfffff : PCI Bus 0000:0c fefe00000-fefffffff : PCI Bus 0000:0b ff0000000-fffffffff : 0000:00:02.0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JtegACgkQGcb56gMuC61LDgCeO1gr1XT4iL4FK6QXrUq4E4SV LgwAnR4zdEVkVcfJ2nebHc2++tfi8UsK =QJc+ -----END PGP SIGNATURE----- [-- Attachment #2: hack_to_force_realloc.diff --] [-- Type: text/x-patch, Size: 2629 bytes --] commit 7063b1e2145bca02bbdd807d3c2ca97748deb73a Author: Steven Newbury <steve@snewbury.org.uk> Date: Sat Apr 14 13:25:14 2012 +0100 Add a new PCI resource flag to force a conflict for a given resource, use this new flag with a quirk to trigger reallocation over >4G. diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index a24d473..820dc1e 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -32,6 +32,20 @@ #include "pci.h" /* + * Force reallocation >4G (if available) for intel GMA + */ +static void __devinit quirk_intel_gma_realloc(struct pci_dev * dev) +{ + if (sizeof(resource_size_t) == 8) { + struct resource *r = &dev->resource [2]; + if (r->start < 0x100000000) { + r->flags |= IORESOURCE_MEM_FORCEREALLOC; + } + } +} +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a02, quirk_intel_gma_realloc); + +/* * Decoding should be disabled for a PCI device during BAR sizing to avoid * conflict. But doing so may cause problems on host bridge and perhaps other * key system devices. For devices that need to have mmio decoding always-on, diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index ea96ced..aad43c3 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -116,6 +116,8 @@ int pci_claim_resource(struct pci_dev *dev, int resource) conflict = request_resource_conflict(root, res); if (conflict) { + if (res->flags & IORESOURCE_MEM_FORCEREALLOC) + res->flags &= ~IORESOURCE_MEM_FORCEREALLOC; dev_info(&dev->dev, "address space collision: %pR conflicts with %s %pR\n", res, conflict->name, conflict); diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 8f8433d..a4159f6 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -89,6 +89,7 @@ struct resource { #define IORESOURCE_MEM_32BIT (3<<3) #define IORESOURCE_MEM_SHADOWABLE (1<<5) /* dup: IORESOURCE_SHADOWABLE */ #define IORESOURCE_MEM_EXPANSIONROM (1<<6) +#define IORESOURCE_MEM_FORCEREALLOC (1<<7) /* Force rellocation of this resource */ /* PnP I/O specific bits (IORESOURCE_BITS) */ #define IORESOURCE_IO_16BIT_ADDR (1<<0) diff --git a/kernel/resource.c b/kernel/resource.c index 9cbfc40..770d713 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -156,6 +156,8 @@ static struct resource * __request_resource(struct resource *root, struct resour resource_size_t end = new->end; struct resource *tmp, **p; + if (new->flags & IORESOURCE_MEM_FORCEREALLOC) + return root; if (end < start) return root; if (start < root->start) ^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-14 17:37 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 17:37 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 3545 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/12 17:40, Steven Newbury wrote: > On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu <yinghai@kernel.org> > wrote: > >> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >> <steve@snewbury.org.uk> wrote: >>> Thanks, that fixed it! :) I had a similar patch I've been >>> working on but I had my fix in the wrong place! >>> >>> In the working case, initially the BIOS has set GMA to within >>> the low system DRAM 0xC0000000 obviously invalid. This >>> conflict is detected and it's relallocated to 0x12000000. >>> >>> I've attempted to modify probe.c to disable 64-bit BARs not >>> allocated above 4G so they get reallocated above when possible >>> later. It seemed to work, but again broke GMA despite the BAR >>> originally containing an invalid address as mentioned above, it >>> seems for some reason something is different when the conflict >>> is detected and rellocated, compared to disabling it early then >>> allocating a valid value..? >>> I've created a new quirk utilising an extra PCI resource flag to force reallocation of the resource. It's the first approach I've had any success at. It does work. Only "Intel Page Flush" now gets allocated @0xe0000000! 00000000-0000ffff : reserved 00010000-0009efff : System RAM 0009f000-0009ffff : reserved 000c0000-000c7fff : Video ROM 000cf000-000cffff : Adapter ROM 000f0000-000fffff : System ROM 00100000-df65a7ff : System RAM 01000000-0136defd : Kernel code 0136defe-0169127f : Kernel data 0172f000-01809fff : Kernel bss df65a800-dfffffff : reserved df65a800-df6fffff : pnp 00:0d df700000-df7fffff : pnp 00:0d e0000000-e0000fff : Intel Flush Page f0000000-f01fffff : PCI Bus 0000:0d f6900000-f69fffff : PCI Bus 0000:09 f69f0000-f69fffff : 0000:09:00.0 f69f0000-f69fffff : tg3 f6a00000-f6bfffff : PCI Bus 0000:0d f6c00000-f6cfffff : PCI Bus 0000:0c f6cfe000-f6cfffff : 0000:0c:00.0 f6cfe000-f6cfffff : iwl4965 f6dfb700-f6dfb7ff : 0000:00:1f.3 f6dfb800-f6dfbfff : 0000:00:1f.2 f6dfb800-f6dfbfff : ahci f6dfc000-f6dfffff : 0000:00:1b.0 f6dfc000-f6dfffff : ICH HD audio f6e00000-f6efffff : 0000:00:02.0 f6f00000-f6ffffff : 0000:00:02.1 f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f] f8000000-fbffffff : reserved f8000000-fbffffff : pnp 00:0d fec00000-fec0ffff : reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:08 fed18000-fed1bfff : reserved fed18000-fed1bfff : pnp 00:0d fed1c000-fed1c3ff : 0000:00:1d.7 fed1c000-fed1c3ff : ehci_hcd fed1c400-fed1c7ff : 0000:00:1a.7 fed1c400-fed1c7ff : ehci_hcd fed20000-fed8ffff : reserved fed20000-fed3ffff : pnp 00:0d fed40000-fed44fff : pnp 00:0a fed45000-fed8ffff : pnp 00:0d feda0000-feda5fff : reserved feda0000-feda3fff : pnp 00:0d feda4000-feda4fff : pnp 00:0d feda5000-feda5fff : pnp 00:0d feda6000-feda6fff : pnp 00:0d fee00000-fee0ffff : reserved fee00000-fee0ffff : pnp 00:0d fee00000-fee00fff : Local APIC ffa00000-ffbfffff : pnp 00:0d ffc00000-ffdfffff : PCI Bus 0000:0b ffe00000-ffffffff : reserved ffe00000-ffffffff : pnp 00:0d 100000000-11fffffff : System RAM fefa00000-fefbfffff : PCI Bus 0000:09 fefc00000-fefdfffff : PCI Bus 0000:0c fefe00000-fefffffff : PCI Bus 0000:0b ff0000000-fffffffff : 0000:00:02.0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JtegACgkQGcb56gMuC61LDgCeO1gr1XT4iL4FK6QXrUq4E4SV LgwAnR4zdEVkVcfJ2nebHc2++tfi8UsK =QJc+ -----END PGP SIGNATURE----- [-- Attachment #2: hack_to_force_realloc.diff --] [-- Type: text/x-patch, Size: 2629 bytes --] commit 7063b1e2145bca02bbdd807d3c2ca97748deb73a Author: Steven Newbury <steve@snewbury.org.uk> Date: Sat Apr 14 13:25:14 2012 +0100 Add a new PCI resource flag to force a conflict for a given resource, use this new flag with a quirk to trigger reallocation over >4G. diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index a24d473..820dc1e 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -32,6 +32,20 @@ #include "pci.h" /* + * Force reallocation >4G (if available) for intel GMA + */ +static void __devinit quirk_intel_gma_realloc(struct pci_dev * dev) +{ + if (sizeof(resource_size_t) == 8) { + struct resource *r = &dev->resource [2]; + if (r->start < 0x100000000) { + r->flags |= IORESOURCE_MEM_FORCEREALLOC; + } + } +} +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a02, quirk_intel_gma_realloc); + +/* * Decoding should be disabled for a PCI device during BAR sizing to avoid * conflict. But doing so may cause problems on host bridge and perhaps other * key system devices. For devices that need to have mmio decoding always-on, diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index ea96ced..aad43c3 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -116,6 +116,8 @@ int pci_claim_resource(struct pci_dev *dev, int resource) conflict = request_resource_conflict(root, res); if (conflict) { + if (res->flags & IORESOURCE_MEM_FORCEREALLOC) + res->flags &= ~IORESOURCE_MEM_FORCEREALLOC; dev_info(&dev->dev, "address space collision: %pR conflicts with %s %pR\n", res, conflict->name, conflict); diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 8f8433d..a4159f6 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -89,6 +89,7 @@ struct resource { #define IORESOURCE_MEM_32BIT (3<<3) #define IORESOURCE_MEM_SHADOWABLE (1<<5) /* dup: IORESOURCE_SHADOWABLE */ #define IORESOURCE_MEM_EXPANSIONROM (1<<6) +#define IORESOURCE_MEM_FORCEREALLOC (1<<7) /* Force rellocation of this resource */ /* PnP I/O specific bits (IORESOURCE_BITS) */ #define IORESOURCE_IO_16BIT_ADDR (1<<0) diff --git a/kernel/resource.c b/kernel/resource.c index 9cbfc40..770d713 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -156,6 +156,8 @@ static struct resource * __request_resource(struct resource *root, struct resour resource_size_t end = new->end; struct resource *tmp, **p; + if (new->flags & IORESOURCE_MEM_FORCEREALLOC) + return root; if (end < start) return root; if (start < root->start) ^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-14 17:37 ` Steven Newbury @ 2012-04-14 18:05 ` Steven Newbury -1 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 18:05 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 1622 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 18:37, Steven Newbury wrote: > On 12/04/12 17:40, Steven Newbury wrote: >> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >> <yinghai@kernel.org> wrote: > >>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>> <steve@snewbury.org.uk> wrote: >>>> Thanks, that fixed it! :) I had a similar patch I've been >>>> working on but I had my fix in the wrong place! >>>> >>>> In the working case, initially the BIOS has set GMA to >>>> within the low system DRAM 0xC0000000 obviously invalid. >>>> This conflict is detected and it's relallocated to >>>> 0x12000000. >>>> >>>> I've attempted to modify probe.c to disable 64-bit BARs not >>>> allocated above 4G so they get reallocated above when >>>> possible later. It seemed to work, but again broke GMA >>>> despite the BAR originally containing an invalid address as >>>> mentioned above, it seems for some reason something is >>>> different when the conflict is detected and rellocated, >>>> compared to disabling it early then allocating a valid >>>> value..? >>>> > I've created a new quirk utilising an extra PCI resource flag to > force reallocation of the resource. It's the first approach I've > had any success at. It does work. Only "Intel Page Flush" now > gets allocated @0xe0000000! > > Hopefully this should fix "Intel Flush Page" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JvIQACgkQGcb56gMuC63G3ACgma4pUxuwjAAJ0ACS5A32xFwa k1MAn21y2w6m+Ar+3DwH4Swy1IlicHmN =nBpy -----END PGP SIGNATURE----- [-- Attachment #2: intel-flush-page-fit.diff --] [-- Type: text/x-patch, Size: 943 bytes --] commit ccc1099a1474815f4094e8689ca0b518de464230 Author: Steven Newbury <steve@snewbury.org.uk> Date: Sat Apr 14 19:02:47 2012 +0100 intel-gtt: Use pci_bus_alloc_resource_fit() to allocate "Intel Flush Page". diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c index 77e150e..30b1ea2 100644 --- a/drivers/char/agp/intel-gtt.c +++ b/drivers/char/agp/intel-gtt.c @@ -1036,9 +1036,9 @@ static struct agp_memory *intel_fake_agp_alloc_by_type(size_t pg_count, static int intel_alloc_chipset_flush_resource(void) { int ret; - ret = pci_bus_alloc_resource(intel_private.bridge_dev->bus, &intel_private.ifp_resource, PAGE_SIZE, + ret = pci_bus_alloc_resource_fit(intel_private.bridge_dev->bus, &intel_private.ifp_resource, PAGE_SIZE, PAGE_SIZE, PCIBIOS_MIN_MEM, 0, - pcibios_align_resource, intel_private.bridge_dev); + pcibios_align_resource, intel_private.bridge_dev, 1); return ret; } ^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-14 18:05 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 18:05 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 1622 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 18:37, Steven Newbury wrote: > On 12/04/12 17:40, Steven Newbury wrote: >> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >> <yinghai@kernel.org> wrote: > >>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>> <steve@snewbury.org.uk> wrote: >>>> Thanks, that fixed it! :) I had a similar patch I've been >>>> working on but I had my fix in the wrong place! >>>> >>>> In the working case, initially the BIOS has set GMA to >>>> within the low system DRAM 0xC0000000 obviously invalid. >>>> This conflict is detected and it's relallocated to >>>> 0x12000000. >>>> >>>> I've attempted to modify probe.c to disable 64-bit BARs not >>>> allocated above 4G so they get reallocated above when >>>> possible later. It seemed to work, but again broke GMA >>>> despite the BAR originally containing an invalid address as >>>> mentioned above, it seems for some reason something is >>>> different when the conflict is detected and rellocated, >>>> compared to disabling it early then allocating a valid >>>> value..? >>>> > I've created a new quirk utilising an extra PCI resource flag to > force reallocation of the resource. It's the first approach I've > had any success at. It does work. Only "Intel Page Flush" now > gets allocated @0xe0000000! > > Hopefully this should fix "Intel Flush Page" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JvIQACgkQGcb56gMuC63G3ACgma4pUxuwjAAJ0ACS5A32xFwa k1MAn21y2w6m+Ar+3DwH4Swy1IlicHmN =nBpy -----END PGP SIGNATURE----- [-- Attachment #2: intel-flush-page-fit.diff --] [-- Type: text/x-patch, Size: 943 bytes --] commit ccc1099a1474815f4094e8689ca0b518de464230 Author: Steven Newbury <steve@snewbury.org.uk> Date: Sat Apr 14 19:02:47 2012 +0100 intel-gtt: Use pci_bus_alloc_resource_fit() to allocate "Intel Flush Page". diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c index 77e150e..30b1ea2 100644 --- a/drivers/char/agp/intel-gtt.c +++ b/drivers/char/agp/intel-gtt.c @@ -1036,9 +1036,9 @@ static struct agp_memory *intel_fake_agp_alloc_by_type(size_t pg_count, static int intel_alloc_chipset_flush_resource(void) { int ret; - ret = pci_bus_alloc_resource(intel_private.bridge_dev->bus, &intel_private.ifp_resource, PAGE_SIZE, + ret = pci_bus_alloc_resource_fit(intel_private.bridge_dev->bus, &intel_private.ifp_resource, PAGE_SIZE, PAGE_SIZE, PCIBIOS_MIN_MEM, 0, - pcibios_align_resource, intel_private.bridge_dev); + pcibios_align_resource, intel_private.bridge_dev, 1); return ret; } ^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-14 18:05 ` Steven Newbury @ 2012-04-14 18:42 ` Steven Newbury -1 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 18:42 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 1760 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 19:05, Steven Newbury wrote: > On 14/04/12 18:37, Steven Newbury wrote: >> On 12/04/12 17:40, Steven Newbury wrote: >>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>> <yinghai@kernel.org> wrote: > >>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>> <steve@snewbury.org.uk> wrote: >>>>> Thanks, that fixed it! :) I had a similar patch I've been >>>>> working on but I had my fix in the wrong place! >>>>> >>>>> In the working case, initially the BIOS has set GMA to >>>>> within the low system DRAM 0xC0000000 obviously invalid. >>>>> This conflict is detected and it's relallocated to >>>>> 0x12000000. >>>>> >>>>> I've attempted to modify probe.c to disable 64-bit BARs not >>>>> allocated above 4G so they get reallocated above when >>>>> possible later. It seemed to work, but again broke GMA >>>>> despite the BAR originally containing an invalid address >>>>> as mentioned above, it seems for some reason something is >>>>> different when the conflict is detected and rellocated, >>>>> compared to disabling it early then allocating a valid >>>>> value..? >>>>> >> I've created a new quirk utilising an extra PCI resource flag to >> force reallocation of the resource. It's the first approach >> I've had any success at. It does work. Only "Intel Page Flush" >> now gets allocated @0xe0000000! > > > Hopefully this should fix "Intel Flush Page" Need to export pci_bus_alloc_resource_fit for intel-gtt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JxRMACgkQGcb56gMuC61LegCcCuANujog4iiIziKwFtcCla1s 7BEAoLfLEEXKT1WhboX/m8bMBP90QCgb =zwK6 -----END PGP SIGNATURE----- [-- Attachment #2: export-resource_fit.diff --] [-- Type: text/x-patch, Size: 639 bytes --] commit fe2ccc15c3cd75af2a582dc6e2b4deb544aca307 Author: Steven Newbury <steve@snewbury.org.uk> Date: Sat Apr 14 19:37:32 2012 +0100 PCI: Export pci_bus_alloc_resource_fit() diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c index 6d2b073..acb51bd 100644 --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -391,6 +391,7 @@ void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *), EXPORT_SYMBOL_GPL(pci_walk_bus); EXPORT_SYMBOL(pci_bus_alloc_resource); +EXPORT_SYMBOL(pci_bus_alloc_resource_fit); EXPORT_SYMBOL_GPL(pci_bus_add_device); EXPORT_SYMBOL(pci_bus_add_devices); EXPORT_SYMBOL(pci_enable_bridges); ^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-14 18:42 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 18:42 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 1760 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 19:05, Steven Newbury wrote: > On 14/04/12 18:37, Steven Newbury wrote: >> On 12/04/12 17:40, Steven Newbury wrote: >>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>> <yinghai@kernel.org> wrote: > >>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>> <steve@snewbury.org.uk> wrote: >>>>> Thanks, that fixed it! :) I had a similar patch I've been >>>>> working on but I had my fix in the wrong place! >>>>> >>>>> In the working case, initially the BIOS has set GMA to >>>>> within the low system DRAM 0xC0000000 obviously invalid. >>>>> This conflict is detected and it's relallocated to >>>>> 0x12000000. >>>>> >>>>> I've attempted to modify probe.c to disable 64-bit BARs not >>>>> allocated above 4G so they get reallocated above when >>>>> possible later. It seemed to work, but again broke GMA >>>>> despite the BAR originally containing an invalid address >>>>> as mentioned above, it seems for some reason something is >>>>> different when the conflict is detected and rellocated, >>>>> compared to disabling it early then allocating a valid >>>>> value..? >>>>> >> I've created a new quirk utilising an extra PCI resource flag to >> force reallocation of the resource. It's the first approach >> I've had any success at. It does work. Only "Intel Page Flush" >> now gets allocated @0xe0000000! > > > Hopefully this should fix "Intel Flush Page" Need to export pci_bus_alloc_resource_fit for intel-gtt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JxRMACgkQGcb56gMuC61LegCcCuANujog4iiIziKwFtcCla1s 7BEAoLfLEEXKT1WhboX/m8bMBP90QCgb =zwK6 -----END PGP SIGNATURE----- [-- Attachment #2: export-resource_fit.diff --] [-- Type: text/x-patch, Size: 639 bytes --] commit fe2ccc15c3cd75af2a582dc6e2b4deb544aca307 Author: Steven Newbury <steve@snewbury.org.uk> Date: Sat Apr 14 19:37:32 2012 +0100 PCI: Export pci_bus_alloc_resource_fit() diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c index 6d2b073..acb51bd 100644 --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -391,6 +391,7 @@ void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *), EXPORT_SYMBOL_GPL(pci_walk_bus); EXPORT_SYMBOL(pci_bus_alloc_resource); +EXPORT_SYMBOL(pci_bus_alloc_resource_fit); EXPORT_SYMBOL_GPL(pci_bus_add_device); EXPORT_SYMBOL(pci_bus_add_devices); EXPORT_SYMBOL(pci_enable_bridges); ^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-14 18:42 ` Steven Newbury @ 2012-04-14 19:08 ` Steven Newbury -1 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 19:08 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 19:42, Steven Newbury wrote: > On 14/04/12 19:05, Steven Newbury wrote: >> On 14/04/12 18:37, Steven Newbury wrote: >>> On 12/04/12 17:40, Steven Newbury wrote: >>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>> <yinghai@kernel.org> wrote: > >>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>> <steve@snewbury.org.uk> wrote: >>>>>> Thanks, that fixed it! :) I had a similar patch I've been >>>>>> working on but I had my fix in the wrong place! >>>>>> >>>>>> In the working case, initially the BIOS has set GMA to >>>>>> within the low system DRAM 0xC0000000 obviously invalid. >>>>>> This conflict is detected and it's relallocated to >>>>>> 0x12000000. >>>>>> >>>>>> I've attempted to modify probe.c to disable 64-bit BARs >>>>>> not allocated above 4G so they get reallocated above when >>>>>> possible later. It seemed to work, but again broke GMA >>>>>> despite the BAR originally containing an invalid >>>>>> address as mentioned above, it seems for some reason >>>>>> something is different when the conflict is detected and >>>>>> rellocated, compared to disabling it early then >>>>>> allocating a valid value..? >>>>>> >>> I've created a new quirk utilising an extra PCI resource flag >>> to force reallocation of the resource. It's the first >>> approach I've had any success at. It does work. Only "Intel >>> Page Flush" now gets allocated @0xe0000000! > > >> Hopefully this should fix "Intel Flush Page" > Need to export pci_bus_alloc_resource_fit for intel-gtt. Nearly worked... Or at least it should have worked, but for some reason the allocator failed to utilise 0xe0000000-0xefffffff for 04:00.0 BAR0..? 00000000-0000ffff : reserved 00010000-0009efff : System RAM 0009f000-0009ffff : reserved 000c0000-000c7fff : Video ROM 000cf000-000cffff : Adapter ROM 000f0000-000fffff : System ROM 00100000-df65a7ff : System RAM 01000000-0136defd : Kernel code 0136defe-0169127f : Kernel data 0172f000-01809fff : Kernel bss df65a800-dfffffff : reserved df65a800-df6fffff : pnp 00:0d df700000-df7fffff : pnp 00:0d f0000000-f01fffff : PCI Bus 0000:0d f6900000-f69fffff : PCI Bus 0000:09 f69f0000-f69fffff : 0000:09:00.0 f69f0000-f69fffff : tg3 f6a00000-f6bfffff : PCI Bus 0000:0d f6c00000-f6cfffff : PCI Bus 0000:0c f6cfe000-f6cfffff : 0000:0c:00.0 f6cfe000-f6cfffff : iwl4965 f6dfb700-f6dfb7ff : 0000:00:1f.3 f6dfb800-f6dfbfff : 0000:00:1f.2 f6dfb800-f6dfbfff : ahci f6dfc000-f6dfffff : 0000:00:1b.0 f6dfc000-f6dfffff : ICH HD audio f6e00000-f6efffff : 0000:00:02.0 f6f00000-f6ffffff : 0000:00:02.1 f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f] f8000000-fbffffff : reserved f8000000-fbffffff : pnp 00:0d fec00000-fec0ffff : reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:08 fed18000-fed1bfff : reserved fed18000-fed1bfff : pnp 00:0d fed1c000-fed1c3ff : 0000:00:1d.7 fed1c000-fed1c3ff : ehci_hcd fed1c400-fed1c7ff : 0000:00:1a.7 fed1c400-fed1c7ff : ehci_hcd fed1d000-fed1dfff : Intel Flush Page fed20000-fed8ffff : reserved fed20000-fed3ffff : pnp 00:0d fed40000-fed44fff : pnp 00:0a fed45000-fed8ffff : pnp 00:0d feda0000-feda5fff : reserved feda0000-feda3fff : pnp 00:0d feda4000-feda4fff : pnp 00:0d feda5000-feda5fff : pnp 00:0d feda6000-feda6fff : pnp 00:0d fee00000-fee0ffff : reserved fee00000-fee0ffff : pnp 00:0d fee00000-fee00fff : Local APIC fef00000-feffffff : PCI Bus 0000:04 fefbc000-fefbffff : 0000:04:00.1 fefbc000-fefbffff : ICH HD audio fefc0000-fefdffff : 0000:04:00.0 fefe0000-feffffff : 0000:04:00.0 ffa00000-ffbfffff : pnp 00:0d ffc00000-ffdfffff : PCI Bus 0000:0b ffe00000-ffffffff : reserved ffe00000-ffffffff : pnp 00:0d 100000000-11fffffff : System RAM fefa00000-fefbfffff : PCI Bus 0000:09 fefc00000-fefdfffff : PCI Bus 0000:0c fefe00000-fefffffff : PCI Bus 0000:0b ff0000000-fffffffff : 0000:00:02.0 dmesg after docking: ACPI: \_SB_.PCI0.PCIE.GDCK - docking usb 3-3: new high-speed USB device number 3 using ehci_hcd usb 3-3: New USB device found, idVendor=413c, idProduct=0058 usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 3-3:1.0: USB hub found hub 3-3:1.0: 4 ports detected ACPI Error: Method parse/execution failed [\SMI_] (Node ffff88011b031550), AE_AML_INFINITE_LOOP (20120320/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.PCI0.PCIE.GDCK._DCK] (Node ffff88011b038528), AE_AML_INFINITE_LOOP (20120320/psparse-536) ACPI Exception: AE_AML_INFINITE_LOOP, \_SB_.PCI0.PCIE.GDCK - failed to execute _DCK (20120320/dock-478) usb 3-3.2: new high-speed USB device number 4 using ehci_hcd usb 3-3.2: New USB device found, idVendor=413c, idProduct=0058 usb 3-3.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 3-3.2:1.0: USB hub found hub 3-3.2:1.0: 4 ports detected pci 0000:03:08.0: [10b5:8112] type 01 class 0x060400 pci 0000:03:08.0: supports D1 pci 0000:03:08.0: PME# supported from D0 D1 D3hot pci 0000:03:08.0: PME# disabled pci 0000:03:08.0: scanning [bus 00-00] behind bridge, pass 0 pci 0000:03:08.0: bus configuration invalid, reconfiguring pci 0000:03:08.0: scanning [bus 00-00] behind bridge, pass 1 pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci_bus 0000:03: busn_res: extended 05 to [bus 03-08] pci_bus 0000:04: busn_res: [bus 04-08] is updated under [bus 03-08] pci_bus 0000:04: scanning bus pass 0 pci 0000:04:00.0: [1002:68e1] type 00 class 0x030000 pci 0000:04:00.0: reg 10: [mem 0x00000000-0x0fffffff 64bit pref] pci 0000:04:00.0: reg 18: [mem 0x00000000-0x0001ffff 64bit] pci 0000:04:00.0: reg 20: [io 0x0000-0x00ff] pci 0000:04:00.0: reg 30: [mem 0x00000000-0x0001ffff pref] pci 0000:04:00.0: supports D1 D2 pci 0000:04:00.1: [1002:aa68] type 00 class 0x040300 pci 0000:04:00.1: reg 10: [mem 0x00000000-0x00003fff 64bit] pci 0000:04:00.1: supports D1 D2 pci_bus 0000:04: fixups for bus pass 0 pci 0000:03:08.0: PCI bridge to [bus 04-08] pci_bus 0000:04: bus scan returning with max=04 pass 0 pci_bus 0000:04: scanning bus pass 1 pci_bus 0000:04: fixups for bus pass 1 pci 0000:03:08.0: PCI bridge to [bus 04-08] pci_bus 0000:04: bus scan returning with max=04 pass 1 pci_bus 0000:04: busn_res: [bus 04-08] end updated to [bus 04] pci_bus 0000:03: busn_res: shrunk 04 to [bus 03-04] ACPI: Delete PCI Interrupt Routing Table for 0000:04 pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x18000000) pci 0000:03:08.0: BAR 14: assigned [mem 0xfef00000-0xfeffffff] pci 0000:03:08.0: BAR 13: assigned [io 0x4000-0x4fff] pci 0000:04:00.0: BAR 0: can't assign mem pref (size 0x10000000) pci 0000:04:00.0: BAR 2: assigned [mem 0xfefe0000-0xfeffffff 64bit] pci 0000:04:00.0: BAR 2: set to [mem 0xfefe0000-0xfeffffff 64bit] (PCI address [0xfefe0000-0xfeffffff]) pci 0000:04:00.0: BAR 6: assigned [mem 0xfefc0000-0xfefdffff pref] pci 0000:04:00.1: BAR 0: assigned [mem 0xfefbc000-0xfefbffff 64bit] pci 0000:04:00.1: BAR 0: set to [mem 0xfefbc000-0xfefbffff 64bit] (PCI address [0xfefbc000-0xfefbffff]) pci 0000:04:00.0: BAR 4: assigned [io 0x4000-0x40ff] pci 0000:04:00.0: BAR 4: set to [io 0x4000-0x40ff] (PCI address [0x4000-0x40ff]) pci 0000:03:08.0: PCI bridge to [bus 04-04] pci 0000:03:08.0: bridge window [io 0x4000-0x4fff] pci 0000:03:08.0: bridge window [mem 0xfef00000-0xfeffffff] pci 0000:03:08.0: no hotplug settings from platform pci 0000:04:00.0: no hotplug settings from platform pci 0000:04:00.1: no hotplug settings from platform pci 0000:03:08.0: enabling device (0000 -> 0003) pci 0000:03:08.0: enabling bus mastering vgaarb: device added: PCI:0000:04:00.0,decodes=io+mem,owns=none,locks=none vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem vgaarb: transferring owner from PCI:0000:00:02.0 to PCI:0000:04:00.0 snd_hda_intel 0000:04:00.1: enabling device (0000 -> 0002) snd_hda_intel 0000:04:00.1: irq 49 for MSI/MSI-X snd_hda_intel 0000:04:00.1: enabling bus mastering input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1e.0/0000:03:08.0/0000:04:00.1/sound/card1/input11 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:04:00.0: enabling device (0000 -> 0003) radeon 0000:04:00.0: enabling bus mastering [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E1 0x1787:0x3000). [drm] register mmio base: 0xFEFE0000 [drm] register mmio size: 131072 ATOM BIOS: B9127JMA.MFK [drm] GPU not posted. posting now... radeon 0000:04:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) radeon 0000:04:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF mtrr: zero sized request [drm] Detected VRAM RAM=512M, BAR=0M [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 2019690 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator radeon_bo_create:132 alloc size 0M bigger than 0Mb limit radeon 0000:04:00.0: Fatal error during GPU init [drm] radeon: finishing device. radeon 0000:04:00.0: no bo for sa manager [TTM] Trying to take down uninitialized memory manager type 1 [TTM] Finalizing pool allocator [TTM] Finalizing DMA pool allocator [TTM] Zone kernel: Used memory at exit: 0 kiB [drm] radeon: ttm finalized -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JyxUACgkQGcb56gMuC61WdwCcDYlntR5ydafo3lwHcDF6MPsD 9g0AoIYq4Rf+gK36+LTNyT7eQWLVOznf =ckOP -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-14 19:08 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 19:08 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 19:42, Steven Newbury wrote: > On 14/04/12 19:05, Steven Newbury wrote: >> On 14/04/12 18:37, Steven Newbury wrote: >>> On 12/04/12 17:40, Steven Newbury wrote: >>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>> <yinghai@kernel.org> wrote: > >>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>> <steve@snewbury.org.uk> wrote: >>>>>> Thanks, that fixed it! :) I had a similar patch I've been >>>>>> working on but I had my fix in the wrong place! >>>>>> >>>>>> In the working case, initially the BIOS has set GMA to >>>>>> within the low system DRAM 0xC0000000 obviously invalid. >>>>>> This conflict is detected and it's relallocated to >>>>>> 0x12000000. >>>>>> >>>>>> I've attempted to modify probe.c to disable 64-bit BARs >>>>>> not allocated above 4G so they get reallocated above when >>>>>> possible later. It seemed to work, but again broke GMA >>>>>> despite the BAR originally containing an invalid >>>>>> address as mentioned above, it seems for some reason >>>>>> something is different when the conflict is detected and >>>>>> rellocated, compared to disabling it early then >>>>>> allocating a valid value..? >>>>>> >>> I've created a new quirk utilising an extra PCI resource flag >>> to force reallocation of the resource. It's the first >>> approach I've had any success at. It does work. Only "Intel >>> Page Flush" now gets allocated @0xe0000000! > > >> Hopefully this should fix "Intel Flush Page" > Need to export pci_bus_alloc_resource_fit for intel-gtt. Nearly worked... Or at least it should have worked, but for some reason the allocator failed to utilise 0xe0000000-0xefffffff for 04:00.0 BAR0..? 00000000-0000ffff : reserved 00010000-0009efff : System RAM 0009f000-0009ffff : reserved 000c0000-000c7fff : Video ROM 000cf000-000cffff : Adapter ROM 000f0000-000fffff : System ROM 00100000-df65a7ff : System RAM 01000000-0136defd : Kernel code 0136defe-0169127f : Kernel data 0172f000-01809fff : Kernel bss df65a800-dfffffff : reserved df65a800-df6fffff : pnp 00:0d df700000-df7fffff : pnp 00:0d f0000000-f01fffff : PCI Bus 0000:0d f6900000-f69fffff : PCI Bus 0000:09 f69f0000-f69fffff : 0000:09:00.0 f69f0000-f69fffff : tg3 f6a00000-f6bfffff : PCI Bus 0000:0d f6c00000-f6cfffff : PCI Bus 0000:0c f6cfe000-f6cfffff : 0000:0c:00.0 f6cfe000-f6cfffff : iwl4965 f6dfb700-f6dfb7ff : 0000:00:1f.3 f6dfb800-f6dfbfff : 0000:00:1f.2 f6dfb800-f6dfbfff : ahci f6dfc000-f6dfffff : 0000:00:1b.0 f6dfc000-f6dfffff : ICH HD audio f6e00000-f6efffff : 0000:00:02.0 f6f00000-f6ffffff : 0000:00:02.1 f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f] f8000000-fbffffff : reserved f8000000-fbffffff : pnp 00:0d fec00000-fec0ffff : reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:08 fed18000-fed1bfff : reserved fed18000-fed1bfff : pnp 00:0d fed1c000-fed1c3ff : 0000:00:1d.7 fed1c000-fed1c3ff : ehci_hcd fed1c400-fed1c7ff : 0000:00:1a.7 fed1c400-fed1c7ff : ehci_hcd fed1d000-fed1dfff : Intel Flush Page fed20000-fed8ffff : reserved fed20000-fed3ffff : pnp 00:0d fed40000-fed44fff : pnp 00:0a fed45000-fed8ffff : pnp 00:0d feda0000-feda5fff : reserved feda0000-feda3fff : pnp 00:0d feda4000-feda4fff : pnp 00:0d feda5000-feda5fff : pnp 00:0d feda6000-feda6fff : pnp 00:0d fee00000-fee0ffff : reserved fee00000-fee0ffff : pnp 00:0d fee00000-fee00fff : Local APIC fef00000-feffffff : PCI Bus 0000:04 fefbc000-fefbffff : 0000:04:00.1 fefbc000-fefbffff : ICH HD audio fefc0000-fefdffff : 0000:04:00.0 fefe0000-feffffff : 0000:04:00.0 ffa00000-ffbfffff : pnp 00:0d ffc00000-ffdfffff : PCI Bus 0000:0b ffe00000-ffffffff : reserved ffe00000-ffffffff : pnp 00:0d 100000000-11fffffff : System RAM fefa00000-fefbfffff : PCI Bus 0000:09 fefc00000-fefdfffff : PCI Bus 0000:0c fefe00000-fefffffff : PCI Bus 0000:0b ff0000000-fffffffff : 0000:00:02.0 dmesg after docking: ACPI: \_SB_.PCI0.PCIE.GDCK - docking usb 3-3: new high-speed USB device number 3 using ehci_hcd usb 3-3: New USB device found, idVendor=413c, idProduct=0058 usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 3-3:1.0: USB hub found hub 3-3:1.0: 4 ports detected ACPI Error: Method parse/execution failed [\SMI_] (Node ffff88011b031550), AE_AML_INFINITE_LOOP (20120320/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.PCI0.PCIE.GDCK._DCK] (Node ffff88011b038528), AE_AML_INFINITE_LOOP (20120320/psparse-536) ACPI Exception: AE_AML_INFINITE_LOOP, \_SB_.PCI0.PCIE.GDCK - failed to execute _DCK (20120320/dock-478) usb 3-3.2: new high-speed USB device number 4 using ehci_hcd usb 3-3.2: New USB device found, idVendor=413c, idProduct=0058 usb 3-3.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 3-3.2:1.0: USB hub found hub 3-3.2:1.0: 4 ports detected pci 0000:03:08.0: [10b5:8112] type 01 class 0x060400 pci 0000:03:08.0: supports D1 pci 0000:03:08.0: PME# supported from D0 D1 D3hot pci 0000:03:08.0: PME# disabled pci 0000:03:08.0: scanning [bus 00-00] behind bridge, pass 0 pci 0000:03:08.0: bus configuration invalid, reconfiguring pci 0000:03:08.0: scanning [bus 00-00] behind bridge, pass 1 pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci_bus 0000:03: busn_res: extended 05 to [bus 03-08] pci_bus 0000:04: busn_res: [bus 04-08] is updated under [bus 03-08] pci_bus 0000:04: scanning bus pass 0 pci 0000:04:00.0: [1002:68e1] type 00 class 0x030000 pci 0000:04:00.0: reg 10: [mem 0x00000000-0x0fffffff 64bit pref] pci 0000:04:00.0: reg 18: [mem 0x00000000-0x0001ffff 64bit] pci 0000:04:00.0: reg 20: [io 0x0000-0x00ff] pci 0000:04:00.0: reg 30: [mem 0x00000000-0x0001ffff pref] pci 0000:04:00.0: supports D1 D2 pci 0000:04:00.1: [1002:aa68] type 00 class 0x040300 pci 0000:04:00.1: reg 10: [mem 0x00000000-0x00003fff 64bit] pci 0000:04:00.1: supports D1 D2 pci_bus 0000:04: fixups for bus pass 0 pci 0000:03:08.0: PCI bridge to [bus 04-08] pci_bus 0000:04: bus scan returning with max=04 pass 0 pci_bus 0000:04: scanning bus pass 1 pci_bus 0000:04: fixups for bus pass 1 pci 0000:03:08.0: PCI bridge to [bus 04-08] pci_bus 0000:04: bus scan returning with max=04 pass 1 pci_bus 0000:04: busn_res: [bus 04-08] end updated to [bus 04] pci_bus 0000:03: busn_res: shrunk 04 to [bus 03-04] ACPI: Delete PCI Interrupt Routing Table for 0000:04 pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x18000000) pci 0000:03:08.0: BAR 14: assigned [mem 0xfef00000-0xfeffffff] pci 0000:03:08.0: BAR 13: assigned [io 0x4000-0x4fff] pci 0000:04:00.0: BAR 0: can't assign mem pref (size 0x10000000) pci 0000:04:00.0: BAR 2: assigned [mem 0xfefe0000-0xfeffffff 64bit] pci 0000:04:00.0: BAR 2: set to [mem 0xfefe0000-0xfeffffff 64bit] (PCI address [0xfefe0000-0xfeffffff]) pci 0000:04:00.0: BAR 6: assigned [mem 0xfefc0000-0xfefdffff pref] pci 0000:04:00.1: BAR 0: assigned [mem 0xfefbc000-0xfefbffff 64bit] pci 0000:04:00.1: BAR 0: set to [mem 0xfefbc000-0xfefbffff 64bit] (PCI address [0xfefbc000-0xfefbffff]) pci 0000:04:00.0: BAR 4: assigned [io 0x4000-0x40ff] pci 0000:04:00.0: BAR 4: set to [io 0x4000-0x40ff] (PCI address [0x4000-0x40ff]) pci 0000:03:08.0: PCI bridge to [bus 04-04] pci 0000:03:08.0: bridge window [io 0x4000-0x4fff] pci 0000:03:08.0: bridge window [mem 0xfef00000-0xfeffffff] pci 0000:03:08.0: no hotplug settings from platform pci 0000:04:00.0: no hotplug settings from platform pci 0000:04:00.1: no hotplug settings from platform pci 0000:03:08.0: enabling device (0000 -> 0003) pci 0000:03:08.0: enabling bus mastering vgaarb: device added: PCI:0000:04:00.0,decodes=io+mem,owns=none,locks=none vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem vgaarb: transferring owner from PCI:0000:00:02.0 to PCI:0000:04:00.0 snd_hda_intel 0000:04:00.1: enabling device (0000 -> 0002) snd_hda_intel 0000:04:00.1: irq 49 for MSI/MSI-X snd_hda_intel 0000:04:00.1: enabling bus mastering input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1e.0/0000:03:08.0/0000:04:00.1/sound/card1/input11 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:04:00.0: enabling device (0000 -> 0003) radeon 0000:04:00.0: enabling bus mastering [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E1 0x1787:0x3000). [drm] register mmio base: 0xFEFE0000 [drm] register mmio size: 131072 ATOM BIOS: B9127JMA.MFK [drm] GPU not posted. posting now... radeon 0000:04:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) radeon 0000:04:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF mtrr: zero sized request [drm] Detected VRAM RAM=512M, BAR=0M [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 2019690 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator radeon_bo_create:132 alloc size 0M bigger than 0Mb limit radeon 0000:04:00.0: Fatal error during GPU init [drm] radeon: finishing device. radeon 0000:04:00.0: no bo for sa manager [TTM] Trying to take down uninitialized memory manager type 1 [TTM] Finalizing pool allocator [TTM] Finalizing DMA pool allocator [TTM] Zone kernel: Used memory at exit: 0 kiB [drm] radeon: ttm finalized -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JyxUACgkQGcb56gMuC61WdwCcDYlntR5ydafo3lwHcDF6MPsD 9g0AoIYq4Rf+gK36+LTNyT7eQWLVOznf =ckOP -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-14 19:08 ` Steven Newbury @ 2012-04-14 19:21 ` Steven Newbury -1 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 19:21 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 20:08, Steven Newbury wrote: > On 14/04/12 19:42, Steven Newbury wrote: >> On 14/04/12 19:05, Steven Newbury wrote: >>> On 14/04/12 18:37, Steven Newbury wrote: >>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>> <yinghai@kernel.org> wrote: > >>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>> <steve@snewbury.org.uk> wrote: >>>>>>> Thanks, that fixed it! :) I had a similar patch I've >>>>>>> been working on but I had my fix in the wrong place! >>>>>>> >>>>>>> In the working case, initially the BIOS has set GMA to >>>>>>> within the low system DRAM 0xC0000000 obviously >>>>>>> invalid. This conflict is detected and it's >>>>>>> relallocated to 0x12000000. >>>>>>> >>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>> BARs not allocated above 4G so they get reallocated >>>>>>> above when possible later. It seemed to work, but >>>>>>> again broke GMA despite the BAR originally containing >>>>>>> an invalid address as mentioned above, it seems for >>>>>>> some reason something is different when the conflict is >>>>>>> detected and rellocated, compared to disabling it early >>>>>>> then allocating a valid value..? >>>>>>> >>>> I've created a new quirk utilising an extra PCI resource >>>> flag to force reallocation of the resource. It's the first >>>> approach I've had any success at. It does work. Only >>>> "Intel Page Flush" now gets allocated @0xe0000000! > > >>> Hopefully this should fix "Intel Flush Page" >> Need to export pci_bus_alloc_resource_fit for intel-gtt. > Nearly worked... Or at least it should have worked, but for some > reason the allocator failed to utilise 0xe0000000-0xefffffff for > 04:00.0 BAR0..? > > > pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x18000000) Ah! Not enough space for the bridge window!:( > pci 0000:03:08.0: BAR 14: assigned [mem 0xfef00000-0xfeffffff] pci > 0000:03:08.0: BAR 13: assigned [io 0x4000-0x4fff] pci > 0000:04:00.0: BAR 0: can't assign mem pref (size 0x10000000) pci > 0000:04:00.0: BAR 2: assigned [mem 0xfefe0000-0xfeffffff 64bit] pci > 0000:04:00.0: BAR 2: set to [mem 0xfefe0000-0xfeffffff 64bit] (PCI > address [0xfefe0000-0xfeffffff]) pci 0000:04:00.0: BAR 6: assigned > [mem 0xfefc0000-0xfefdffff pref] pci 0000:04:00.1: BAR 0: assigned > [mem 0xfefbc000-0xfefbffff 64bit] pci 0000:04:00.1: BAR 0: set to > [mem 0xfefbc000-0xfefbffff 64bit] (PCI address > [0xfefbc000-0xfefbffff]) pci 0000:04:00.0: BAR 4: assigned [io > 0x4000-0x40ff] pci 0000:04:00.0: BAR 4: set to [io 0x4000-0x40ff] > (PCI address [0x4000-0x40ff]) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JzkIACgkQGcb56gMuC63MmQCfSvoLv0y+/sbW2HJKM02QfpLN ld8AoLivGvEaB8ZSlzVcfVi8lJBQDzLS =5T9j -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-14 19:21 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-14 19:21 UTC (permalink / raw) To: Steven Newbury Cc: Yinghai Lu, Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 20:08, Steven Newbury wrote: > On 14/04/12 19:42, Steven Newbury wrote: >> On 14/04/12 19:05, Steven Newbury wrote: >>> On 14/04/12 18:37, Steven Newbury wrote: >>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>> <yinghai@kernel.org> wrote: > >>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>> <steve@snewbury.org.uk> wrote: >>>>>>> Thanks, that fixed it! :) I had a similar patch I've >>>>>>> been working on but I had my fix in the wrong place! >>>>>>> >>>>>>> In the working case, initially the BIOS has set GMA to >>>>>>> within the low system DRAM 0xC0000000 obviously >>>>>>> invalid. This conflict is detected and it's >>>>>>> relallocated to 0x12000000. >>>>>>> >>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>> BARs not allocated above 4G so they get reallocated >>>>>>> above when possible later. It seemed to work, but >>>>>>> again broke GMA despite the BAR originally containing >>>>>>> an invalid address as mentioned above, it seems for >>>>>>> some reason something is different when the conflict is >>>>>>> detected and rellocated, compared to disabling it early >>>>>>> then allocating a valid value..? >>>>>>> >>>> I've created a new quirk utilising an extra PCI resource >>>> flag to force reallocation of the resource. It's the first >>>> approach I've had any success at. It does work. Only >>>> "Intel Page Flush" now gets allocated @0xe0000000! > > >>> Hopefully this should fix "Intel Flush Page" >> Need to export pci_bus_alloc_resource_fit for intel-gtt. > Nearly worked... Or at least it should have worked, but for some > reason the allocator failed to utilise 0xe0000000-0xefffffff for > 04:00.0 BAR0..? > > > pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x18000000) Ah! Not enough space for the bridge window!:( > pci 0000:03:08.0: BAR 14: assigned [mem 0xfef00000-0xfeffffff] pci > 0000:03:08.0: BAR 13: assigned [io 0x4000-0x4fff] pci > 0000:04:00.0: BAR 0: can't assign mem pref (size 0x10000000) pci > 0000:04:00.0: BAR 2: assigned [mem 0xfefe0000-0xfeffffff 64bit] pci > 0000:04:00.0: BAR 2: set to [mem 0xfefe0000-0xfeffffff 64bit] (PCI > address [0xfefe0000-0xfeffffff]) pci 0000:04:00.0: BAR 6: assigned > [mem 0xfefc0000-0xfefdffff pref] pci 0000:04:00.1: BAR 0: assigned > [mem 0xfefbc000-0xfefbffff 64bit] pci 0000:04:00.1: BAR 0: set to > [mem 0xfefbc000-0xfefbffff 64bit] (PCI address > [0xfefbc000-0xfefbffff]) pci 0000:04:00.0: BAR 4: assigned [io > 0x4000-0x40ff] pci 0000:04:00.0: BAR 4: set to [io 0x4000-0x40ff] > (PCI address [0x4000-0x40ff]) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JzkIACgkQGcb56gMuC63MmQCfSvoLv0y+/sbW2HJKM02QfpLN ld8AoLivGvEaB8ZSlzVcfVi8lJBQDzLS =5T9j -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-14 19:21 ` Steven Newbury (?) @ 2012-04-14 20:48 ` Yinghai Lu 2012-04-15 10:19 ` Steven Newbury 2012-04-15 10:20 ` Steven Newbury -1 siblings, 2 replies; 94+ messages in thread From: Yinghai Lu @ 2012-04-14 20:48 UTC (permalink / raw) To: Steven Newbury Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury <steve@snewbury.org.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 14/04/12 20:08, Steven Newbury wrote: >> On 14/04/12 19:42, Steven Newbury wrote: >>> On 14/04/12 19:05, Steven Newbury wrote: >>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>> <yinghai@kernel.org> wrote: >> >>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>> Thanks, that fixed it! :) I had a similar patch I've >>>>>>>> been working on but I had my fix in the wrong place! >>>>>>>> >>>>>>>> In the working case, initially the BIOS has set GMA to >>>>>>>> within the low system DRAM 0xC0000000 obviously >>>>>>>> invalid. This conflict is detected and it's >>>>>>>> relallocated to 0x12000000. >>>>>>>> >>>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>>> BARs not allocated above 4G so they get reallocated >>>>>>>> above when possible later. It seemed to work, but >>>>>>>> again broke GMA despite the BAR originally containing >>>>>>>> an invalid address as mentioned above, it seems for >>>>>>>> some reason something is different when the conflict is >>>>>>>> detected and rellocated, compared to disabling it early >>>>>>>> then allocating a valid value..? >>>>>>>> >>>>> I've created a new quirk utilising an extra PCI resource >>>>> flag to force reallocation of the resource. It's the first >>>>> approach I've had any success at. It does work. Only >>>>> "Intel Page Flush" now gets allocated @0xe0000000! >> >> >>>> Hopefully this should fix "Intel Flush Page" >>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >> Nearly worked... Or at least it should have worked, but for some >> reason the allocator failed to utilise 0xe0000000-0xefffffff for >> 04:00.0 BAR0..? >> >> >> pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x18000000) > Ah! Not enough space for the bridge window!:( > please append pci=norom ... Yinghai ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-14 20:48 ` Yinghai Lu @ 2012-04-15 10:19 ` Steven Newbury 2012-04-15 10:20 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 10:19 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 21:48, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 14/04/12 20:08, Steven Newbury wrote: >>> On 14/04/12 19:42, Steven Newbury wrote: >>>> On 14/04/12 19:05, Steven Newbury wrote: >>>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>>> <yinghai@kernel.org> wrote: >>> >>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>>> Thanks, that fixed it! :) I had a similar patch >>>>>>>>> I've been working on but I had my fix in the wrong >>>>>>>>> place! >>>>>>>>> >>>>>>>>> In the working case, initially the BIOS has set GMA >>>>>>>>> to within the low system DRAM 0xC0000000 obviously >>>>>>>>> invalid. This conflict is detected and it's >>>>>>>>> relallocated to 0x12000000. >>>>>>>>> >>>>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>>>> BARs not allocated above 4G so they get >>>>>>>>> reallocated above when possible later. It seemed >>>>>>>>> to work, but again broke GMA despite the BAR >>>>>>>>> originally containing an invalid address as >>>>>>>>> mentioned above, it seems for some reason something >>>>>>>>> is different when the conflict is detected and >>>>>>>>> rellocated, compared to disabling it early then >>>>>>>>> allocating a valid value..? >>>>>>>>> >>>>>> I've created a new quirk utilising an extra PCI resource >>>>>> flag to force reallocation of the resource. It's the >>>>>> first approach I've had any success at. It does work. >>>>>> Only "Intel Page Flush" now gets allocated @0xe0000000! >>> >>> >>>>> Hopefully this should fix "Intel Flush Page" >>>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >>> Nearly worked... Or at least it should have worked, but for >>> some reason the allocator failed to utilise >>> 0xe0000000-0xefffffff for 04:00.0 BAR0..? >>> >>> >>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>> 0x18000000) >> Ah! Not enough space for the bridge window!:( >> > > please append pci=norom ... > That worked. Except of course the radeon driver can't POST the card without the ROM! ;) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KoMgACgkQGcb56gMuC62ZrACfcMJDlIVy8EfpwQyyAL91OH/d uEIAoMK2L1LEmy8OZIvaGRqt7UjxlYRM =v+/Q -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-15 10:19 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 10:19 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 21:48, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 14/04/12 20:08, Steven Newbury wrote: >>> On 14/04/12 19:42, Steven Newbury wrote: >>>> On 14/04/12 19:05, Steven Newbury wrote: >>>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>>> <yinghai@kernel.org> wrote: >>> >>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>>> Thanks, that fixed it! :) I had a similar patch >>>>>>>>> I've been working on but I had my fix in the wrong >>>>>>>>> place! >>>>>>>>> >>>>>>>>> In the working case, initially the BIOS has set GMA >>>>>>>>> to within the low system DRAM 0xC0000000 obviously >>>>>>>>> invalid. This conflict is detected and it's >>>>>>>>> relallocated to 0x12000000. >>>>>>>>> >>>>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>>>> BARs not allocated above 4G so they get >>>>>>>>> reallocated above when possible later. It seemed >>>>>>>>> to work, but again broke GMA despite the BAR >>>>>>>>> originally containing an invalid address as >>>>>>>>> mentioned above, it seems for some reason something >>>>>>>>> is different when the conflict is detected and >>>>>>>>> rellocated, compared to disabling it early then >>>>>>>>> allocating a valid value..? >>>>>>>>> >>>>>> I've created a new quirk utilising an extra PCI resource >>>>>> flag to force reallocation of the resource. It's the >>>>>> first approach I've had any success at. It does work. >>>>>> Only "Intel Page Flush" now gets allocated @0xe0000000! >>> >>> >>>>> Hopefully this should fix "Intel Flush Page" >>>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >>> Nearly worked... Or at least it should have worked, but for >>> some reason the allocator failed to utilise >>> 0xe0000000-0xefffffff for 04:00.0 BAR0..? >>> >>> >>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>> 0x18000000) >> Ah! Not enough space for the bridge window!:( >> > > please append pci=norom ... > That worked. Except of course the radeon driver can't POST the card without the ROM! ;) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KoMgACgkQGcb56gMuC62ZrACfcMJDlIVy8EfpwQyyAL91OH/d uEIAoMK2L1LEmy8OZIvaGRqt7UjxlYRM =v+/Q -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-14 20:48 ` Yinghai Lu @ 2012-04-15 10:20 ` Steven Newbury 2012-04-15 10:20 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 10:20 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 21:48, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 14/04/12 20:08, Steven Newbury wrote: >>> On 14/04/12 19:42, Steven Newbury wrote: >>>> On 14/04/12 19:05, Steven Newbury wrote: >>>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>>> <yinghai@kernel.org> wrote: >>> >>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>>> Thanks, that fixed it! :) I had a similar patch >>>>>>>>> I've been working on but I had my fix in the wrong >>>>>>>>> place! >>>>>>>>> >>>>>>>>> In the working case, initially the BIOS has set >>>>>>>>> GMA to within the low system DRAM 0xC0000000 >>>>>>>>> obviously invalid. This conflict is detected and >>>>>>>>> it's relallocated to 0x12000000. >>>>>>>>> >>>>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>>>> BARs not allocated above 4G so they get >>>>>>>>> reallocated above when possible later. It seemed >>>>>>>>> to work, but again broke GMA despite the BAR >>>>>>>>> originally containing an invalid address as >>>>>>>>> mentioned above, it seems for some reason >>>>>>>>> something is different when the conflict is >>>>>>>>> detected and rellocated, compared to disabling it >>>>>>>>> early then allocating a valid value..? >>>>>>>>> >>>>>> I've created a new quirk utilising an extra PCI resource >>>>>> flag to force reallocation of the resource. It's the >>>>>> first approach I've had any success at. It does work. >>>>>> Only "Intel Page Flush" now gets allocated @0xe0000000! >>> >>> >>>>> Hopefully this should fix "Intel Flush Page" >>>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >>> Nearly worked... Or at least it should have worked, but for >>> some reason the allocator failed to utilise >>> 0xe0000000-0xefffffff for 04:00.0 BAR0..? >>> >>> >>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>> 0x18000000) >> Ah! Not enough space for the bridge window!:( >> > > please append pci=norom ... > That worked. Except of course the radeon driver can't POST the card without the ROM! :-P -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KoNwACgkQGcb56gMuC62uAACfdaoIb/NT7+7xGIa4G+Wtw0K0 /IsAoL8NIg6g4q3qoTJuQpp6WyqDYUfu =OzC5 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-15 10:20 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 10:20 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 21:48, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 14/04/12 20:08, Steven Newbury wrote: >>> On 14/04/12 19:42, Steven Newbury wrote: >>>> On 14/04/12 19:05, Steven Newbury wrote: >>>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>>> <yinghai@kernel.org> wrote: >>> >>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>>> Thanks, that fixed it! :) I had a similar patch >>>>>>>>> I've been working on but I had my fix in the wrong >>>>>>>>> place! >>>>>>>>> >>>>>>>>> In the working case, initially the BIOS has set >>>>>>>>> GMA to within the low system DRAM 0xC0000000 >>>>>>>>> obviously invalid. This conflict is detected and >>>>>>>>> it's relallocated to 0x12000000. >>>>>>>>> >>>>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>>>> BARs not allocated above 4G so they get >>>>>>>>> reallocated above when possible later. It seemed >>>>>>>>> to work, but again broke GMA despite the BAR >>>>>>>>> originally containing an invalid address as >>>>>>>>> mentioned above, it seems for some reason >>>>>>>>> something is different when the conflict is >>>>>>>>> detected and rellocated, compared to disabling it >>>>>>>>> early then allocating a valid value..? >>>>>>>>> >>>>>> I've created a new quirk utilising an extra PCI resource >>>>>> flag to force reallocation of the resource. It's the >>>>>> first approach I've had any success at. It does work. >>>>>> Only "Intel Page Flush" now gets allocated @0xe0000000! >>> >>> >>>>> Hopefully this should fix "Intel Flush Page" >>>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >>> Nearly worked... Or at least it should have worked, but for >>> some reason the allocator failed to utilise >>> 0xe0000000-0xefffffff for 04:00.0 BAR0..? >>> >>> >>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>> 0x18000000) >> Ah! Not enough space for the bridge window!:( >> > > please append pci=norom ... > That worked. Except of course the radeon driver can't POST the card without the ROM! :-P -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KoNwACgkQGcb56gMuC62uAACfdaoIb/NT7+7xGIa4G+Wtw0K0 /IsAoL8NIg6g4q3qoTJuQpp6WyqDYUfu =OzC5 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-15 10:20 ` Steven Newbury @ 2012-04-15 11:37 ` Steven Newbury -1 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 11:37 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 11:20, Steven Newbury wrote: > On 14/04/12 21:48, Yinghai Lu wrote: >> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury >> <steve@snewbury.org.uk> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 14/04/12 20:08, Steven Newbury wrote: >>>> On 14/04/12 19:42, Steven Newbury wrote: >>>>> On 14/04/12 19:05, Steven Newbury wrote: >>>>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>>>> <yinghai@kernel.org> wrote: >>>> >>>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>>>> Thanks, that fixed it! :) I had a similar patch >>>>>>>>>> I've been working on but I had my fix in the >>>>>>>>>> wrong place! >>>>>>>>>> >>>>>>>>>> In the working case, initially the BIOS has set >>>>>>>>>> GMA to within the low system DRAM 0xC0000000 >>>>>>>>>> obviously invalid. This conflict is detected and >>>>>>>>>> it's relallocated to 0x12000000. >>>>>>>>>> >>>>>>>>>> I've attempted to modify probe.c to disable >>>>>>>>>> 64-bit BARs not allocated above 4G so they get >>>>>>>>>> reallocated above when possible later. It seemed >>>>>>>>>> to work, but again broke GMA despite the BAR >>>>>>>>>> originally containing an invalid address as >>>>>>>>>> mentioned above, it seems for some reason >>>>>>>>>> something is different when the conflict is >>>>>>>>>> detected and rellocated, compared to disabling >>>>>>>>>> it early then allocating a valid value..? >>>>>>>>>> >>>>>>> I've created a new quirk utilising an extra PCI >>>>>>> resource flag to force reallocation of the resource. >>>>>>> It's the first approach I've had any success at. It >>>>>>> does work. Only "Intel Page Flush" now gets allocated >>>>>>> @0xe0000000! >>>> >>>> >>>>>> Hopefully this should fix "Intel Flush Page" >>>>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >>>> Nearly worked... Or at least it should have worked, but for >>>> some reason the allocator failed to utilise >>>> 0xe0000000-0xefffffff for 04:00.0 BAR0..? >>>> >>>> >>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>> 0x18000000) >>> Ah! Not enough space for the bridge window!:( >>> > >> please append pci=norom ... > > That worked. Except of course the radeon driver can't POST the > card without the ROM! :-P Can the ROM resource be mapped above 4G? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KsxIACgkQGcb56gMuC63JTQCeOK9EGuyoWPe8lsSS5Y6QcfPi 9HQAniZQP84biGVRM4bP8R6/ulGjuRWV =i8py -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-15 11:37 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 11:37 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 11:20, Steven Newbury wrote: > On 14/04/12 21:48, Yinghai Lu wrote: >> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury >> <steve@snewbury.org.uk> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 14/04/12 20:08, Steven Newbury wrote: >>>> On 14/04/12 19:42, Steven Newbury wrote: >>>>> On 14/04/12 19:05, Steven Newbury wrote: >>>>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>>>> <yinghai@kernel.org> wrote: >>>> >>>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>>>> Thanks, that fixed it! :) I had a similar patch >>>>>>>>>> I've been working on but I had my fix in the >>>>>>>>>> wrong place! >>>>>>>>>> >>>>>>>>>> In the working case, initially the BIOS has set >>>>>>>>>> GMA to within the low system DRAM 0xC0000000 >>>>>>>>>> obviously invalid. This conflict is detected and >>>>>>>>>> it's relallocated to 0x12000000. >>>>>>>>>> >>>>>>>>>> I've attempted to modify probe.c to disable >>>>>>>>>> 64-bit BARs not allocated above 4G so they get >>>>>>>>>> reallocated above when possible later. It seemed >>>>>>>>>> to work, but again broke GMA despite the BAR >>>>>>>>>> originally containing an invalid address as >>>>>>>>>> mentioned above, it seems for some reason >>>>>>>>>> something is different when the conflict is >>>>>>>>>> detected and rellocated, compared to disabling >>>>>>>>>> it early then allocating a valid value..? >>>>>>>>>> >>>>>>> I've created a new quirk utilising an extra PCI >>>>>>> resource flag to force reallocation of the resource. >>>>>>> It's the first approach I've had any success at. It >>>>>>> does work. Only "Intel Page Flush" now gets allocated >>>>>>> @0xe0000000! >>>> >>>> >>>>>> Hopefully this should fix "Intel Flush Page" >>>>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >>>> Nearly worked... Or at least it should have worked, but for >>>> some reason the allocator failed to utilise >>>> 0xe0000000-0xefffffff for 04:00.0 BAR0..? >>>> >>>> >>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>> 0x18000000) >>> Ah! Not enough space for the bridge window!:( >>> > >> please append pci=norom ... > > That worked. Except of course the radeon driver can't POST the > card without the ROM! :-P Can the ROM resource be mapped above 4G? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KsxIACgkQGcb56gMuC63JTQCeOK9EGuyoWPe8lsSS5Y6QcfPi 9HQAniZQP84biGVRM4bP8R6/ulGjuRWV =i8py -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-15 11:37 ` Steven Newbury @ 2012-04-15 17:25 ` Steven Newbury -1 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 17:25 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 12:37, Steven Newbury wrote: > On 15/04/12 11:20, Steven Newbury wrote: >> On 14/04/12 21:48, Yinghai Lu wrote: [snip] >>> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury >>>>> >>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>> 0x18000000) >>>> Ah! Not enough space for the bridge window!:( >>>> > >>> please append pci=norom ... > >> That worked. Except of course the radeon driver can't POST the >> card without the ROM! :-P > Can the ROM resource be mapped above 4G? I didn't really think that through, obviously it can't because it's not on a 64-bit capable bridge. I wonder though, could it be shadowed then disabled early before the IOMEM? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+LBKQACgkQGcb56gMuC61OjQCeNPLWh+k03+gvjvWtpG6B4gW0 US0AoJpCmnNrxWtScyOdvX3sP62KPGUX =Sl0p -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-15 17:25 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 17:25 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 12:37, Steven Newbury wrote: > On 15/04/12 11:20, Steven Newbury wrote: >> On 14/04/12 21:48, Yinghai Lu wrote: [snip] >>> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury >>>>> >>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>> 0x18000000) >>>> Ah! Not enough space for the bridge window!:( >>>> > >>> please append pci=norom ... > >> That worked. Except of course the radeon driver can't POST the >> card without the ROM! :-P > Can the ROM resource be mapped above 4G? I didn't really think that through, obviously it can't because it's not on a 64-bit capable bridge. I wonder though, could it be shadowed then disabled early before the IOMEM? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+LBKQACgkQGcb56gMuC61OjQCeNPLWh+k03+gvjvWtpG6B4gW0 US0AoJpCmnNrxWtScyOdvX3sP62KPGUX =Sl0p -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-15 17:25 ` Steven Newbury @ 2012-04-15 17:31 ` Steven Newbury -1 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 17:31 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 18:25, Steven Newbury wrote: > On 15/04/12 12:37, Steven Newbury wrote: >> On 15/04/12 11:20, Steven Newbury wrote: >>> On 14/04/12 21:48, Yinghai Lu wrote: > > [snip] > >>>> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury > >>>>>> >>>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>>> 0x18000000) >>>>> Ah! Not enough space for the bridge window!:( >>>>> > >>>> please append pci=norom ... > >>> That worked. Except of course the radeon driver can't POST the >>> card without the ROM! :-P >> Can the ROM resource be mapped above 4G? > I didn't really think that through, obviously it can't because > it's not on a 64-bit capable bridge. I wonder though, could it be > shadowed then disabled early before the IOMEM? I see there's "#if 0"'d helper functions for exactly that in rom.c. They've been disabled since 2007! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+LBgkACgkQGcb56gMuC61NGgCeJoZY9iUXeM6GuhDAntEjVrAu rsUAoIROJFA5xBrZ9qzYQTGSf7lTJUTA =lofL -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-15 17:31 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 17:31 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 18:25, Steven Newbury wrote: > On 15/04/12 12:37, Steven Newbury wrote: >> On 15/04/12 11:20, Steven Newbury wrote: >>> On 14/04/12 21:48, Yinghai Lu wrote: > > [snip] > >>>> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury > >>>>>> >>>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>>> 0x18000000) >>>>> Ah! Not enough space for the bridge window!:( >>>>> > >>>> please append pci=norom ... > >>> That worked. Except of course the radeon driver can't POST the >>> card without the ROM! :-P >> Can the ROM resource be mapped above 4G? > I didn't really think that through, obviously it can't because > it's not on a 64-bit capable bridge. I wonder though, could it be > shadowed then disabled early before the IOMEM? I see there's "#if 0"'d helper functions for exactly that in rom.c. They've been disabled since 2007! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+LBgkACgkQGcb56gMuC61NGgCeJoZY9iUXeM6GuhDAntEjVrAu rsUAoIROJFA5xBrZ9qzYQTGSf7lTJUTA =lofL -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-15 17:31 ` Steven Newbury (?) @ 2012-04-15 20:05 ` Yinghai Lu 2012-04-15 20:06 ` Yinghai Lu -1 siblings, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-04-15 20:05 UTC (permalink / raw) To: Steven Newbury, Linus Torvalds Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 1506 bytes --] On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >>>>>>> >>>>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>>>> 0x18000000) >>>>>> Ah! Not enough space for the bridge window!:( >>>>>> >> >>>>> please append pci=norom ... >> >>>> That worked. Except of course the radeon driver can't POST the >>>> card without the ROM! :-P >>> Can the ROM resource be mapped above 4G? >> I didn't really think that through, obviously it can't because >> it's not on a 64-bit capable bridge. I wonder though, could it be >> shadowed then disabled early before the IOMEM? > I see there's "#if 0"'d helper functions for exactly that in rom.c. > They've been disabled since 2007! solution could be one of three: 1. when bridge support 64bit pref, will not allocate rom bar in bridge pref resource. ====> patch: rom_pref.patch 2. unconditionally to make rom bar allocation in bridge non-pref range. ====> patch: rom_no_pref.patch Looks like BIOS and at least one of other OSes is doing that. I can not find the the history why ROM res is with PREFETCH bit set. Maybe Linus has some idea about that. 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but that could fail. so could hack it like a. disable bar 0x10 and steal BAR address, then set 0x30 to that address then copy ROM to ram. after that, disable rom again and set back address to 0x10. You try to update radeon_get_bios() to achieve that. Yinghai [-- Attachment #2: rom_pref.patch --] [-- Type: application/octet-stream, Size: 1102 bytes --] Subject: [PATCH] PCI: Don't let ROM bar reduce chance to pref mem64 Now rom resource is set to PREFETCH, but is not MEM_64, So it would make the whole bridge not use pref above 4g. In that case, just clear PREFETCH for that rom resource, and push it to bridge resource without pref. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/setup-bus.c | 10 ++++++++++ 1 file changed, 10 insertions(+) Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -810,6 +810,16 @@ static int pbus_size_mem(struct pci_bus if (r->parent || (r->flags & mask) != type) continue; + + /* Don't let ROM pull down pref64 */ + if (sizeof(resource_size_t) >= 8 && + i == PCI_ROM_RESOURCE && + (type & IORESOURCE_PREFETCH) && + (mem64_mask & IORESOURCE_MEM_64)) { + r->flags &= ~IORESOURCE_PREFETCH; + continue; + } + r_size = resource_size(r); #ifdef CONFIG_PCI_IOV /* put SRIOV requested res to the optional list */ ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-15 20:05 ` Yinghai Lu @ 2012-04-15 20:06 ` Yinghai Lu 2012-04-16 6:54 ` Yinghai Lu 0 siblings, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-04-15 20:06 UTC (permalink / raw) To: Steven Newbury, Linus Torvalds Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 1667 bytes --] On Sun, Apr 15, 2012 at 1:05 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >>>>>>>> >>>>>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>>>>> 0x18000000) >>>>>>> Ah! Not enough space for the bridge window!:( >>>>>>> >>> >>>>>> please append pci=norom ... >>> >>>>> That worked. Except of course the radeon driver can't POST the >>>>> card without the ROM! :-P >>>> Can the ROM resource be mapped above 4G? >>> I didn't really think that through, obviously it can't because >>> it's not on a 64-bit capable bridge. I wonder though, could it be >>> shadowed then disabled early before the IOMEM? >> I see there's "#if 0"'d helper functions for exactly that in rom.c. >> They've been disabled since 2007! > > solution could be one of three: > 1. when bridge support 64bit pref, will not allocate rom bar in bridge > pref resource. > ====> patch: rom_pref.patch > > 2. unconditionally to make rom bar allocation in bridge non-pref range. > ====> patch: rom_no_pref.patch missed attach rom_no_pref.patch > Looks like BIOS and at least one of other OSes is doing that. > > I can not find the the history why ROM res is with PREFETCH bit set. > Maybe Linus has some idea about that. > > 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but > that could fail. > so could hack it like a. disable bar 0x10 and steal BAR address, > then set 0x30 to that address then copy ROM to ram. > after that, disable rom again and set back address to 0x10. > You try to update radeon_get_bios() to achieve that. > > Yinghai [-- Attachment #2: rom_no_pref.patch --] [-- Type: application/octet-stream, Size: 840 bytes --] Subject: [PATCH] PCI: Don't allocate rom bar in bridge pref resource Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/probe.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Index: linux-2.6/drivers/pci/probe.c =================================================================== --- linux-2.6.orig/drivers/pci/probe.c +++ linux-2.6/drivers/pci/probe.c @@ -336,9 +336,8 @@ static void pci_read_bases(struct pci_de if (rom) { struct resource *res = &dev->resource[PCI_ROM_RESOURCE]; dev->rom_base_reg = rom; - res->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH | - IORESOURCE_READONLY | IORESOURCE_CACHEABLE | - IORESOURCE_SIZEALIGN; + res->flags = IORESOURCE_MEM | IORESOURCE_READONLY | + IORESOURCE_CACHEABLE | IORESOURCE_SIZEALIGN; __pci_read_base(dev, pci_bar_mem32, res, rom); } } ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-15 20:06 ` Yinghai Lu @ 2012-04-16 6:54 ` Yinghai Lu 2012-04-16 7:01 ` Steven Newbury 2012-04-16 17:29 ` Yinghai Lu 0 siblings, 2 replies; 94+ messages in thread From: Yinghai Lu @ 2012-04-16 6:54 UTC (permalink / raw) To: Steven Newbury Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 564 bytes --] On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> wrote: >> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but >> that could fail. >> so could hack it like a. disable bar 0x10 and steal BAR address, >> then set 0x30 to that address then copy ROM to ram. >> after that, disable rom again and set back address to 0x10. >> You try to update radeon_get_bios() to achieve that. patches for solution 3: map_rom.patch will try to borrow mem or mem pref bar for ROM copying and You still need to use pci=norom Yinghai [-- Attachment #2: rom_option.patch --] [-- Type: application/octet-stream, Size: 1673 bytes --] Subject: [PATCH] PCI: Add is_pci_iov_resource_idx() So we can remove one ifdef in setup-bus.c. and will share the code in that ifdef block. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/setup-bus.c | 7 +++---- include/linux/pci.h | 8 ++++++++ 2 files changed, 11 insertions(+), 4 deletions(-) Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -813,16 +813,15 @@ static int pbus_size_mem(struct pci_bus if (r->parent || (r->flags & mask) != type) continue; r_size = resource_size(r); -#ifdef CONFIG_PCI_IOV + /* put SRIOV requested res to the optional list */ - if (realloc_head && i >= PCI_IOV_RESOURCES && - i <= PCI_IOV_RESOURCE_END) { + if (realloc_head && is_pci_iov_resource_idx(i)) { r->end = r->start - 1; add_to_list(realloc_head, dev, r, r_size, 0/* dont' care */); children_add_size += r_size; continue; } -#endif + /* For bridges size != alignment */ align = pci_resource_alignment(dev, r); order = __ffs(align) - 20; Index: linux-2.6/include/linux/pci.h =================================================================== --- linux-2.6.orig/include/linux/pci.h +++ linux-2.6/include/linux/pci.h @@ -114,6 +114,14 @@ enum { DEVICE_COUNT_RESOURCE = PCI_NUM_RESOURCES, }; +static inline bool is_pci_iov_resource_idx(int i) +{ +#ifdef CONFIG_PCI_IOV + return i >= PCI_IOV_RESOURCES && i <= PCI_IOV_RESOURCE_END; +#endif + return false; +} + typedef int __bitwise pci_power_t; #define PCI_D0 ((pci_power_t __force) 0) [-- Attachment #3: rom_option_1.patch --] [-- Type: application/octet-stream, Size: 2254 bytes --] Subject: [PATCH] PCI: Treat ROM resource as optional during assigning. So will try to allocate them together with requested ones, if can not assign them, could go with requested one only, and just skip ROM resource. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/setup-bus.c | 21 +++++++-------------- include/linux/pci.h | 5 +++++ 2 files changed, 12 insertions(+), 14 deletions(-) Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -286,18 +286,10 @@ static void assign_requested_resources_s idx = res - &dev_res->dev->resource[0]; if (resource_size(res) && pci_assign_resource_fit(dev_res->dev, idx, fit)) { - if (fail_head) { - /* - * if the failed res is for ROM BAR, and it will - * be enabled later, don't add it to the list - */ - if (!((idx == PCI_ROM_RESOURCE) && - (!(res->flags & IORESOURCE_ROM_ENABLE)))) - add_to_list(fail_head, - dev_res->dev, res, - 0 /* dont care */, - 0 /* dont care */); - } + if (fail_head) + add_to_list(fail_head, dev_res->dev, res, + 0 /* dont care */, + 0 /* dont care */); reset_resource(res); } } @@ -814,8 +806,9 @@ static int pbus_size_mem(struct pci_bus continue; r_size = resource_size(r); - /* put SRIOV requested res to the optional list */ - if (realloc_head && is_pci_iov_resource_idx(i)) { + /* put SRIOV/ROM requested res to the optional list */ + if (realloc_head && (is_pci_iov_resource_idx(i) || + is_pci_rom_resource_idx(i))) { r->end = r->start - 1; add_to_list(realloc_head, dev, r, r_size, 0/* dont' care */); children_add_size += r_size; Index: linux-2.6/include/linux/pci.h =================================================================== --- linux-2.6.orig/include/linux/pci.h +++ linux-2.6/include/linux/pci.h @@ -122,6 +122,11 @@ static inline bool is_pci_iov_resource_i return false; } +static inline bool is_pci_rom_resource_idx(int i) +{ + return i == PCI_ROM_RESOURCE; +} + typedef int __bitwise pci_power_t; #define PCI_D0 ((pci_power_t __force) 0) [-- Attachment #4: map_rom.patch --] [-- Type: application/octet-stream, Size: 4307 bytes --] Subject: [PATCH] PCI: Borrow dev mem windows to copy ROM If the mem bar is not used yet and size is bigger enough. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/pci/common.c | 3 + drivers/pci/rom.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++-- drivers/pci/setup-bus.c | 8 ++++- 3 files changed, 79 insertions(+), 5 deletions(-) Index: linux-2.6/drivers/pci/rom.c =================================================================== --- linux-2.6.orig/drivers/pci/rom.c +++ linux-2.6/drivers/pci/rom.c @@ -116,6 +116,10 @@ void __iomem *pci_map_rom(struct pci_dev struct resource *res = &pdev->resource[PCI_ROM_RESOURCE]; loff_t start; void __iomem *rom; + int i = -1; + struct resource *mem_r = NULL; + resource_size_t mem_r_start = 0; + resource_size_t mem_r_size = 0; /* * IORESOURCE_ROM_SHADOW set on x86, x86_64 and IA64 supports legacy @@ -135,8 +139,45 @@ void __iomem *pci_map_rom(struct pci_dev } else { /* assign the ROM an address if it doesn't have one */ if (res->parent == NULL && - pci_assign_resource(pdev,PCI_ROM_RESOURCE)) - return NULL; + pci_assign_resource(pdev,PCI_ROM_RESOURCE)) { + struct resource *r; + + if (res->flags || !res->end || + !resource_size(res)) + return NULL; + + /* borrow MEM resource windows */ + for (i = 0; i < PCI_ROM_RESOURCE; i++) { + r = &pdev->resource[i]; + if (!r->parent || + (r->flags & IORESOURCE_MEM) || + r->child || + resource_size(r) < resource_size(res) || + r->start >= (1ULL<<32)) + continue; + /* found one */ + mem_r = r; + break; + } + if (!mem_r) { + i = -1; + return NULL; + } + /* disable mem_r temperily */ + mem_r_start = mem_r->start; + mem_r_size = resource_size(mem_r); + mem_r->start = 0xffff0000; + mem_r->end = 0; + pci_update_resource(pdev, i); + /* restore flags */ + res->flags = IORESOURCE_MEM | + IORESOURCE_PREFETCH | + IORESOURCE_READONLY | + IORESOURCE_CACHEABLE | + IORESOURCE_SIZEALIGN; + res->end = resource_size(res) + mem_r_start - 1; + res->start = mem_r_start; + } start = pci_resource_start(pdev, PCI_ROM_RESOURCE); *size = pci_resource_len(pdev, PCI_ROM_RESOURCE); if (*size == 0) @@ -155,7 +196,7 @@ void __iomem *pci_map_rom(struct pci_dev IORESOURCE_ROM_SHADOW | IORESOURCE_ROM_COPY))) pci_disable_rom(pdev); - return NULL; + goto restore_mem_r; } /* @@ -164,6 +205,32 @@ void __iomem *pci_map_rom(struct pci_dev * True size is important if the ROM is going to be copied. */ *size = pci_get_rom_size(pdev, rom, *size); + + /* copy rom and restore borrow mem io */ + if (i >= 0) { + void __iomem *new_rom; + + new_rom = kmalloc(*size, GFP_KERNEL); + if (new_rom) + memcpy_fromio(new_rom, rom, *size); + pci_unmap_rom(pdev, rom); + if (new_rom) { + res->start = (unsigned long long)new_rom; + res->end = res->start + *size; + res->flags |= IORESOURCE_ROM_COPY; + } else { + res->start = res->end = res->flags = 0; + } + rom = new_rom; + } + +restore_mem_r: + if (i >= 0) { + mem_r->start = mem_r_start; + mem_r->end = mem_r_size + mem_r->start - 1; + pci_update_resource(pdev, i); + } + return rom; } Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -290,7 +290,13 @@ static void assign_requested_resources_s add_to_list(fail_head, dev_res->dev, res, 0 /* dont care */, 0 /* dont care */); - reset_resource(res); + /* need to save the size */ + if (idx == PCI_ROM_RESOURCE) { + res->flags = 0; + res->end -= res->start; + res->start = 0; + } else + reset_resource(res); } } } Index: linux-2.6/arch/x86/pci/common.c =================================================================== --- linux-2.6.orig/arch/x86/pci/common.c +++ linux-2.6/arch/x86/pci/common.c @@ -151,7 +151,8 @@ static void __devinit pcibios_fixup_devi /* we deal with BIOS assigned ROM later */ return; } - rom_r->start = rom_r->end = rom_r->flags = 0; + /* need to save the size */ + rom_r->flags = 0; } } ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-16 6:54 ` Yinghai Lu @ 2012-04-16 7:01 ` Steven Newbury 2012-04-16 17:29 ` Yinghai Lu 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-16 7:01 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/04/12 07:54, Yinghai Lu wrote: > On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> > wrote: >>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> >>> but that could fail. so could hack it like a. disable bar 0x10 >>> and steal BAR address, then set 0x30 to that address then copy >>> ROM to ram. after that, disable rom again and set back address >>> to 0x10. You try to update radeon_get_bios() to achieve that. > > patches for solution 3: map_rom.patch will try to borrow mem or mem > pref bar for ROM copying > > and You still need to use pci=norom > I've tested solution 2 so far and it works well. I'll test your patches for 1 and 3 later today. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Lw9oACgkQGcb56gMuC621nwCeM+6rJo8BQhKrbUNzDCJkhVsu 1sQAoJVf/8XNBsro2tyhHxj1giNrVZ6e =w3sG -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-16 7:01 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-16 7:01 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/04/12 07:54, Yinghai Lu wrote: > On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> > wrote: >>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> >>> but that could fail. so could hack it like a. disable bar 0x10 >>> and steal BAR address, then set 0x30 to that address then copy >>> ROM to ram. after that, disable rom again and set back address >>> to 0x10. You try to update radeon_get_bios() to achieve that. > > patches for solution 3: map_rom.patch will try to borrow mem or mem > pref bar for ROM copying > > and You still need to use pci=norom > I've tested solution 2 so far and it works well. I'll test your patches for 1 and 3 later today. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Lw9oACgkQGcb56gMuC621nwCeM+6rJo8BQhKrbUNzDCJkhVsu 1sQAoJVf/8XNBsro2tyhHxj1giNrVZ6e =w3sG -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-16 6:54 ` Yinghai Lu 2012-04-16 7:01 ` Steven Newbury @ 2012-04-16 17:29 ` Yinghai Lu 2012-04-18 7:21 ` Steven Newbury 2012-04-24 9:49 ` Steven Newbury 1 sibling, 2 replies; 94+ messages in thread From: Yinghai Lu @ 2012-04-16 17:29 UTC (permalink / raw) To: Steven Newbury Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 727 bytes --] On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> wrote: >>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but >>> that could fail. >>> so could hack it like a. disable bar 0x10 and steal BAR address, >>> then set 0x30 to that address then copy ROM to ram. >>> after that, disable rom again and set back address to 0x10. >>> You try to update radeon_get_bios() to achieve that. > > patches for solution 3: > map_rom.patch will try to borrow mem or mem pref bar for ROM copying > > and You still need to use pci=norom map_rom.patch missed one ! Please check map_rom_v2.patch Thanks Yinghai [-- Attachment #2: map_rom_v2.patch --] [-- Type: application/octet-stream, Size: 4308 bytes --] Subject: [PATCH] PCI: Borrow dev mem windows to copy ROM If the mem bar is not used yet and size is bigger enough. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/pci/common.c | 3 + drivers/pci/rom.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++-- drivers/pci/setup-bus.c | 8 ++++- 3 files changed, 79 insertions(+), 5 deletions(-) Index: linux-2.6/drivers/pci/rom.c =================================================================== --- linux-2.6.orig/drivers/pci/rom.c +++ linux-2.6/drivers/pci/rom.c @@ -116,6 +116,10 @@ void __iomem *pci_map_rom(struct pci_dev struct resource *res = &pdev->resource[PCI_ROM_RESOURCE]; loff_t start; void __iomem *rom; + int i = -1; + struct resource *mem_r = NULL; + resource_size_t mem_r_start = 0; + resource_size_t mem_r_size = 0; /* * IORESOURCE_ROM_SHADOW set on x86, x86_64 and IA64 supports legacy @@ -135,8 +139,45 @@ void __iomem *pci_map_rom(struct pci_dev } else { /* assign the ROM an address if it doesn't have one */ if (res->parent == NULL && - pci_assign_resource(pdev,PCI_ROM_RESOURCE)) - return NULL; + pci_assign_resource(pdev,PCI_ROM_RESOURCE)) { + struct resource *r; + + if (res->flags || !res->end || + !resource_size(res)) + return NULL; + + /* borrow MEM resource windows */ + for (i = 0; i < PCI_ROM_RESOURCE; i++) { + r = &pdev->resource[i]; + if (!r->parent || + !(r->flags & IORESOURCE_MEM) || + r->child || + resource_size(r) < resource_size(res) || + r->start >= (1ULL<<32)) + continue; + /* found one */ + mem_r = r; + break; + } + if (!mem_r) { + i = -1; + return NULL; + } + /* disable mem_r temperily */ + mem_r_start = mem_r->start; + mem_r_size = resource_size(mem_r); + mem_r->start = 0xffff0000; + mem_r->end = 0; + pci_update_resource(pdev, i); + /* restore flags */ + res->flags = IORESOURCE_MEM | + IORESOURCE_PREFETCH | + IORESOURCE_READONLY | + IORESOURCE_CACHEABLE | + IORESOURCE_SIZEALIGN; + res->end = resource_size(res) + mem_r_start - 1; + res->start = mem_r_start; + } start = pci_resource_start(pdev, PCI_ROM_RESOURCE); *size = pci_resource_len(pdev, PCI_ROM_RESOURCE); if (*size == 0) @@ -155,7 +196,7 @@ void __iomem *pci_map_rom(struct pci_dev IORESOURCE_ROM_SHADOW | IORESOURCE_ROM_COPY))) pci_disable_rom(pdev); - return NULL; + goto restore_mem_r; } /* @@ -164,6 +205,32 @@ void __iomem *pci_map_rom(struct pci_dev * True size is important if the ROM is going to be copied. */ *size = pci_get_rom_size(pdev, rom, *size); + + /* copy rom and restore borrow mem io */ + if (i >= 0) { + void __iomem *new_rom; + + new_rom = kmalloc(*size, GFP_KERNEL); + if (new_rom) + memcpy_fromio(new_rom, rom, *size); + pci_unmap_rom(pdev, rom); + if (new_rom) { + res->start = (unsigned long long)new_rom; + res->end = res->start + *size; + res->flags |= IORESOURCE_ROM_COPY; + } else { + res->start = res->end = res->flags = 0; + } + rom = new_rom; + } + +restore_mem_r: + if (i >= 0) { + mem_r->start = mem_r_start; + mem_r->end = mem_r_size + mem_r->start - 1; + pci_update_resource(pdev, i); + } + return rom; } Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -290,7 +290,13 @@ static void assign_requested_resources_s add_to_list(fail_head, dev_res->dev, res, 0 /* dont care */, 0 /* dont care */); - reset_resource(res); + /* need to save the size */ + if (idx == PCI_ROM_RESOURCE) { + res->flags = 0; + res->end -= res->start; + res->start = 0; + } else + reset_resource(res); } } } Index: linux-2.6/arch/x86/pci/common.c =================================================================== --- linux-2.6.orig/arch/x86/pci/common.c +++ linux-2.6/arch/x86/pci/common.c @@ -151,7 +151,8 @@ static void __devinit pcibios_fixup_devi /* we deal with BIOS assigned ROM later */ return; } - rom_r->start = rom_r->end = rom_r->flags = 0; + /* need to save the size */ + rom_r->flags = 0; } } ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-16 17:29 ` Yinghai Lu @ 2012-04-18 7:21 ` Steven Newbury 2012-04-24 9:49 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-18 7:21 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/04/12 18:29, Yinghai Lu wrote: > On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu <yinghai@kernel.org> > wrote: >> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... >>>> ===> but that could fail. so could hack it like a. disable >>>> bar 0x10 and steal BAR address, then set 0x30 to that address >>>> then copy ROM to ram. after that, disable rom again and set >>>> back address to 0x10. You try to update radeon_get_bios() to >>>> achieve that. >> >> patches for solution 3: map_rom.patch will try to borrow mem or >> mem pref bar for ROM copying >> >> and You still need to use pci=norom > > map_rom.patch missed one ! > > Please check map_rom_v2.patch I've been really busy, and I'm going to be mostly unavailable until Monday. I will get back to it as soon as I can. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Oa3AACgkQGcb56gMuC63HogCfWQTdBSlNcj9zwHy9m4duwmHI A4YAn2bVH1M4BjPxdfzb+AdX7v3wW79Q =mUxP -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-18 7:21 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-18 7:21 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/04/12 18:29, Yinghai Lu wrote: > On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu <yinghai@kernel.org> > wrote: >> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... >>>> ===> but that could fail. so could hack it like a. disable >>>> bar 0x10 and steal BAR address, then set 0x30 to that address >>>> then copy ROM to ram. after that, disable rom again and set >>>> back address to 0x10. You try to update radeon_get_bios() to >>>> achieve that. >> >> patches for solution 3: map_rom.patch will try to borrow mem or >> mem pref bar for ROM copying >> >> and You still need to use pci=norom > > map_rom.patch missed one ! > > Please check map_rom_v2.patch I've been really busy, and I'm going to be mostly unavailable until Monday. I will get back to it as soon as I can. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Oa3AACgkQGcb56gMuC63HogCfWQTdBSlNcj9zwHy9m4duwmHI A4YAn2bVH1M4BjPxdfzb+AdX7v3wW79Q =mUxP -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-16 17:29 ` Yinghai Lu @ 2012-04-24 9:49 ` Steven Newbury 2012-04-24 9:49 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-24 9:49 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/04/12 18:29, Yinghai Lu wrote: > On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu <yinghai@kernel.org> > wrote: >> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... >>>> ===> but that could fail. so could hack it like a. disable >>>> bar 0x10 and steal BAR address, then set 0x30 to that address >>>> then copy ROM to ram. after that, disable rom again and set >>>> back address to 0x10. You try to update radeon_get_bios() to >>>> achieve that. >> >> patches for solution 3: map_rom.patch will try to borrow mem or >> mem pref bar for ROM copying >> >> and You still need to use pci=norom > > map_rom.patch missed one ! > > Please check map_rom_v2.patch > Hopefully, I'm going to have time to look into this again later today, depending how well other tasks go... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+WdwwACgkQGcb56gMuC62DgQCglk+MxOIxWxbLChNWNlAOdbSp tysAnA83Mfa6tZ6TC97xHIqpFqtPJ5Wc =Vd8+ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-24 9:49 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-24 9:49 UTC (permalink / raw) To: Yinghai Lu; +Cc: Bjorn Helgaas, Barnes, Jesse, DRI mailing list, linux-pci -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/04/12 18:29, Yinghai Lu wrote: > On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu <yinghai@kernel.org> > wrote: >> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... >>>> ===> but that could fail. so could hack it like a. disable >>>> bar 0x10 and steal BAR address, then set 0x30 to that address >>>> then copy ROM to ram. after that, disable rom again and set >>>> back address to 0x10. You try to update radeon_get_bios() to >>>> achieve that. >> >> patches for solution 3: map_rom.patch will try to borrow mem or >> mem pref bar for ROM copying >> >> and You still need to use pci=norom > > map_rom.patch missed one ! > > Please check map_rom_v2.patch > Hopefully, I'm going to have time to look into this again later today, depending how well other tasks go... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+WdwwACgkQGcb56gMuC62DgQCglk+MxOIxWxbLChNWNlAOdbSp tysAnA83Mfa6tZ6TC97xHIqpFqtPJ5Wc =Vd8+ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
[parent not found: <4FB227D3.7090002@snewbury.org.uk>]
[parent not found: <CAE9FiQX48eCS85eWMFxm6fCWgu2zwxvSywtQhsf-35WEvBfJVQ@mail.gmail.com>]
* Re: PCI resources above 4GB [not found] ` <CAE9FiQX48eCS85eWMFxm6fCWgu2zwxvSywtQhsf-35WEvBfJVQ@mail.gmail.com> @ 2012-05-17 12:27 ` Steven Newbury 2012-05-17 12:34 ` Steven Newbury 0 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-05-17 12:27 UTC (permalink / raw) To: Yinghai Lu; +Cc: linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/05/12 18:42, Yinghai Lu wrote: > On Tue, May 15, 2012 at 2:54 AM, Steven Newbury > <steve@snewbury.org.uk> wrote: > >> I'll get re-synced back up, and if they're still relevant give >> the patches a test. Is there an updated branch I should work >> from? > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > > for-pci-res-alloc > > and attached patch. > > Thanks > > Yinghai Hi Yinghai, I also cherry-picked the pref_bar patch and my local "Intel Flush Page" patch. It boots, and the Intel GMA is allocated >4G, but the radeon doesn't get detected with "for-pci-res-alloc" on hotplug (needs busn-alloc patches), so I can't test it. Booting docked, then undocking/docking does work though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+07pkACgkQGcb56gMuC634nwCfcmr5Ub8mA9HOXjsFdWmttjEb NTAAn0ul6BEKzGz2eoobq2CvpOTzUBzf =kq5H -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-05-17 12:27 ` Steven Newbury @ 2012-05-17 12:34 ` Steven Newbury 2012-05-17 16:36 ` Yinghai Lu 0 siblings, 1 reply; 94+ messages in thread From: Steven Newbury @ 2012-05-17 12:34 UTC (permalink / raw) To: Yinghai Lu; +Cc: linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/05/12 13:27, Steven Newbury wrote: > On 15/05/12 18:42, Yinghai Lu wrote: >> On Tue, May 15, 2012 at 2:54 AM, Steven Newbury >> <steve@snewbury.org.uk> wrote: > >>> I'll get re-synced back up, and if they're still relevant give >>> the patches a test. Is there an updated branch I should work >>> from? > >> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > >> > > for-pci-res-alloc > >> and attached patch. > >> Thanks > >> Yinghai > > Hi Yinghai, I also cherry-picked the pref_bar patch and my local > "Intel Flush Page" patch. > > It boots, and the Intel GMA is allocated >4G, but the radeon > doesn't get detected with "for-pci-res-alloc" on hotplug (needs > busn-alloc patches), Strange, the busn branch is merged with for-pci-res-alloc, but for some reason it isn't working. Only the bridge is detected, not the devices behind it. so I can't test it. Booting docked, then undocking/docking > does work though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+08DkACgkQGcb56gMuC62miwCgv7nU/Uf3CccBwbqFLHTQL2Zp wygAoLsYma5GaAVHorCRxjS5v6Hw2fQx =bGut -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-05-17 12:34 ` Steven Newbury @ 2012-05-17 16:36 ` Yinghai Lu 2012-05-18 7:45 ` Yinghai Lu 0 siblings, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-05-17 16:36 UTC (permalink / raw) To: Steven Newbury; +Cc: linux-pci, DRI mailing list On Thu, May 17, 2012 at 5:34 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Strange, the busn branch is merged with for-pci-res-alloc, but for > some reason it isn't working. Only the bridge is detected, not the > devices behind it. Can you post the boot log ? maybe recently reordering patches applying sequence break it. Yinghai ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-05-17 16:36 ` Yinghai Lu @ 2012-05-18 7:45 ` Yinghai Lu 2012-05-18 9:08 ` Yinghai Lu 0 siblings, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-05-18 7:45 UTC (permalink / raw) To: Steven Newbury; +Cc: linux-pci, DRI mailing list On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> wrote: > On Thu, May 17, 2012 at 5:34 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Strange, the busn branch is merged with for-pci-res-alloc, but for >> some reason it isn't working. Only the bridge is detected, not the >> devices behind it. > > Can you post the boot log ? maybe recently reordering patches applying > sequence break it. Never mind, found the problem. will check if i could fix it tomorrow. Yinghai ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-05-18 7:45 ` Yinghai Lu @ 2012-05-18 9:08 ` Yinghai Lu 2012-05-21 17:27 ` Steven Newbury 0 siblings, 1 reply; 94+ messages in thread From: Yinghai Lu @ 2012-05-18 9:08 UTC (permalink / raw) To: Steven Newbury; +Cc: linux-pci, DRI mailing list On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu <yinghai@kernel.org> wrote: > On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> wrote: >> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Strange, the busn branch is merged with for-pci-res-alloc, but for >>> some reason it isn't working. Only the bridge is detected, not the >>> devices behind it. >> >> Can you post the boot log ? maybe recently reordering patches applying >> sequence break it. > > Never mind, found the problem. updated for-pci-res-alloc branch. please check it. Thanks Yinghai ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-05-18 9:08 ` Yinghai Lu @ 2012-05-21 17:27 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-05-21 17:27 UTC (permalink / raw) To: Yinghai Lu; +Cc: linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/05/12 10:08, Yinghai Lu wrote: > On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu <yinghai@kernel.org> > wrote: >> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury >>> <steve@snewbury.org.uk> wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Strange, the busn branch >>>> is merged with for-pci-res-alloc, but for some reason it >>>> isn't working. Only the bridge is detected, not the devices >>>> behind it. >>> >>> Can you post the boot log ? maybe recently reordering patches >>> applying sequence break it. >> >> Never mind, found the problem. > > updated for-pci-res-alloc branch. please check it. > Tested and working fine now. Some random update broke gnome-shell, so couldn't test it straight away. In the end I gave up fixing it and reverted to an earlier system snapshot. btrfs can be very useful! :) There is an outstanding issue with i915 though. With the moved BAR the screen remains blank when i915 loads (should show fbcon) and doesn't light up until X initialises. (X produces a modeset I assume.) After that everything works fine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+6eu4ACgkQGcb56gMuC61InACfa+SvYmWXxJb3x1YTXOJhQWLE 0HkAoKcKhk7elSx1LIaxVdrxiBZibzDa =MaOP -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-05-21 17:27 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-05-21 17:27 UTC (permalink / raw) To: Yinghai Lu; +Cc: linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/05/12 10:08, Yinghai Lu wrote: > On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu <yinghai@kernel.org> > wrote: >> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury >>> <steve@snewbury.org.uk> wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Strange, the busn branch >>>> is merged with for-pci-res-alloc, but for some reason it >>>> isn't working. Only the bridge is detected, not the devices >>>> behind it. >>> >>> Can you post the boot log ? maybe recently reordering patches >>> applying sequence break it. >> >> Never mind, found the problem. > > updated for-pci-res-alloc branch. please check it. > Tested and working fine now. Some random update broke gnome-shell, so couldn't test it straight away. In the end I gave up fixing it and reverted to an earlier system snapshot. btrfs can be very useful! :) There is an outstanding issue with i915 though. With the moved BAR the screen remains blank when i915 loads (should show fbcon) and doesn't light up until X initialises. (X produces a modeset I assume.) After that everything works fine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+6eu4ACgkQGcb56gMuC61InACfa+SvYmWXxJb3x1YTXOJhQWLE 0HkAoKcKhk7elSx1LIaxVdrxiBZibzDa =MaOP -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-05-21 17:27 ` Steven Newbury (?) @ 2012-05-29 23:19 ` Bjorn Helgaas 2012-06-01 23:06 ` Bjorn Helgaas -1 siblings, 1 reply; 94+ messages in thread From: Bjorn Helgaas @ 2012-05-29 23:19 UTC (permalink / raw) To: Steven Newbury; +Cc: Yinghai Lu, linux-pci, DRI mailing list On Mon, May 21, 2012 at 11:27 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 18/05/12 10:08, Yinghai Lu wrote: >> On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> >>> wrote: >>>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury >>>> <steve@snewbury.org.uk> wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Strange, the busn branch >>>>> is merged with for-pci-res-alloc, but for some reason it >>>>> isn't working. Only the bridge is detected, not the devices >>>>> behind it. >>>> >>>> Can you post the boot log ? maybe recently reordering patches >>>> applying sequence break it. >>> >>> Never mind, found the problem. >> >> updated for-pci-res-alloc branch. please check it. >> > Tested and working fine now. Can you attach dmesg logs without Yinghai's patches (where I assume it doesn't work) and with them (where it *does* work) to the bugzilla? I assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the relevant report. I'm confused because I thought your _CRS showed no apertures above 4GB, and I'm trying to figure out how Yinghai's patches can help if that's the case. Bjorn ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-05-29 23:19 ` Bjorn Helgaas @ 2012-06-01 23:06 ` Bjorn Helgaas 0 siblings, 0 replies; 94+ messages in thread From: Bjorn Helgaas @ 2012-06-01 23:06 UTC (permalink / raw) To: Steven Newbury; +Cc: Yinghai Lu, linux-pci, DRI mailing list On Tue, May 29, 2012 at 5:19 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > On Mon, May 21, 2012 at 11:27 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 18/05/12 10:08, Yinghai Lu wrote: >>> On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu <yinghai@kernel.org> >>> wrote: >>>> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> >>>> wrote: >>>>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury >>>>> <steve@snewbury.org.uk> wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Strange, the busn branch >>>>>> is merged with for-pci-res-alloc, but for some reason it >>>>>> isn't working. Only the bridge is detected, not the devices >>>>>> behind it. >>>>> >>>>> Can you post the boot log ? maybe recently reordering patches >>>>> applying sequence break it. >>>> >>>> Never mind, found the problem. >>> >>> updated for-pci-res-alloc branch. please check it. >>> >> Tested and working fine now. > > Can you attach dmesg logs without Yinghai's patches (where I assume it > doesn't work) and with them (where it *does* work) to the bugzilla? I > assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the > relevant report. > > I'm confused because I thought your _CRS showed no apertures above > 4GB, and I'm trying to figure out how Yinghai's patches can help if > that's the case. Your _CRS *doesn't* show any apertures above 4GB, but you're booting with "pci=nocrs", so we ignore them anyway. Doing hotplug with "pci=nocrs" is not a supportable proposition. Patches that help in the "pci=nocrs" case might be acceptable, but only if there is clearly no risk to the "pci=use_crs" case. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-14 17:37 ` Steven Newbury (?) (?) @ 2012-04-15 3:21 ` Yinghai Lu 2012-04-15 10:18 ` Steven Newbury 2012-04-15 11:31 ` Steven Newbury -1 siblings, 2 replies; 94+ messages in thread From: Yinghai Lu @ 2012-04-15 3:21 UTC (permalink / raw) To: Steven Newbury Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 438 bytes --] On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > I've created a new quirk utilising an extra PCI resource flag to force > reallocation of the resource. It's the first approach I've had any > success at. It does work. Only "Intel Page Flush" now gets allocated > @0xe0000000! Maybe we can be more aggressive with pci=pref_bar to reassign all pref mem. Please check attached patch. Yinghai [-- Attachment #2: pci_assign_pref.patch --] [-- Type: application/octet-stream, Size: 2358 bytes --] Subject: [PATCH] PCI, x86: Add pci=pref_bar to realloc pref bars So could reallocate 64bit pref mem above 4g. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/include/asm/pci_x86.h | 1 + arch/x86/pci/common.c | 3 +++ arch/x86/pci/i386.c | 8 ++++++-- 3 files changed, 10 insertions(+), 2 deletions(-) Index: linux-2.6/arch/x86/include/asm/pci_x86.h =================================================================== --- linux-2.6.orig/arch/x86/include/asm/pci_x86.h +++ linux-2.6/arch/x86/include/asm/pci_x86.h @@ -31,6 +31,7 @@ #define PCI_NOASSIGN_ROMS 0x80000 #define PCI_ROOT_NO_CRS 0x100000 #define PCI_NOASSIGN_BARS 0x200000 +#define PCI_ASSIGN_PREF_BARS 0x400000 extern unsigned int pci_probe; extern unsigned long pirq_table_addr; Index: linux-2.6/arch/x86/pci/common.c =================================================================== --- linux-2.6.orig/arch/x86/pci/common.c +++ linux-2.6/arch/x86/pci/common.c @@ -556,6 +556,9 @@ char * __devinit pcibios_setup(char *st } else if (!strcmp(str, "assign-busses")) { pci_probe |= PCI_ASSIGN_ALL_BUSSES; return NULL; + } else if (!strcmp(str, "pref_bar")) { + pci_probe |= PCI_ASSIGN_PREF_BARS; + return NULL; } else if (!strcmp(str, "use_crs")) { pci_probe |= PCI_USE__CRS; return NULL; Index: linux-2.6/arch/x86/pci/i386.c =================================================================== --- linux-2.6.orig/arch/x86/pci/i386.c +++ linux-2.6/arch/x86/pci/i386.c @@ -212,7 +212,9 @@ static void pcibios_allocate_bridge_reso continue; if (!r->flags) continue; - if (!r->start || pci_claim_resource(dev, idx) < 0) { + if (((r->flags & IORESOURCE_PREFETCH) && + (pci_probe & PCI_ASSIGN_PREF_BARS)) || + !r->start || pci_claim_resource(dev, idx) < 0) { /* * Something is wrong with the region. * Invalidate the resource to prevent @@ -256,7 +258,9 @@ static void pcibios_allocate_dev_resourc dev_dbg(&dev->dev, "BAR %d: reserving %pr (d=%d, p=%d)\n", idx, r, disabled, pass); - if (pci_claim_resource(dev, idx) < 0) { + if (((r->flags & IORESOURCE_PREFETCH) && + (pci_probe & PCI_ASSIGN_PREF_BARS)) || + pci_claim_resource(dev, idx) < 0) { /* We'll assign a new address later */ pcibios_save_fw_addr(dev, idx, r->start); r->end -= r->start; ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-15 3:21 ` Yinghai Lu @ 2012-04-15 10:18 ` Steven Newbury 2012-04-15 11:31 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 10:18 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 04:21, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> I've created a new quirk utilising an extra PCI resource flag to >> force reallocation of the resource. It's the first approach I've >> had any success at. It does work. Only "Intel Page Flush" now >> gets allocated @0xe0000000! > > Maybe we can be more aggressive with pci=pref_bar to reassign all > pref mem. > > Please check attached patch. I'll give it a go, but not sure if it will work if it causes the GMA 1Mb MEMIO above 4G. From my testing the i915 driver isn't happy with that. Lower part of the framebuffer is corrupted (overlapping something?), and the Xorg driver fails to initialise (just garbage on the screen). Not sure what's happing there, I tried to duplicate your gma_addr patch for the other 64-bit registers read into gtt_addr and reg_addr. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KoJMACgkQGcb56gMuC6056gCcCLtdrliMEudCY32F5Vobz9+I vc0AnRX0vy6vI9EBtSqxI6KpkHIMQ0o4 =teYN -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-15 10:18 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 10:18 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 04:21, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> I've created a new quirk utilising an extra PCI resource flag to >> force reallocation of the resource. It's the first approach I've >> had any success at. It does work. Only "Intel Page Flush" now >> gets allocated @0xe0000000! > > Maybe we can be more aggressive with pci=pref_bar to reassign all > pref mem. > > Please check attached patch. I'll give it a go, but not sure if it will work if it causes the GMA 1Mb MEMIO above 4G. From my testing the i915 driver isn't happy with that. Lower part of the framebuffer is corrupted (overlapping something?), and the Xorg driver fails to initialise (just garbage on the screen). Not sure what's happing there, I tried to duplicate your gma_addr patch for the other 64-bit registers read into gtt_addr and reg_addr. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KoJMACgkQGcb56gMuC6056gCcCLtdrliMEudCY32F5Vobz9+I vc0AnRX0vy6vI9EBtSqxI6KpkHIMQ0o4 =teYN -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-15 3:21 ` Yinghai Lu @ 2012-04-15 11:31 ` Steven Newbury 2012-04-15 11:31 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 11:31 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 04:21, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> I've created a new quirk utilising an extra PCI resource flag to >> force reallocation of the resource. It's the first approach I've >> had any success at. It does work. Only "Intel Page Flush" now >> gets allocated @0xe0000000! > > Maybe we can be more aggressive with pci=pref_bar to reassign all > pref mem. > > Please check attached patch. Had the same effect as my patch in allocating the 256MB GMA BAR high. 00000000-0000ffff : reserved 00010000-0009efff : System RAM 0009f000-0009ffff : reserved 000c0000-000c7fff : Video ROM 000cf000-000cffff : Adapter ROM 000f0000-000fffff : System ROM 00100000-df65a7ff : System RAM 01000000-0136df3d : Kernel code 0136df3e-0169127f : Kernel data 0172f000-01809fff : Kernel bss df65a800-dfffffff : reserved df65a800-df6fffff : pnp 00:0d df700000-df7fffff : pnp 00:0d f6900000-f69fffff : PCI Bus 0000:09 f69f0000-f69fffff : 0000:09:00.0 f69f0000-f69fffff : tg3 f6a00000-f6bfffff : PCI Bus 0000:0d f6c00000-f6cfffff : PCI Bus 0000:0c f6cfe000-f6cfffff : 0000:0c:00.0 f6cfe000-f6cfffff : iwl4965 f6dfb700-f6dfb7ff : 0000:00:1f.3 f6dfb800-f6dfbfff : 0000:00:1f.2 f6dfb800-f6dfbfff : ahci f6dfc000-f6dfffff : 0000:00:1b.0 f6dfc000-f6dfffff : ICH HD audio f6e00000-f6efffff : 0000:00:02.0 f6f00000-f6ffffff : 0000:00:02.1 f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f] f8000000-fbffffff : reserved f8000000-fbffffff : pnp 00:0d fec00000-fec0ffff : reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:08 fed18000-fed1bfff : reserved fed18000-fed1bfff : pnp 00:0d fed1c000-fed1c3ff : 0000:00:1d.7 fed1c000-fed1c3ff : ehci_hcd fed1c400-fed1c7ff : 0000:00:1a.7 fed1c400-fed1c7ff : ehci_hcd fed1d000-fed1dfff : Intel Flush Page fed20000-fed8ffff : reserved fed20000-fed3ffff : pnp 00:0d fed40000-fed44fff : pnp 00:0a fed45000-fed8ffff : pnp 00:0d feda0000-feda5fff : reserved feda0000-feda3fff : pnp 00:0d feda4000-feda4fff : pnp 00:0d feda5000-feda5fff : pnp 00:0d feda6000-feda6fff : pnp 00:0d fee00000-fee0ffff : reserved fee00000-fee0ffff : pnp 00:0d fee00000-fee00fff : Local APIC fef00000-feffffff : PCI Bus 0000:04 fefbc000-fefbffff : 0000:04:00.1 fefbc000-fefbffff : ICH HD audio fefc0000-fefdffff : 0000:04:00.0 fefe0000-feffffff : 0000:04:00.0 ffa00000-ffbfffff : pnp 00:0d ffc00000-ffdfffff : PCI Bus 0000:0b ffe00000-ffffffff : reserved ffe00000-ffffffff : pnp 00:0d 100000000-11fffffff : System RAM fef800000-fef9fffff : PCI Bus 0000:09 fefa00000-fefbfffff : PCI Bus 0000:0d fefc00000-fefdfffff : PCI Bus 0000:0c fefe00000-fefffffff : PCI Bus 0000:0b ff0000000-fffffffff : 0000:00:02.0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KsYMACgkQGcb56gMuC62iIQCfWJ7oLOrcL/88YzalEzIrWY/a LbgAnjzqkflQKzJVDhs0qQ/gxQ1a9FXH =/ae3 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB @ 2012-04-15 11:31 ` Steven Newbury 0 siblings, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-15 11:31 UTC (permalink / raw) To: Yinghai Lu Cc: Barnes, Jesse, Dave Airlie, Bjorn Helgaas, linux-pci, DRI mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 04:21, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> I've created a new quirk utilising an extra PCI resource flag to >> force reallocation of the resource. It's the first approach I've >> had any success at. It does work. Only "Intel Page Flush" now >> gets allocated @0xe0000000! > > Maybe we can be more aggressive with pci=pref_bar to reassign all > pref mem. > > Please check attached patch. Had the same effect as my patch in allocating the 256MB GMA BAR high. 00000000-0000ffff : reserved 00010000-0009efff : System RAM 0009f000-0009ffff : reserved 000c0000-000c7fff : Video ROM 000cf000-000cffff : Adapter ROM 000f0000-000fffff : System ROM 00100000-df65a7ff : System RAM 01000000-0136df3d : Kernel code 0136df3e-0169127f : Kernel data 0172f000-01809fff : Kernel bss df65a800-dfffffff : reserved df65a800-df6fffff : pnp 00:0d df700000-df7fffff : pnp 00:0d f6900000-f69fffff : PCI Bus 0000:09 f69f0000-f69fffff : 0000:09:00.0 f69f0000-f69fffff : tg3 f6a00000-f6bfffff : PCI Bus 0000:0d f6c00000-f6cfffff : PCI Bus 0000:0c f6cfe000-f6cfffff : 0000:0c:00.0 f6cfe000-f6cfffff : iwl4965 f6dfb700-f6dfb7ff : 0000:00:1f.3 f6dfb800-f6dfbfff : 0000:00:1f.2 f6dfb800-f6dfbfff : ahci f6dfc000-f6dfffff : 0000:00:1b.0 f6dfc000-f6dfffff : ICH HD audio f6e00000-f6efffff : 0000:00:02.0 f6f00000-f6ffffff : 0000:00:02.1 f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f] f8000000-fbffffff : reserved f8000000-fbffffff : pnp 00:0d fec00000-fec0ffff : reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:08 fed18000-fed1bfff : reserved fed18000-fed1bfff : pnp 00:0d fed1c000-fed1c3ff : 0000:00:1d.7 fed1c000-fed1c3ff : ehci_hcd fed1c400-fed1c7ff : 0000:00:1a.7 fed1c400-fed1c7ff : ehci_hcd fed1d000-fed1dfff : Intel Flush Page fed20000-fed8ffff : reserved fed20000-fed3ffff : pnp 00:0d fed40000-fed44fff : pnp 00:0a fed45000-fed8ffff : pnp 00:0d feda0000-feda5fff : reserved feda0000-feda3fff : pnp 00:0d feda4000-feda4fff : pnp 00:0d feda5000-feda5fff : pnp 00:0d feda6000-feda6fff : pnp 00:0d fee00000-fee0ffff : reserved fee00000-fee0ffff : pnp 00:0d fee00000-fee00fff : Local APIC fef00000-feffffff : PCI Bus 0000:04 fefbc000-fefbffff : 0000:04:00.1 fefbc000-fefbffff : ICH HD audio fefc0000-fefdffff : 0000:04:00.0 fefe0000-feffffff : 0000:04:00.0 ffa00000-ffbfffff : pnp 00:0d ffc00000-ffdfffff : PCI Bus 0000:0b ffe00000-ffffffff : reserved ffe00000-ffffffff : pnp 00:0d 100000000-11fffffff : System RAM fef800000-fef9fffff : PCI Bus 0000:09 fefa00000-fefbfffff : PCI Bus 0000:0d fefc00000-fefdfffff : PCI Bus 0000:0c fefe00000-fefffffff : PCI Bus 0000:0b ff0000000-fffffffff : 0000:00:02.0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KsYMACgkQGcb56gMuC62iIQCfWJ7oLOrcL/88YzalEzIrWY/a LbgAnjzqkflQKzJVDhs0qQ/gxQ1a9FXH =/ae3 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-12 11:22 ` Steven Newbury 2012-04-12 16:07 ` Yinghai Lu @ 2012-04-12 16:29 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-12 16:29 UTC (permalink / raw) To: Yinghai Lu, Barnes, Jesse, Dave Airlie Cc: Bjorn Helgaas, linux-pci, DRI mailing list On Thu, 12 Apr 2012, 12:22:34 BST, Steven Newbury <steve@snewbury.org.uk> wrote: > I've attempted to modify probe.c to disable 64-bit BARs not allocated > above 4G so they get reallocated above when possible later. It seemed > to work, but again broke GMA despite the BAR originally containing an > invalid address as mentioned above, it seems for some reason something > is different when the conflict is detected and rellocated, compared to > disabling it early then allocating a valid value..? I understand now why it didn't work. Memory decoding was enabled in the GMA device. When it's detected as in conflict with system RAM it gets reallocated cleanly, but setting the BAR to 0 prevents that from happening. Somehow I need to get the resources I want moved onto a realloc list, but I can't work out where or how... ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: PCI resources above 4GB 2012-04-10 20:45 ` Yinghai Lu 2012-04-10 21:19 ` Steven Newbury @ 2012-04-11 11:43 ` Steven Newbury 1 sibling, 0 replies; 94+ messages in thread From: Steven Newbury @ 2012-04-11 11:43 UTC (permalink / raw) To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci On Tue, 10 Apr 2012, 21:45:54 BST, Yinghai Lu <yinghai@kernel.org> wrote: > On Tue, Apr 10, 2012 at 1:26 PM, Steven Newbury <steve@snewbury.org.uk> > wrote: > > > > > So far I'm concluding the BIOS isn't sane. Is it possible to define a > > custom memory map from the linux boot cmdline to set TOP_OF_LOW_MEM? > > The BIOS have MMIO and memory overlapping... > > > > > Obviously, I'd prefer getting everything allocated into the address > > space available, and working, but if it comes down to it I'd accept a > > hack like the above if there's no other way. > > Could try to reduce carbus preallocated size.... boot with > pci=cbmemsize=16M I've managed to get the radeon to work by turning off the cardbus controller in the BIOS setup. I'll try the patch and the above parameter next. > > Please apply attached patch in addtition to allocate_high_at_first Btw, I've verified why the intel gfx isn't working, intel-agp.c only reads the lower 32bits of the aperture location. It is definitely supported over 4G by the hardware, see my other email. ^ permalink raw reply [flat|nested] 94+ messages in thread
end of thread, other threads:[~2012-06-01 23:07 UTC | newest] Thread overview: 94+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-09 10:49 PCI resources above 4GB Steven Newbury 2012-04-10 0:51 ` Bjorn Helgaas 2012-04-10 10:53 ` Steven Newbury 2012-04-10 15:16 ` Yinghai Lu [not found] ` <4F8467AA.90305@snewbury.org.uk> 2012-04-10 17:29 ` Steven Newbury 2012-04-10 18:40 ` Yinghai Lu 2012-04-10 18:44 ` Steven Newbury 2012-04-10 19:00 ` Steven Newbury 2012-04-10 19:04 ` Steven Newbury 2012-04-10 19:16 ` Yinghai Lu 2012-04-10 19:46 ` Steven Newbury 2012-04-10 20:07 ` Yinghai Lu 2012-04-10 20:26 ` Steven Newbury 2012-04-10 20:45 ` Yinghai Lu 2012-04-10 21:19 ` Steven Newbury 2012-04-11 3:37 ` Bjorn Helgaas 2012-04-11 5:33 ` Steven Newbury 2012-04-11 9:03 ` Steven Newbury 2012-04-11 14:33 ` Steven Newbury 2012-04-11 23:59 ` Bjorn Helgaas 2012-04-12 11:39 ` Steven Newbury 2012-04-12 0:57 ` Yinghai Lu 2012-04-12 11:22 ` Steven Newbury 2012-04-12 16:07 ` Yinghai Lu 2012-04-12 16:40 ` Steven Newbury 2012-04-13 8:26 ` Yinghai Lu 2012-04-13 8:34 ` Steven Newbury 2012-04-13 11:45 ` Steven Newbury 2012-04-13 11:58 ` Steven Newbury 2012-04-13 11:58 ` Steven Newbury 2012-04-13 12:49 ` Steven Newbury 2012-04-13 12:49 ` Steven Newbury 2012-04-13 13:26 ` Steven Newbury 2012-04-13 13:26 ` Steven Newbury 2012-04-13 13:52 ` drm-next i915 regression? ( was: Re: PCI resources above 4GB) Steven Newbury 2012-04-13 14:08 ` Steven Newbury 2012-04-13 14:08 ` Steven Newbury 2012-04-13 14:13 ` Daniel Vetter 2012-04-13 14:19 ` Steven Newbury 2012-04-13 15:23 ` Steven Newbury 2012-04-13 15:23 ` Steven Newbury 2012-04-13 15:49 ` Steven Newbury 2012-04-13 16:17 ` Yinghai Lu 2012-04-13 17:12 ` btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)] Steven Newbury 2012-04-13 17:38 ` drm-next i915 regression? ( was: Re: PCI resources above 4GB) Steven Newbury 2012-04-13 18:12 ` Steven Newbury 2012-04-13 21:51 ` Btrfs corruption Oops " Steven Newbury 2012-04-14 17:37 ` PCI resources above 4GB Steven Newbury 2012-04-14 17:37 ` Steven Newbury 2012-04-14 18:05 ` Steven Newbury 2012-04-14 18:05 ` Steven Newbury 2012-04-14 18:42 ` Steven Newbury 2012-04-14 18:42 ` Steven Newbury 2012-04-14 19:08 ` Steven Newbury 2012-04-14 19:08 ` Steven Newbury 2012-04-14 19:21 ` Steven Newbury 2012-04-14 19:21 ` Steven Newbury 2012-04-14 20:48 ` Yinghai Lu 2012-04-15 10:19 ` Steven Newbury 2012-04-15 10:19 ` Steven Newbury 2012-04-15 10:20 ` Steven Newbury 2012-04-15 10:20 ` Steven Newbury 2012-04-15 11:37 ` Steven Newbury 2012-04-15 11:37 ` Steven Newbury 2012-04-15 17:25 ` Steven Newbury 2012-04-15 17:25 ` Steven Newbury 2012-04-15 17:31 ` Steven Newbury 2012-04-15 17:31 ` Steven Newbury 2012-04-15 20:05 ` Yinghai Lu 2012-04-15 20:06 ` Yinghai Lu 2012-04-16 6:54 ` Yinghai Lu 2012-04-16 7:01 ` Steven Newbury 2012-04-16 7:01 ` Steven Newbury 2012-04-16 17:29 ` Yinghai Lu 2012-04-18 7:21 ` Steven Newbury 2012-04-18 7:21 ` Steven Newbury 2012-04-24 9:49 ` Steven Newbury 2012-04-24 9:49 ` Steven Newbury [not found] ` <4FB227D3.7090002@snewbury.org.uk> [not found] ` <CAE9FiQX48eCS85eWMFxm6fCWgu2zwxvSywtQhsf-35WEvBfJVQ@mail.gmail.com> 2012-05-17 12:27 ` Steven Newbury 2012-05-17 12:34 ` Steven Newbury 2012-05-17 16:36 ` Yinghai Lu 2012-05-18 7:45 ` Yinghai Lu 2012-05-18 9:08 ` Yinghai Lu 2012-05-21 17:27 ` Steven Newbury 2012-05-21 17:27 ` Steven Newbury 2012-05-29 23:19 ` Bjorn Helgaas 2012-06-01 23:06 ` Bjorn Helgaas 2012-04-15 3:21 ` Yinghai Lu 2012-04-15 10:18 ` Steven Newbury 2012-04-15 10:18 ` Steven Newbury 2012-04-15 11:31 ` Steven Newbury 2012-04-15 11:31 ` Steven Newbury 2012-04-12 16:29 ` Steven Newbury 2012-04-11 11:43 ` Steven Newbury
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.