agp/intel: can't ioremap flush page - no chipset flushing

agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

0) Booting v3.14-rc1 on an (outdated) ThinkPad X41 triggers a kernel
error:
    pci 0000: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: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

I can't remember seeing that error before. It is apparently printed by
drivers/char/agp/intel-gtt.c. (So I've sent this message to the people
touching that file between v3.13 and v3.14-rc1. No, I haven't yet
pinpointed a specific commit.)

1) What am I supposed to do to make this error go away?


Paul Bolle

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Daniel Vetter]

On Sat, Feb 8, 2014 at 8:06 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> 0) Booting v3.14-rc1 on an (outdated) ThinkPad X41 triggers a kernel
> error:
>     pci 0000: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: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
>
> I can't remember seeing that error before. It is apparently printed by
> drivers/char/agp/intel-gtt.c. (So I've sent this message to the people
> touching that file between v3.13 and v3.14-rc1. No, I haven't yet
> pinpointed a specific commit.)
>
> 1) What am I supposed to do to make this error go away?

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 resource handling changes in the driver/pci core, so you
can't restrict the bisect really. But before going down this route it
would be worth to check out the resource allocations of both kernels.
Can you please attach /proc/iomem for both 3.13 and 3.14-rc1

Adding more mailing lists.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Daniel Vetter]

On Sat, Feb 8, 2014 at 8:06 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> 0) Booting v3.14-rc1 on an (outdated) ThinkPad X41 triggers a kernel
> error:
>     pci 0000: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: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
>
> I can't remember seeing that error before. It is apparently printed by
> drivers/char/agp/intel-gtt.c. (So I've sent this message to the people
> touching that file between v3.13 and v3.14-rc1. No, I haven't yet
> pinpointed a specific commit.)
>
> 1) What am I supposed to do to make this error go away?

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 resource handling changes in the driver/pci core, so you
can't restrict the bisect really. But before going down this route it
would be worth to check out the resource allocations of both kernels.
Can you please attach /proc/iomem for both 3.13 and 3.14-rc1

Adding more mailing lists.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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 resource handling changes in the driver/pci core, so you
> can't restrict the bisect really.

The last bisect on this machine took over 20 builds to pinpoint the
offending commit. So that's bad news ...

>  But before going down this route it
> would be worth to check out the resource allocations of both kernels.
> Can you please attach /proc/iomem for both 3.13 and 3.14-rc1

The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is:
--- iomem-3.13.2	2014-02-08 21:14:30.214030591 +0100
+++ iomem-3.14-rc1	2014-02-08 21:07:22.041189158 +0100
@@ -11,16 +11,13 @@
   000e0000-000effff : Extension ROM
   000f0000-000fffff : System ROM
 00100000-7f6dffff : System RAM
-  00400000-009af63a : Kernel code
-  009af63b-00c932ff : Kernel data
-  00d4f000-00e4dfff : Kernel bss
+  00400000-009c57bf : Kernel code
+  009c57c0-00cb6aff : Kernel data
+  00d78000-00e74fff : Kernel bss
 7f6e0000-7f6f4fff : ACPI Tables
 7f6f5000-7f6fffff : ACPI Non-volatile Storage
 7f700000-7fffffff : reserved
   7f800000-7fffffff : Graphics Stolen Memory
-80000000-801fffff : PCI Bus 0000:02
-80200000-8027ffff : 0000:00:02.1
-80280000-80280fff : Intel Flush Page
 a0000000-a003ffff : 0000:00:02.0
 a0040000-a00403ff : 0000:00:1d.7
   a0040000-a00403ff : ehci_hcd

/proc/iomem for v3.13.2:
00000000-00000fff : reserved
00001000-0009efff : System RAM
0009f000-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000c8000-000cbfff : pnp 00:00
000cf800-000d3fff : reserved
  000cf800-000d0dff : Adapter ROM
  000d1000-000d1fff : Adapter ROM
000dc000-000fffff : reserved
  000e0000-000effff : Extension ROM
  000f0000-000fffff : System ROM
00100000-7f6dffff : System RAM
  00400000-009af63a : Kernel code
  009af63b-00c932ff : Kernel data
  00d4f000-00e4dfff : Kernel bss
7f6e0000-7f6f4fff : ACPI Tables
7f6f5000-7f6fffff : ACPI Non-volatile Storage
7f700000-7fffffff : reserved
  7f800000-7fffffff : Graphics Stolen Memory
80000000-801fffff : PCI Bus 0000:02
80200000-8027ffff : 0000:00:02.1
80280000-80280fff : Intel Flush Page
a0000000-a003ffff : 0000:00:02.0
a0040000-a00403ff : 0000:00:1d.7
  a0040000-a00403ff : ehci_hcd
a0040400-a00404ff : 0000:00:1e.2
  a0040400-a00404ff : Intel ICH6
a0040800-a00409ff : 0000:00:1e.2
  a0040800-a00409ff : Intel ICH6
a0080000-a00fffff : 0000:00:02.0
a0100000-a01fffff : PCI Bus 0000:02
  a0100000-a010ffff : 0000:02:00.0
    a0100000-a010ffff : tg3
a0200000-afffffff : PCI Bus 0000:04
  a0200000-a0200fff : 0000:04:00.0
    a0200000-a0200fff : yenta_socket
  a0201000-a02010ff : 0000:04:00.1
    a0201000-a02010ff : mmc0
  a0202000-a0202fff : 0000:04:02.0
    a0202000-a0202fff : ipw2200
  a4000000-a7ffffff : PCI CardBus 0000:05
c0000000-cfffffff : 0000:00:02.0
d0000000-d7ffffff : PCI Bus 0000:04
  d0000000-d3ffffff : PCI CardBus 0000:05
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
  e0000000-efffffff : reserved
    e0000000-efffffff : pnp 00:01
f0008000-f000bfff : reserved
  f0008000-f000bfff : pnp 00:01
    f000b410-f000b414 : iTCO_wdt
      f000b410-f000b414 : iTCO_wdt
fec00000-fec0ffff : reserved
  fec00000-fec003ff : IOAPIC 0
fed14000-fed19fff : reserved
  fed14000-fed17fff : pnp 00:01
  fed18000-fed18fff : pnp 00:01
  fed19000-fed19fff : pnp 00:01
fed20000-fed8ffff : reserved
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
ff000000-ffffffff : reserved

/proc/iomem for v3.14-rc1:
00000000-00000fff : reserved
00001000-0009efff : System RAM
0009f000-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000c8000-000cbfff : pnp 00:00
000cf800-000d3fff : reserved
  000cf800-000d0dff : Adapter ROM
  000d1000-000d1fff : Adapter ROM
000dc000-000fffff : reserved
  000e0000-000effff : Extension ROM
  000f0000-000fffff : System ROM
00100000-7f6dffff : System RAM
  00400000-009c57bf : Kernel code
  009c57c0-00cb6aff : Kernel data
  00d78000-00e74fff : Kernel bss
7f6e0000-7f6f4fff : ACPI Tables
7f6f5000-7f6fffff : ACPI Non-volatile Storage
7f700000-7fffffff : reserved
  7f800000-7fffffff : Graphics Stolen Memory
a0000000-a003ffff : 0000:00:02.0
a0040000-a00403ff : 0000:00:1d.7
  a0040000-a00403ff : ehci_hcd
a0040400-a00404ff : 0000:00:1e.2
  a0040400-a00404ff : Intel ICH6
a0040800-a00409ff : 0000:00:1e.2
  a0040800-a00409ff : Intel ICH6
a0080000-a00fffff : 0000:00:02.0
a0100000-a01fffff : PCI Bus 0000:02
  a0100000-a010ffff : 0000:02:00.0
    a0100000-a010ffff : tg3
a0200000-afffffff : PCI Bus 0000:04
  a0200000-a0200fff : 0000:04:00.0
    a0200000-a0200fff : yenta_socket
  a0201000-a02010ff : 0000:04:00.1
    a0201000-a02010ff : mmc0
  a0202000-a0202fff : 0000:04:02.0
    a0202000-a0202fff : ipw2200
  a4000000-a7ffffff : PCI CardBus 0000:05
c0000000-cfffffff : 0000:00:02.0
d0000000-d7ffffff : PCI Bus 0000:04
  d0000000-d3ffffff : PCI CardBus 0000:05
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
  e0000000-efffffff : reserved
    e0000000-efffffff : pnp 00:01
f0008000-f000bfff : reserved
  f0008000-f000bfff : pnp 00:01
    f000b410-f000b414 : iTCO_wdt
      f000b410-f000b414 : iTCO_wdt
fec00000-fec0ffff : reserved
  fec00000-fec003ff : IOAPIC 0
fed14000-fed19fff : reserved
  fed14000-fed17fff : pnp 00:01
  fed18000-fed18fff : pnp 00:01
  fed19000-fed19fff : pnp 00:01
fed20000-fed8ffff : reserved
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
ff000000-ffffffff : reserved

Thanks,


Paul Bolle

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Daniel Vetter]

On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle <pebolle@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 bisect is what we need here. Note that this could also
>> be due to resource handling changes in the driver/pci core, so you
>> can't restrict the bisect really.
>
> The last bisect on this machine took over 20 builds to pinpoint the
> offending commit. So that's bad news ...

Somehow we can't allocate the flush page resource any more, but I
don't have any idea what. There's nothing occupying the old spot (the
usual reason why resource management goes boom), so dunno why this
doesn't work any more. I think bisecting is the most fruitful avenue
here.
-Daniel


>
>>  But before going down this route it
>> would be worth to check out the resource allocations of both kernels.
>> Can you please attach /proc/iomem for both 3.13 and 3.14-rc1
>
> The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is:
> --- iomem-3.13.2        2014-02-08 21:14:30.214030591 +0100
> +++ iomem-3.14-rc1      2014-02-08 21:07:22.041189158 +0100
> @@ -11,16 +11,13 @@
>    000e0000-000effff : Extension ROM
>    000f0000-000fffff : System ROM
>  00100000-7f6dffff : System RAM
> -  00400000-009af63a : Kernel code
> -  009af63b-00c932ff : Kernel data
> -  00d4f000-00e4dfff : Kernel bss
> +  00400000-009c57bf : Kernel code
> +  009c57c0-00cb6aff : Kernel data
> +  00d78000-00e74fff : Kernel bss
>  7f6e0000-7f6f4fff : ACPI Tables
>  7f6f5000-7f6fffff : ACPI Non-volatile Storage
>  7f700000-7fffffff : reserved
>    7f800000-7fffffff : Graphics Stolen Memory
> -80000000-801fffff : PCI Bus 0000:02
> -80200000-8027ffff : 0000:00:02.1
> -80280000-80280fff : Intel Flush Page
>  a0000000-a003ffff : 0000:00:02.0
>  a0040000-a00403ff : 0000:00:1d.7
>    a0040000-a00403ff : ehci_hcd
>
> /proc/iomem for v3.13.2:
> 00000000-00000fff : reserved
> 00001000-0009efff : System RAM
> 0009f000-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000c8000-000cbfff : pnp 00:00
> 000cf800-000d3fff : reserved
>   000cf800-000d0dff : Adapter ROM
>   000d1000-000d1fff : Adapter ROM
> 000dc000-000fffff : reserved
>   000e0000-000effff : Extension ROM
>   000f0000-000fffff : System ROM
> 00100000-7f6dffff : System RAM
>   00400000-009af63a : Kernel code
>   009af63b-00c932ff : Kernel data
>   00d4f000-00e4dfff : Kernel bss
> 7f6e0000-7f6f4fff : ACPI Tables
> 7f6f5000-7f6fffff : ACPI Non-volatile Storage
> 7f700000-7fffffff : reserved
>   7f800000-7fffffff : Graphics Stolen Memory
> 80000000-801fffff : PCI Bus 0000:02
> 80200000-8027ffff : 0000:00:02.1
> 80280000-80280fff : Intel Flush Page
> a0000000-a003ffff : 0000:00:02.0
> a0040000-a00403ff : 0000:00:1d.7
>   a0040000-a00403ff : ehci_hcd
> a0040400-a00404ff : 0000:00:1e.2
>   a0040400-a00404ff : Intel ICH6
> a0040800-a00409ff : 0000:00:1e.2
>   a0040800-a00409ff : Intel ICH6
> a0080000-a00fffff : 0000:00:02.0
> a0100000-a01fffff : PCI Bus 0000:02
>   a0100000-a010ffff : 0000:02:00.0
>     a0100000-a010ffff : tg3
> a0200000-afffffff : PCI Bus 0000:04
>   a0200000-a0200fff : 0000:04:00.0
>     a0200000-a0200fff : yenta_socket
>   a0201000-a02010ff : 0000:04:00.1
>     a0201000-a02010ff : mmc0
>   a0202000-a0202fff : 0000:04:02.0
>     a0202000-a0202fff : ipw2200
>   a4000000-a7ffffff : PCI CardBus 0000:05
> c0000000-cfffffff : 0000:00:02.0
> d0000000-d7ffffff : PCI Bus 0000:04
>   d0000000-d3ffffff : PCI CardBus 0000:05
> e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
>   e0000000-efffffff : reserved
>     e0000000-efffffff : pnp 00:01
> f0008000-f000bfff : reserved
>   f0008000-f000bfff : pnp 00:01
>     f000b410-f000b414 : iTCO_wdt
>       f000b410-f000b414 : iTCO_wdt
> fec00000-fec0ffff : reserved
>   fec00000-fec003ff : IOAPIC 0
> fed14000-fed19fff : reserved
>   fed14000-fed17fff : pnp 00:01
>   fed18000-fed18fff : pnp 00:01
>   fed19000-fed19fff : pnp 00:01
> fed20000-fed8ffff : reserved
> fee00000-fee00fff : Local APIC
>   fee00000-fee00fff : reserved
> ff000000-ffffffff : reserved
>
> /proc/iomem for v3.14-rc1:
> 00000000-00000fff : reserved
> 00001000-0009efff : System RAM
> 0009f000-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000c8000-000cbfff : pnp 00:00
> 000cf800-000d3fff : reserved
>   000cf800-000d0dff : Adapter ROM
>   000d1000-000d1fff : Adapter ROM
> 000dc000-000fffff : reserved
>   000e0000-000effff : Extension ROM
>   000f0000-000fffff : System ROM
> 00100000-7f6dffff : System RAM
>   00400000-009c57bf : Kernel code
>   009c57c0-00cb6aff : Kernel data
>   00d78000-00e74fff : Kernel bss
> 7f6e0000-7f6f4fff : ACPI Tables
> 7f6f5000-7f6fffff : ACPI Non-volatile Storage
> 7f700000-7fffffff : reserved
>   7f800000-7fffffff : Graphics Stolen Memory
> a0000000-a003ffff : 0000:00:02.0
> a0040000-a00403ff : 0000:00:1d.7
>   a0040000-a00403ff : ehci_hcd
> a0040400-a00404ff : 0000:00:1e.2
>   a0040400-a00404ff : Intel ICH6
> a0040800-a00409ff : 0000:00:1e.2
>   a0040800-a00409ff : Intel ICH6
> a0080000-a00fffff : 0000:00:02.0
> a0100000-a01fffff : PCI Bus 0000:02
>   a0100000-a010ffff : 0000:02:00.0
>     a0100000-a010ffff : tg3
> a0200000-afffffff : PCI Bus 0000:04
>   a0200000-a0200fff : 0000:04:00.0
>     a0200000-a0200fff : yenta_socket
>   a0201000-a02010ff : 0000:04:00.1
>     a0201000-a02010ff : mmc0
>   a0202000-a0202fff : 0000:04:02.0
>     a0202000-a0202fff : ipw2200
>   a4000000-a7ffffff : PCI CardBus 0000:05
> c0000000-cfffffff : 0000:00:02.0
> d0000000-d7ffffff : PCI Bus 0000:04
>   d0000000-d3ffffff : PCI CardBus 0000:05
> e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
>   e0000000-efffffff : reserved
>     e0000000-efffffff : pnp 00:01
> f0008000-f000bfff : reserved
>   f0008000-f000bfff : pnp 00:01
>     f000b410-f000b414 : iTCO_wdt
>       f000b410-f000b414 : iTCO_wdt
> fec00000-fec0ffff : reserved
>   fec00000-fec003ff : IOAPIC 0
> fed14000-fed19fff : reserved
>   fed14000-fed17fff : pnp 00:01
>   fed18000-fed18fff : pnp 00:01
>   fed19000-fed19fff : pnp 00:01
> fed20000-fed8ffff : reserved
> fee00000-fee00fff : Local APIC
>   fee00000-fee00fff : reserved
> ff000000-ffffffff : reserved
>
> Thanks,
>
>
> Paul Bolle
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Daniel Vetter]

On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle <pebolle@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 bisect is what we need here. Note that this could also
>> be due to resource handling changes in the driver/pci core, so you
>> can't restrict the bisect really.
>
> The last bisect on this machine took over 20 builds to pinpoint the
> offending commit. So that's bad news ...

Somehow we can't allocate the flush page resource any more, but I
don't have any idea what. There's nothing occupying the old spot (the
usual reason why resource management goes boom), so dunno why this
doesn't work any more. I think bisecting is the most fruitful avenue
here.
-Daniel


>
>>  But before going down this route it
>> would be worth to check out the resource allocations of both kernels.
>> Can you please attach /proc/iomem for both 3.13 and 3.14-rc1
>
> The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is:
> --- iomem-3.13.2        2014-02-08 21:14:30.214030591 +0100
> +++ iomem-3.14-rc1      2014-02-08 21:07:22.041189158 +0100
> @@ -11,16 +11,13 @@
>    000e0000-000effff : Extension ROM
>    000f0000-000fffff : System ROM
>  00100000-7f6dffff : System RAM
> -  00400000-009af63a : Kernel code
> -  009af63b-00c932ff : Kernel data
> -  00d4f000-00e4dfff : Kernel bss
> +  00400000-009c57bf : Kernel code
> +  009c57c0-00cb6aff : Kernel data
> +  00d78000-00e74fff : Kernel bss
>  7f6e0000-7f6f4fff : ACPI Tables
>  7f6f5000-7f6fffff : ACPI Non-volatile Storage
>  7f700000-7fffffff : reserved
>    7f800000-7fffffff : Graphics Stolen Memory
> -80000000-801fffff : PCI Bus 0000:02
> -80200000-8027ffff : 0000:00:02.1
> -80280000-80280fff : Intel Flush Page
>  a0000000-a003ffff : 0000:00:02.0
>  a0040000-a00403ff : 0000:00:1d.7
>    a0040000-a00403ff : ehci_hcd
>
> /proc/iomem for v3.13.2:
> 00000000-00000fff : reserved
> 00001000-0009efff : System RAM
> 0009f000-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000c8000-000cbfff : pnp 00:00
> 000cf800-000d3fff : reserved
>   000cf800-000d0dff : Adapter ROM
>   000d1000-000d1fff : Adapter ROM
> 000dc000-000fffff : reserved
>   000e0000-000effff : Extension ROM
>   000f0000-000fffff : System ROM
> 00100000-7f6dffff : System RAM
>   00400000-009af63a : Kernel code
>   009af63b-00c932ff : Kernel data
>   00d4f000-00e4dfff : Kernel bss
> 7f6e0000-7f6f4fff : ACPI Tables
> 7f6f5000-7f6fffff : ACPI Non-volatile Storage
> 7f700000-7fffffff : reserved
>   7f800000-7fffffff : Graphics Stolen Memory
> 80000000-801fffff : PCI Bus 0000:02
> 80200000-8027ffff : 0000:00:02.1
> 80280000-80280fff : Intel Flush Page
> a0000000-a003ffff : 0000:00:02.0
> a0040000-a00403ff : 0000:00:1d.7
>   a0040000-a00403ff : ehci_hcd
> a0040400-a00404ff : 0000:00:1e.2
>   a0040400-a00404ff : Intel ICH6
> a0040800-a00409ff : 0000:00:1e.2
>   a0040800-a00409ff : Intel ICH6
> a0080000-a00fffff : 0000:00:02.0
> a0100000-a01fffff : PCI Bus 0000:02
>   a0100000-a010ffff : 0000:02:00.0
>     a0100000-a010ffff : tg3
> a0200000-afffffff : PCI Bus 0000:04
>   a0200000-a0200fff : 0000:04:00.0
>     a0200000-a0200fff : yenta_socket
>   a0201000-a02010ff : 0000:04:00.1
>     a0201000-a02010ff : mmc0
>   a0202000-a0202fff : 0000:04:02.0
>     a0202000-a0202fff : ipw2200
>   a4000000-a7ffffff : PCI CardBus 0000:05
> c0000000-cfffffff : 0000:00:02.0
> d0000000-d7ffffff : PCI Bus 0000:04
>   d0000000-d3ffffff : PCI CardBus 0000:05
> e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
>   e0000000-efffffff : reserved
>     e0000000-efffffff : pnp 00:01
> f0008000-f000bfff : reserved
>   f0008000-f000bfff : pnp 00:01
>     f000b410-f000b414 : iTCO_wdt
>       f000b410-f000b414 : iTCO_wdt
> fec00000-fec0ffff : reserved
>   fec00000-fec003ff : IOAPIC 0
> fed14000-fed19fff : reserved
>   fed14000-fed17fff : pnp 00:01
>   fed18000-fed18fff : pnp 00:01
>   fed19000-fed19fff : pnp 00:01
> fed20000-fed8ffff : reserved
> fee00000-fee00fff : Local APIC
>   fee00000-fee00fff : reserved
> ff000000-ffffffff : reserved
>
> /proc/iomem for v3.14-rc1:
> 00000000-00000fff : reserved
> 00001000-0009efff : System RAM
> 0009f000-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000c8000-000cbfff : pnp 00:00
> 000cf800-000d3fff : reserved
>   000cf800-000d0dff : Adapter ROM
>   000d1000-000d1fff : Adapter ROM
> 000dc000-000fffff : reserved
>   000e0000-000effff : Extension ROM
>   000f0000-000fffff : System ROM
> 00100000-7f6dffff : System RAM
>   00400000-009c57bf : Kernel code
>   009c57c0-00cb6aff : Kernel data
>   00d78000-00e74fff : Kernel bss
> 7f6e0000-7f6f4fff : ACPI Tables
> 7f6f5000-7f6fffff : ACPI Non-volatile Storage
> 7f700000-7fffffff : reserved
>   7f800000-7fffffff : Graphics Stolen Memory
> a0000000-a003ffff : 0000:00:02.0
> a0040000-a00403ff : 0000:00:1d.7
>   a0040000-a00403ff : ehci_hcd
> a0040400-a00404ff : 0000:00:1e.2
>   a0040400-a00404ff : Intel ICH6
> a0040800-a00409ff : 0000:00:1e.2
>   a0040800-a00409ff : Intel ICH6
> a0080000-a00fffff : 0000:00:02.0
> a0100000-a01fffff : PCI Bus 0000:02
>   a0100000-a010ffff : 0000:02:00.0
>     a0100000-a010ffff : tg3
> a0200000-afffffff : PCI Bus 0000:04
>   a0200000-a0200fff : 0000:04:00.0
>     a0200000-a0200fff : yenta_socket
>   a0201000-a02010ff : 0000:04:00.1
>     a0201000-a02010ff : mmc0
>   a0202000-a0202fff : 0000:04:02.0
>     a0202000-a0202fff : ipw2200
>   a4000000-a7ffffff : PCI CardBus 0000:05
> c0000000-cfffffff : 0000:00:02.0
> d0000000-d7ffffff : PCI Bus 0000:04
>   d0000000-d3ffffff : PCI CardBus 0000:05
> e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
>   e0000000-efffffff : reserved
>     e0000000-efffffff : pnp 00:01
> f0008000-f000bfff : reserved
>   f0008000-f000bfff : pnp 00:01
>     f000b410-f000b414 : iTCO_wdt
>       f000b410-f000b414 : iTCO_wdt
> fec00000-fec0ffff : reserved
>   fec00000-fec003ff : IOAPIC 0
> fed14000-fed19fff : reserved
>   fed14000-fed17fff : pnp 00:01
>   fed18000-fed18fff : pnp 00:01
>   fed19000-fed19fff : pnp 00:01
> fed20000-fed8ffff : reserved
> fee00000-fee00fff : Local APIC
>   fee00000-fee00fff : reserved
> ff000000-ffffffff : reserved
>
> Thanks,
>
>
> Paul Bolle
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Steven Newbury]

On Sun, 2014-02-09 at 01:02 +0100, Daniel Vetter wrote:
> On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle <pebolle@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 bisect is what we need here. Note that this could also
> >> be due to resource handling changes in the driver/pci core, so you
> >> can't restrict the bisect really.
> >
> > The last bisect on this machine took over 20 builds to pinpoint the
> > offending commit. So that's bad news ...
> 
> Somehow we can't allocate the flush page resource any more, but I
> don't have any idea what. There's nothing occupying the old spot (the
> usual reason why resource management goes boom), so dunno why this
> doesn't work any more. I think bisecting is the most fruitful avenue
> here.
> -Daniel
> 
> 
> >
> >>  But before going down this route it
> >> would be worth to check out the resource allocations of both kernels.
> >> Can you please attach /proc/iomem for both 3.13 and 3.14-rc1
> >
> > The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is:
> > --- iomem-3.13.2        2014-02-08 21:14:30.214030591 +0100
> > +++ iomem-3.14-rc1      2014-02-08 21:07:22.041189158 +0100
> > @@ -11,16 +11,13 @@
> >    000e0000-000effff : Extension ROM
> >    000f0000-000fffff : System ROM
> >  00100000-7f6dffff : System RAM
> > -  00400000-009af63a : Kernel code
> > -  009af63b-00c932ff : Kernel data
> > -  00d4f000-00e4dfff : Kernel bss
> > +  00400000-009c57bf : Kernel code
> > +  009c57c0-00cb6aff : Kernel data
> > +  00d78000-00e74fff : Kernel bss
> >  7f6e0000-7f6f4fff : ACPI Tables
> >  7f6f5000-7f6fffff : ACPI Non-volatile Storage
> >  7f700000-7fffffff : reserved
> >    7f800000-7fffffff : Graphics Stolen Memory
> > -80000000-801fffff : PCI Bus 0000:02
> > -80200000-8027ffff : 0000:00:02.1
> > -80280000-80280fff : Intel Flush Page
> >  a0000000-a003ffff : 0000:00:02.0
> >  a0040000-a00403ff : 0000:00:1d.7
> >    a0040000-a00403ff : ehci_hcd
> >
> > /proc/iomem for v3.13.2:
> > 00000000-00000fff : reserved
> > 00001000-0009efff : System RAM
> > 0009f000-0009ffff : reserved
> > 000a0000-000bffff : Video RAM area
> > 000c0000-000c7fff : Video ROM
> > 000c8000-000cbfff : pnp 00:00
> > 000cf800-000d3fff : reserved
> >   000cf800-000d0dff : Adapter ROM
> >   000d1000-000d1fff : Adapter ROM
> > 000dc000-000fffff : reserved
> >   000e0000-000effff : Extension ROM
> >   000f0000-000fffff : System ROM
> > 00100000-7f6dffff : System RAM
> >   00400000-009af63a : Kernel code
> >   009af63b-00c932ff : Kernel data
> >   00d4f000-00e4dfff : Kernel bss
> > 7f6e0000-7f6f4fff : ACPI Tables
> > 7f6f5000-7f6fffff : ACPI Non-volatile Storage
> > 7f700000-7fffffff : reserved
> >   7f800000-7fffffff : Graphics Stolen Memory
> > 80000000-801fffff : PCI Bus 0000:02
> > 80200000-8027ffff : 0000:00:02.1
> > 80280000-80280fff : Intel Flush Page
> > a0000000-a003ffff : 0000:00:02.0
> > a0040000-a00403ff : 0000:00:1d.7
> >   a0040000-a00403ff : ehci_hcd
> > a0040400-a00404ff : 0000:00:1e.2
> >   a0040400-a00404ff : Intel ICH6
> > a0040800-a00409ff : 0000:00:1e.2
> >   a0040800-a00409ff : Intel ICH6
> > a0080000-a00fffff : 0000:00:02.0
> > a0100000-a01fffff : PCI Bus 0000:02
> >   a0100000-a010ffff : 0000:02:00.0
> >     a0100000-a010ffff : tg3
> > a0200000-afffffff : PCI Bus 0000:04
> >   a0200000-a0200fff : 0000:04:00.0
> >     a0200000-a0200fff : yenta_socket
> >   a0201000-a02010ff : 0000:04:00.1
> >     a0201000-a02010ff : mmc0
> >   a0202000-a0202fff : 0000:04:02.0
> >     a0202000-a0202fff : ipw2200
> >   a4000000-a7ffffff : PCI CardBus 0000:05
> > c0000000-cfffffff : 0000:00:02.0
> > d0000000-d7ffffff : PCI Bus 0000:04
> >   d0000000-d3ffffff : PCI CardBus 0000:05
> > e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
> >   e0000000-efffffff : reserved
> >     e0000000-efffffff : pnp 00:01
> > f0008000-f000bfff : reserved
> >   f0008000-f000bfff : pnp 00:01
> >     f000b410-f000b414 : iTCO_wdt
> >       f000b410-f000b414 : iTCO_wdt
> > fec00000-fec0ffff : reserved
> >   fec00000-fec003ff : IOAPIC 0
> > fed14000-fed19fff : reserved
> >   fed14000-fed17fff : pnp 00:01
> >   fed18000-fed18fff : pnp 00:01
> >   fed19000-fed19fff : pnp 00:01
> > fed20000-fed8ffff : reserved
> > fee00000-fee00fff : Local APIC
> >   fee00000-fee00fff : reserved
> > ff000000-ffffffff : reserved
> >
> > /proc/iomem for v3.14-rc1:
> > 00000000-00000fff : reserved
> > 00001000-0009efff : System RAM
> > 0009f000-0009ffff : reserved
> > 000a0000-000bffff : Video RAM area
> > 000c0000-000c7fff : Video ROM
> > 000c8000-000cbfff : pnp 00:00
> > 000cf800-000d3fff : reserved
> >   000cf800-000d0dff : Adapter ROM
> >   000d1000-000d1fff : Adapter ROM
> > 000dc000-000fffff : reserved
> >   000e0000-000effff : Extension ROM
> >   000f0000-000fffff : System ROM
> > 00100000-7f6dffff : System RAM
> >   00400000-009c57bf : Kernel code
> >   009c57c0-00cb6aff : Kernel data
> >   00d78000-00e74fff : Kernel bss
> > 7f6e0000-7f6f4fff : ACPI Tables
> > 7f6f5000-7f6fffff : ACPI Non-volatile Storage
> > 7f700000-7fffffff : reserved
> >   7f800000-7fffffff : Graphics Stolen Memory
> > a0000000-a003ffff : 0000:00:02.0
> > a0040000-a00403ff : 0000:00:1d.7
> >   a0040000-a00403ff : ehci_hcd
> > a0040400-a00404ff : 0000:00:1e.2
> >   a0040400-a00404ff : Intel ICH6
> > a0040800-a00409ff : 0000:00:1e.2
> >   a0040800-a00409ff : Intel ICH6
> > a0080000-a00fffff : 0000:00:02.0
> > a0100000-a01fffff : PCI Bus 0000:02
> >   a0100000-a010ffff : 0000:02:00.0
> >     a0100000-a010ffff : tg3
> > a0200000-afffffff : PCI Bus 0000:04
> >   a0200000-a0200fff : 0000:04:00.0
> >     a0200000-a0200fff : yenta_socket
> >   a0201000-a02010ff : 0000:04:00.1
> >     a0201000-a02010ff : mmc0
> >   a0202000-a0202fff : 0000:04:02.0
> >     a0202000-a0202fff : ipw2200
> >   a4000000-a7ffffff : PCI CardBus 0000:05
> > c0000000-cfffffff : 0000:00:02.0
> > d0000000-d7ffffff : PCI Bus 0000:04
> >   d0000000-d3ffffff : PCI CardBus 0000:05
> > e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
> >   e0000000-efffffff : reserved
> >     e0000000-efffffff : pnp 00:01
> > f0008000-f000bfff : reserved
> >   f0008000-f000bfff : pnp 00:01
> >     f000b410-f000b414 : iTCO_wdt
> >       f000b410-f000b414 : iTCO_wdt
> > fec00000-fec0ffff : reserved
> >   fec00000-fec003ff : IOAPIC 0
> > fed14000-fed19fff : reserved
> >   fed14000-fed17fff : pnp 00:01
> >   fed18000-fed18fff : pnp 00:01
> >   fed19000-fed19fff : pnp 00:01
> > fed20000-fed8ffff : reserved
> > fee00000-fee00fff : Local APIC
> >   fee00000-fee00fff : reserved
> > ff000000-ffffffff : reserved
> >
> > Thanks,
> >
> >
> > Paul Bolle
> >
> 
> 
> 

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 provide much better resource allocation in the 32 bit
PCI address space, and prevent problems like this from cropping up.

See Yinghai Lu's for-pci-res-alloc branch.

I've been carrying the changes in my local tree, but right now the
upstream PCI changes are quite extensive.  He's planning on rebasing the
branch soon.

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Steven Newbury]

On Sun, 2014-02-09 at 01:02 +0100, Daniel Vetter wrote:
> On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle <pebolle@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 bisect is what we need here. Note that this could also
> >> be due to resource handling changes in the driver/pci core, so you
> >> can't restrict the bisect really.
> >
> > The last bisect on this machine took over 20 builds to pinpoint the
> > offending commit. So that's bad news ...
> 
> Somehow we can't allocate the flush page resource any more, but I
> don't have any idea what. There's nothing occupying the old spot (the
> usual reason why resource management goes boom), so dunno why this
> doesn't work any more. I think bisecting is the most fruitful avenue
> here.
> -Daniel
> 
> 
> >
> >>  But before going down this route it
> >> would be worth to check out the resource allocations of both kernels.
> >> Can you please attach /proc/iomem for both 3.13 and 3.14-rc1
> >
> > The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is:
> > --- iomem-3.13.2        2014-02-08 21:14:30.214030591 +0100
> > +++ iomem-3.14-rc1      2014-02-08 21:07:22.041189158 +0100
> > @@ -11,16 +11,13 @@
> >    000e0000-000effff : Extension ROM
> >    000f0000-000fffff : System ROM
> >  00100000-7f6dffff : System RAM
> > -  00400000-009af63a : Kernel code
> > -  009af63b-00c932ff : Kernel data
> > -  00d4f000-00e4dfff : Kernel bss
> > +  00400000-009c57bf : Kernel code
> > +  009c57c0-00cb6aff : Kernel data
> > +  00d78000-00e74fff : Kernel bss
> >  7f6e0000-7f6f4fff : ACPI Tables
> >  7f6f5000-7f6fffff : ACPI Non-volatile Storage
> >  7f700000-7fffffff : reserved
> >    7f800000-7fffffff : Graphics Stolen Memory
> > -80000000-801fffff : PCI Bus 0000:02
> > -80200000-8027ffff : 0000:00:02.1
> > -80280000-80280fff : Intel Flush Page
> >  a0000000-a003ffff : 0000:00:02.0
> >  a0040000-a00403ff : 0000:00:1d.7
> >    a0040000-a00403ff : ehci_hcd
> >
> > /proc/iomem for v3.13.2:
> > 00000000-00000fff : reserved
> > 00001000-0009efff : System RAM
> > 0009f000-0009ffff : reserved
> > 000a0000-000bffff : Video RAM area
> > 000c0000-000c7fff : Video ROM
> > 000c8000-000cbfff : pnp 00:00
> > 000cf800-000d3fff : reserved
> >   000cf800-000d0dff : Adapter ROM
> >   000d1000-000d1fff : Adapter ROM
> > 000dc000-000fffff : reserved
> >   000e0000-000effff : Extension ROM
> >   000f0000-000fffff : System ROM
> > 00100000-7f6dffff : System RAM
> >   00400000-009af63a : Kernel code
> >   009af63b-00c932ff : Kernel data
> >   00d4f000-00e4dfff : Kernel bss
> > 7f6e0000-7f6f4fff : ACPI Tables
> > 7f6f5000-7f6fffff : ACPI Non-volatile Storage
> > 7f700000-7fffffff : reserved
> >   7f800000-7fffffff : Graphics Stolen Memory
> > 80000000-801fffff : PCI Bus 0000:02
> > 80200000-8027ffff : 0000:00:02.1
> > 80280000-80280fff : Intel Flush Page
> > a0000000-a003ffff : 0000:00:02.0
> > a0040000-a00403ff : 0000:00:1d.7
> >   a0040000-a00403ff : ehci_hcd
> > a0040400-a00404ff : 0000:00:1e.2
> >   a0040400-a00404ff : Intel ICH6
> > a0040800-a00409ff : 0000:00:1e.2
> >   a0040800-a00409ff : Intel ICH6
> > a0080000-a00fffff : 0000:00:02.0
> > a0100000-a01fffff : PCI Bus 0000:02
> >   a0100000-a010ffff : 0000:02:00.0
> >     a0100000-a010ffff : tg3
> > a0200000-afffffff : PCI Bus 0000:04
> >   a0200000-a0200fff : 0000:04:00.0
> >     a0200000-a0200fff : yenta_socket
> >   a0201000-a02010ff : 0000:04:00.1
> >     a0201000-a02010ff : mmc0
> >   a0202000-a0202fff : 0000:04:02.0
> >     a0202000-a0202fff : ipw2200
> >   a4000000-a7ffffff : PCI CardBus 0000:05
> > c0000000-cfffffff : 0000:00:02.0
> > d0000000-d7ffffff : PCI Bus 0000:04
> >   d0000000-d3ffffff : PCI CardBus 0000:05
> > e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
> >   e0000000-efffffff : reserved
> >     e0000000-efffffff : pnp 00:01
> > f0008000-f000bfff : reserved
> >   f0008000-f000bfff : pnp 00:01
> >     f000b410-f000b414 : iTCO_wdt
> >       f000b410-f000b414 : iTCO_wdt
> > fec00000-fec0ffff : reserved
> >   fec00000-fec003ff : IOAPIC 0
> > fed14000-fed19fff : reserved
> >   fed14000-fed17fff : pnp 00:01
> >   fed18000-fed18fff : pnp 00:01
> >   fed19000-fed19fff : pnp 00:01
> > fed20000-fed8ffff : reserved
> > fee00000-fee00fff : Local APIC
> >   fee00000-fee00fff : reserved
> > ff000000-ffffffff : reserved
> >
> > /proc/iomem for v3.14-rc1:
> > 00000000-00000fff : reserved
> > 00001000-0009efff : System RAM
> > 0009f000-0009ffff : reserved
> > 000a0000-000bffff : Video RAM area
> > 000c0000-000c7fff : Video ROM
> > 000c8000-000cbfff : pnp 00:00
> > 000cf800-000d3fff : reserved
> >   000cf800-000d0dff : Adapter ROM
> >   000d1000-000d1fff : Adapter ROM
> > 000dc000-000fffff : reserved
> >   000e0000-000effff : Extension ROM
> >   000f0000-000fffff : System ROM
> > 00100000-7f6dffff : System RAM
> >   00400000-009c57bf : Kernel code
> >   009c57c0-00cb6aff : Kernel data
> >   00d78000-00e74fff : Kernel bss
> > 7f6e0000-7f6f4fff : ACPI Tables
> > 7f6f5000-7f6fffff : ACPI Non-volatile Storage
> > 7f700000-7fffffff : reserved
> >   7f800000-7fffffff : Graphics Stolen Memory
> > a0000000-a003ffff : 0000:00:02.0
> > a0040000-a00403ff : 0000:00:1d.7
> >   a0040000-a00403ff : ehci_hcd
> > a0040400-a00404ff : 0000:00:1e.2
> >   a0040400-a00404ff : Intel ICH6
> > a0040800-a00409ff : 0000:00:1e.2
> >   a0040800-a00409ff : Intel ICH6
> > a0080000-a00fffff : 0000:00:02.0
> > a0100000-a01fffff : PCI Bus 0000:02
> >   a0100000-a010ffff : 0000:02:00.0
> >     a0100000-a010ffff : tg3
> > a0200000-afffffff : PCI Bus 0000:04
> >   a0200000-a0200fff : 0000:04:00.0
> >     a0200000-a0200fff : yenta_socket
> >   a0201000-a02010ff : 0000:04:00.1
> >     a0201000-a02010ff : mmc0
> >   a0202000-a0202fff : 0000:04:02.0
> >     a0202000-a0202fff : ipw2200
> >   a4000000-a7ffffff : PCI CardBus 0000:05
> > c0000000-cfffffff : 0000:00:02.0
> > d0000000-d7ffffff : PCI Bus 0000:04
> >   d0000000-d3ffffff : PCI CardBus 0000:05
> > e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
> >   e0000000-efffffff : reserved
> >     e0000000-efffffff : pnp 00:01
> > f0008000-f000bfff : reserved
> >   f0008000-f000bfff : pnp 00:01
> >     f000b410-f000b414 : iTCO_wdt
> >       f000b410-f000b414 : iTCO_wdt
> > fec00000-fec0ffff : reserved
> >   fec00000-fec003ff : IOAPIC 0
> > fed14000-fed19fff : reserved
> >   fed14000-fed17fff : pnp 00:01
> >   fed18000-fed18fff : pnp 00:01
> >   fed19000-fed19fff : pnp 00:01
> > fed20000-fed8ffff : reserved
> > fee00000-fee00fff : Local APIC
> >   fee00000-fee00fff : reserved
> > ff000000-ffffffff : reserved
> >
> > Thanks,
> >
> >
> > Paul Bolle
> >
> 
> 
> 

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 provide much better resource allocation in the 32 bit
PCI address space, and prevent problems like this from cropping up.

See Yinghai Lu's for-pci-res-alloc branch.

I've been carrying the changes in my local tree, but right now the
upstream PCI changes are quite extensive.  He's planning on rebasing the
branch soon.

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

On Sun, 2014-02-09 at 13:15 +0000, 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 provide much better resource allocation in the 32 bit
> PCI address space, and prevent problems like this from cropping up.
> 
> See Yinghai Lu's for-pci-res-alloc branch.
> 
> I've been carrying the changes in my local tree, but right now the
> upstream PCI changes are quite extensive.  He's planning on rebasing the
> branch soon.

Does this mean I might be better of not bisecting this just yet? Or are
these changes targeted at v3.15 (or later)?


Paul Bolle

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

On Sun, 2014-02-09 at 13:15 +0000, 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 provide much better resource allocation in the 32 bit
> PCI address space, and prevent problems like this from cropping up.
> 
> See Yinghai Lu's for-pci-res-alloc branch.
> 
> I've been carrying the changes in my local tree, but right now the
> upstream PCI changes are quite extensive.  He's planning on rebasing the
> branch soon.

Does this mean I might be better of not bisecting this just yet? Or are
these changes targeted at v3.15 (or later)?


Paul Bolle

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Steven Newbury]

On Sun, 2014-02-09 at 14:25 +0100, Paul Bolle wrote:
> On Sun, 2014-02-09 at 13:15 +0000, 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 provide much better resource allocation in the 32 bit
> > PCI address space, and prevent problems like this from cropping up.
> > 
> > See Yinghai Lu's for-pci-res-alloc branch.
> > 
> > I've been carrying the changes in my local tree, but right now the
> > upstream PCI changes are quite extensive.  He's planning on rebasing the
> > branch soon.
> 
> Does this mean I might be better of not bisecting this just yet? Or are
> these changes targeted at v3.15 (or later)?
> 
> 
> Paul Bolle
> 

It's an aside really for now.  The bug has probably been introduced by
the recent pci allocation changes so it should be easier for you to
bisect, hopefully.

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Steven Newbury]

On Sun, 2014-02-09 at 14:25 +0100, Paul Bolle wrote:
> On Sun, 2014-02-09 at 13:15 +0000, 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 provide much better resource allocation in the 32 bit
> > PCI address space, and prevent problems like this from cropping up.
> > 
> > See Yinghai Lu's for-pci-res-alloc branch.
> > 
> > I've been carrying the changes in my local tree, but right now the
> > upstream PCI changes are quite extensive.  He's planning on rebasing the
> > branch soon.
> 
> Does this mean I might be better of not bisecting this just yet? Or are
> these changes targeted at v3.15 (or later)?
> 
> 
> Paul Bolle
> 

It's an aside really for now.  The bug has probably been introduced by
the recent pci allocation changes so it should be easier for you to
bisect, hopefully.

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Sun, Feb 9, 2014 at 6:25 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> On Sun, 2014-02-09 at 13:15 +0000, 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 provide much better resource allocation in the 32 bit
>> PCI address space, and prevent problems like this from cropping up.
>>
>> See Yinghai Lu's for-pci-res-alloc branch.
>>
>> I've been carrying the changes in my local tree, but right now the
>> upstream PCI changes are quite extensive.  He's planning on rebasing the
>> branch soon.
>
> Does this mean I might be better of not bisecting this just yet? Or are
> these changes targeted at v3.15 (or later)?

Yinghai's changes would probably be in v3.15 or later.

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.

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 next".  If 04f982beb900 is
good, there are only about 15 commits on the pci/resource branch to
look at.

Thanks for the report!

Bjorn

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Sun, Feb 9, 2014 at 6:25 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> On Sun, 2014-02-09 at 13:15 +0000, 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 provide much better resource allocation in the 32 bit
>> PCI address space, and prevent problems like this from cropping up.
>>
>> See Yinghai Lu's for-pci-res-alloc branch.
>>
>> I've been carrying the changes in my local tree, but right now the
>> upstream PCI changes are quite extensive.  He's planning on rebasing the
>> branch soon.
>
> Does this mean I might be better of not bisecting this just yet? Or are
> these changes targeted at v3.15 (or later)?

Yinghai's changes would probably be in v3.15 or later.

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.

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 next".  If 04f982beb900 is
good, there are only about 15 commits on the pci/resource branch to
look at.

Thanks for the report!

Bjorn

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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 I finally opened a
report at
https://bugzilla.kernel.org/show_bug.cgi?id=71611 .

Note that the dmesg's are identical (up to that error). Are you still
interested?

> 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 next".  If 04f982beb900 is
> good, there are only about 15 commits on the pci/resource branch to
> look at.

I hope to do a bisect in the next few days. If that bisect pinpoints an
interesting commit that might just be in time for v3.14.


Paul Bolle

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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 I finally opened a
report at
https://bugzilla.kernel.org/show_bug.cgi?id=71611 .

Note that the dmesg's are identical (up to that error). Are you still
interested?

> 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 next".  If 04f982beb900 is
> good, there are only about 15 commits on the pci/resource branch to
> look at.

I hope to do a bisect in the next few days. If that bisect pinpoints an
interesting commit that might just be in time for v3.14.


Paul Bolle

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle <pebolle@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 from the PCI core.
>
> That took me quite a bit longer than I hoped, but I finally opened a
> report at
> https://bugzilla.kernel.org/show_bug.cgi?id=71611 .
>
> Note that the dmesg's are identical (up to that error). Are you still
> interested?

Yep, I wouldn't mind seeing the dmesg log to compare with the
/proc/iomem contents you posted earlier.  Since they're identical,
there might not be a clue, but you never know, and it would be really
great to squash this regression before v3.14.

>> 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 next".  If 04f982beb900 is
>> good, there are only about 15 commits on the pci/resource branch to
>> look at.
>
> I hope to do a bisect in the next few days. If that bisect pinpoints an
> interesting commit that might just be in time for v3.14.
>
>
> Paul Bolle
>

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle <pebolle@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 from the PCI core.
>
> That took me quite a bit longer than I hoped, but I finally opened a
> report at
> https://bugzilla.kernel.org/show_bug.cgi?id=71611 .
>
> Note that the dmesg's are identical (up to that error). Are you still
> interested?

Yep, I wouldn't mind seeing the dmesg log to compare with the
/proc/iomem contents you posted earlier.  Since they're identical,
there might not be a clue, but you never know, and it would be really
great to squash this regression before v3.14.

>> 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 next".  If 04f982beb900 is
>> good, there are only about 15 commits on the pci/resource branch to
>> look at.
>
> I hope to do a bisect in the next few days. If that bisect pinpoints an
> interesting commit that might just be in time for v3.14.
>
>
> Paul Bolle
>

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle <pebolle@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 from the PCI core.
>
> That took me quite a bit longer than I hoped, but I finally opened a
> report at
> https://bugzilla.kernel.org/show_bug.cgi?id=71611 .
>
> Note that the dmesg's are identical (up to that error). Are you still
> interested?

Thanks for attaching the dmesg log.  I also attached the iomem
contents you previously posted.

This is likely a tangent from the AGP issue, but I don't understand
this iomem diff between v3.13.2 and v3.14-rc1:

  -80000000-801fffff : PCI Bus 0000:02
  -80200000-8027ffff : 0000:00:02.1

The first line is a bridge window to [bus 02], and the second is an
MMIO region for one of your AGP devices (00:02.0 is VGA and 00:02.1
seems to be some related device).

The bridge to [bus 02] is 00:1c.0, and your dmesg shows:

  pci 0000:00:1c.0: PCI bridge to [bus 02]
  pci 0000:00:1c.0:   bridge window [io  0x6000-0x6fff]
  pci 0000:00:1c.0:   bridge window [mem 0xa0100000-0xa01fffff]

The [mem 0xa0100000-0xa01fffff] window appears in the dmesg log and in
both iomem captures; that makes good sense.  The 80000000-801fffff
window is in only the v3.13.2 iomem, and it *should* appear in the
v3.13.2 dmesg log but apparently doesn't?

Likewise, the 00:02.1 resource appears only in the v3.13.2 iomem, and
it should also be mentioned in the v3.13.2 dmesg log.  The v3.14-rc5
dmesg log shows an unassigned resource there:

  pci 0000:00:02.1: reg 0x10: [mem 0x00000000-0x0007ffff]

and says we were unable to assign anything.  But apparently v3.13.2
*did* assign something, and the dmesg log should show that.

Bjorn

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle <pebolle@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 from the PCI core.
>
> That took me quite a bit longer than I hoped, but I finally opened a
> report at
> https://bugzilla.kernel.org/show_bug.cgi?id=71611 .
>
> Note that the dmesg's are identical (up to that error). Are you still
> interested?

Thanks for attaching the dmesg log.  I also attached the iomem
contents you previously posted.

This is likely a tangent from the AGP issue, but I don't understand
this iomem diff between v3.13.2 and v3.14-rc1:

  -80000000-801fffff : PCI Bus 0000:02
  -80200000-8027ffff : 0000:00:02.1

The first line is a bridge window to [bus 02], and the second is an
MMIO region for one of your AGP devices (00:02.0 is VGA and 00:02.1
seems to be some related device).

The bridge to [bus 02] is 00:1c.0, and your dmesg shows:

  pci 0000:00:1c.0: PCI bridge to [bus 02]
  pci 0000:00:1c.0:   bridge window [io  0x6000-0x6fff]
  pci 0000:00:1c.0:   bridge window [mem 0xa0100000-0xa01fffff]

The [mem 0xa0100000-0xa01fffff] window appears in the dmesg log and in
both iomem captures; that makes good sense.  The 80000000-801fffff
window is in only the v3.13.2 iomem, and it *should* appear in the
v3.13.2 dmesg log but apparently doesn't?

Likewise, the 00:02.1 resource appears only in the v3.13.2 iomem, and
it should also be mentioned in the v3.13.2 dmesg log.  The v3.14-rc5
dmesg log shows an unassigned resource there:

  pci 0000:00:02.1: reg 0x10: [mem 0x00000000-0x0007ffff]

and says we were unable to assign anything.  But apparently v3.13.2
*did* assign something, and the dmesg log should show that.

Bjorn

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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 next".  If 04f982beb900 is
> good, there are only about 15 commits on the pci/resource branch to
> look at.

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
- how can I use the list of those hashes to limit the range of commits
  to do a git bisect?


Paul Bolle

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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 next".  If 04f982beb900 is
> good, there are only about 15 commits on the pci/resource branch to
> look at.

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
- how can I use the list of those hashes to limit the range of commits
  to do a git bisect?


Paul Bolle

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle <pebolle@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 could try the pre-merge commit:
>> 04f982beb900 "Merge branch 'pci/msi' into next".  If 04f982beb900 is
>> good, there are only about 15 commits on the pci/resource branch to
>> look at.
>
> 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.

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

Bjorn

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle <pebolle@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 could try the pre-merge commit:
>> 04f982beb900 "Merge branch 'pci/msi' into next".  If 04f982beb900 is
>> good, there are only about 15 commits on the pci/resource branch to
>> look at.
>
> 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.

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

Bjorn

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]:
> On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle <pebolle@tiscali.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.)


Paul Bolle

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]:
> On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle <pebolle@tiscali.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.)


Paul Bolle

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

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@tiscali.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;
 	}

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

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@tiscali.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;
 	}

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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 you can try it, please attach the
> dmesg log to the bugzilla.

That ThinkPad X41 is now building 96702be56037. Once that build is
finished and tested I'll try your debug patch (on top of v3.14-rc5, see
later). It might take some time to finish both builds and test boots.

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

My v3.13 based builds don't have INTEL_GTT set! My v3.14-rcy based
builds do. I have not yet investigated why that is.

(Note that the .config on that ThinkPad X41 is - in short - rebranched
from the kernel .config that is shipped for Fedora 20 every time a rc1
is released.)

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

Too bad drivers/pci/bus.o is built in by definition. If only one could
build a kernel without rebuilding all modules. Or is there some way to
actually do that?


Paul Bolle

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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 you can try it, please attach the
> dmesg log to the bugzilla.

That ThinkPad X41 is now building 96702be56037. Once that build is
finished and tested I'll try your debug patch (on top of v3.14-rc5, see
later). It might take some time to finish both builds and test boots.

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

My v3.13 based builds don't have INTEL_GTT set! My v3.14-rcy based
builds do. I have not yet investigated why that is.

(Note that the .config on that ThinkPad X41 is - in short - rebranched
from the kernel .config that is shipped for Fedora 20 every time a rc1
is released.)

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

Too bad drivers/pci/bus.o is built in by definition. If only one could
build a kernel without rebuilding all modules. Or is there some way to
actually do that?


Paul Bolle

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Fri, Mar 7, 2014 at 2:03 PM, Paul Bolle <pebolle@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 against v3.14-rc5.  It
>> should apply cleanly to 96702be56037.  If you can try it, please attach the
>> dmesg log to the bugzilla.
>
> That ThinkPad X41 is now building 96702be56037. Once that build is
> finished and tested I'll try your debug patch (on top of v3.14-rc5, see
> later). It might take some time to finish both builds and test boots.

> My v3.13 based builds don't have INTEL_GTT set! My v3.14-rcy based
> builds do. I have not yet investigated why that is.

I think that's OK.  CONFIG_INTEL_GTT was added after v3.13
(00fe639a56b4 "drm/i915: Make AGP support optional").  It looks like
in v3.13, intel-gtt.o was built if CONFIG_AGP_INTEL=y (or =m), which
you probably do have (see drivers/char/agp/Makefile).

> Too bad drivers/pci/bus.o is built in by definition. If only one could
> build a kernel without rebuilding all modules. Or is there some way to
> actually do that?

You should be able to "make bzImage" and get just the kernel.  But
there might be module loading issues if the modules don't exactly
match the kernel.  I think it's possible to turn that checking off,
but I don't do it often enough to remember details.

Bjorn

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Fri, Mar 7, 2014 at 2:03 PM, Paul Bolle <pebolle@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 against v3.14-rc5.  It
>> should apply cleanly to 96702be56037.  If you can try it, please attach the
>> dmesg log to the bugzilla.
>
> That ThinkPad X41 is now building 96702be56037. Once that build is
> finished and tested I'll try your debug patch (on top of v3.14-rc5, see
> later). It might take some time to finish both builds and test boots.

> My v3.13 based builds don't have INTEL_GTT set! My v3.14-rcy based
> builds do. I have not yet investigated why that is.

I think that's OK.  CONFIG_INTEL_GTT was added after v3.13
(00fe639a56b4 "drm/i915: Make AGP support optional").  It looks like
in v3.13, intel-gtt.o was built if CONFIG_AGP_INTEL=y (or =m), which
you probably do have (see drivers/char/agp/Makefile).

> Too bad drivers/pci/bus.o is built in by definition. If only one could
> build a kernel without rebuilding all modules. Or is there some way to
> actually do that?

You should be able to "make bzImage" and get just the kernel.  But
there might be module loading issues if the modules don't exactly
match the kernel.  I think it's possible to turn that checking off,
but I don't do it often enough to remember details.

Bjorn

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Fri, Mar 7, 2014 at 1:40 PM, Bjorn Helgaas <bhelgaas@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 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

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Fri, Mar 7, 2014 at 1:40 PM, Bjorn Helgaas <bhelgaas@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 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

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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_ADDR_T_64BIT=n here.


Paul Bolle

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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_ADDR_T_64BIT=n here.


Paul Bolle

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

[+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-0.rc5.1.local2.fc20.i686 
> # CONFIG_PHYS_ADDR_T_64BIT is not set
> 
> So, yes, CONFIG_PHYS_ADDR_T_64BIT=n here.

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 <bhelgaas@google.com>

When resource_size_t is 32 bits wide, e.g., when CONFIG_PHYS_ADDR_T_64BIT
is not defined, resource_size() on [mem 0x00000000-0xffffffff] returns 0
because (r->end - r->start + 1) overflows.

Therefore, we can't use "resource_size() == 0" to decide that allocation
from this resource will fail.  allocate_resource() should fail anyway if it
can't satisfy the address constraints, so we should just depend on that.

A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
but we do fall back to it as a default when we don't have information about
host bridge apertures.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
 drivers/pci/bus.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 00660cc502c5..38901665c770 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -162,8 +162,6 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
 
 		avail = *r;
 		pci_clip_resource_to_region(bus, &avail, region);
-		if (!resource_size(&avail))
-			continue;
 
 		/*
 		 * "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

[+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-0.rc5.1.local2.fc20.i686 
> # CONFIG_PHYS_ADDR_T_64BIT is not set
> 
> So, yes, CONFIG_PHYS_ADDR_T_64BIT=n here.

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 <bhelgaas@google.com>

When resource_size_t is 32 bits wide, e.g., when CONFIG_PHYS_ADDR_T_64BIT
is not defined, resource_size() on [mem 0x00000000-0xffffffff] returns 0
because (r->end - r->start + 1) overflows.

Therefore, we can't use "resource_size() == 0" to decide that allocation
from this resource will fail.  allocate_resource() should fail anyway if it
can't satisfy the address constraints, so we should just depend on that.

A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
but we do fall back to it as a default when we don't have information about
host bridge apertures.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
 drivers/pci/bus.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 00660cc502c5..38901665c770 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -162,8 +162,6 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
 
 		avail = *r;
 		pci_clip_resource_to_region(bus, &avail, region);
-		if (!resource_size(&avail))
-			continue;
 
 		/*
 		 * "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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 <bhelgaas@google.com>
> 
> When resource_size_t is 32 bits wide, e.g., when CONFIG_PHYS_ADDR_T_64BIT
> is not defined, resource_size() on [mem 0x00000000-0xffffffff] returns 0
> because (r->end - r->start + 1) overflows.
> 
> Therefore, we can't use "resource_size() == 0" to decide that allocation
> from this resource will fail.  allocate_resource() should fail anyway if it
> can't satisfy the address constraints, so we should just depend on that.
> 
> A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
> but we do fall back to it as a default when we don't have information about
> host bridge apertures.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
> Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
>  drivers/pci/bus.c |    2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index 00660cc502c5..38901665c770 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -162,8 +162,6 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
>  
>  		avail = *r;
>  		pci_clip_resource_to_region(bus, &avail, region);
> -		if (!resource_size(&avail))
> -			continue;
>  
>  		/*
>  		 * "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to

I've applied your patch on top of v3.14-rc6. The boot warning is gone.
And /proc/iomem once again has the lines:
    [...]
    80000000-801fffff : PCI Bus 0000:02
    80200000-8027ffff : 0000:00:02.1
    80280000-80280fff : Intel Flush Page
    [...]

Which is what we want, don't we?

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.14-rc6 without your patch, so these might be
unrelated. They're unclear to me, anyway.

Thanks,


Paul Bolle

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

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 <bhelgaas@google.com>
> 
> When resource_size_t is 32 bits wide, e.g., when CONFIG_PHYS_ADDR_T_64BIT
> is not defined, resource_size() on [mem 0x00000000-0xffffffff] returns 0
> because (r->end - r->start + 1) overflows.
> 
> Therefore, we can't use "resource_size() == 0" to decide that allocation
> from this resource will fail.  allocate_resource() should fail anyway if it
> can't satisfy the address constraints, so we should just depend on that.
> 
> A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
> but we do fall back to it as a default when we don't have information about
> host bridge apertures.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
> Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
>  drivers/pci/bus.c |    2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index 00660cc502c5..38901665c770 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -162,8 +162,6 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
>  
>  		avail = *r;
>  		pci_clip_resource_to_region(bus, &avail, region);
> -		if (!resource_size(&avail))
> -			continue;
>  
>  		/*
>  		 * "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to

I've applied your patch on top of v3.14-rc6. The boot warning is gone.
And /proc/iomem once again has the lines:
    [...]
    80000000-801fffff : PCI Bus 0000:02
    80200000-8027ffff : 0000:00:02.1
    80280000-80280fff : Intel Flush Page
    [...]

Which is what we want, don't we?

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.14-rc6 without your patch, so these might be
unrelated. They're unclear to me, anyway.

Thanks,


Paul Bolle

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

[+cc Rafael]

On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle <pebolle@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 Helgaas <bhelgaas@google.com>
>>
>> When resource_size_t is 32 bits wide, e.g., when CONFIG_PHYS_ADDR_T_64BIT
>> is not defined, resource_size() on [mem 0x00000000-0xffffffff] returns 0
>> because (r->end - r->start + 1) overflows.
>>
>> Therefore, we can't use "resource_size() == 0" to decide that allocation
>> from this resource will fail.  allocate_resource() should fail anyway if it
>> can't satisfy the address constraints, so we should just depend on that.
>>
>> A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
>> but we do fall back to it as a default when we don't have information about
>> host bridge apertures.
>>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
>> Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation
>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>> ---
>>  drivers/pci/bus.c |    2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
>> index 00660cc502c5..38901665c770 100644
>> --- a/drivers/pci/bus.c
>> +++ b/drivers/pci/bus.c
>> @@ -162,8 +162,6 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
>>
>>               avail = *r;
>>               pci_clip_resource_to_region(bus, &avail, region);
>> -             if (!resource_size(&avail))
>> -                     continue;
>>
>>               /*
>>                * "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to
>
> I've applied your patch on top of v3.14-rc6. The boot warning is gone.
> And /proc/iomem once again has the lines:
>     [...]
>     80000000-801fffff : PCI Bus 0000:02
>     80200000-8027ffff : 0000:00:02.1
>     80280000-80280fff : Intel Flush Page
>     [...]
>
> Which is what we want, don't we?

Yep, that part looks good.

> 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.14-rc6 without your patch, so these might be
> unrelated. They're unclear to me, anyway.

Hmm, this is definitely concerning.  Resource type 10 is
ACPI_RESOURCE_TYPE_FIXED_MEMORY32, which we do handle (unless it's
length 0).  And your previous dmesg logs (at
https://bugzilla.kernel.org/show_bug.cgi?id=71611) don't show anything
like that.

Can you attach an acpidump and the dmesg log with my patch to the bugzilla?

Bjorn

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

[+cc Rafael]

On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle <pebolle@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 Helgaas <bhelgaas@google.com>
>>
>> When resource_size_t is 32 bits wide, e.g., when CONFIG_PHYS_ADDR_T_64BIT
>> is not defined, resource_size() on [mem 0x00000000-0xffffffff] returns 0
>> because (r->end - r->start + 1) overflows.
>>
>> Therefore, we can't use "resource_size() == 0" to decide that allocation
>> from this resource will fail.  allocate_resource() should fail anyway if it
>> can't satisfy the address constraints, so we should just depend on that.
>>
>> A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
>> but we do fall back to it as a default when we don't have information about
>> host bridge apertures.
>>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
>> Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation
>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>> ---
>>  drivers/pci/bus.c |    2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
>> index 00660cc502c5..38901665c770 100644
>> --- a/drivers/pci/bus.c
>> +++ b/drivers/pci/bus.c
>> @@ -162,8 +162,6 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
>>
>>               avail = *r;
>>               pci_clip_resource_to_region(bus, &avail, region);
>> -             if (!resource_size(&avail))
>> -                     continue;
>>
>>               /*
>>                * "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to
>
> I've applied your patch on top of v3.14-rc6. The boot warning is gone.
> And /proc/iomem once again has the lines:
>     [...]
>     80000000-801fffff : PCI Bus 0000:02
>     80200000-8027ffff : 0000:00:02.1
>     80280000-80280fff : Intel Flush Page
>     [...]
>
> Which is what we want, don't we?

Yep, that part looks good.

> 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.14-rc6 without your patch, so these might be
> unrelated. They're unclear to me, anyway.

Hmm, this is definitely concerning.  Resource type 10 is
ACPI_RESOURCE_TYPE_FIXED_MEMORY32, which we do handle (unless it's
length 0).  And your previous dmesg logs (at
https://bugzilla.kernel.org/show_bug.cgi?id=71611) don't show anything
like that.

Can you attach an acpidump and the dmesg log with my patch to the bugzilla?

Bjorn

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
> On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle <pebolle@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 tried v3.14-rc6 without your patch, so these might be
> > unrelated. They're unclear to me, anyway.
> 
> Hmm, this is definitely concerning.  Resource type 10 is
> ACPI_RESOURCE_TYPE_FIXED_MEMORY32, which we do handle (unless it's
> length 0).  And your previous dmesg logs (at
> https://bugzilla.kernel.org/show_bug.cgi?id=71611) don't show anything
> like that.
> 
> Can you attach an acpidump and the dmesg log with my patch to the bugzilla?

It's getting rather late over here. So I'll try (quite) a few hours
later. But acpidump doesn't ring any bells right now. Any hints?

Thanks,


Paul Bolle

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Bjorn Helgaas]

On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle <pebolle@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 <pebolle@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 tried v3.14-rc6 without your patch, so these might be
>> > unrelated. They're unclear to me, anyway.
>>
>> Hmm, this is definitely concerning.  Resource type 10 is
>> ACPI_RESOURCE_TYPE_FIXED_MEMORY32, which we do handle (unless it's
>> length 0).  And your previous dmesg logs (at
>> https://bugzilla.kernel.org/show_bug.cgi?id=71611) don't show anything
>> like that.
>>
>> Can you attach an acpidump and the dmesg log with my patch to the bugzilla?
>
> It's getting rather late over here. So I'll try (quite) a few hours
> later. But acpidump doesn't ring any bells right now. Any hints?

There's acpidump info here: https://01.org/linux-acpi/utilities .  You
don't need to extract the binary tables or anything; just attach the
text dump to the bugzilla.

It would be very interesting to try v3.14-rc6 without my patch.  I
hope it has the same "unknown resource type" messages, because I don't
see how my patch could be related to them.  There were no recent
PNP-related changes, so then I start to worry about some sort of
memory corruption from an unrelated patch.  But I hope that's not the
case.

Bjorn

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

Bjorn Helgaas schreef op ma 10-03-2014 om 20:07 [-0600]:
> On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle <pebolle@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 <pebolle@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 tried v3.14-rc6 without your patch, so these might be
> >> > unrelated. They're unclear to me, anyway.
> >>
> >> Hmm, this is definitely concerning.  Resource type 10 is
> >> ACPI_RESOURCE_TYPE_FIXED_MEMORY32, which we do handle (unless it's
> >> length 0).  And your previous dmesg logs (at
> >> https://bugzilla.kernel.org/show_bug.cgi?id=71611) don't show anything
> >> like that.
> >>
> >> Can you attach an acpidump and the dmesg log with my patch to the bugzilla?
> >
> > It's getting rather late over here. So I'll try (quite) a few hours
> > later. But acpidump doesn't ring any bells right now. Any hints?
> 
> There's acpidump info here: https://01.org/linux-acpi/utilities .  You
> don't need to extract the binary tables or anything; just attach the
> text dump to the bugzilla.

(On Fedora it's shipped in acpica-tools. But since acpidump is a symlink
to /usr/bin/acpidump-acpica that is created at install time it won't
show up when one does "repoquery -f "*/acpidump". Add to this that "yum
list pmtools" returns an error, and one is guaranteed roughly 30 minutes
of sheer fun. Unsurprisingly, stubbornly trying "yum install pmtools"
will actually install acpica-tools.)

At least this all is written down somewhere now.)

> It would be very interesting to try v3.14-rc6 without my patch.  I
> hope it has the same "unknown resource type" messages, because I don't
> see how my patch could be related to them.  There were no recent
> PNP-related changes, so then I start to worry about some sort of
> memory corruption from an unrelated patch.  But I hope that's not the
> case.

lkml.org is returning some error page, but Markus Trippelsdorf just
reported seeing this message too. Markus is unlikely to be also trying
this patch.

I've just added you to the CC's of my reply to Markus. I won't update
the bugzilla report for now, because those messages appear unrelated to
your patch.

Thanks,


Paul Bolle

Re: agp/intel: can't ioremap flush page - no chipset flushing

[Paul Bolle]

Bjorn Helgaas schreef op ma 10-03-2014 om 20:07 [-0600]:
> On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle <pebolle@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 <pebolle@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 tried v3.14-rc6 without your patch, so these might be
> >> > unrelated. They're unclear to me, anyway.
> >>
> >> Hmm, this is definitely concerning.  Resource type 10 is
> >> ACPI_RESOURCE_TYPE_FIXED_MEMORY32, which we do handle (unless it's
> >> length 0).  And your previous dmesg logs (at
> >> https://bugzilla.kernel.org/show_bug.cgi?id=71611) don't show anything
> >> like that.
> >>
> >> Can you attach an acpidump and the dmesg log with my patch to the bugzilla?
> >
> > It's getting rather late over here. So I'll try (quite) a few hours
> > later. But acpidump doesn't ring any bells right now. Any hints?
> 
> There's acpidump info here: https://01.org/linux-acpi/utilities .  You
> don't need to extract the binary tables or anything; just attach the
> text dump to the bugzilla.

(On Fedora it's shipped in acpica-tools. But since acpidump is a symlink
to /usr/bin/acpidump-acpica that is created at install time it won't
show up when one does "repoquery -f "*/acpidump". Add to this that "yum
list pmtools" returns an error, and one is guaranteed roughly 30 minutes
of sheer fun. Unsurprisingly, stubbornly trying "yum install pmtools"
will actually install acpica-tools.)

At least this all is written down somewhere now.)

> It would be very interesting to try v3.14-rc6 without my patch.  I
> hope it has the same "unknown resource type" messages, because I don't
> see how my patch could be related to them.  There were no recent
> PNP-related changes, so then I start to worry about some sort of
> memory corruption from an unrelated patch.  But I hope that's not the
> case.

lkml.org is returning some error page, but Markus Trippelsdorf just
reported seeing this message too. Markus is unlikely to be also trying
this patch.

I've just added you to the CC's of my reply to Markus. I won't update
the bugzilla report for now, because those messages appear unrelated to
your patch.

Thanks,


Paul Bolle