Bjorn Helgaas schreef op ma 10-03-2014 om 20:07 [-0600]:
On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle pebo...@tiscali.nl wrote:
On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle pebo...@tiscali.nl wrote:
A bit of doubt is caused by two new
[+cc linux-pci]
On Sat, Mar 08, 2014 at 03:44:37PM +0100, Paul Bolle wrote:
Bjorn Helgaas schreef op za 08-03-2014 om 07:12 [-0700]:
I assume you have CONFIG_PHYS_ADDR_T_64BIT=n (which is perfectly
legal); let me know if otherwise.
$ grep CONFIG_PHYS_ADDR_T_64BIT
Bjorn Helgaas schreef op ma 10-03-2014 om 12:24 [-0600]:
Thanks. Can you try the patch below? I think it should fix the problem.
PCI: Don't check resource_size() in pci_bus_alloc_resource()
From: Bjorn Helgaas bhelg...@google.com
When resource_size_t is 32 bits wide, e.g., when
[+cc Rafael]
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle pebo...@tiscali.nl wrote:
Bjorn Helgaas schreef op ma 10-03-2014 om 12:24 [-0600]:
Thanks. Can you try the patch below? I think it should fix the problem.
PCI: Don't check resource_size() in pci_bus_alloc_resource()
From: Bjorn
On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle pebo...@tiscali.nl wrote:
A bit of doubt is caused by two new boot time messages:
pnp 00:00: unknown resource type 10 in _CRS
pnp 00:00: can't evaluate _CRS: 1
But I haven't yet
On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle pebo...@tiscali.nl wrote:
On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle pebo...@tiscali.nl wrote:
A bit of doubt is caused by two new boot time messages:
pnp 00:00: unknown resource type 10
On Fri, Mar 7, 2014 at 1:40 PM, Bjorn Helgaas bhelg...@google.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
Bjorn Helgaas schreef op za 08-03-2014 om 07:12 [-0700]:
I assume you have CONFIG_PHYS_ADDR_T_64BIT=n (which is perfectly
legal); let me know if otherwise.
$ grep CONFIG_PHYS_ADDR_T_64BIT /boot/config-3.14.0-0.rc5.1.local2.fc20.i686
# CONFIG_PHYS_ADDR_T_64BIT is not set
So, yes,
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
I wouldn't start bisecting yet, but if you're in the mood, this
commit: 96702be56037 Merge branch 'pci/resource' into next looks
like a good place to start, so you could try the pre-merge commit:
04f982beb900 Merge branch 'pci/msi' into
On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle pebo...@tiscali.nl wrote:
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
I wouldn't start bisecting yet, but if you're in the mood, this
commit: 96702be56037 Merge branch 'pci/resource' into next looks
like a good place to start, so you
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle pebo...@tiscali.nl wrote:
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
Can you open a kernel.org bugzilla report and attach complete dmesg
logs of the working and broken kernels to it? There might be more
useful resource-related messages
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 pebo...@tiscali.nl wrote:
This might end up not being relevant. And this is surely documented
somewhere, but anyhow:
- what
On Fri, 2014-03-07 at 13:40 -0700, Bjorn Helgaas 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
On Fri, Mar 7, 2014 at 2:03 PM, Paul Bolle pebo...@tiscali.nl wrote:
On Fri, 2014-03-07 at 13:40 -0700, Bjorn Helgaas 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
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
Can you open a kernel.org bugzilla report and attach complete dmesg
logs of the working and broken kernels to it? There might be more
useful resource-related messages from the PCI core.
That took me quite a bit longer than I hoped, but
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle pebo...@tiscali.nl wrote:
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
Can you open a kernel.org bugzilla report and attach complete dmesg
logs of the working and broken kernels to it? There might be more
useful resource-related messages
On Sun, Feb 9, 2014 at 6:25 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote:
PCI resource allocation is undergoing some changes at the moment, it's
definitely a bug if the Flush Page isn't getting allocated. I'm looking
forward to hopefully
On Sun, 2014-02-09 at 01:02 +0100, Daniel Vetter wrote:
On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle pebo...@tiscali.nl wrote:
Daniel Vetter schreef op za 08-02-2014 om 20:59 [+0100]:
Hm, if this is really a regression between 3.13 and 3.14-rc1 then I
don't see any quick candidates - relevant
On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote:
PCI resource allocation is undergoing some changes at the moment, it's
definitely a bug if the Flush Page isn't getting allocated. I'm looking
forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in
mainline, it will
On Sun, 2014-02-09 at 14:25 +0100, Paul Bolle wrote:
On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote:
PCI resource allocation is undergoing some changes at the moment, it's
definitely a bug if the Flush Page isn't getting allocated. I'm looking
forward to hopefully getting
On Sat, Feb 8, 2014 at 8:06 PM, Paul Bolle pebo...@tiscali.nl wrote:
0) Booting v3.14-rc1 on an (outdated) ThinkPad X41 triggers a kernel
error:
pci :00:02.0: can't ioremap flush page - no chipset flushing
That is this pci device:
lspci | grep 00:02.0
00:02.0 VGA
Daniel Vetter schreef op za 08-02-2014 om 20:59 [+0100]:
Hm, if this is really a regression between 3.13 and 3.14-rc1 then I
don't see any quick candidates - relevant functions in intel-gtt.c
seem unchanged.
So probably a bisect is what we need here. Note that this could also
be due to
On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle pebo...@tiscali.nl wrote:
Daniel Vetter schreef op za 08-02-2014 om 20:59 [+0100]:
Hm, if this is really a regression between 3.13 and 3.14-rc1 then I
don't see any quick candidates - relevant functions in intel-gtt.c
seem unchanged.
So probably a
23 matches
Mail list logo
