Bjorn Helgaas schreef op ma 10-03-2014 om 20:07 [-0600]:
> On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle wrote:
> > On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
> >> On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote:
> >> > A bit of doubt is caused by two new boot time messages:
> >> >
On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle wrote:
> On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
>> On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle 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:
On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
> On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle 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 tried v3.
[+cc Rafael]
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle 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 Helgaas
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
>
> When resource_size_t is 32 bits wide, e.g., when CONFIG_PHYS_ADDR_
[+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 /boot/config-3.14.0
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, CONFIG_PHYS_
On Fri, Mar 7, 2014 at 1:40 PM, 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 you
On Fri, Mar 7, 2014 at 2:03 PM, Paul Bolle 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 against v3.
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. I
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 wrote:
> > > This might end up not being relevant. And this is surely documented
> > > somewhere, but anyhow:
> > > - what git magic
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle 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 from the PCI
Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]:
> On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle 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
> > 96702be5
On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle 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 could try the
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'
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle 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 from the PCI
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, bu
On Sun, Feb 9, 2014 at 6:25 AM, 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 pci_bus
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 pc
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 p
On Sun, 2014-02-09 at 01:02 +0100, Daniel Vetter wrote:
> On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle 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
On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle 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 bisect is
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 8:06 PM, Paul Bolle 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 compatible controller
24 matches
Mail list logo
