Re: PCI resources above 4GB

Re: PCI resources above 4GB

[Yinghai Lu]

[-- 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;

Re: PCI resources above 4GB

[Steven Newbury]

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.

Re: PCI resources above 4GB

[Yinghai Lu]

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

Re: PCI resources above 4GB

[Steven Newbury]

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.

Re: PCI resources above 4GB

[Yinghai Lu]

[-- 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;
 }

Re: PCI resources above 4GB

[Steven Newbury]

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.

Re: PCI resources above 4GB

[Steven Newbury]

[-- 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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

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

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

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

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Daniel Vetter]

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

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

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

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

[-- 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

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

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

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Yinghai Lu]

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

btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)]

[Steven Newbury]

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

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

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

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

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

Btrfs corruption Oops ( was: Re: PCI resources above 4GB)

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

[-- 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)

Re: PCI resources above 4GB

[Steven Newbury]

[-- 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;
 }

Re: PCI resources above 4GB

[Steven Newbury]

[-- 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);

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Yinghai Lu]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Yinghai Lu]

[-- 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 */

Re: PCI resources above 4GB

[Yinghai Lu]

[-- 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);
 	}
 }

Re: PCI resources above 4GB

[Yinghai Lu]

[-- 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;
 	}
 }
 

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Yinghai Lu]

[-- 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;
 	}
 }
 

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Yinghai Lu]

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

Re: PCI resources above 4GB

[Yinghai Lu]

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

Re: PCI resources above 4GB

[Yinghai Lu]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Bjorn Helgaas]

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

Re: PCI resources above 4GB

[Bjorn Helgaas]

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.

Re: PCI resources above 4GB

[Yinghai Lu]

[-- 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;

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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

Re: PCI resources above 4GB

[Steven Newbury]

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