Re: 2.6.24-rc8-mm1

Re: 2.6.24-rc8-mm1

[Balbir Singh]

* Andrew Morton <akpm@linux-foundation.org> [2008-01-17 02:35:14]:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
> 
> - selinux is busted on one of my two selinux-enabled test machines.
> 
> - suspend-to-ram and suspend-to-disk are totally hosed on one of my test
>   machines.  I guess I get to bisect this.
> 
> - git-nfsd is dropped due to conflicts with git-nfs
> 
> - git-newsetup is dropped due to conflicts with git-x86 (I think)
> 
> - git-perfmon is dropped due to conflicts with git-x86 (I think)
> 
> - git-kgdb is dropped due to conflicts with git-damn-near-everything
> 
> - git-block is dropped due to conflicts with the IDE tree
> 
> - kvm probably doesn't work properly because I couldn't be bothered fixing
>   the conflicts between git-kvm and the driver tree
> 
> - the volume of rejects and build errors which are caused by subsystem
>   maintainers fiddling with other people's stuff is quite out of control. 
>   Something needs to happen here.

Hi, Andrew,

May be it was one of the conflicts, but my system fails to get
ethernet working with this version. I see

e100: Intel(R) PRO/100 Network Driver, 3. 5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 20 (level, low) -> IRQ 20
modprobe:2584 conflicting cache attribute 50000000-50001000
uncached<->default
e100: 0000:04:08.0: e100_probe: Cannot map device registers, aborting.
ACPI: PCI interrupt for device 0000:04:08.0 disabled
e100: probe of 0000:04:08.0 failed with error -12

Other interesting boot information

Using ACPI (MADT) for SMP configuration information
PM: Registered nosave memory: 000000000008f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
PM: Registered nosave memory: 000000003e5d1000 - 000000003e6e5000
PM: Registered nosave memory: 000000003f574000 - 000000003f57c000
PM: Registered nosave memory: 000000003f62d000 - 000000003f631000
PM: Registered nosave memory: 000000003f6a7000 - 000000003f6e9000
PM: Registered nosave memory: 000000003f6ed000 - 000000003f6ff000
Allocating PCI resources starting at 50000000 (gap: 40000000:bff80000)

 PCI: Bridge: 0000:00:1c.0
   IO window: disabled.
   MEM window:
0x50300000-0x503fffff
   PREFETCH window: disabled.
 PCI: Bridge: 0000:00:1c.2
   IO window: disabled.
   MEM window:
0x50400000-0x504fffff
   PREFETCH window: disabled.
 PCI: Bridge: 0000:00:1c.3
   IO window: disabled.
   MEM window:
0x50500000-0x505fffff
   PREFETCH window: disabled.
 PCI: Bridge: 0000:00:1e.0
   IO window: 1000-1fff
   MEM window:
0x50000000-0x500fffff
   PREFETCH window: disabled.

I am yet to get down to the root cause, thought I'd report it first to
the x86 and ACPI list to see if someone has seen the problem before.

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

Re: 2.6.24-rc8-mm1

[Andrew Morton]

On Thu, 17 Jan 2008 18:16:22 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * Andrew Morton <akpm@linux-foundation.org> [2008-01-17 02:35:14]:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
> > 
> > - selinux is busted on one of my two selinux-enabled test machines.
> > 
> > - suspend-to-ram and suspend-to-disk are totally hosed on one of my test
> >   machines.  I guess I get to bisect this.
> > 
> > - git-nfsd is dropped due to conflicts with git-nfs
> > 
> > - git-newsetup is dropped due to conflicts with git-x86 (I think)
> > 
> > - git-perfmon is dropped due to conflicts with git-x86 (I think)
> > 
> > - git-kgdb is dropped due to conflicts with git-damn-near-everything
> > 
> > - git-block is dropped due to conflicts with the IDE tree
> > 
> > - kvm probably doesn't work properly because I couldn't be bothered fixing
> >   the conflicts between git-kvm and the driver tree
> > 
> > - the volume of rejects and build errors which are caused by subsystem
> >   maintainers fiddling with other people's stuff is quite out of control. 
> >   Something needs to happen here.
> 
> Hi, Andrew,
> 
> May be it was one of the conflicts, but my system fails to get
> ethernet working with this version. I see
> 
> e100: Intel(R) PRO/100 Network Driver, 3. 5.23-k4-NAPI
> e100: Copyright(c) 1999-2006 Intel Corporation
> ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 20 (level, low) -> IRQ 20
> modprobe:2584 conflicting cache attribute 50000000-50001000
> uncached<->default
> e100: 0000:04:08.0: e100_probe: Cannot map device registers, aborting.
> ACPI: PCI interrupt for device 0000:04:08.0 disabled
> e100: probe of 0000:04:08.0 failed with error -12
> 
> Other interesting boot information
> 
> Using ACPI (MADT) for SMP configuration information
> PM: Registered nosave memory: 000000000008f000 - 00000000000a0000
> PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
> PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
> PM: Registered nosave memory: 000000003e5d1000 - 000000003e6e5000
> PM: Registered nosave memory: 000000003f574000 - 000000003f57c000
> PM: Registered nosave memory: 000000003f62d000 - 000000003f631000
> PM: Registered nosave memory: 000000003f6a7000 - 000000003f6e9000
> PM: Registered nosave memory: 000000003f6ed000 - 000000003f6ff000
> Allocating PCI resources starting at 50000000 (gap: 40000000:bff80000)
> 
>  PCI: Bridge: 0000:00:1c.0
>    IO window: disabled.
>    MEM window:
> 0x50300000-0x503fffff
>    PREFETCH window: disabled.
>  PCI: Bridge: 0000:00:1c.2
>    IO window: disabled.
>    MEM window:
> 0x50400000-0x504fffff
>    PREFETCH window: disabled.
>  PCI: Bridge: 0000:00:1c.3
>    IO window: disabled.
>    MEM window:
> 0x50500000-0x505fffff
>    PREFETCH window: disabled.
>  PCI: Bridge: 0000:00:1e.0
>    IO window: 1000-1fff
>    MEM window:
> 0x50000000-0x500fffff
>    PREFETCH window: disabled.
> 
> I am yet to get down to the root cause, thought I'd report it first to
> the x86 and ACPI list to see if someone has seen the problem before.
> 

It appears that the new PAT code didn't like e100's pci_iomap().  Venki, can you
take a look please?


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

RE: 2.6.24-rc8-mm1

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Andrew Morton [mailto:akpm@linux-foundation.org] 
>Sent: Thursday, January 17, 2008 10:40 AM
>To: balbir@linux.vnet.ibm.com
>Cc: linux-kernel@vger.kernel.org; Linux ACPI mailing list; 
>Intel E/100 mailing list; Ingo Molnar; Thomas Gleixner; 
>Pallipadi, Venkatesh
>Subject: Re: 2.6.24-rc8-mm1
>
>On Thu, 17 Jan 2008 18:16:22 +0530 Balbir Singh 
><balbir@linux.vnet.ibm.com> wrote:
>
>> * Andrew Morton <akpm@linux-foundation.org> [2008-01-17 02:35:14]:
>> 
>> > 
>> > 
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>.6.24-rc8/2.6.24-rc8-mm1/
>> > 
>> > - selinux is busted on one of my two selinux-enabled test machines.
>> > 
>> > - suspend-to-ram and suspend-to-disk are totally hosed on 
>one of my test
>> >   machines.  I guess I get to bisect this.
>> > 
>> > - git-nfsd is dropped due to conflicts with git-nfs
>> > 
>> > - git-newsetup is dropped due to conflicts with git-x86 (I think)
>> > 
>> > - git-perfmon is dropped due to conflicts with git-x86 (I think)
>> > 
>> > - git-kgdb is dropped due to conflicts with 
>git-damn-near-everything
>> > 
>> > - git-block is dropped due to conflicts with the IDE tree
>> > 
>> > - kvm probably doesn't work properly because I couldn't be 
>bothered fixing
>> >   the conflicts between git-kvm and the driver tree
>> > 
>> > - the volume of rejects and build errors which are caused 
>by subsystem
>> >   maintainers fiddling with other people's stuff is quite 
>out of control. 
>> >   Something needs to happen here.
>> 
>> Hi, Andrew,
>> 
>> May be it was one of the conflicts, but my system fails to get
>> ethernet working with this version. I see
>> 
>> e100: Intel(R) PRO/100 Network Driver, 3. 5.23-k4-NAPI
>> e100: Copyright(c) 1999-2006 Intel Corporation
>> ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 20 (level, low) -> IRQ 20
>> modprobe:2584 conflicting cache attribute 50000000-50001000
>> uncached<->default
>> e100: 0000:04:08.0: e100_probe: Cannot map device registers, 
>aborting.
>> ACPI: PCI interrupt for device 0000:04:08.0 disabled
>> e100: probe of 0000:04:08.0 failed with error -12
>> 
>It appears that the new PAT code didn't like e100's 
>pci_iomap().  Venki, can you
>take a look please?
>

This seems similar to one problem we saw yday. May not be specific to
e1000. May be at some generic pci code.

The problem is
>> modprobe:2584 conflicting cache attribute 50000000-50001000
>> uncached<->default

Some address range here is being mapped with conflicting types.
Somewhere the range was mapped with default (write-back). Later
pci_iomap() is mapping that region as uncacheable which is basically
aliasing. PAT code detects the aliasing and fails the second uncacheable
request which leads in the failure.

We are trying to find who exactly is mapping this with default at the
beginning.
Balbir: Full dmesg with debug boot parameter may help.

Thanks,
Venki

Re: 2.6.24-rc8-mm1

[Andrew Morton]

On Thu, 17 Jan 2008 11:22:19 -0800 "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:

>  
> The problem is
> >> modprobe:2584 conflicting cache attribute 50000000-50001000
> >> uncached<->default
> 
> Some address range here is being mapped with conflicting types.
> Somewhere the range was mapped with default (write-back). Later
> pci_iomap() is mapping that region as uncacheable which is basically
> aliasing. PAT code detects the aliasing and fails the second uncacheable
> request which leads in the failure.

It sounds to me like you need considerably more runtime debugging and
reporting support in that code.  Ensure that it generates enough output
both during regular operation and during failures for you to be able to
diagnose things in a single iteration.

We can always take it out later.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

RE: [E1000-devel] 2.6.24-rc8-mm1

[Brandeburg, Jesse]

Andrew Morton wrote:
> On Thu, 17 Jan 2008 11:22:19 -0800 "Pallipadi, Venkatesh"
> <venkatesh.pallipadi@intel.com> wrote: 
> 
>> 
>> The problem is
>>>> modprobe:2584 conflicting cache attribute 50000000-50001000
>>>> uncached<->default
>> 
>> Some address range here is being mapped with conflicting types.
>> Somewhere the range was mapped with default (write-back). Later
>> pci_iomap() is mapping that region as uncacheable which is basically
>> aliasing. PAT code detects the aliasing and fails the second
>> uncacheable request which leads in the failure.

its probably the e100 screaming interrupt disable quirk code doing the
mapping?
 
> It sounds to me like you need considerably more runtime debugging and
> reporting support in that code.  Ensure that it generates enough
> output 
> both during regular operation and during failures for you to be able
> to 
> diagnose things in a single iteration.
> 
> We can always take it out later.

FWIW (nothing) I agree.

Re: 2.6.24-rc8-mm1

[Venki Pallipadi]

On Thu, Jan 17, 2008 at 11:40:32AM -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 11:22:19 -0800 "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:
> 
> >  
> > The problem is
> > >> modprobe:2584 conflicting cache attribute 50000000-50001000
> > >> uncached<->default
> > 
> > Some address range here is being mapped with conflicting types.
> > Somewhere the range was mapped with default (write-back). Later
> > pci_iomap() is mapping that region as uncacheable which is basically
> > aliasing. PAT code detects the aliasing and fails the second uncacheable
> > request which leads in the failure.
> 
> It sounds to me like you need considerably more runtime debugging and
> reporting support in that code.  Ensure that it generates enough output
> both during regular operation and during failures for you to be able to
> diagnose things in a single iteration.
> 
> We can always take it out later.
> 
> 

Patch below makes the interesting printks from PAT non DEBUG.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

Index: linux-2.6.git/arch/x86/mm/ioremap.c
===================================================================
--- linux-2.6.git.orig/arch/x86/mm/ioremap.c	2008-01-17 03:18:59.000000000 -0800
+++ linux-2.6.git/arch/x86/mm/ioremap.c	2008-01-17 08:11:51.000000000 -0800
@@ -25,10 +25,13 @@
  */
 void __iomem *ioremap_wc(unsigned long phys_addr, unsigned long size)
 {
-	if (pat_wc_enabled)
+	if (pat_wc_enabled) {
+		printk(KERN_INFO "ioremap_wc: addr %lx, size %lx\n",
+		       phys_addr, size);
 		return __ioremap(phys_addr, size, _PAGE_WC);
-	else
+	} else {
 		return ioremap_nocache(phys_addr, size);
+	}
 }
 EXPORT_SYMBOL(ioremap_wc);
 
Index: linux-2.6.git/arch/x86/mm/ioremap_32.c
===================================================================
--- linux-2.6.git.orig/arch/x86/mm/ioremap_32.c	2008-01-17 03:18:59.000000000 -0800
+++ linux-2.6.git/arch/x86/mm/ioremap_32.c	2008-01-17 08:10:58.000000000 -0800
@@ -164,6 +164,8 @@
 
 void __iomem *ioremap_nocache (unsigned long phys_addr, unsigned long size)
 {
+	printk(KERN_INFO "ioremap_nocache: addr %lx, size %lx\n",
+	       phys_addr, size);
 	return __ioremap(phys_addr, size, _PAGE_UC);
 }
 EXPORT_SYMBOL(ioremap_nocache);
Index: linux-2.6.git/arch/x86/mm/ioremap_64.c
===================================================================
--- linux-2.6.git.orig/arch/x86/mm/ioremap_64.c	2008-01-17 03:18:59.000000000 -0800
+++ linux-2.6.git/arch/x86/mm/ioremap_64.c	2008-01-17 08:10:13.000000000 -0800
@@ -144,7 +144,7 @@
 
 void __iomem *ioremap_nocache (unsigned long phys_addr, unsigned long size)
 {
-	printk(KERN_DEBUG "ioremap_nocache: addr %lx, size %lx\n",
+	printk(KERN_INFO "ioremap_nocache: addr %lx, size %lx\n",
 	       phys_addr, size);
 	return __ioremap(phys_addr, size, _PAGE_UC);
 }
Index: linux-2.6.git/arch/x86/mm/pat.c
===================================================================
--- linux-2.6.git.orig/arch/x86/mm/pat.c	2008-01-17 03:18:59.000000000 -0800
+++ linux-2.6.git/arch/x86/mm/pat.c	2008-01-17 08:06:23.000000000 -0800
@@ -170,7 +170,7 @@
 
 			if (!fattr && attr != ml->attr) {
 				printk(
-	KERN_DEBUG "%s:%d conflicting cache attribute %Lx-%Lx %s<->%s\n",
+	KERN_WARNING "%s:%d conflicting cache attribute %Lx-%Lx %s<->%s\n",
 					current->comm, current->pid,
 					start, end,
 					cattr_name(attr), cattr_name(ml->attr));
@@ -205,7 +205,7 @@
 	list_for_each_entry(ml, &mattr_list, nd) {
 		if (ml->start == start && ml->end == end) {
 			if (ml->attr != attr)
-				printk(KERN_DEBUG
+				printk(KERN_WARNING
 	"%s:%d conflicting cache attributes on free %Lx-%Lx %s<->%s\n",
 			current->comm, current->pid, start, end,
 			cattr_name(attr), cattr_name(ml->attr));
@@ -217,7 +217,7 @@
 	}
 	spin_unlock(&mattr_lock);
 	if (err)
-		printk(KERN_DEBUG "%s:%d freeing invalid mattr %Lx-%Lx %s\n",
+		printk(KERN_WARNING "%s:%d freeing invalid mattr %Lx-%Lx %s\n",
 			current->comm, current->pid,
 			start, end, cattr_name(attr));
 	return err;
Index: linux-2.6.git/include/asm-x86/io_32.h
===================================================================
--- linux-2.6.git.orig/include/asm-x86/io_32.h	2008-01-17 06:28:06.000000000 -0800
+++ linux-2.6.git/include/asm-x86/io_32.h	2008-01-17 08:09:30.000000000 -0800
@@ -113,6 +113,8 @@
 
 static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
 {
+	printk(KERN_INFO "ioremap: addr %lx, size %lx\n",
+	       offset, size);
 	return __ioremap(offset, size, 0);
 }
 
Index: linux-2.6.git/include/asm-x86/io_64.h
===================================================================
--- linux-2.6.git.orig/include/asm-x86/io_64.h	2008-01-17 08:08:23.000000000 -0800
+++ linux-2.6.git/include/asm-x86/io_64.h	2008-01-17 08:08:44.000000000 -0800
@@ -154,7 +154,7 @@
 
 static inline void __iomem * ioremap (unsigned long offset, unsigned long size)
 {
-	printk(KERN_DEBUG "ioremap: addr %lx, size %lx\n",
+	printk(KERN_INFO "ioremap: addr %lx, size %lx\n",
 	       offset, size);
 	return __ioremap(offset, size, 0);
 }

Re: 2.6.24-rc8-mm1

[Balbir Singh]

* Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> [2008-01-17 11:22:19]:

> 
> 
> >-----Original Message-----
> >From: Andrew Morton [mailto:akpm@linux-foundation.org] 
> >Sent: Thursday, January 17, 2008 10:40 AM
> >To: balbir@linux.vnet.ibm.com
> >Cc: linux-kernel@vger.kernel.org; Linux ACPI mailing list; 
> >Intel E/100 mailing list; Ingo Molnar; Thomas Gleixner; 
> >Pallipadi, Venkatesh
> >Subject: Re: 2.6.24-rc8-mm1
> >
> >On Thu, 17 Jan 2008 18:16:22 +0530 Balbir Singh 
> ><balbir@linux.vnet.ibm.com> wrote:
> >
> >> * Andrew Morton <akpm@linux-foundation.org> [2008-01-17 02:35:14]:
> >> 
> >> > 
> >> > 
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
> >.6.24-rc8/2.6.24-rc8-mm1/
> >> > 
> >> > - selinux is busted on one of my two selinux-enabled test machines.
> >> > 
> >> > - suspend-to-ram and suspend-to-disk are totally hosed on 
> >one of my test
> >> >   machines.  I guess I get to bisect this.
> >> > 
> >> > - git-nfsd is dropped due to conflicts with git-nfs
> >> > 
> >> > - git-newsetup is dropped due to conflicts with git-x86 (I think)
> >> > 
> >> > - git-perfmon is dropped due to conflicts with git-x86 (I think)
> >> > 
> >> > - git-kgdb is dropped due to conflicts with 
> >git-damn-near-everything
> >> > 
> >> > - git-block is dropped due to conflicts with the IDE tree
> >> > 
> >> > - kvm probably doesn't work properly because I couldn't be 
> >bothered fixing
> >> >   the conflicts between git-kvm and the driver tree
> >> > 
> >> > - the volume of rejects and build errors which are caused 
> >by subsystem
> >> >   maintainers fiddling with other people's stuff is quite 
> >out of control. 
> >> >   Something needs to happen here.
> >> 
> >> Hi, Andrew,
> >> 
> >> May be it was one of the conflicts, but my system fails to get
> >> ethernet working with this version. I see
> >> 
> >> e100: Intel(R) PRO/100 Network Driver, 3. 5.23-k4-NAPI
> >> e100: Copyright(c) 1999-2006 Intel Corporation
> >> ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 20 (level, low) -> IRQ 20
> >> modprobe:2584 conflicting cache attribute 50000000-50001000
> >> uncached<->default
> >> e100: 0000:04:08.0: e100_probe: Cannot map device registers, 
> >aborting.
> >> ACPI: PCI interrupt for device 0000:04:08.0 disabled
> >> e100: probe of 0000:04:08.0 failed with error -12
> >> 
> >It appears that the new PAT code didn't like e100's 
> >pci_iomap().  Venki, can you
> >take a look please?
> >
> 
> This seems similar to one problem we saw yday. May not be specific to
> e1000. May be at some generic pci code.
> 
> The problem is
> >> modprobe:2584 conflicting cache attribute 50000000-50001000
> >> uncached<->default
> 
> Some address range here is being mapped with conflicting types.
> Somewhere the range was mapped with default (write-back). Later
> pci_iomap() is mapping that region as uncacheable which is basically
> aliasing. PAT code detects the aliasing and fails the second uncacheable
> request which leads in the failure.
> 
> We are trying to find who exactly is mapping this with default at the
> beginning.
> Balbir: Full dmesg with debug boot parameter may help.
>

Venki/Andrew,

I think I found the root cause of the problem and a fix for it. 
The fix works for me.

Description
-----------

With the introduction of reserve_mattr() and free_mattr(), the ioremap* routines
started exploiting it. The recent 2.6.24-rc8-mm1 kernel has a peculiar problem
where in, certain devices disappear. In my case for example

e100: Intel(R) PRO/100 Network Driver, 3. 5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 20 (level, low) -> IRQ 20
modprobe:2584 conflicting cache attribute 50000000-50001000 uncached<->default
e100: 0000:04:08.0: e100_probe: Cannot map device registers, aborting.
ACPI: PCI interrupt for device 0000:04:08.0 disabled

On further analysis, it was discovered that quirk_e100_interrupt() calls
ioremap(), which reserves memory attributes for the e100 card, but iounmap()
does not free it. The patch below removes the check fixes this problem.
It removes for the check of (p->flags >> 20), which checks for architecture
specific bits set on the vm_struct's flags member. ioremap() unconditionally
reserves memory attributes, iounmap() should undo it.


Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---

 arch/x86/mm/ioremap_32.c |    2 +-
 arch/x86/mm/ioremap_64.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff -puN arch/x86/mm/ioremap_32.c~fix-mattr-issue arch/x86/mm/ioremap_32.c
--- linux-2.6.24-rc8/arch/x86/mm/ioremap_32.c~fix-mattr-issue	2008-01-18 04:25:33.000000000 +0530
+++ linux-2.6.24-rc8-balbir/arch/x86/mm/ioremap_32.c	2008-01-18 04:25:53.000000000 +0530
@@ -220,7 +220,7 @@ void iounmap(volatile void __iomem *addr
 	}
 
 	/* Reset the direct mapping. Can block */
-	if (p->flags >> 20) {
+	if (p->flags) {
 		free_mattr(p->phys_addr, p->phys_addr + get_vm_area_size(p),
 		           p->flags>>20);
 		ioremap_change_attr(p->phys_addr, get_vm_area_size(p), 0);
diff -puN arch/x86/mm/ioremap_64.c~fix-mattr-issue arch/x86/mm/ioremap_64.c
--- linux-2.6.24-rc8/arch/x86/mm/ioremap_64.c~fix-mattr-issue	2008-01-18 04:25:33.000000000 +0530
+++ linux-2.6.24-rc8-balbir/arch/x86/mm/ioremap_64.c	2008-01-18 04:25:53.000000000 +0530
@@ -191,7 +191,7 @@ void iounmap(volatile void __iomem *addr
 	}
 
 	/* Reset the direct mapping. Can block */
-	if (p->flags >> 20) {
+	if (p->flags) {
 		free_mattr(p->phys_addr, p->phys_addr + get_vm_area_size(p),
 		           p->flags>>20);
 		ioremap_change_attr(p->phys_addr, get_vm_area_size(p), 0);
_
 
-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

Re: 2.6.24-rc8-mm1

[Siddha, Suresh B]

On Thu, Jan 17, 2008 at 03:04:03PM -0800, Balbir Singh wrote:
> I think I found the root cause of the problem and a fix for it.
> The fix works for me.
> 

Thanks Balbir. But the appended fix is more clean and appropriate. Can you
please check if it works.
---

>From Balbir Singh:
> With the introduction of reserve_mattr() and free_mattr(), the ioremap*
> routines
> started exploiting it. The recent 2.6.24-rc8-mm1 kernel has a peculiar
> problem
> where in, certain devices disappear. In my case for example
>
> e100: Intel(R) PRO/100 Network Driver, 3. 5.23-k4-NAPI
> e100: Copyright(c) 1999-2006 Intel Corporation
> ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 20 (level, low) -> IRQ 20
> modprobe:2584 conflicting cache attribute 50000000-50001000
> uncached<->default
> e100: 0000:04:08.0: e100_probe: Cannot map device registers, aborting.
> ACPI: PCI interrupt for device 0000:04:08.0 disabled
>
> On further analysis, it was discovered that quirk_e100_interrupt() calls
> ioremap(), which reserves memory attributes for the e100 card, but
> iounmap()
> does not free it.

Fix the iounmap() to call free_matrr() unconditionally.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---

diff --git a/arch/x86/mm/ioremap_32.c b/arch/x86/mm/ioremap_32.c
index ae9c8b3..4d5bea8 100644
--- a/arch/x86/mm/ioremap_32.c
+++ b/arch/x86/mm/ioremap_32.c
@@ -201,12 +201,11 @@ void iounmap(volatile void __iomem *addr)
 		return;
 	}
 
+	free_mattr(p->phys_addr, p->phys_addr + get_vm_area_size(p),
+	           p->flags>>20);
 	/* Reset the direct mapping. Can block */
-	if (p->flags >> 20) {
-		free_mattr(p->phys_addr, p->phys_addr + get_vm_area_size(p),
-		           p->flags>>20);
+	if (p->flags >> 20)
 		ioremap_change_attr(p->phys_addr, get_vm_area_size(p), 0);
-	}
 
 	/* Finally remove it */
 	o = remove_vm_area((void *)addr);
diff --git a/arch/x86/mm/ioremap_64.c b/arch/x86/mm/ioremap_64.c
index 022b645..c766327 100644
--- a/arch/x86/mm/ioremap_64.c
+++ b/arch/x86/mm/ioremap_64.c
@@ -183,12 +183,11 @@ void iounmap(volatile void __iomem *addr)
 		return;
 	}
 
+	free_mattr(p->phys_addr, p->phys_addr + get_vm_area_size(p),
+	           p->flags>>20);
 	/* Reset the direct mapping. Can block */
-	if (p->flags >> 20) {
-		free_mattr(p->phys_addr, p->phys_addr + get_vm_area_size(p),
-		           p->flags>>20);
+	if (p->flags >> 20)
 		ioremap_change_attr(p->phys_addr, get_vm_area_size(p), 0);
-	}
 
 	/* Finally remove it */
 	o = remove_vm_area((void *)addr);

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: 2.6.24-rc8-mm1

[Balbir Singh]

On Jan 18, 2008 7:12 AM, Siddha, Suresh B <suresh.b.siddha@intel.com> wrote:
>
> On Thu, Jan 17, 2008 at 03:04:03PM -0800, Balbir Singh wrote:
> > I think I found the root cause of the problem and a fix for it.
> > The fix works for me.
> >
>
> Thanks Balbir. But the appended fix is more clean and appropriate. Can you
> please check if it works.
> ---
>
> From Balbir Singh:
>
> > With the introduction of reserve_mattr() and free_mattr(), the ioremap*
> > routines
> > started exploiting it. The recent 2.6.24-rc8-mm1 kernel has a peculiar
> > problem
> > where in, certain devices disappear. In my case for example
> >
> > e100: Intel(R) PRO/100 Network Driver, 3. 5.23-k4-NAPI
> > e100: Copyright(c) 1999-2006 Intel Corporation
> > ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 20 (level, low) -> IRQ 20
> > modprobe:2584 conflicting cache attribute 50000000-50001000
> > uncached<->default
> > e100: 0000:04:08.0: e100_probe: Cannot map device registers, aborting.
> > ACPI: PCI interrupt for device 0000:04:08.0 disabled
> >
> > On further analysis, it was discovered that quirk_e100_interrupt() calls
> > ioremap(), which reserves memory attributes for the e100 card, but
> > iounmap()
> > does not free it.
>
> Fix the iounmap() to call free_matrr() unconditionally.
>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
>
> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>

Yes, it looks better. p->flags is always set, so the check was not doing much.
I also tested it and it works for me!

Tested-by: Balbir Singh <balbir@linux.vnet.ibm.com>

Balbir

Re: 2.6.24-rc8-mm1

[Balbir Singh]

* Andrew Morton <akpm@linux-foundation.org> [2008-01-17 10:40:21]:

> On Thu, 17 Jan 2008 18:16:22 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > * Andrew Morton <akpm@linux-foundation.org> [2008-01-17 02:35:14]:
> > 
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
> > > 
> > > - selinux is busted on one of my two selinux-enabled test machines.
> > > 
> > > - suspend-to-ram and suspend-to-disk are totally hosed on one of my test
> > >   machines.  I guess I get to bisect this.
> > > 
> > > - git-nfsd is dropped due to conflicts with git-nfs
> > > 
> > > - git-newsetup is dropped due to conflicts with git-x86 (I think)
> > > 
> > > - git-perfmon is dropped due to conflicts with git-x86 (I think)
> > > 
> > > - git-kgdb is dropped due to conflicts with git-damn-near-everything
> > > 
> > > - git-block is dropped due to conflicts with the IDE tree
> > > 
> > > - kvm probably doesn't work properly because I couldn't be bothered fixing
> > >   the conflicts between git-kvm and the driver tree
> > > 
> > > - the volume of rejects and build errors which are caused by subsystem
> > >   maintainers fiddling with other people's stuff is quite out of control. 
> > >   Something needs to happen here.
> > 
> > Hi, Andrew,
> > 
> > May be it was one of the conflicts, but my system fails to get
> > ethernet working with this version. I see
> > 
> > e100: Intel(R) PRO/100 Network Driver, 3. 5.23-k4-NAPI
> > e100: Copyright(c) 1999-2006 Intel Corporation
> > ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 20 (level, low) -> IRQ 20
> > modprobe:2584 conflicting cache attribute 50000000-50001000
> > uncached<->default
> > e100: 0000:04:08.0: e100_probe: Cannot map device registers, aborting.
> > ACPI: PCI interrupt for device 0000:04:08.0 disabled
> > e100: probe of 0000:04:08.0 failed with error -12
> > 
> > Other interesting boot information
> > 
> > Using ACPI (MADT) for SMP configuration information
> > PM: Registered nosave memory: 000000000008f000 - 00000000000a0000
> > PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
> > PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
> > PM: Registered nosave memory: 000000003e5d1000 - 000000003e6e5000
> > PM: Registered nosave memory: 000000003f574000 - 000000003f57c000
> > PM: Registered nosave memory: 000000003f62d000 - 000000003f631000
> > PM: Registered nosave memory: 000000003f6a7000 - 000000003f6e9000
> > PM: Registered nosave memory: 000000003f6ed000 - 000000003f6ff000
> > Allocating PCI resources starting at 50000000 (gap: 40000000:bff80000)
> > 
> >  PCI: Bridge: 0000:00:1c.0
> >    IO window: disabled.
> >    MEM window:
> > 0x50300000-0x503fffff
> >    PREFETCH window: disabled.
> >  PCI: Bridge: 0000:00:1c.2
> >    IO window: disabled.
> >    MEM window:
> > 0x50400000-0x504fffff
> >    PREFETCH window: disabled.
> >  PCI: Bridge: 0000:00:1c.3
> >    IO window: disabled.
> >    MEM window:
> > 0x50500000-0x505fffff
> >    PREFETCH window: disabled.
> >  PCI: Bridge: 0000:00:1e.0
> >    IO window: 1000-1fff
> >    MEM window:
> > 0x50000000-0x500fffff
> >    PREFETCH window: disabled.
> > 
> > I am yet to get down to the root cause, thought I'd report it first to
> > the x86 and ACPI list to see if someone has seen the problem before.
> > 
> 
> It appears that the new PAT code didn't like e100's pci_iomap().  Venki, can you
> take a look please?
>

I tried booting with nopat with no effect. 

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL