* 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
* 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-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
* 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-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-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-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 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-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 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-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 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-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
* 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
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.