| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20140307204021.GA9822@google.com>
Date: Fri, 7 Mar 2014 13:40:21 -0700
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: Paul Bolle <pebolle@...cali.nl>
Cc: Steven Newbury <steve@...wbury.org.uk>,
Daniel Vetter <daniel.vetter@...ll.ch>,
David Airlie <airlied@...ux.ie>,
intel-gfx <intel-gfx@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Yinghai Lu <yinghai@...nel.org>
Subject: Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset
flushing
On Fri, Mar 07, 2014 at 06:16:49PM +0100, Paul Bolle wrote:
> Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]:
> > On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle <pebolle@...cali.nl> wrote:
> > > This might end up not being relevant. And this is surely documented
> > > somewhere, but anyhow:
> > > - what git magic returns the hashes of the 15 commits that merge commit
> > > 96702be56037 added to the tree; and
> >
> > "git show 96702be56037" gives:
> >
> > commit 96702be560374ee7e7139a34cab03554129abbb4
> > Merge: 04f982beb900 d56dbf5bab8c
> > ...
> >
> > 04f982beb900 is the previous HEAD, d56dbf5bab8c is the head of the
> > branch merged by this commit. "git log 04f982beb900..96702be56037"
> > shows the commits merged.
>
> Thanks. Fairly obvious, actually. Not sure why I didn't think of this
> myself.
>
> > > - how can I use the list of those hashes to limit the range of commits
> > > to do a git bisect?
> >
> > I'm not a git bisect expert, but I *think* you should be able to do
> > something like this:
> >
> > git bisect start
> > git bisect bad 96702be56037
> > git bisect good 04f982beb900
> >
> > (assuming you've verified that 96702be56037 really *is* bad and
> > 04f982beb900 really *is* good), and git should checkout something in
> > the middle and you can build and test it, then use "git bisect good"
> > or "git bisect bad" depending on the result.
>
> Makes sense. Thanks again. 04f982beb900 appears to be good. So if
> 96702be56037 turns out to be bad bisecting might not turn into the
> ordeal it usually is. (On this machine, with my workflow, bisecting an
> v3.x..v3.x+1-rcy range takes a few days.)
It seems quite possible that I broke pci_bus_alloc_resource(), which could
cause an allocation failure like this.
If you have a chance to try it, here's a debug patch against v3.14-rc5. It
should apply cleanly to 96702be56037. If you can try it, please attach the
dmesg log to the bugzilla.
Bjorn
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 5c85350f4c3d..0dbba6c7c001 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -997,6 +997,7 @@ static int intel_alloc_chipset_flush_resource(void)
ret = pci_bus_alloc_resource(intel_private.bridge_dev->bus, &intel_private.ifp_resource, PAGE_SIZE,
PAGE_SIZE, PCIBIOS_MIN_MEM, 0,
pcibios_align_resource, intel_private.bridge_dev);
+ dev_info(&intel_private.bridge_dev->dev, "pci_bus_alloc ret %d\n", ret);
return ret;
}
@@ -1007,6 +1008,7 @@ static void intel_i915_setup_chipset_flush(void)
u32 temp;
pci_read_config_dword(intel_private.bridge_dev, I915_IFPADDR, &temp);
+ dev_info(&intel_private.bridge_dev->dev, "I915_IFPADDR %#010x\n", temp);
if (!(temp & 0x1)) {
intel_alloc_chipset_flush_resource();
intel_private.resource_valid = 1;
@@ -1022,6 +1024,7 @@ static void intel_i915_setup_chipset_flush(void)
if (ret)
intel_private.resource_valid = 0;
}
+ dev_info(&intel_private.bridge_dev->dev, "ifp_resource %pR\n", &intel_private.ifp_resource);
}
static void intel_i965_g33_setup_chipset_flush(void)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 00660cc502c5..1c6d75ae34d9 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -146,24 +146,31 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
+ dev_info(&bus->dev, "%s: alloc %pR size %#llx from bus region [%#010llx-%#010llx]\n", __func__, res, (long long) size, (long long) region->start, (long long) region->end);
pci_bus_for_each_resource(bus, r, i) {
if (!r)
continue;
/* type_mask must match */
- if ((res->flags ^ r->flags) & type_mask)
+ if ((res->flags ^ r->flags) & type_mask) {
+ dev_info(&bus->dev, "%s: %pR: wrong type (%#lx %#lx mask %#x)\n", __func__, r, res->flags, r->flags, type_mask);
continue;
+ }
/* We cannot allocate a non-prefetching resource
from a pre-fetching area */
if ((r->flags & IORESOURCE_PREFETCH) &&
- !(res->flags & IORESOURCE_PREFETCH))
+ !(res->flags & IORESOURCE_PREFETCH)) {
+ dev_info(&bus->dev, "%s: %pR: wrong prefetchability\n", __func__, r);
continue;
+ }
avail = *r;
pci_clip_resource_to_region(bus, &avail, region);
- if (!resource_size(&avail))
+ if (!resource_size(&avail)) {
+ dev_info(&bus->dev, "%s: %pR: no space (avail %pR)\n", __func__, r, &avail);
continue;
+ }
/*
* "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to
@@ -179,6 +186,7 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
/* Ok, try it out.. */
ret = allocate_resource(r, res, size, min, max,
align, alignf, alignf_data);
+ dev_info(&bus->dev, "%s: %pR: alloc from %#llx-%#llx, ret %d\n", __func__, r, min, max, ret);
if (ret == 0)
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists