Re: 2.6.24-rc8-mm1
* Andrew Morton <[EMAIL PROTECTED]> [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 :04:08.0[A] -> GSI 20 (level, low) -> IRQ 20 modprobe:2584 conflicting cache attribute 5000-50001000 uncached<->default e100: :04:08.0: e100_probe: Cannot map device registers, aborting. ACPI: PCI interrupt for device :04:08.0 disabled e100: probe of :04:08.0 failed with error -12 Other interesting boot information Using ACPI (MADT) for SMP configuration information PM: Registered nosave memory: 0008f000 - 000a PM: Registered nosave memory: 000a - 000e PM: Registered nosave memory: 000e - 0010 PM: Registered nosave memory: 3e5d1000 - 3e6e5000 PM: Registered nosave memory: 3f574000 - 3f57c000 PM: Registered nosave memory: 3f62d000 - 3f631000 PM: Registered nosave memory: 3f6a7000 - 3f6e9000 PM: Registered nosave memory: 3f6ed000 - 3f6ff000 Allocating PCI resources starting at 5000 (gap: 4000:bff8) PCI: Bridge: :00:1c.0 IO window: disabled. MEM window: 0x5030-0x503f PREFETCH window: disabled. PCI: Bridge: :00:1c.2 IO window: disabled. MEM window: 0x5040-0x504f PREFETCH window: disabled. PCI: Bridge: :00:1c.3 IO window: disabled. MEM window: 0x5050-0x505f PREFETCH window: disabled. PCI: Bridge: :00:1e.0 IO window: 1000-1fff MEM window: 0x5000-0x500f 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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc8-mm1
On Thu, 17 Jan 2008 18:16:22 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > * Andrew Morton <[EMAIL PROTECTED]> [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 :04:08.0[A] -> GSI 20 (level, low) -> IRQ 20 > modprobe:2584 conflicting cache attribute 5000-50001000 > uncached<->default > e100: :04:08.0: e100_probe: Cannot map device registers, aborting. > ACPI: PCI interrupt for device :04:08.0 disabled > e100: probe of :04:08.0 failed with error -12 > > Other interesting boot information > > Using ACPI (MADT) for SMP configuration information > PM: Registered nosave memory: 0008f000 - 000a > PM: Registered nosave memory: 000a - 000e > PM: Registered nosave memory: 000e - 0010 > PM: Registered nosave memory: 3e5d1000 - 3e6e5000 > PM: Registered nosave memory: 3f574000 - 3f57c000 > PM: Registered nosave memory: 3f62d000 - 3f631000 > PM: Registered nosave memory: 3f6a7000 - 3f6e9000 > PM: Registered nosave memory: 3f6ed000 - 3f6ff000 > Allocating PCI resources starting at 5000 (gap: 4000:bff8) > > PCI: Bridge: :00:1c.0 >IO window: disabled. >MEM window: > 0x5030-0x503f >PREFETCH window: disabled. > PCI: Bridge: :00:1c.2 >IO window: disabled. >MEM window: > 0x5040-0x504f >PREFETCH window: disabled. > PCI: Bridge: :00:1c.3 >IO window: disabled. >MEM window: > 0x5050-0x505f >PREFETCH window: disabled. > PCI: Bridge: :00:1e.0 >IO window: 1000-1fff >MEM window: > 0x5000-0x500f >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? - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.24-rc8-mm1
>-Original Message- >From: Andrew Morton [mailto:[EMAIL PROTECTED] >Sent: Thursday, January 17, 2008 10:40 AM >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED]; 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 ><[EMAIL PROTECTED]> wrote: > >> * Andrew Morton <[EMAIL PROTECTED]> [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 :04:08.0[A] -> GSI 20 (level, low) -> IRQ 20 >> modprobe:2584 conflicting cache attribute 5000-50001000 >> uncached<->default >> e100: :04:08.0: e100_probe: Cannot map device registers, >aborting. >> ACPI: PCI interrupt for device :04:08.0 disabled >> e100: probe of :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 5000-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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc8-mm1
On Thu, 17 Jan 2008 11:22:19 -0800 "Pallipadi, Venkatesh" <[EMAIL PROTECTED]> wrote: > > The problem is > >> modprobe:2584 conflicting cache attribute 5000-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. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc8-mm1
* Pallipadi, Venkatesh <[EMAIL PROTECTED]> [2008-01-17 11:22:19]: > > > >-Original Message- > >From: Andrew Morton [mailto:[EMAIL PROTECTED] > >Sent: Thursday, January 17, 2008 10:40 AM > >To: [EMAIL PROTECTED] > >Cc: [EMAIL PROTECTED]; 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 > ><[EMAIL PROTECTED]> wrote: > > > >> * Andrew Morton <[EMAIL PROTECTED]> [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 :04:08.0[A] -> GSI 20 (level, low) -> IRQ 20 > >> modprobe:2584 conflicting cache attribute 5000-50001000 > >> uncached<->default > >> e100: :04:08.0: e100_probe: Cannot map device registers, > >aborting. > >> ACPI: PCI interrupt for device :04:08.0 disabled > >> e100: probe of :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 5000-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 :04:08.0[A] -> GSI 20 (level, low) -> IRQ 20 modprobe:2584 conflicting cache attribute 5000-50001000 uncached<->default e100: :04:08.0: e100_probe: Cannot map device registers, aborting. ACPI: PCI interrupt for device :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 i
Re: 2.6.24-rc8-mm1
On Thu, Jan 17, 2008 at 11:40:32AM -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 11:22:19 -0800 "Pallipadi, Venkatesh" <[EMAIL PROTECTED]>
> wrote:
>
> >
> > The problem is
> > >> modprobe:2584 conflicting cache attribute 5000-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 <[EMAIL PROTECTED]>
Index: linux-2.6.git/arch/x86/mm/ioremap.c
===
--- linux-2.6.git.orig/arch/x86/mm/ioremap.c2008-01-17 03:18:59.0
-0800
+++ linux-2.6.git/arch/x86/mm/ioremap.c 2008-01-17 08:11:51.0 -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.0
-0800
+++ linux-2.6.git/arch/x86/mm/ioremap_32.c 2008-01-17 08:10:58.0
-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.0
-0800
+++ linux-2.6.git/arch/x86/mm/ioremap_64.c 2008-01-17 08:10:13.0
-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.c2008-01-17 03:18:59.0
-0800
+++ linux-2.6.git/arch/x86/mm/pat.c 2008-01-17 08:06:23.0 -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.0
-0800
+++ linux-2.6.git/include/asm-x86/io_32.h 2008-01-17 08:09:30.0
-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",
+ offse
Re: 2.6.24-rc8-mm1
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 :04:08.0[A] -> GSI 20 (level, low) -> IRQ 20
> modprobe:2584 conflicting cache attribute 5000-50001000
> uncached<->default
> e100: :04:08.0: e100_probe: Cannot map device registers, aborting.
> ACPI: PCI interrupt for device :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 <[EMAIL PROTECTED]>
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
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);
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc8-mm1
On Jan 18, 2008 7:12 AM, Siddha, Suresh B <[EMAIL PROTECTED]> 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 :04:08.0[A] -> GSI 20 (level, low) -> IRQ 20 > > modprobe:2584 conflicting cache attribute 5000-50001000 > > uncached<->default > > e100: :04:08.0: e100_probe: Cannot map device registers, aborting. > > ACPI: PCI interrupt for device :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 <[EMAIL PROTECTED]> > > Signed-off-by: Balbir Singh <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Balbir - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc8-mm1
* Andrew Morton <[EMAIL PROTECTED]> [2008-01-17 10:40:21]: > On Thu, 17 Jan 2008 18:16:22 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > > > * Andrew Morton <[EMAIL PROTECTED]> [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 :04:08.0[A] -> GSI 20 (level, low) -> IRQ 20 > > modprobe:2584 conflicting cache attribute 5000-50001000 > > uncached<->default > > e100: :04:08.0: e100_probe: Cannot map device registers, aborting. > > ACPI: PCI interrupt for device :04:08.0 disabled > > e100: probe of :04:08.0 failed with error -12 > > > > Other interesting boot information > > > > Using ACPI (MADT) for SMP configuration information > > PM: Registered nosave memory: 0008f000 - 000a > > PM: Registered nosave memory: 000a - 000e > > PM: Registered nosave memory: 000e - 0010 > > PM: Registered nosave memory: 3e5d1000 - 3e6e5000 > > PM: Registered nosave memory: 3f574000 - 3f57c000 > > PM: Registered nosave memory: 3f62d000 - 3f631000 > > PM: Registered nosave memory: 3f6a7000 - 3f6e9000 > > PM: Registered nosave memory: 3f6ed000 - 3f6ff000 > > Allocating PCI resources starting at 5000 (gap: 4000:bff8) > > > > PCI: Bridge: :00:1c.0 > >IO window: disabled. > >MEM window: > > 0x5030-0x503f > >PREFETCH window: disabled. > > PCI: Bridge: :00:1c.2 > >IO window: disabled. > >MEM window: > > 0x5040-0x504f > >PREFETCH window: disabled. > > PCI: Bridge: :00:1c.3 > >IO window: disabled. > >MEM window: > > 0x5050-0x505f > >PREFETCH window: disabled. > > PCI: Bridge: :00:1e.0 > >IO window: 1000-1fff > >MEM window: > > 0x5000-0x500f > >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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [E1000-devel] 2.6.24-rc8-mm1
Andrew Morton wrote: > On Thu, 17 Jan 2008 11:22:19 -0800 "Pallipadi, Venkatesh" > <[EMAIL PROTECTED]> wrote: > >> >> The problem is modprobe:2584 conflicting cache attribute 5000-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. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
