[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAErSpo7Np8oju1ENQA5EgEpN4=Vv7f3s4E823ecbyp6FCWPL_Q@mail.gmail.com>
Date: Sat, 8 Mar 2014 07:12:19 -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 7, 2014 at 1:40 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
> 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.
Paul verified that I *did* break this. More details in the bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=71691
The problem is basically that I used resource_size() to figure out
whether there's any available space. resource_size() is res->end -
res->start + 1, so applying it to [mem 0x00000000-0xffffffff] returns
zero in a kernel 32-bit resource addresses, i.e., with
CONFIG_PHYS_ADDR_T_64BIT=n.
Paul, I assume you have CONFIG_PHYS_ADDR_T_64BIT=n (which is perfectly
legal); let me know if otherwise.
pci_bus 0000:00: pci_bus_alloc_from_region: alloc [mem 0x00000000]
size 0x1000 from bus region [0x00000000-0xffffffff]
pci_bus 0000:00: pci_bus_alloc_from_region: [mem
0x00000000-0xffffffff]: no space (avail [mem 0x00000000-0xffffffff])
Bjorn
--
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