Re: resource map sanity check conflict

Re: resource map sanity check conflict

[Andreas Hartmann]

Hi,

well, I do have the same problem with a Radeon HD3200 onboard gfxcard.
On loading the fglrx-module, the following trace comes up:


resource map sanity check conflict: 0xcfbfb000 0xcfffbfff 0xcff00000
0xfebfffff PCI Bus 0000:00
------------[ cut here ]------------
WARNING: at
/usr/src/packages/BUILD/kernel-desktop-2.6.34.7/linux-2.6.34/arch/x86/mm/ioremap.c:98
__ioremap_caller+0x350/0x380()
Hardware name: GA-MA78G-DS3H
Info: mapping multiple BARs. Your kernel is fine.
Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device
bridge stp llc tun cpufreq_conservative cpufreq_userspace
cpufreq_powersave powernow_k8 mperf fuse sha256_generic cryptd
aes_x86_64 aes_generic cbc dm_crypt reiserfs loop dm_mod
snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec
firewire_ohci firewire_core snd_hwdep snd_pcm crc_itu_t snd_timer
fglrx(P) ohci1394 kvm_amd snd shpchp edac_core sr_mod soundcore
edac_mce_amd ieee1394 kvm e100 cdrom snd_page_alloc usb_storage wmi
pci_hotplug i2c_piix4 k8temp pcspkr r8169 sg button sd_mod ahci edd fan
processor ata_generic pata_atiixp libata scsi_mod thermal thermal_sys raid1
Pid: 6069, comm: Xorg Tainted: P           2.6.34.7-33-desktop #1
Call Trace:
[<ffffffff810060a9>] dump_trace+0x79/0x340
[<ffffffff8149b75e>] dump_stack+0x69/0x6f
[<ffffffff81050f83>] warn_slowpath_common+0x73/0xb0
[<ffffffff81051020>] warn_slowpath_fmt+0x40/0x50
[<ffffffff810322c0>] __ioremap_caller+0x350/0x380
[<ffffffffa0251712>] drm_ioremap_nocache+0x52/0x120 [fglrx]
[<ffffffffa026b7ff>] __create_mapping+0x7f/0x4b0 [fglrx]
[<ffffffffa0267c52>] gal_map_virtual_space+0x62/0xc0 [fglrx]
[<ffffffffa027013e>] __mc_heap_map_virtual_space+0x12e/0x210 [fglrx]
[<ffffffffa026d7eb>] mc_heap_alloc_reserved_mem+0x1fb/0x360 [fglrx]
[<ffffffffa02627a4>] MCIL_AllocateMemory+0x264/0x420 [fglrx]
[<ffffffffa02f5198>]
_ZN7GpsBase15GPS_AllocMemoryEPvmjP15_ULARGE_INTEGERP9MCADDRESSb+0x68/0xa0 [fglrx]
[<ffffffffa02f5012>]
_ZN7GpsBase11AllocMemoryEmjP15_ULARGE_INTEGERP9MCADDRESSb+0x22/0x30 [fglrx]
[<ffffffffa03039a7>] _ZN9PageTable16CreateTableInLFBEm+0x47/0xb0 [fglrx]
[<ffffffffa02f4725>] _ZN17PageTableGartVmpt4InitEv+0x15/0x40 [fglrx]
[<ffffffffa0302342>]
_ZN13GartVmptRS78015CreatePageTableEP9GpsConfig+0x52/0x200 [fglrx]
[<ffffffffa02f631d>] _ZN10GPSContext18InitializeAsicGartEv+0x3d/0xf0 [fglrx]
[<ffffffffa02f1c63>] Gps_GartInitialization+0x23/0x40 [fglrx]
[<ffffffffa026ad1b>] __gart_init+0x2eb/0x6f0 [fglrx]
[<ffffffffa02686e0>] gal_init+0xc0/0x160 [fglrx]
[<ffffffffa026e552>] mc_heap_init+0xe2/0x200 [fglrx]
[<ffffffffa025ca2a>] firegl_init_pcie+0x16a/0x3e0 [fglrx]
[<ffffffffa02584da>] firegl_ioctl+0x1ea/0x250 [fglrx]
[<ffffffff81134086>] vfs_ioctl+0x96/0xd0
[<ffffffff811345a8>] do_vfs_ioctl+0x78/0x420
[<ffffffff811349d0>] sys_ioctl+0x80/0xa0
[<ffffffff81002fbb>] system_call_fastpath+0x16/0x1b
[<00007f5db85c0547>] 0x7f5db85c0547
---[ end trace e6f2dfd959f0bb46 ]---
[   56.972841] [fglrx] Could not enable MSI; System prevented initialization
[fglrx] Firegl kernel thread PID: 6104
[fglrx] IRQ 18 Enabled
[fglrx] Gart USWC size:1279 M.
[fglrx] Gart cacheable size:508 M.
[fglrx] Reserved FB block: Shared offset:0, size:1000000
[fglrx] Reserved FB block: Unshared offset:fbfb000, size:401000
[fglrx] Reserved FB block: Unshared offset:fffc000, size:4000


dmesg


Linux version 2.6.34.7-33-desktop (geeko@buildhost) (gcc version 4.4.1
[gcc-4_4-branch revision 150839] (SUSE Linux) ) #1 SMP PREEMPT
2010-11-09 20:08:44 +0100
Command line:
root=/dev/disk/by-id/scsi-SATA_WDC_WD5000AACS-_WD-WCAUF1158341-part1
splash=silent quiet nmi_watchdog=0 iommu=noagp,memaper=0 agp=off vga=0x376
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000bfde0000 (usable)
BIOS-e820: 00000000bfde0000 - 00000000bfde3000 (ACPI NVS)
BIOS-e820: 00000000bfde3000 - 00000000bfdf0000 (ACPI data)
BIOS-e820: 00000000bfdf0000 - 00000000bfe00000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000230000000 (usable)
NX (Execute Disable) protection: active
DMI 2.4 present.
e820 update range: 0000000000000000 - 0000000000001000 (usable) ==>
(reserved)
e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
No AGP bridge found
last_pfn = 0x230000 max_arch_pfn = 0x400000000
MTRR default type: uncachable
MTRR fixed ranges enabled:
 00000-9FFFF write-back
 A0000-BFFFF uncachable
 C0000-C7FFF write-protect
 C8000-FFFFF uncachable
MTRR variable ranges enabled:
 0 base 0000000000 mask FF80000000 write-back
 1 base 0080000000 mask FFC0000000 write-back
 2 base 00BFE00000 mask FFFFE00000 uncachable
 3 base 0100000000 mask FF00000000 write-back
 4 base 0200000000 mask FFE0000000 write-back
 5 base 0220000000 mask FFF0000000 write-back
 6 disabled
 7 disabled
TOM2: 0000000230000000 aka 8960M
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
e820 update range: 00000000bfe00000 - 0000000100000000 (usable) ==>
(reserved)
last_pfn = 0xbfde0 max_arch_pfn = 0x400000000
e820 update range: 0000000000001000 - 0000000000010000 (usable) ==>
(reserved)
Scanning 1 areas for low memory corruption
modified physical RAM map:
modified: 0000000000000000 - 0000000000010000 (reserved)
modified: 0000000000010000 - 000000000009f800 (usable)
modified: 000000000009f800 - 00000000000a0000 (reserved)
modified: 00000000000f0000 - 0000000000100000 (reserved)
modified: 0000000000100000 - 00000000bfde0000 (usable)
modified: 00000000bfde0000 - 00000000bfde3000 (ACPI NVS)
modified: 00000000bfde3000 - 00000000bfdf0000 (ACPI data)
modified: 00000000bfdf0000 - 00000000bfe00000 (reserved)
modified: 00000000e0000000 - 00000000f0000000 (reserved)
modified: 00000000fec00000 - 0000000100000000 (reserved)
modified: 0000000100000000 - 0000000230000000 (usable)
initial memory mapped : 0 - 20000000


lspci -v
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200
Graphics (prog-if 00 [VGA controller])
        Subsystem: Giga-byte Technology GA-MA78GM-S2H Motherboard
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        I/O ports at ee00 [size=256]
        Memory at fdfe0000 (32-bit, non-prefetchable) [size=64K]
        Memory at fde00000 (32-bit, non-prefetchable) [size=1M]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [50] Power Management version 3
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Kernel driver in use: fglrx_pci


btw: There is some memory missing:
The machine has 8 GB physical RAM, but free -m reports only 7779 MB. If
you ad the 256 MB of the shared memory for the gfxcard, you get 8035 MB.
This means: I'm missing 157 MB!


Kind regards,
Andreas

resource map sanity check conflict

[Jiri Slaby]

Hi,

with 2.6.37-rc2 with some unrelated patches the following WARNING is
generated:

pnp 00:0a: [mem 0xfed40000-0xfed44fff]
pnp 00:0a: Plug and Play ACPI device, IDs ATM1200 PNP0c31 (active)
...
resource map sanity check conflict: 0xfed40000 0xfed44fff 0xfed44000
0xfed44fff Intel Flush Page
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:98 __ioremap_caller+0x353/0x380()
Hardware name: 766929G
Info: mapping multiple BARs. Your kernel is fine.
Modules linked in: snd tpm_tis(+) snd_page_alloc e1000e(+) rfkill pcspkr
iTCO_wdt soundcore yenta_socket pcmcia_rsrc pcmcia_core
iTCO_vendor_support battery sg tpm tpm_bios ac i915 drm_kms_helper drm
i2c_algo_bit button video ext4 crc16 jbd2 fan processor ata_generic
thermal thermal_sys
Pid: 382, comm: modprobe Not tainted 2.6.37-rc2-0.0.0.4ae942e-desktop #1
Call Trace:
 [<ffffffff81005ac9>] dump_trace+0x79/0x340
 [<ffffffff8151e921>] dump_stack+0x69/0x6f
 [<ffffffff81057d2b>] warn_slowpath_common+0x7b/0xc0
 [<ffffffff81057e25>] warn_slowpath_fmt+0x45/0x50
 [<ffffffff81032453>] __ioremap_caller+0x353/0x380
 [<ffffffffa02c68d7>] tpm_tis_init+0x57/0x660 [tpm_tis]
 [<ffffffff812e8f29>] pnp_device_probe+0x69/0xe0
 [<ffffffff8132afc4>] really_probe+0x64/0x200
 [<ffffffff8132b343>] driver_probe_device+0x43/0xa0
 [<ffffffff8132b433>] __driver_attach+0x93/0xa0
 [<ffffffff8132a02e>] bus_for_each_dev+0x4e/0x80
 [<ffffffff8132a978>] bus_add_driver+0x148/0x2f0
 [<ffffffff8132b68a>] driver_register+0x6a/0x130
 [<ffffffff810002da>] do_one_initcall+0x3a/0x170
 [<ffffffff8109629a>] sys_init_module+0xba/0x210
 [<ffffffff8100307b>] system_call_fastpath+0x16/0x1b
 [<00007f5b8a330eda>] 0x7f5b8a330eda
---[ end trace 1409850b53f9aab2 ]---
tpm_tis 00:0a: 1.2 TPM (device-id 0x3203, rev-id 9)


/proc/iomem:
fed1c000-fed8ffff : reserved
  fed1c000-fed1ffff : pnp 00:02
  fed40000-fed4bfff : PCI Bus 0000:00
    fed44000-fed44fff : Intel Flush Page
    fed45000-fed4bfff : pnp 00:02


Is it a result of the past resource handling rewrote?

It seems like pci_bus_alloc_resource in
intel_alloc_chipset_flush_resource chooses a weird place to put the
mapping in.

dmesg:
https://bugzillafiles.novell.org/attachment.cgi?id=401414
lspci -vvnnxxx:
https://bugzillafiles.novell.org/attachment.cgi?id=401643
/proc/iomem:
https://bugzillafiles.novell.org/attachment.cgi?id=401476

regards,
-- 
js
suse labs

Re: resource map sanity check conflict

[Bjorn Helgaas]

On Wednesday, November 24, 2010 06:36:01 am Jiri Slaby wrote:
> Hi,
> 
> with 2.6.37-rc2 with some unrelated patches the following WARNING is
> generated:
> 
> pnp 00:0a: [mem 0xfed40000-0xfed44fff]
> pnp 00:0a: Plug and Play ACPI device, IDs ATM1200 PNP0c31 (active)
> ...
> resource map sanity check conflict: 0xfed40000 0xfed44fff 0xfed44000
> 0xfed44fff Intel Flush Page
> ------------[ cut here ]------------
> WARNING: at arch/x86/mm/ioremap.c:98 __ioremap_caller+0x353/0x380()
> ...

> /proc/iomem:
> fed1c000-fed8ffff : reserved
>   fed1c000-fed1ffff : pnp 00:02
>   fed40000-fed4bfff : PCI Bus 0000:00
>     fed44000-fed44fff : Intel Flush Page
>     fed45000-fed4bfff : pnp 00:02
> 
> 
> Is it a result of the past resource handling rewrote?
> 
> It seems like pci_bus_alloc_resource in
> intel_alloc_chipset_flush_resource chooses a weird place to put the
> mapping in.

Yes, this is related to the PCI resource changes I made recently.
We used to allocate PCI resources from low addresses first and work
upwards, and now we do the reverse.  So in 2.6.36, the "Intel Flush
Page" was probably allocated low in the [mem 0x7e000000-0xfebfffff]
window, but now we put it in the [mem 0xfed40000-0xfed4bfff] window:

  pci_root PNP0A08:00: host bridge window [mem 0x000dc000-0x000dffff]
  pci_root PNP0A08:00: host bridge window [mem 0xfed40000-0xfed4bfff]

I think the problem is that we ignore most of what ACPI tells us
about motherboard device resource usage.  We do have the "system"
driver, which reserves resources used by PNP0c01 and PNP0c02 devices,
but we don't do anything about other devices like the ATM1200/PNP0c31
device which, in your case, is using some of the space in that
[mem 0xfed40000-0xfed4bfff] host bridge window.

I've been worried that this would bite us eventually, and I tried to
reserve all the ACPI resources in the PNP core a couple years ago,
but we had to revert that because it caused other problems.  I still
think it's something we need to do after we straighten out the issues.

> dmesg:
> https://bugzillafiles.novell.org/attachment.cgi?id=401414
> lspci -vvnnxxx:
> https://bugzillafiles.novell.org/attachment.cgi?id=401643
> /proc/iomem:
> https://bugzillafiles.novell.org/attachment.cgi?id=401476

Is there a kernel.org bugzilla about this?  If not, could you open one
and assign it to me?

Does your system still work, despite the warning?  It can't be good
that we put the flush page on top of the TPM device, but I don't know
what intel-gtt actually *does* with the flush page.

Thanks,
  Bjorn

Re: resource map sanity check conflict

[Jiri Slaby]

On 11/24/2010 08:22 PM, Bjorn Helgaas wrote:
> On Wednesday, November 24, 2010 06:36:01 am Jiri Slaby wrote:
>> Hi,
>>
>> with 2.6.37-rc2 with some unrelated patches the following WARNING is
>> generated:
>>
>> pnp 00:0a: [mem 0xfed40000-0xfed44fff]
>> pnp 00:0a: Plug and Play ACPI device, IDs ATM1200 PNP0c31 (active)
>> ...
>> resource map sanity check conflict: 0xfed40000 0xfed44fff 0xfed44000
>> 0xfed44fff Intel Flush Page
>> ------------[ cut here ]------------
>> WARNING: at arch/x86/mm/ioremap.c:98 __ioremap_caller+0x353/0x380()
>> ...
> 
>> /proc/iomem:
>> fed1c000-fed8ffff : reserved
>>   fed1c000-fed1ffff : pnp 00:02
>>   fed40000-fed4bfff : PCI Bus 0000:00
>>     fed44000-fed44fff : Intel Flush Page
>>     fed45000-fed4bfff : pnp 00:02
>>
>>
>> Is it a result of the past resource handling rewrote?
>>
>> It seems like pci_bus_alloc_resource in
>> intel_alloc_chipset_flush_resource chooses a weird place to put the
>> mapping in.
> 
> Yes, this is related to the PCI resource changes I made recently.
> We used to allocate PCI resources from low addresses first and work
> upwards, and now we do the reverse.  So in 2.6.36, the "Intel Flush
> Page" was probably allocated low in the [mem 0x7e000000-0xfebfffff]
> window, but now we put it in the [mem 0xfed40000-0xfed4bfff] window:
> 
>   pci_root PNP0A08:00: host bridge window [mem 0x000dc000-0x000dffff]
>   pci_root PNP0A08:00: host bridge window [mem 0xfed40000-0xfed4bfff]
> 
> I think the problem is that we ignore most of what ACPI tells us
> about motherboard device resource usage.  We do have the "system"
> driver, which reserves resources used by PNP0c01 and PNP0c02 devices,
> but we don't do anything about other devices like the ATM1200/PNP0c31
> device which, in your case, is using some of the space in that
> [mem 0xfed40000-0xfed4bfff] host bridge window.
> 
> I've been worried that this would bite us eventually, and I tried to
> reserve all the ACPI resources in the PNP core a couple years ago,
> but we had to revert that because it caused other problems.  I still
> think it's something we need to do after we straighten out the issues.
> 
>> dmesg:
>> https://bugzillafiles.novell.org/attachment.cgi?id=401414
>> lspci -vvnnxxx:
>> https://bugzillafiles.novell.org/attachment.cgi?id=401643
>> /proc/iomem:
>> https://bugzillafiles.novell.org/attachment.cgi?id=401476
> 
> Is there a kernel.org bugzilla about this?  If not, could you open one
> and assign it to me?

I created the bko entry some time ago:
https://bugzilla.kernel.org/show_bug.cgi?id=23802

Any chance you will take a look?

> Does your system still work, despite the warning?  It can't be good
> that we put the flush page on top of the TPM device, but I don't know
> what intel-gtt actually *does* with the flush page.

I think there is no problem other than the warning. I might ask the
reporter if you want to know for sure.

thanks,
-- 
js

Re: resource map sanity check conflict

[Bjorn Helgaas]

On Monday, December 06, 2010 01:17:33 pm Jiri Slaby wrote:
> On 11/24/2010 08:22 PM, Bjorn Helgaas wrote:
> > On Wednesday, November 24, 2010 06:36:01 am Jiri Slaby wrote:
> >> Hi,
> >>
> >> with 2.6.37-rc2 with some unrelated patches the following WARNING is
> >> generated:
> >>
> >> pnp 00:0a: [mem 0xfed40000-0xfed44fff]
> >> pnp 00:0a: Plug and Play ACPI device, IDs ATM1200 PNP0c31 (active)
> >> ...
> >> resource map sanity check conflict: 0xfed40000 0xfed44fff 0xfed44000
> >> 0xfed44fff Intel Flush Page
> >> ------------[ cut here ]------------
> >> WARNING: at arch/x86/mm/ioremap.c:98 __ioremap_caller+0x353/0x380()
> >> ...
> > 
> >> /proc/iomem:
> >> fed1c000-fed8ffff : reserved
> >>   fed1c000-fed1ffff : pnp 00:02
> >>   fed40000-fed4bfff : PCI Bus 0000:00
> >>     fed44000-fed44fff : Intel Flush Page
> >>     fed45000-fed4bfff : pnp 00:02
> >>
> >>
> >> Is it a result of the past resource handling rewrote?
> >>
> >> It seems like pci_bus_alloc_resource in
> >> intel_alloc_chipset_flush_resource chooses a weird place to put the
> >> mapping in.
> > 
> > Yes, this is related to the PCI resource changes I made recently.
> > We used to allocate PCI resources from low addresses first and work
> > upwards, and now we do the reverse.  So in 2.6.36, the "Intel Flush
> > Page" was probably allocated low in the [mem 0x7e000000-0xfebfffff]
> > window, but now we put it in the [mem 0xfed40000-0xfed4bfff] window:
> > 
> >   pci_root PNP0A08:00: host bridge window [mem 0x000dc000-0x000dffff]
> >   pci_root PNP0A08:00: host bridge window [mem 0xfed40000-0xfed4bfff]
> > 
> > I think the problem is that we ignore most of what ACPI tells us
> > about motherboard device resource usage.  We do have the "system"
> > driver, which reserves resources used by PNP0c01 and PNP0c02 devices,
> > but we don't do anything about other devices like the ATM1200/PNP0c31
> > device which, in your case, is using some of the space in that
> > [mem 0xfed40000-0xfed4bfff] host bridge window.
> > 
> > I've been worried that this would bite us eventually, and I tried to
> > reserve all the ACPI resources in the PNP core a couple years ago,
> > but we had to revert that because it caused other problems.  I still
> > think it's something we need to do after we straighten out the issues.
> > 
> >> dmesg:
> >> https://bugzillafiles.novell.org/attachment.cgi?id=401414
> >> lspci -vvnnxxx:
> >> https://bugzillafiles.novell.org/attachment.cgi?id=401643
> >> /proc/iomem:
> >> https://bugzillafiles.novell.org/attachment.cgi?id=401476
> > 
> > Is there a kernel.org bugzilla about this?  If not, could you open one
> > and assign it to me?
> 
> I created the bko entry some time ago:
> https://bugzilla.kernel.org/show_bug.cgi?id=23802
> 
> Any chance you will take a look?

I will take a look, and in fact, I'm working on these:
  https://bugzilla.kernel.org/show_bug.cgi?id=23542
  https://bugzilla.kernel.org/show_bug.cgi?id=23332

and the fix I'm contemplating should also apply to 23802.

Bjorn

Re: resource map sanity check conflict

[Bjorn Helgaas]

On Monday, December 06, 2010 01:34:56 pm Bjorn Helgaas wrote:
> On Monday, December 06, 2010 01:17:33 pm Jiri Slaby wrote:
> > On 11/24/2010 08:22 PM, Bjorn Helgaas wrote:
> > > On Wednesday, November 24, 2010 06:36:01 am Jiri Slaby wrote:
...
> > >> pnp 00:0a: [mem 0xfed40000-0xfed44fff]
> > >> pnp 00:0a: Plug and Play ACPI device, IDs ATM1200 PNP0c31 (active)
> > >> ...
> > >> resource map sanity check conflict: 0xfed40000 0xfed44fff 0xfed44000
...
> > > Yes, this is related to the PCI resource changes I made recently.
> > > We used to allocate PCI resources from low addresses first and work
> > > upwards, and now we do the reverse.  So in 2.6.36, the "Intel Flush
> > > Page" was probably allocated low in the [mem 0x7e000000-0xfebfffff]
> > > window, but now we put it in the [mem 0xfed40000-0xfed4bfff] window:
> > > 
> > >   pci_root PNP0A08:00: host bridge window [mem 0x000dc000-0x000dffff]
> > >   pci_root PNP0A08:00: host bridge window [mem 0xfed40000-0xfed4bfff]
> > > 
> > > I think the problem is that we ignore most of what ACPI tells us
> > > about motherboard device resource usage.  We do have the "system"
> > > driver, which reserves resources used by PNP0c01 and PNP0c02 devices,
> > > but we don't do anything about other devices like the ATM1200/PNP0c31
> > > device which, in your case, is using some of the space in that
> > > [mem 0xfed40000-0xfed4bfff] host bridge window.

> > I created the bko entry some time ago:
> > https://bugzilla.kernel.org/show_bug.cgi?id=23802

I have a patch here for testing:

  https://bugzilla.kernel.org/attachment.cgi?id=39262

Bjorn

Re: resource map sanity check conflict

[Jiri Slaby]

On 12/08/2010 08:56 PM, Bjorn Helgaas wrote:
> On Monday, December 06, 2010 01:34:56 pm Bjorn Helgaas wrote:
>> On Monday, December 06, 2010 01:17:33 pm Jiri Slaby wrote:
>>> On 11/24/2010 08:22 PM, Bjorn Helgaas wrote:
>>>> On Wednesday, November 24, 2010 06:36:01 am Jiri Slaby wrote:
> ...
>>>>> pnp 00:0a: [mem 0xfed40000-0xfed44fff]
>>>>> pnp 00:0a: Plug and Play ACPI device, IDs ATM1200 PNP0c31 (active)
>>>>> ...
>>>>> resource map sanity check conflict: 0xfed40000 0xfed44fff 0xfed44000
> ...
>>>> Yes, this is related to the PCI resource changes I made recently.
>>>> We used to allocate PCI resources from low addresses first and work
>>>> upwards, and now we do the reverse.  So in 2.6.36, the "Intel Flush
>>>> Page" was probably allocated low in the [mem 0x7e000000-0xfebfffff]
>>>> window, but now we put it in the [mem 0xfed40000-0xfed4bfff] window:
>>>>
>>>>   pci_root PNP0A08:00: host bridge window [mem 0x000dc000-0x000dffff]
>>>>   pci_root PNP0A08:00: host bridge window [mem 0xfed40000-0xfed4bfff]
>>>>
>>>> I think the problem is that we ignore most of what ACPI tells us
>>>> about motherboard device resource usage.  We do have the "system"
>>>> driver, which reserves resources used by PNP0c01 and PNP0c02 devices,
>>>> but we don't do anything about other devices like the ATM1200/PNP0c31
>>>> device which, in your case, is using some of the space in that
>>>> [mem 0xfed40000-0xfed4bfff] host bridge window.
> 
>>> I created the bko entry some time ago:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=23802
> 
> I have a patch here for testing:
> 
>   https://bugzilla.kernel.org/attachment.cgi?id=39262

Yes, it works:
https://bugzillafiles.novell.org/attachment.cgi?id=404327

thanks,
-- 
js