From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adrian Bunk <bunk@stusta.de>
Subject: 2.6.17-rc1-mm1: why did acpi_ns_build_external_path() become global?
Date: Tue, 4 Apr 2006 18:29:55 +0200
Message-ID: <20060404162955.GN6529@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1750753AbWDDQab@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
Sender: linux-kernel-owner@vger.kernel.org
To: Andrew Morton <akpm@osdl.org>, len.brown@intel.com
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
List-Id: linux-acpi@vger.kernel.org

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.16-mm2:
> 
>  git-acpi.patch
>...
>  git trees.
>...

acpi_ns_build_external_path() became global but isn't used outside the 
file it's defined in.

Was this accidental or is a usage pending?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adrian Bunk <bunk@stusta.de>
Subject: 2.6.17-rc1-mm1: drivers/acpi/numa.c compile error
Date: Fri, 7 Apr 2006 14:27:57 +0200
Message-ID: <20060407122757.GI7118@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-acpi-owner@vger.kernel.org>
Received: from emailhub.stusta.mhn.de ([141.84.69.5]:38155 "HELO
	mailout.stusta.mhn.de") by vger.kernel.org with SMTP
	id S964783AbWDGM17 (ORCPT <rfc822;linux-acpi@vger.kernel.org>);
	Fri, 7 Apr 2006 08:27:59 -0400
Content-Disposition: inline
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
Sender: linux-acpi-owner@vger.kernel.org
List-Id: linux-acpi@vger.kernel.org
To: Andrew Morton <akpm@osdl.org>, len.brown@intel.com
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org

I'm getting the following compile error with CONFIG_ACPI_NUMA=y:

<--  snip  -->

...
  CC      drivers/acpi/numa.o
drivers/acpi/numa.c: In function 'acpi_numa_init':
drivers/acpi/numa.c:231: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)
drivers/acpi/numa.c:231: error: (Each undeclared identifier is reported only once
drivers/acpi/numa.c:231: error: for each function it appears in.)
make[2]: *** [drivers/acpi/numa.o] Error 1

<--  snip  -->

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Morton <akpm@osdl.org>
Subject: Re: 2.6.17-rc1-mm1: drivers/acpi/numa.c compile error
Date: Fri, 7 Apr 2006 13:59:37 -0700
Message-ID: <20060407135937.56a84d44.akpm@osdl.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060407122757.GI7118@stusta.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-path: <linux-acpi-owner@vger.kernel.org>
Received: from smtp.osdl.org ([65.172.181.4]:62378 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S964843AbWDGVA2 (ORCPT
	<rfc822;linux-acpi@vger.kernel.org>); Fri, 7 Apr 2006 17:00:28 -0400
In-Reply-To: <20060407122757.GI7118@stusta.de>
Sender: linux-acpi-owner@vger.kernel.org
List-Id: linux-acpi@vger.kernel.org
To: Adrian Bunk <bunk@stusta.de>
Cc: len.brown@intel.com, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, Yasunori Goto <y-goto@jp.fujitsu.com>

Adrian Bunk <bunk@stusta.de> wrote:
>
> I'm getting the following compile error with CONFIG_ACPI_NUMA=y:
> 
> <--  snip  -->
> 
> ...
>   CC      drivers/acpi/numa.o
> drivers/acpi/numa.c: In function 'acpi_numa_init':
> drivers/acpi/numa.c:231: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)

I'm not quite sure how we managed that, but I guess
unify-pxm_to_node-and-node_to_pxm.patch triggered it?

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adrian Bunk <bunk@stusta.de>
Subject: Re: 2.6.17-rc1-mm1: drivers/acpi/numa.c compile error
Date: Sun, 9 Apr 2006 17:44:46 +0200
Message-ID: <20060409154446.GE8454@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060407122757.GI7118@stusta.de> <20060407135937.56a84d44.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-acpi-owner@vger.kernel.org>
Received: from emailhub.stusta.mhn.de ([141.84.69.5]:43013 "HELO
	mailout.stusta.mhn.de") by vger.kernel.org with SMTP
	id S1750797AbWDIPor (ORCPT <rfc822;linux-acpi@vger.kernel.org>);
	Sun, 9 Apr 2006 11:44:47 -0400
Content-Disposition: inline
In-Reply-To: <20060407135937.56a84d44.akpm@osdl.org>
Sender: linux-acpi-owner@vger.kernel.org
List-Id: linux-acpi@vger.kernel.org
To: Andrew Morton <akpm@osdl.org>
Cc: len.brown@intel.com, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, Yasunori Goto <y-goto@jp.fujitsu.com>, tony.luck@intel.com, Andi Kleen <ak@muc.de>, Dave Hansen <haveblue@us.ibm.com>

On Fri, Apr 07, 2006 at 01:59:37PM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > I'm getting the following compile error with CONFIG_ACPI_NUMA=y:
> > 
> > <--  snip  -->
> > 
> > ...
> >   CC      drivers/acpi/numa.o
> > drivers/acpi/numa.c: In function 'acpi_numa_init':
> > drivers/acpi/numa.c:231: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)
> 
> I'm not quite sure how we managed that, but I guess
> unify-pxm_to_node-and-node_to_pxm.patch triggered it?

Yes, obviously (I got this error on i386):

 config ACPI_NUMA
        bool "NUMA support"
        depends on NUMA
-       depends on (IA64 || X86_64)
+       depends on (X86_32 || IA64 || X86_64)
        default y if IA64_GENERIC || IA64_SGI_SN2


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Randy.Dunlap" <rdunlap@xenotime.net>
Subject: Re: 2.6.17-rc1-mm1: drivers/acpi/numa.c compile error
Date: Sun, 9 Apr 2006 08:57:08 -0700
Message-ID: <20060409085708.6ed19e81.rdunlap@xenotime.net>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060407122757.GI7118@stusta.de>
	<20060407135937.56a84d44.akpm@osdl.org>
	<20060409154446.GE8454@stusta.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-path: <linux-acpi-owner@vger.kernel.org>
Received: from xenotime.net ([66.160.160.81]:16779 "HELO xenotime.net")
	by vger.kernel.org with SMTP id S1750781AbWDIPyu (ORCPT
	<rfc822;linux-acpi@vger.kernel.org>); Sun, 9 Apr 2006 11:54:50 -0400
Received: from midway.site ([71.111.157.99]) by xenotime.net for <linux-acpi@vger.kernel.org>; Sun, 9 Apr 2006 08:54:48 -0700
In-Reply-To: <20060409154446.GE8454@stusta.de>
Sender: linux-acpi-owner@vger.kernel.org
List-Id: linux-acpi@vger.kernel.org
To: Adrian Bunk <bunk@stusta.de>
Cc: akpm@osdl.org, len.brown@intel.com, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, y-goto@jp.fujitsu.com, tony.luck@intel.com, ak@muc.de, haveblue@us.ibm.com

On Sun, 9 Apr 2006 17:44:46 +0200 Adrian Bunk wrote:

> On Fri, Apr 07, 2006 at 01:59:37PM -0700, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > I'm getting the following compile error with CONFIG_ACPI_NUMA=y:
> > > 
> > > <--  snip  -->
> > > 
> > > ...
> > >   CC      drivers/acpi/numa.o
> > > drivers/acpi/numa.c: In function 'acpi_numa_init':
> > > drivers/acpi/numa.c:231: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)
> > 
> > I'm not quite sure how we managed that, but I guess
> > unify-pxm_to_node-and-node_to_pxm.patch triggered it?
> 
> Yes, obviously (I got this error on i386):
> 
>  config ACPI_NUMA
>         bool "NUMA support"
>         depends on NUMA
> -       depends on (IA64 || X86_64)
> +       depends on (X86_32 || IA64 || X86_64)
>         default y if IA64_GENERIC || IA64_SGI_SN2

The new/fixed line should just be
	depends on X86 || IA64
since X86_32 and X86_64 both set X86.

---
~Randy

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Luck, Tony" <tony.luck@intel.com>
Date: Tue, 04 Apr 2006 23:38:51 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060404233851.GA6411@agluck-lia64.sc.intel.com>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> - VGA on ia64 is broken - the screen comes up blank.  But ia64 otherwise
>   seems to work OK.  I didn't have time to investigate.

Broken in base 2.6.17-rc1 too :-(  VGA comes up and prints a
few messages, and then goes wonky and dies.  Comparing
what I _think_ I saw with the dmesg output, it appears to
die here:

[    6.416740] ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 18 (level, low) -> IRQ 48
[    6.708439] e1000: 0000:01:00.0: e1000_probe: (PCI:33MHz:32-bit) 00:03:47:fd:bb:42
[    6.754439] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
[    6.761547] netconsole: not configured, aborting
[    6.766195] initcall at 0xa0000001007c4c30: init_netconsole+0x0/0x140(): returned with error code -22
[    6.775520] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2

    DEAD DEAD DEAD

Should have gone on to say:
[    6.781924] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[    6.790052] ICH4: IDE controller at PCI slot 0000:00:1f.1
[    6.795513] PCI: Device 0000:00:1f.1 not available because of resource collisions
[    6.803100] ACPI: PCI Interrupt 0000:00:1f.1[A]: no GSI
[    6.808403] ICH4: BIOS configuration fixed.
[    6.812646] ICH4: chipset revision 1
[    6.816271] ICH4: not 100% native mode: will probe irqs later


But I might be off by a line or two, the last bit flashed by quite quickly.

I'll start bisecting tomorrow to see when it was broken.

-Tony

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Zou Nan hai <nanhai.zou@intel.com>
Date: Wed, 05 Apr 2006 02:05:06 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <1144202706.3197.11.camel@linux-znh>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
	 <20060404233851.GA6411@agluck-lia64.sc.intel.com>
In-Reply-To: <20060404233851.GA6411@agluck-lia64.sc.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

On Wed, 2006-04-05 at 07:38, Luck, Tony wrote:
> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> > - VGA on ia64 is broken - the screen comes up blank.  But ia64 otherwise
> >   seems to work OK.  I didn't have time to investigate.
> 
> Broken in base 2.6.17-rc1 too :-(  VGA comes up and prints a
> few messages, and then goes wonky and dies.  Comparing
> what I _think_ I saw with the dmesg output, it appears to
> die here:
> 

The wild VGA comes from the patch which changed ioremap.

Now ioremap would not remap memory to region 6 unless that memory is
marked as EFI_MEMORY_UC by EFI.

Unfortunately on the Tiger Machine, VGA ram base was marked as
EFI_MEMORY_WB instead of EFI_MEMORY_UC...

So you can see the problem disappear if change VGA_MAP_MEM to use
ioremap_nocache.

But I am not quite sure if we can fully trust EFI on this attribute.

Zou Nan hai

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Date: Wed, 05 Apr 2006 16:15:34 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <200604051015.34217.bjorn.helgaas@hp.com>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404233851.GA6411@agluck-lia64.sc.intel.com> <1144202706.3197.11.camel@linux-znh>
In-Reply-To: <1144202706.3197.11.camel@linux-znh>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Zou Nan hai <nanhai.zou@intel.com>
Cc: "Luck, Tony" <tony.luck@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

On Tuesday 04 April 2006 20:05, Zou Nan hai wrote:
> On Wed, 2006-04-05 at 07:38, Luck, Tony wrote:
> > On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> > > - VGA on ia64 is broken - the screen comes up blank.  But ia64 otherwise
> > >   seems to work OK.  I didn't have time to investigate.
> > 
> > Broken in base 2.6.17-rc1 too :-(  VGA comes up and prints a
> > few messages, and then goes wonky and dies.  Comparing
> > what I _think_ I saw with the dmesg output, it appears to
> > die here:
> 
> The wild VGA comes from the patch which changed ioremap.
> 
> Now ioremap would not remap memory to region 6 unless that memory is
> marked as EFI_MEMORY_UC by EFI.
> 
> Unfortunately on the Tiger Machine, VGA ram base was marked as
> EFI_MEMORY_WB instead of EFI_MEMORY_UC...
> 
> So you can see the problem disappear if change VGA_MAP_MEM to use
> ioremap_nocache.
> 
> But I am not quite sure if we can fully trust EFI on this attribute.

Huh.  Intel firmware used to just not mention the VGA framebuffer
(0xa0000-0xc0000) at all in the EFI memory map.  I think that was
clearly a bug.  So maybe they fixed that by marking it WB (and
hopefully UC as well).

Tiger might support WB to the VGA framebuffer, but I don't think it
make much sense for us to use it that way.  If we did, writes to the
framebuffer would just sit in the cache until forced out by something
else.  Probably using WC would be the best, but we don't have a good
interface for that yet.

Tony, if you agree with this analysis and haven't fixed it yet, here's
a trivial patch.


[IA64] always map VGA framebuffer UC, even if it supports WB

EFI on some machines, e.g., Intel Tiger, reports that the VGA framebuffer
supports WB access.  ioremap() prefers WB when possible, so it can work
when mapping main memory.

But it doesn't make sense to map a framebuffer WB, because the driver
doesn't flush explicitly, so updates won't make it to the device
immediately.

This is due to Zou Nan hai <nanhai.zou@intel.com>.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: work-mm5/include/asm-ia64/vga.h
=================================--- work-mm5.orig/include/asm-ia64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-ia64/vga.h	2006-04-05 09:57:55.000000000 -0600
@@ -17,7 +17,7 @@
 extern unsigned long vga_console_iobase;
 extern unsigned long vga_console_membase;
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x)	((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Luck, Tony" <tony.luck@intel.com>
Date: Wed, 05 Apr 2006 21:17:57 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404233851.GA6411@agluck-lia64.sc.intel.com> <1144202706.3197.11.camel@linux-znh> <200604051015.34217.bjorn.helgaas@hp.com>
In-Reply-To: <200604051015.34217.bjorn.helgaas@hp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> Huh.  Intel firmware used to just not mention the VGA framebuffer
> (0xa0000-0xc0000) at all in the EFI memory map.  I think that was
> clearly a bug.  So maybe they fixed that by marking it WB (and
> hopefully UC as well).

Nope ... not fixed (at least not in the f/w that I'm running). The
VGA buffer is still simply not mentioned in the EFI memory map.

The problem looks to come from this code in vgacon.c:

	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
	vga_vram_size = vga_vram_end - vga_vram_base;

vga_vram_base is 0xb8000, and this call gets a UC return of
c0000000000b8000.  But vga_vram_end is 0xc0000 ... which is
the address of the start of a block of memory that is both
WB and UC capable.  So ioremap() gives us e0000000000c0000
(which means that vga_vram_size is 2000000000008000, surely
the biggest, baddest video card in the history of the world!).

Perhaps the right fix is to subtract 1 from vga_vram_end and pass
that into VGA_MAP_MEM(), and then add the 1 byte back when computing
the size?  But I don't know whether that might do something bad on
some other architecture that uses vgacon.c.  If this is not
acceptable, then we can fall back and use the Nanhai/Bjorn fix
of using ioremap_nocache().

Signed-off-by: Tony Luck <tony.luck@intel.com>

---

diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index d5a04b6..4ca9877 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -484,8 +484,8 @@ #endif
 	}
 
 	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
-	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
-	vga_vram_size = vga_vram_end - vga_vram_base;
+	vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1);
+	vga_vram_size = vga_vram_end - vga_vram_base + 1;
 
 	/*
 	 *      Find out if there is a graphics card present.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Morton <akpm@osdl.org>
Date: Wed, 05 Apr 2006 21:37:27 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060405143727.2b2fde15.akpm@osdl.org>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404233851.GA6411@agluck-lia64.sc.intel.com>
	<1144202706.3197.11.camel@linux-znh>
	<200604051015.34217.bjorn.helgaas@hp.com>
	<20060405211757.GA8536@agluck-lia64.sc.intel.com>
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "Luck, Tony" <tony.luck@intel.com>
Cc: bjorn.helgaas@hp.com, nanhai.zou@intel.com, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, "Antonino A. Daplas" <adaplas@pol.net>

"Luck, Tony" <tony.luck@intel.com> wrote:
>
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh.  Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map.  I think that was
> > clearly a bug.  So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
> 
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
> 
> The problem looks to come from this code in vgacon.c:
> 
> 	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> 	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> 	vga_vram_size = vga_vram_end - vga_vram_base;
> 
> vga_vram_base is 0xb8000, and this call gets a UC return of
> c0000000000b8000.  But vga_vram_end is 0xc0000 ... which is
> the address of the start of a block of memory that is both
> WB and UC capable.

OK, so it's really an off-by-one error.

>  So ioremap() gives us e0000000000c0000
> (which means that vga_vram_size is 2000000000008000, surely
> the biggest, baddest video card in the history of the world!).
> 
> Perhaps the right fix is to subtract 1 from vga_vram_end and pass
> that into VGA_MAP_MEM(), and then add the 1 byte back when computing
> the size?  But I don't know whether that might do something bad on
> some other architecture that uses vgacon.c.  If this is not
> acceptable, then we can fall back and use the Nanhai/Bjorn fix
> of using ioremap_nocache().
> 
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> 
> ---
> 
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index d5a04b6..4ca9877 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -484,8 +484,8 @@ #endif
>  	}
>  
>  	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> -	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> -	vga_vram_size = vga_vram_end - vga_vram_base;
> +	vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1);
> +	vga_vram_size = vga_vram_end - vga_vram_base + 1;
>  
>  	/*
>  	 *      Find out if there is a graphics card present.

Looks like the correct fix to me.

Tony (D), can you think of any problems with that approach?

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andreas Schwab <schwab@suse.de>
Date: Wed, 05 Apr 2006 21:39:16 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <jer74b7ldn.fsf@sykes.suse.de>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404233851.GA6411@agluck-lia64.sc.intel.com>
	<1144202706.3197.11.camel@linux-znh>
	<200604051015.34217.bjorn.helgaas@hp.com>
	<20060405211757.GA8536@agluck-lia64.sc.intel.com>
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com> (Tony Luck's
	message of "Wed, 5 Apr 2006 14:17:57 -0700")
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>, Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

"Luck, Tony" <tony.luck@intel.com> writes:

> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgaco=
n.c
> index d5a04b6..4ca9877 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -484,8 +484,8 @@ #endif
>  	}
> =20
>  	vga_vram_base =3D VGA_MAP_MEM(vga_vram_base);
> -	vga_vram_end =3D VGA_MAP_MEM(vga_vram_end);
> -	vga_vram_size =3D vga_vram_end - vga_vram_base;
> +	vga_vram_end =3D VGA_MAP_MEM(vga_vram_end - 1);
> +	vga_vram_size =3D vga_vram_end - vga_vram_base + 1;

Better use vga_vram_end =3D VGA_MAP_MEM(vga_vram_end - 1) + 1, or you'll
screw up the other computations using vga_vram_end.

Andreas.

--=20
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Date: Wed, 05 Apr 2006 22:01:08 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <200604051601.08776.bjorn.helgaas@hp.com>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com>
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

On Wednesday 05 April 2006 15:17, Luck, Tony wrote:
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh.  Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map.  I think that was
> > clearly a bug.  So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
> 
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
> 
> The problem looks to come from this code in vgacon.c:
> 
> 	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> 	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> 	vga_vram_size = vga_vram_end - vga_vram_base;
> 
> vga_vram_base is 0xb8000, and this call gets a UC return of
> c0000000000b8000.  But vga_vram_end is 0xc0000 ... which is
> the address of the start of a block of memory that is both
> WB and UC capable.  So ioremap() gives us e0000000000c0000
> (which means that vga_vram_size is 2000000000008000, surely
> the biggest, baddest video card in the history of the world!).
> 
> Perhaps the right fix is to subtract 1 from vga_vram_end and pass
> that into VGA_MAP_MEM(), and then add the 1 byte back when computing
> the size?  But I don't know whether that might do something bad on
> some other architecture that uses vgacon.c.

I think the VGA_MAP_MEM(vga_vram_end) is just bogus -- it's not
that we need to map the memory starting at vga_vram_end.  I think
it would cleaner (though much more intrusive) to do something like
the patch below, which basically just hard-codes (base, size)
rather than (base, end).

> If this is not 
> acceptable, then we can fall back and use the Nanhai/Bjorn fix
> of using ioremap_nocache().

Regardless of how we solve the vga_vram_size issue, I still think
ioremap_nocache() is more appropriate in this case.  A framebuffer
won't work like we expect if it's mapped WB, will it?

(The patch below assumes the ioremap_nocache change precedes it.)


[PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use

VGA_MAP_MEM translates to ioremap() on some architectures.  It
makes sense to do this to vga_vram_base, because we're going to
access memory between vga_vram_base and vga_vram_end.

But it doesn't really make sense to map starting at vga_vram_end,
because we aren't going to access memory starting there.  On ia64,
which always has to be different, ioremapping vga_vram_end gives
you something completely incompatible with ioremapped vga_vram_start,
so vga_vram_size ends up being nonsense.

As a bonus, we often know the size up front, so we can use ioremap()
correctly, rather than giving it a zero size.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: work-mm5/drivers/video/console/vgacon.c
=================================--- work-mm5.orig/drivers/video/console/vgacon.c	2006-04-03 15:04:48.000000000 -0600
+++ work-mm5/drivers/video/console/vgacon.c	2006-04-05 15:48:37.000000000 -0600
@@ -391,7 +391,7 @@
 			static struct resource ega_console_resource  			    { .name = "ega", .start = 0x3B0, .end = 0x3BF };
 			vga_video_type = VIDEO_TYPE_EGAM;
-			vga_vram_end = 0xb8000;
+			vga_vram_size = 0x8000;
 			display_desc = "EGA+";
 			request_resource(&ioport_resource,
 					 &ega_console_resource);
@@ -401,7 +401,7 @@
 			static struct resource mda2_console_resource  			    { .name = "mda", .start = 0x3BF, .end = 0x3BF };
 			vga_video_type = VIDEO_TYPE_MDA;
-			vga_vram_end = 0xb2000;
+			vga_vram_size = 0x2000;
 			display_desc = "*MDA";
 			request_resource(&ioport_resource,
 					 &mda1_console_resource);
@@ -418,7 +418,7 @@
 		if ((ORIG_VIDEO_EGA_BX & 0xff) != 0x10) {
 			int i;
 
-			vga_vram_end = 0xc0000;
+			vga_vram_size = 0x8000;
 
 			if (!ORIG_VIDEO_ISVGA) {
 				static struct resource ega_console_resource
@@ -443,7 +443,7 @@
 				 * and COE=1 isn't necessarily a good idea)
 				 */
 				vga_vram_base = 0xa0000;
-				vga_vram_end = 0xb0000;
+				vga_vram_size = 0x10000;
 				outb_p(6, VGA_GFX_I);
 				outb_p(6, VGA_GFX_D);
 #endif
@@ -475,7 +475,7 @@
 			static struct resource cga_console_resource  			    { .name = "cga", .start = 0x3D4, .end = 0x3D5 };
 			vga_video_type = VIDEO_TYPE_CGA;
-			vga_vram_end = 0xba000;
+			vga_vram_size = 0x2000;
 			display_desc = "*CGA";
 			request_resource(&ioport_resource,
 					 &cga_console_resource);
@@ -483,9 +483,8 @@
 		}
 	}
 
-	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
-	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
-	vga_vram_size = vga_vram_end - vga_vram_base;
+	vga_vram_base = VGA_MAP_MEM(vga_vram_base, vga_vram_size);
+	vga_vram_end = vga_vram_base + vga_vram_size;
 
 	/*
 	 *      Find out if there is a graphics card present.
@@ -1020,14 +1019,14 @@
 	char *charmap;
 	
 	if (vga_video_type != VIDEO_TYPE_EGAM) {
-		charmap = (char *) VGA_MAP_MEM(colourmap);
+		charmap = (char *) VGA_MAP_MEM(colourmap, 0);
 		beg = 0x0e;
 #ifdef VGA_CAN_DO_64KB
 		if (vga_video_type = VIDEO_TYPE_VGAC)
 			beg = 0x06;
 #endif
 	} else {
-		charmap = (char *) VGA_MAP_MEM(blackwmap);
+		charmap = (char *) VGA_MAP_MEM(blackwmap, 0);
 		beg = 0x0a;
 	}
 
Index: work-mm5/include/asm-alpha/vga.h
=================================--- work-mm5.orig/include/asm-alpha/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-alpha/vga.h	2006-04-05 15:42:35.000000000 -0600
@@ -46,6 +46,6 @@
 #define vga_readb(a)	readb((u8 __iomem *)(a))
 #define vga_writeb(v,a)	writeb(v, (u8 __iomem *)(a))
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap(x, 0))
+#define VGA_MAP_MEM(x,s)	((unsigned long) ioremap(x, s))
 
 #endif
Index: work-mm5/include/asm-arm/vga.h
=================================--- work-mm5.orig/include/asm-arm/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-arm/vga.h	2006-04-05 15:42:21.000000000 -0600
@@ -4,7 +4,7 @@
 #include <asm/hardware.h>
 #include <asm/io.h>
 
-#define VGA_MAP_MEM(x)	(PCIMEM_BASE + (x))
+#define VGA_MAP_MEM(x,s)	(PCIMEM_BASE + (x))
 
 #define vga_readb(x)	(*((volatile unsigned char *)x))
 #define vga_writeb(x,y)	(*((volatile unsigned char *)y) = (x))
Index: work-mm5/include/asm-i386/vga.h
=================================--- work-mm5.orig/include/asm-i386/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-i386/vga.h	2006-04-05 15:42:49.000000000 -0600
@@ -12,7 +12,7 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-ia64/vga.h
=================================--- work-mm5.orig/include/asm-ia64/vga.h	2006-04-05 09:57:55.000000000 -0600
+++ work-mm5/include/asm-ia64/vga.h	2006-04-05 15:43:09.000000000 -0600
@@ -17,7 +17,7 @@
 extern unsigned long vga_console_iobase;
 extern unsigned long vga_console_membase;
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x,s)	((unsigned long) ioremap_nocache(vga_console_membase + (x), s))
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/include/asm-m32r/vga.h
=================================--- work-mm5.orig/include/asm-m32r/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-m32r/vga.h	2006-04-05 15:43:22.000000000 -0600
@@ -14,7 +14,7 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-mips/vga.h
=================================--- work-mm5.orig/include/asm-mips/vga.h	2006-03-23 10:22:17.000000000 -0700
+++ work-mm5/include/asm-mips/vga.h	2006-04-05 15:43:32.000000000 -0600
@@ -13,7 +13,7 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x)	(0xb0000000L + (unsigned long)(x))
+#define VGA_MAP_MEM(x,s)	(0xb0000000L + (unsigned long)(x))
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/include/asm-powerpc/vga.h
=================================--- work-mm5.orig/include/asm-powerpc/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-powerpc/vga.h	2006-04-05 15:43:57.000000000 -0600
@@ -42,9 +42,9 @@
 extern unsigned long vgacon_remap_base;
 
 #ifdef __powerpc64__
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap((x), 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
 #else
-#define VGA_MAP_MEM(x) (x + vgacon_remap_base)
+#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
 #endif
 
 #define vga_readb(x) (*(x))
Index: work-mm5/include/asm-sparc64/vga.h
=================================--- work-mm5.orig/include/asm-sparc64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-sparc64/vga.h	2006-04-05 15:44:08.000000000 -0600
@@ -28,6 +28,6 @@
 	return *addr;
 }
 
-#define VGA_MAP_MEM(x) (x)
+#define VGA_MAP_MEM(x,s) (x)
 
 #endif
Index: work-mm5/include/asm-x86_64/vga.h
=================================--- work-mm5.orig/include/asm-x86_64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-x86_64/vga.h	2006-04-05 15:44:18.000000000 -0600
@@ -12,7 +12,7 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-xtensa/vga.h
=================================--- work-mm5.orig/include/asm-xtensa/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-xtensa/vga.h	2006-04-05 15:44:31.000000000 -0600
@@ -11,7 +11,7 @@
 #ifndef _XTENSA_VGA_H
 #define _XTENSA_VGA_H
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/drivers/video/console/mdacon.c
=================================--- work-mm5.orig/drivers/video/console/mdacon.c	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/drivers/video/console/mdacon.c	2006-04-05 15:46:33.000000000 -0600
@@ -313,8 +313,8 @@
 	mda_num_columns = 80;
 	mda_num_lines   = 25;
 
-	mda_vram_base = VGA_MAP_MEM(0xb0000);
 	mda_vram_len  = 0x01000;
+	mda_vram_base = VGA_MAP_MEM(0xb0000, mda_vram_len);
 
 	mda_index_port  = 0x3b4;
 	mda_value_port  = 0x3b5;
Index: work-mm5/drivers/video/vga16fb.c
=================================--- work-mm5.orig/drivers/video/vga16fb.c	2006-03-23 10:22:16.000000000 -0700
+++ work-mm5/drivers/video/vga16fb.c	2006-04-05 15:49:34.000000000 -0600
@@ -1351,7 +1351,7 @@
 	}
 
 	/* XXX share VGA_FB_PHYS and I/O region with vgacon and others */
-	info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS);
+	info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS, 0);
 
 	if (!info->screen_base) {
 		printk(KERN_ERR "vga16fb: unable to map device\n");

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Luck, Tony" <tony.luck@intel.com>
Date: Wed, 05 Apr 2006 22:50:30 +0000
Subject: RE: 2.6.17-rc1-mm1
Message-Id: <B8E391BBE9FE384DAA4C5C003888BE6F06290233@scsmsx401.amr.corp.intel.com>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404233851.GA6411@agluck-lia64.sc.intel.com>
In-Reply-To: <20060404233851.GA6411@agluck-lia64.sc.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Zou, Nanhai" <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

> I think the VGA_MAP_MEM(vga_vram_end) is just bogus -- it's not
> that we need to map the memory starting at vga_vram_end.  I think
> it would cleaner (though much more intrusive) to do something like
> the patch below, which basically just hard-codes (base, size)
> rather than (base, end).

This patch works for me on ia64/Tiger

-Tony

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Antonino A. Daplas" <adaplas@gmail.com>
Date: Thu, 06 Apr 2006 01:49:55 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <443473C3.4050807@gmail.com>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com> <200604051601.08776.bjorn.helgaas@hp.com>
In-Reply-To: <200604051601.08776.bjorn.helgaas@hp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Luck, Tony" <tony.luck@intel.com>, Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

Bjorn Helgaas wrote:
> On Wednesday 05 April 2006 15:17, Luck, Tony wrote:
>> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:

> [PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use
> 
> VGA_MAP_MEM translates to ioremap() on some architectures.  It
> makes sense to do this to vga_vram_base, because we're going to
> access memory between vga_vram_base and vga_vram_end.
> 
> But it doesn't really make sense to map starting at vga_vram_end,
> because we aren't going to access memory starting there.  On ia64,
> which always has to be different, ioremapping vga_vram_end gives
> you something completely incompatible with ioremapped vga_vram_start,
> so vga_vram_size ends up being nonsense.
> 
> As a bonus, we often know the size up front, so we can use ioremap()
> correctly, rather than giving it a zero size.

I definitely prefer this patch.

> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Antonino Daplas <adaplas@pol.net>

Tony

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Russell King <rmk+lkml@arm.linux.org.uk>
Date: Thu, 06 Apr 2006 10:16:05 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060406101604.GA28056@flint.arm.linux.org.uk>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404233851.GA6411@agluck-lia64.sc.intel.com> <1144202706.3197.11.camel@linux-znh> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com>
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>, Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

On Wed, Apr 05, 2006 at 02:17:57PM -0700, Luck, Tony wrote:
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh.  Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map.  I think that was
> > clearly a bug.  So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
> 
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
> 
> The problem looks to come from this code in vgacon.c:
> 
> 	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> 	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> 	vga_vram_size = vga_vram_end - vga_vram_base;

Wouldn't it be better to do:

	vga_vram_size = vga_vram_end - vga_vram_base;
	vga_vram_base = VGA_IOREMAP(vga_vram_base, vga_vram_size);
	vga_vram_end = vga_vram_base + vga_vram_size;

and for compatibility:

#define VGA_IOREMAP(base,size)	VGA_MAP_MEM(base)

?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Russell King <rmk+lkml@arm.linux.org.uk>
Date: Thu, 06 Apr 2006 10:21:54 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060406102154.GB28056@flint.arm.linux.org.uk>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com> <200604051601.08776.bjorn.helgaas@hp.com>
In-Reply-To: <200604051601.08776.bjorn.helgaas@hp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Luck, Tony" <tony.luck@intel.com>, Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

On Wed, Apr 05, 2006 at 04:01:08PM -0600, Bjorn Helgaas wrote:
> [PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use

Ah, seems to be what I just suggested...

> @@ -1020,14 +1019,14 @@
>  	char *charmap;
>  	
>  	if (vga_video_type != VIDEO_TYPE_EGAM) {
> -		charmap = (char *) VGA_MAP_MEM(colourmap);
> +		charmap = (char *) VGA_MAP_MEM(colourmap, 0);

Don't like this though - can't we pass a real size here rather than zero?
There seems to be several clues as to the maximum size:

#define cmapsz 8192

        if (!vga_font_is_default)
                charmap += 4 * cmapsz;

                        charmap += 2 * cmapsz;
                                for (i = 0; i < cmapsz; i++)
                                        vga_writeb(arg[i], charmap + i);

so that's about 7 * cmapsz - call that 8 for completeness, which is 64K.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Russell King <rmk+lkml@arm.linux.org.uk>
Date: Thu, 06 Apr 2006 10:34:27 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060406103427.GC28056@flint.arm.linux.org.uk>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com> <200604051601.08776.bjorn.helgaas@hp.com> <20060406102154.GB28056@flint.arm.linux.org.uk>
In-Reply-To: <20060406102154.GB28056@flint.arm.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Bjorn Helgaas <bjorn.helgaas@hp.com>, "Luck, Tony" <tony.luck@intel.com>, Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

On Thu, Apr 06, 2006 at 11:21:54AM +0100, Russell King wrote:
> On Wed, Apr 05, 2006 at 04:01:08PM -0600, Bjorn Helgaas wrote:
> > [PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use
> 
> Ah, seems to be what I just suggested...
> 
> > @@ -1020,14 +1019,14 @@
> >  	char *charmap;
> >  	
> >  	if (vga_video_type != VIDEO_TYPE_EGAM) {
> > -		charmap = (char *) VGA_MAP_MEM(colourmap);
> > +		charmap = (char *) VGA_MAP_MEM(colourmap, 0);
> 
> Don't like this though - can't we pass a real size here rather than zero?
> There seems to be several clues as to the maximum size:
> 
> #define cmapsz 8192
> 
>         if (!vga_font_is_default)
>                 charmap += 4 * cmapsz;
> 
>                         charmap += 2 * cmapsz;
>                                 for (i = 0; i < cmapsz; i++)
>                                         vga_writeb(arg[i], charmap + i);
> 
> so that's about 7 * cmapsz - call that 8 for completeness, which is 64K.

Oh, and obviously, can we also have a VGA_UNMAP_MEM() macro as well please?
8)  IOW, something like this (which I cobbled together from your patch, some
of it by hand-edits - couldn't get it to apply cleanly to current -git.)

diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -391,7 +391,7 @@ static const char __init *vgacon_startup
 			static struct resource ega_console_resource  			    { .name = "ega", .start = 0x3B0, .end = 0x3BF };
 			vga_video_type = VIDEO_TYPE_EGAM;
-			vga_vram_end = 0xb8000;
+			vga_vram_size = 0x8000;
 			display_desc = "EGA+";
 			request_resource(&ioport_resource,
 					 &ega_console_resource);
@@ -401,7 +401,7 @@ static const char __init *vgacon_startup
 			static struct resource mda2_console_resource  			    { .name = "mda", .start = 0x3BF, .end = 0x3BF };
 			vga_video_type = VIDEO_TYPE_MDA;
-			vga_vram_end = 0xb2000;
+			vga_vram_size = 0x2000;
 			display_desc = "*MDA";
 			request_resource(&ioport_resource,
 					 &mda1_console_resource);
@@ -418,7 +418,7 @@ static const char __init *vgacon_startup
 		if ((ORIG_VIDEO_EGA_BX & 0xff) != 0x10) {
 			int i;
 
-			vga_vram_end = 0xc0000;
+			vga_vram_size = 0x8000;
 
 			if (!ORIG_VIDEO_ISVGA) {
 				static struct resource ega_console_resource
@@ -443,7 +443,7 @@ static const char __init *vgacon_startup
 				 * and COE=1 isn't necessarily a good idea)
 				 */
 				vga_vram_base = 0xa0000;
-				vga_vram_end = 0xb0000;
+				vga_vram_size = 0x10000;
 				outb_p(6, VGA_GFX_I);
 				outb_p(6, VGA_GFX_D);
 #endif
@@ -475,7 +475,7 @@ static const char __init *vgacon_startup
 			static struct resource cga_console_resource  			    { .name = "cga", .start = 0x3D4, .end = 0x3D5 };
 			vga_video_type = VIDEO_TYPE_CGA;
-			vga_vram_end = 0xba000;
+			vga_vram_size = 0x2000;
 			display_desc = "*CGA";
 			request_resource(&ioport_resource,
 					 &cga_console_resource);
@@ -483,9 +483,8 @@ static const char __init *vgacon_startup
 		}
 	}
 
-	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
-	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
-	vga_vram_size = vga_vram_end - vga_vram_base;
+	vga_vram_base = VGA_MAP_MEM(vga_vram_base, vga_vram_size);
+	vga_vram_end = vga_vram_base + vga_vram_size;
 
 	/*
 	 *      Find out if there is a graphics card present.
@@ -1020,14 +1019,14 @@ static int vgacon_do_font_op(struct vgas
 	char *charmap;
 	
 	if (vga_video_type != VIDEO_TYPE_EGAM) {
-		charmap = (char *) VGA_MAP_MEM(colourmap);
+		charmap = (char *) VGA_MAP_MEM(colourmap, 8 * cmapsz);
 		beg = 0x0e;
 #ifdef VGA_CAN_DO_64KB
 		if (vga_video_type = VIDEO_TYPE_VGAC)
 			beg = 0x06;
 #endif
 	} else {
-		charmap = (char *) VGA_MAP_MEM(blackwmap);
+		charmap = (char *) VGA_MAP_MEM(blackwmap, 8 * cmapsz);
 		beg = 0x0a;
 	}
 
@@ -1102,6 +1101,8 @@ static int vgacon_do_font_op(struct vgas
 		}
 	}
 
+	VGA_UNMAP_MEM(charmap, 8 * cmapsz);
+
 	spin_lock_irq(&vga_lock);
 	/* First, the sequencer, Synchronous reset */
 	vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x01);	
Index: work-mm5/include/asm-alpha/vga.h
=================================--- work-mm5.orig/include/asm-alpha/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-alpha/vga.h	2006-04-05 15:42:35.000000000 -0600
@@ -46,6 +46,7 @@
 #define vga_readb(a)	readb((u8 __iomem *)(a))
 #define vga_writeb(v,a)	writeb(v, (u8 __iomem *)(a))
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap(x, 0))
+#define VGA_MAP_MEM(x,s)	((unsigned long) ioremap(x, s))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #endif
Index: work-mm5/include/asm-arm/vga.h
=================================--- work-mm5.orig/include/asm-arm/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-arm/vga.h	2006-04-05 15:42:21.000000000 -0600
@@ -4,7 +4,8 @@
 #include <asm/hardware.h>
 #include <asm/io.h>
 
-#define VGA_MAP_MEM(x)	(PCIMEM_BASE + (x))
+#define VGA_MAP_MEM(x,s)	(PCIMEM_BASE + (x))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x)	(*((volatile unsigned char *)x))
 #define vga_writeb(x,y)	(*((volatile unsigned char *)y) = (x))
Index: work-mm5/include/asm-i386/vga.h
=================================--- work-mm5.orig/include/asm-i386/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-i386/vga.h	2006-04-05 15:42:49.000000000 -0600
@@ -12,7 +12,8 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-ia64/vga.h
=================================--- work-mm5.orig/include/asm-ia64/vga.h	2006-04-05 09:57:55.000000000 -0600
+++ work-mm5/include/asm-ia64/vga.h	2006-04-05 15:43:09.000000000 -0600
@@ -17,7 +17,8 @@
 extern unsigned long vga_console_iobase;
 extern unsigned long vga_console_membase;
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x,s)	((unsigned long) ioremap_nocache(vga_console_membase + (x), s))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/include/asm-m32r/vga.h
=================================--- work-mm5.orig/include/asm-m32r/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-m32r/vga.h	2006-04-05 15:43:22.000000000 -0600
@@ -14,7 +14,8 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-mips/vga.h
=================================--- work-mm5.orig/include/asm-mips/vga.h	2006-03-23 10:22:17.000000000 -0700
+++ work-mm5/include/asm-mips/vga.h	2006-04-05 15:43:32.000000000 -0600
@@ -13,7 +13,8 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x)	(0xb0000000L + (unsigned long)(x))
+#define VGA_MAP_MEM(x,s)	(0xb0000000L + (unsigned long)(x))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/include/asm-powerpc/vga.h
=================================--- work-mm5.orig/include/asm-powerpc/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-powerpc/vga.h	2006-04-05 15:43:57.000000000 -0600
@@ -42,9 +42,11 @@
 extern unsigned long vgacon_remap_base;
 
 #ifdef __powerpc64__
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap((x), 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 #else
-#define VGA_MAP_MEM(x) (x + vgacon_remap_base)
+#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 #endif
 
 #define vga_readb(x) (*(x))
Index: work-mm5/include/asm-sparc64/vga.h
=================================--- work-mm5.orig/include/asm-sparc64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-sparc64/vga.h	2006-04-05 15:44:08.000000000 -0600
@@ -28,6 +28,7 @@
 	return *addr;
 }
 
-#define VGA_MAP_MEM(x) (x)
+#define VGA_MAP_MEM(x,s) (x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #endif
Index: work-mm5/include/asm-x86_64/vga.h
=================================--- work-mm5.orig/include/asm-x86_64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-x86_64/vga.h	2006-04-05 15:44:18.000000000 -0600
@@ -12,7 +12,8 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-xtensa/vga.h
=================================--- work-mm5.orig/include/asm-xtensa/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-xtensa/vga.h	2006-04-05 15:44:31.000000000 -0600
@@ -11,7 +11,8 @@
 #ifndef _XTENSA_VGA_H
 #define _XTENSA_VGA_H
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/drivers/video/console/mdacon.c
=================================--- work-mm5.orig/drivers/video/console/mdacon.c	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/drivers/video/console/mdacon.c	2006-04-05 15:46:33.000000000 -0600
@@ -313,8 +313,8 @@
 	mda_num_columns = 80;
 	mda_num_lines   = 25;
 
-	mda_vram_base = VGA_MAP_MEM(0xb0000);
 	mda_vram_len  = 0x01000;
+	mda_vram_base = VGA_MAP_MEM(0xb0000, mda_vram_len);
 
 	mda_index_port  = 0x3b4;
 	mda_value_port  = 0x3b5;
Index: work-mm5/drivers/video/vga16fb.c
=================================--- work-mm5.orig/drivers/video/vga16fb.c	2006-03-23 10:22:16.000000000 -0700
+++ work-mm5/drivers/video/vga16fb.c	2006-04-05 15:49:34.000000000 -0600
@@ -1351,7 +1351,7 @@
 	}
 
 	/* XXX share VGA_FB_PHYS and I/O region with vgacon and others */
-	info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS);
+	info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS, VGA_FB_PHYS_LEN);
 
 	if (!info->screen_base) {
 		printk(KERN_ERR "vga16fb: unable to map device\n");

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Date: Thu, 06 Apr 2006 14:55:27 +0000
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <200604060855.27673.bjorn.helgaas@hp.com>
List-Id: <linux-ia64.vger.kernel.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060406102154.GB28056@flint.arm.linux.org.uk> <20060406103427.GC28056@flint.arm.linux.org.uk>
In-Reply-To: <20060406103427.GC28056@flint.arm.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: "Luck, Tony" <tony.luck@intel.com>, Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org

On Thursday 06 April 2006 04:34, Russell King wrote:
> On Thu, Apr 06, 2006 at 11:21:54AM +0100, Russell King wrote:
> > On Wed, Apr 05, 2006 at 04:01:08PM -0600, Bjorn Helgaas wrote:
> > > [PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use
> > 
> > Ah, seems to be what I just suggested...
> > 
> > > @@ -1020,14 +1019,14 @@
> > >  	char *charmap;
> > >  	
> > >  	if (vga_video_type != VIDEO_TYPE_EGAM) {
> > > -		charmap = (char *) VGA_MAP_MEM(colourmap);
> > > +		charmap = (char *) VGA_MAP_MEM(colourmap, 0);
> > 
> > Don't like this though - can't we pass a real size here rather than zero?
> > There seems to be several clues as to the maximum size:

I didn't like it either, but was too lazy to work out the actual size,
so I just preserved the previous behavior.

Andrew's put my first patch in -mm already, so I'll put this size
issue and your unmap suggestion on my to-do list.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adrian Bunk <bunk@stusta.de>
Subject: [-mm patch] fs/nfsd/nfs4state.c: make a struct static
Date: Tue, 4 Apr 2006 18:30:10 +0200
Message-ID: <20060404163010.GQ6529@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net
Return-path: <nfs-admin@lists.sourceforge.net>
Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net)
	by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30)
	id 1FQoQ6-000694-D3
	for nfs@lists.sourceforge.net; Tue, 04 Apr 2006 09:30:18 -0700
Received: from mailout.stusta.mhn.de ([141.84.69.5])
	by mail.sourceforge.net with smtp (Exim 4.44)
	id 1FQoQ4-00051R-T6
	for nfs@lists.sourceforge.net; Tue, 04 Apr 2006 09:30:18 -0700
To: Andrew Morton <akpm@osdl.org>, NeilBrown <neilb@suse.de>
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/nfs>,
	<mailto:nfs-request@lists.sourceforge.net?subject=unsubscribe>
List-Id: Discussion of NFS under Linux development,
	interoperability,
	and testing. <nfs.lists.sourceforge.net>
List-Post: <mailto:nfs@lists.sourceforge.net>
List-Help: <mailto:nfs-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/nfs>,
	<mailto:nfs-request@lists.sourceforge.net?subject=subscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=nfs>

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.16-mm2:
>...
> +knfsd-locks-flag-nfsv4-owned-locks.patch
>...
>  knfsd updates.
>...

This patch makes the needlessly global struct nfsd_posix_mng_ops static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-rc1-mm1-full/fs/nfsd/nfs4state.c.old	2006-04-04 18:03:25.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/fs/nfsd/nfs4state.c	2006-04-04 18:03:38.000000000 +0200
@@ -2507,7 +2507,7 @@
 
 /* Hack!: For now, we're defining this just so we can use a pointer to it
  * as a unique cookie to identify our (NFSv4's) posix locks. */
-struct lock_manager_operations nfsd_posix_mng_ops  = {
+static struct lock_manager_operations nfsd_posix_mng_ops  = {
 };
 
 static inline void


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [NFS] [-mm patch] fs/nfsd/nfs4state.c: make a struct static
Date: Tue, 4 Apr 2006 12:50:45 -0400
Message-ID: <20060404165045.GD17709@fieldses.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404163010.GQ6529@stusta.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Andrew Morton <akpm@osdl.org>, NeilBrown <neilb@suse.de>,
	linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1750755AbWDDQu4@vger.kernel.org>
To: Adrian Bunk <bunk@stusta.de>
In-Reply-To: <20060404163010.GQ6529@stusta.de>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <nfs.lists.sourceforge.net>

On Tue, Apr 04, 2006 at 06:30:10PM +0200, Adrian Bunk wrote:
> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.16-mm2:
> >...
> > +knfsd-locks-flag-nfsv4-owned-locks.patch
> >...
> >  knfsd updates.
> >...
> 
> This patch makes the needlessly global struct nfsd_posix_mng_ops static.

Whoops, thanks, looks good.

Do you have a script to look for patches that add non-statics?

--b.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adrian Bunk <bunk@stusta.de>
Subject: Re: [NFS] [-mm patch] fs/nfsd/nfs4state.c: make a struct static
Date: Tue, 4 Apr 2006 19:29:13 +0200
Message-ID: <20060404172913.GT6529@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404163010.GQ6529@stusta.de> <20060404165045.GD17709@fieldses.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Andrew Morton <akpm@osdl.org>, NeilBrown <neilb@suse.de>,
	linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1750725AbWDDR3P@vger.kernel.org>
To: "J. Bruce Fields" <bfields@fieldses.org>
In-Reply-To: <20060404165045.GD17709@fieldses.org>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <nfs.lists.sourceforge.net>

On Tue, Apr 04, 2006 at 12:50:45PM -0400, J. Bruce Fields wrote:
> On Tue, Apr 04, 2006 at 06:30:10PM +0200, Adrian Bunk wrote:
> > On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.16-mm2:
> > >...
> > > +knfsd-locks-flag-nfsv4-owned-locks.patch
> > >...
> > >  knfsd updates.
> > >...
> > 
> > This patch makes the needlessly global struct nfsd_posix_mng_ops static.
> 
> Whoops, thanks, looks good.
> 
> Do you have a script to look for patches that add non-statics?

I diff the output of "make namespacecheck" with the output from the 
-mm kernel before.

> --b.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Zan Lynx <zlynx@acm.org>
Subject: Re: 2.6.17-rc1-mm1, nfsd/reiser4 BUG
Date: Tue, 04 Apr 2006 20:27:16 -0600
Message-ID: <1144204036.26812.72.camel@localhost>
References: <20060404014504.564bf45a.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-J7X/cuQXOp3onmdryQe3"
Cc: linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net,  reiserfs-list@namesys.com
Return-path: <reiserfs-list-return-28443-reiserfs=m.gmane.org@namesys.com>
list-help: <mailto:reiserfs-list-help@namesys.com>
list-unsubscribe: <mailto:reiserfs-list-unsubscribe@namesys.com>
list-post: <mailto:reiserfs-list@namesys.com>
Errors-To: flx@namesys.com
To: Andrew Morton <akpm@osdl.org>
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
List-ID: <nfs.lists.sourceforge.net>

--=-J7X/cuQXOp3onmdryQe3
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2006-04-04 at 01:45 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc1/=
2.6.17-rc1-mm1/

While running the following command on a Reiser4 partition mounted on a
MD RAID-0 device on top of two SCSI disks:

find -type f -print0 | xargs -0 cat > /dev/null

I was running this on the local machine, not on the NFS mounts.  In
fact, the NFS mounts should have had none, or very little, activity.

I started getting the following error messages.  I had been running
2.6.16-rc5-mm3 and hadn't noticed anything like that, so when I get some
time I may try to isolate it, if I can reproduce it.

But, in case anyone else knows the problem, here it is

BUG: unable to handle kernel NULL pointer dereference at virtual address 00=
000000
 printing eip:
e0a9a3d2
*pde =3D 00000000
Oops: 0002 [#1]
PREEMPT
last sysfs file: /devices/pci0000:00/0000:00:00.0/class
Modules linked in: it87 hwmon_vid hwmon i2c_isa parport_pc lp parport nfsd =
exportfs lockd autofs4 sunrpc iptable_filter ip_tables x_tables binfmt_misc=
 dm_mod ohci_hcd eepro100 uhci_hcd ehci_hcd sis_agp agpgart i2c_sis630 i2c_=
core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd=
_pcm snd_timer snd soundcore snd_page_alloc e100 via_rhine sis900 mii crc32=
 ide_cd cdrom usbcore
CPU:    0
EIP:    0060:[<e0a9a3d2>]    Not tainted VLI
EFLAGS: 00010246   (2.6.17-rc1-mm1 #1)
EIP is at nfsd_cache_lookup+0x169/0x2e3 [nfsd]
eax: 00000000   ebx: dd05a120   ecx: ddc3da38   edx: 00000000
esi: c815319e   edi: 00000000   ebp: 00000007   esp: ddfe1f40
ds: 007b   es: 007b   ss: 0068
Process nfsd (pid: 2170, threadinfo=3Dddfe1000 task=3Dc148a070)
Stack: <0>de05d000 ddc3d9e0 00000011 00000003 e0ac9d00 de05d000 e0aa80bc e0=
aa7fa0
       e0aa80bc e0a93049 c51b9014 de05d064 e0aa80bc e0aa7fa0 de05d000 e0ab2=
7d2
       0000003d dd7eaba0 e0aa7fa0 de05d040 c51b9014 000186a3 00000007 c51b9=
008
Call Trace:
 <e0a93049> nfsd_dispatch+0x39/0x16f [nfsd]   <e0ab27d2> svc_process+0x38c/=
0x5c6 [sunrpc]
 <e0a93509> nfsd+0x19a/0x315 [nfsd]   <e0a9336f> nfsd+0x0/0x315 [nfsd]
 <c0101005> kernel_thread_helper+0x5/0xb
Code: 28 8b 54 24 0c 89 53 30 8b 53 24 a1 e8 ba 3b c0 89 43 34 89 d0 c1 e8 =
18 31 d0 8b 54 24 04 83 e0 3f 8d 0c 82 8b 03 8b 53 04 85 c0 <89> 02 74 03 8=
9 50 04 8b 01 85 c0 89 03 74 03 89 58 04 89 19 80
EIP: [<e0a9a3d2>] nfsd_cache_lookup+0x169/0x2e3 [nfsd] SS:ESP 0068:ddfe1f40
 <6>note: nfsd[2170] exited with preempt_count 1
BUG: unable to handle kernel NULL pointer dereference at virtual address 00=
000000
 printing eip:
e0a9a3d2
*pde =3D 00000000
Oops: 0002 [#2]
PREEMPT
last sysfs file: /devices/pci0000:00/0000:00:00.0/class
Modules linked in: it87 hwmon_vid hwmon i2c_isa parport_pc lp parport nfsd =
exportfs lockd autofs4 sunrpc iptable_filter ip_tables x_tables binfmt_misc=
 dm_mod ohci_hcd eepro100 uhci_hcd ehci_hcd sis_agp agpgart i2c_sis630 i2c_=
core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd=
_pcm snd_timer snd soundcore snd_page_alloc e100 via_rhine sis900 mii crc32=
 ide_cd cdrom usbcore
CPU:    0
EIP:    0060:[<e0a9a3d2>]    Not tainted VLI
EFLAGS: 00010246   (2.6.17-rc1-mm1 #1)
EIP is at nfsd_cache_lookup+0x169/0x2e3 [nfsd]
eax: 00000000   ebx: dd05a160   ecx: ddc3da38   edx: 00000000
esi: c815319e   edi: 00000000   ebp: 00000007   esp: dff43f40
ds: 007b   es: 007b   ss: 0068
Process nfsd (pid: 2167, threadinfo=3Ddff43000 task=3Ddf599550)
Stack: <0>de7f5000 ddc3d9e0 00000011 00000003 e0ac9d00 de7f5000 e0aa80bc e0=
aa7fa0
       e0aa80bc e0a93049 d7196014 de7f5064 e0aa80bc e0aa7fa0 de7f5000 e0ab2=
7d2
       0000003d dd7eaba0 e0aa7fa0 de7f5040 d7196014 000186a3 00000007 d7196=
008
Call Trace:
 <e0a93049> nfsd_dispatch+0x39/0x16f [nfsd]   <e0ab27d2> svc_process+0x38c/=
0x5c6 [sunrpc]
 <e0a93509> nfsd+0x19a/0x315 [nfsd]   <e0a9336f> nfsd+0x0/0x315 [nfsd]
 <c0101005> kernel_thread_helper+0x5/0xb
Code: 28 8b 54 24 0c 89 53 30 8b 53 24 a1 e8 ba 3b c0 89 43 34 89 d0 c1 e8 =
18 31 d0 8b 54 24 04 83 e0 3f 8d 0c 82 8b 03 8b 53 04 85 c0 <89> 02 74 03 8=
9 50 04 8b 01 85 c0 89 03 74 03 89 58 04 89 19 80
EIP: [<e0a9a3d2>] nfsd_cache_lookup+0x169/0x2e3 [nfsd] SS:ESP 0068:dff43f40
 <6>note: nfsd[2167] exited with preempt_count 1
BUG: unable to handle kernel NULL pointer dereference at virtual address 00=
000000
 printing eip:
e0a9a3d2
*pde =3D 00000000
Oops: 0002 [#3]
PREEMPT
last sysfs file: /devices/pci0000:00/0000:00:00.0/class
Modules linked in: it87 hwmon_vid hwmon i2c_isa parport_pc lp parport nfsd =
exportfs lockd autofs4 sunrpc iptable_filter ip_tables x_tables binfmt_misc=
 dm_mod ohci_hcd eepro100 uhci_hcd ehci_hcd sis_agp agpgart i2c_sis630 i2c_=
core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd=
_pcm snd_timer snd soundcore snd_page_alloc e100 via_rhine sis900 mii crc32=
 ide_cd cdrom usbcore
CPU:    0
EIP:    0060:[<e0a9a3d2>]    Not tainted VLI
EFLAGS: 00010246   (2.6.17-rc1-mm1 #1)
EIP is at nfsd_cache_lookup+0x169/0x2e3 [nfsd]
eax: 00000000   ebx: dd05a1a0   ecx: ddc3da38   edx: 00000000
esi: c815319e   edi: 00000000   ebp: 00000007   esp: de555f40
ds: 007b   es: 007b   ss: 0068
Process nfsd (pid: 2171, threadinfo=3Dde555000 task=3Ddfe23030)
Stack: <0>dd7cda00 ddc3d9e0 00000011 00000003 e0ac9d00 dd7cda00 e0aa80bc e0=
aa7fa0
       e0aa80bc e0a93049 c54bb014 dd7cda64 e0aa80bc e0aa7fa0 dd7cda00 e0ab2=
7d2
       0000003d dd7eaba0 e0aa7fa0 dd7cda40 c54bb014 000186a3 00000007 c54bb=
008
Call Trace:
 <e0a93049> nfsd_dispatch+0x39/0x16f [nfsd]   <e0ab27d2> svc_process+0x38c/=
0x5c6 [sunrpc]
 <e0a93509> nfsd+0x19a/0x315 [nfsd]   <e0a9336f> nfsd+0x0/0x315 [nfsd]
 <c0101005> kernel_thread_helper+0x5/0xb
Code: 28 8b 54 24 0c 89 53 30 8b 53 24 a1 e8 ba 3b c0 89 43 34 89 d0 c1 e8 =
18 31 d0 8b 54 24 04 83 e0 3f 8d 0c 82 8b 03 8b 53 04 85 c0 <89> 02 74 03 8=
9 50 04 8b 01 85 c0 89 03 74 03 89 58 04 89 19 80
EIP: [<e0a9a3d2>] nfsd_cache_lookup+0x169/0x2e3 [nfsd] SS:ESP 0068:de555f40
 <6>note: nfsd[2171] exited with preempt_count 1
BUG: unable to handle kernel NULL pointer dereference at virtual address 00=
000000
 printing eip:
e0a9a3d2
*pde =3D 00000000
Oops: 0002 [#4]
PREEMPT
last sysfs file: /devices/pci0000:00/0000:00:00.0/class
Modules linked in: it87 hwmon_vid hwmon i2c_isa parport_pc lp parport nfsd =
exportfs lockd autofs4 sunrpc iptable_filter ip_tables x_tables binfmt_misc=
 dm_mod ohci_hcd eepro100 uhci_hcd ehci_hcd sis_agp agpgart i2c_sis630 i2c_=
core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd=
_pcm snd_timer snd soundcore snd_page_alloc e100 via_rhine sis900 mii crc32=
 ide_cd cdrom usbcore
CPU:    0
EIP:    0060:[<e0a9a3d2>]    Not tainted VLI
EFLAGS: 00010246   (2.6.17-rc1-mm1 #1)
EIP is at nfsd_cache_lookup+0x169/0x2e3 [nfsd]
eax: 00000000   ebx: dd05a1e0   ecx: ddc3da38   edx: 00000000
esi: c815319e   edi: 00000000   ebp: 00000007   esp: ddfccf40
ds: 007b   es: 007b   ss: 0068
Process nfsd (pid: 2166, threadinfo=3Dddfcc000 task=3Ddf488a90)
Stack: <0>ddfebe00 ddc3d9e0 00000011 00000003 e0ac9d00 ddfebe00 e0aa80bc e0=
aa7fa0
       e0aa80bc e0a93049 c5629014 ddfebe64 e0aa80bc e0aa7fa0 ddfebe00 e0ab2=
7d2
       0000003d dd7eaba0 e0aa7fa0 ddfebe40 c5629014 000186a3 00000007 c5629=
008
Call Trace:
 <e0a93049> nfsd_dispatch+0x39/0x16f [nfsd]   <e0ab27d2> svc_process+0x38c/=
0x5c6 [sunrpc]
 <e0a93509> nfsd+0x19a/0x315 [nfsd]   <e0a9336f> nfsd+0x0/0x315 [nfsd]
 <c0101005> kernel_thread_helper+0x5/0xb
Code: 28 8b 54 24 0c 89 53 30 8b 53 24 a1 e8 ba 3b c0 89 43 34 89 d0 c1 e8 =
18 31 d0 8b 54 24 04 83 e0 3f 8d 0c 82 8b 03 8b 53 04 85 c0 <89> 02 74 03 8=
9 50 04 8b 01 85 c0 89 03 74 03 89 58 04 89 19 80
EIP: [<e0a9a3d2>] nfsd_cache_lookup+0x169/0x2e3 [nfsd] SS:ESP 0068:ddfccf40
 <6>note: nfsd[2166] exited with preempt_count 1
BUG: unable to handle kernel NULL pointer dereference at virtual address 00=
000000
 printing eip:
e0a9a3d2
*pde =3D 00000000
Oops: 0002 [#5]
PREEMPT
last sysfs file: /devices/pci0000:00/0000:00:00.0/class
Modules linked in: it87 hwmon_vid hwmon i2c_isa parport_pc lp parport nfsd =
exportfs lockd autofs4 sunrpc iptable_filter ip_tables x_tables binfmt_misc=
 dm_mod ohci_hcd eepro100 uhci_hcd ehci_hcd sis_agp agpgart i2c_sis630 i2c_=
core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd=
_pcm snd_timer snd soundcore snd_page_alloc e100 via_rhine sis900 mii crc32=
 ide_cd cdrom usbcore
CPU:    0
EIP:    0060:[<e0a9a3d2>]    Not tainted VLI
EFLAGS: 00010246   (2.6.17-rc1-mm1 #1)
EIP is at nfsd_cache_lookup+0x169/0x2e3 [nfsd]
eax: 00000000   ebx: dd05a220   ecx: ddc3da38   edx: 00000000
esi: c815319e   edi: 00000000   ebp: 00000007   esp: de477f40
ds: 007b   es: 007b   ss: 0068
Process nfsd (pid: 2169, threadinfo=3Dde477000 task=3Ddebdba70)
Stack: <0>de05d600 ddc3d9e0 00000011 00000003 e0ac9d00 de05d600 e0aa80bc e0=
aa7fa0
       e0aa80bc e0a93049 db0ed014 de05d664 e0aa80bc e0aa7fa0 de05d600 e0ab2=
7d2
       0000003d dd7eaba0 e0aa7fa0 de05d640 db0ed014 000186a3 00000007 db0ed=
008
Call Trace:
 <e0a93049> nfsd_dispatch+0x39/0x16f [nfsd]   <e0ab27d2> svc_process+0x38c/=
0x5c6 [sunrpc]
 <e0a93509> nfsd+0x19a/0x315 [nfsd]   <e0a9336f> nfsd+0x0/0x315 [nfsd]
 <c0101005> kernel_thread_helper+0x5/0xb
Code: 28 8b 54 24 0c 89 53 30 8b 53 24 a1 e8 ba 3b c0 89 43 34 89 d0 c1 e8 =
18 31 d0 8b 54 24 04 83 e0 3f 8d 0c 82 8b 03 8b 53 04 85 c0 <89> 02 74 03 8=
9 50 04 8b 01 85 c0 89 03 74 03 89 58 04 89 19 80
EIP: [<e0a9a3d2>] nfsd_cache_lookup+0x169/0x2e3 [nfsd] SS:ESP 0068:de477f40
 <6>note: nfsd[2169] exited with preempt_count 1
BUG: unable to handle kernel NULL pointer dereference at virtual address 00=
000000
 printing eip:
e0a9a3d2
*pde =3D 00000000
Oops: 0002 [#6]
PREEMPT
last sysfs file: /devices/pci0000:00/0000:00:00.0/class
Modules linked in: it87 hwmon_vid hwmon i2c_isa parport_pc lp parport nfsd =
exportfs lockd autofs4 sunrpc iptable_filter ip_tables x_tables binfmt_misc=
 dm_mod ohci_hcd eepro100 uhci_hcd ehci_hcd sis_agp agpgart i2c_sis630 i2c_=
core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd=
_pcm snd_timer snd soundcore snd_page_alloc e100 via_rhine sis900 mii crc32=
 ide_cd cdrom usbcore
CPU:    0
EIP:    0060:[<e0a9a3d2>]    Not tainted VLI
EFLAGS: 00010246   (2.6.17-rc1-mm1 #1)
EIP is at nfsd_cache_lookup+0x169/0x2e3 [nfsd]
eax: 00000000   ebx: dd05a260   ecx: ddc3da38   edx: 00000000
esi: c815319e   edi: 00000000   ebp: 00000007   esp: ddf70f40
ds: 007b   es: 007b   ss: 0068
Process nfsd (pid: 2165, threadinfo=3Dddf70000 task=3Ddfe1aa90)
Stack: <0>ddfeb200 ddc3d9e0 00000011 00000003 e0ac9d00 ddfeb200 e0aa80bc e0=
aa7fa0
       e0aa80bc e0a93049 db575014 ddfeb264 e0aa80bc e0aa7fa0 ddfeb200 e0ab2=
7d2
       0000003d dd7eaba0 e0aa7fa0 ddfeb240 db575014 000186a3 00000007 db575=
008
Call Trace:
 <e0a93049> nfsd_dispatch+0x39/0x16f [nfsd]   <e0ab27d2> svc_process+0x38c/=
0x5c6 [sunrpc]
 <e0a93509> nfsd+0x19a/0x315 [nfsd]   <e0a9336f> nfsd+0x0/0x315 [nfsd]
 <c0101005> kernel_thread_helper+0x5/0xb
Code: 28 8b 54 24 0c 89 53 30 8b 53 24 a1 e8 ba 3b c0 89 43 34 89 d0 c1 e8 =
18 31 d0 8b 54 24 04 83 e0 3f 8d 0c 82 8b 03 8b 53 04 85 c0 <89> 02 74 03 8=
9 50 04 8b 01 85 c0 89 03 74 03 89 58 04 89 19 80
EIP: [<e0a9a3d2>] nfsd_cache_lookup+0x169/0x2e3 [nfsd] SS:ESP 0068:ddf70f40
 <6>note: nfsd[2165] exited with preempt_count 1

--=20
Zan Lynx <zlynx@acm.org>

--=-J7X/cuQXOp3onmdryQe3
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEMysEG8fHaOLTWwgRAsYtAJ9xXZ8L2T5DiOhifw+AMzsOaXyFfwCfeC0s
QhZXqsK4OpoI/Uar2o03hzU=
=/s/d
-----END PGP SIGNATURE-----

--=-J7X/cuQXOp3onmdryQe3--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S932316AbWDDIqD@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932316AbWDDIqD (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 04:46:03 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932373AbWDDIqD
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 04:46:03 -0400
Received: from smtp.osdl.org ([65.172.181.4]:62404 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S932310AbWDDIp7 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 04:45:59 -0400
Date: Tue, 4 Apr 2006 01:45:04 -0700
From: Andrew Morton <akpm@osdl.org>
To: linux-kernel@vger.kernel.org
Subject: 2.6.17-rc1-mm1
Message-Id: <20060404014504.564bf45a.akpm@osdl.org>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc1/2.6.17-rc1-mm1/


- VGA on ia64 is broken - the screen comes up blank.  But ia64 otherwise
  seems to work OK.  I didn't have time to investigate.

- Linus is out of town until the weekend - his net connectedness is
  uncertain.

- I dropped the old kgdb patch and picked up a new version for x86 only from
  kgdb.linsyssoft.com.  It works much better, but disagrees violently with
  gcc-4.2 for some reason.




Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

        echo "subscribe mm-commits" | mail majordomo@vger.kernel.org

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

        http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.



Changes since 2.6.16-mm2:


 git-acpi.patch
 git-agpgart.patch
 git-cfq.patch
 git-cpufreq.patch
 git-dvb.patch
 git-infiniband.patch
 git-intelfb.patch
 git-libata-all.patch
 git-netdev-all.patch
 git-ocfs2.patch
 git-scsi-misc.patch
 git-scsi-target.patch
 git-sas-jg.patch
 git-viro-bird-m32r.patch
 git-viro-bird-m68k.patch
 git-viro-bird-frv.patch
 git-viro-bird-upf.patch
 git-viro-bird-volatile.patch

 git trees.

-rtc-remove-rtc-uip-synchronization-on-x86.patch
-rtc-remove-rtc-uip-synchronization-on-x86_64.patch
-rtc-remove-rtc-uip-synchronization-on-sparc64.patch
-rtc-remove-rtc-uip-synchronization-on-ppc-chrp-arch-ppc.patch
-rtc-remove-rtc-uip-synchronization-on-chrp-arch-powerpc.patch
-rtc-remove-rtc-uip-synchronization-on-ppc-maple.patch
-rtc-remove-rtc-uip-synchronization-on-arm.patch
-rtc-remove-rtc-uip-synchronization-on-mips-mc146818.patch
-rtc-remove-rtc-uip-synchronization-on-mips-based-dec.patch
-rtc-remove-rtc-uip-synchronization-on-sh03.patch
-rtc-remove-rtc-uip-synchronization-on-sh-mpc1211.patch
-rtc-remove-rtc-uip-synchronization-on-alpha.patch
-rtc-fix-up-some-rtc-whitespace-and-style.patch
-rtc-remove-some-duplicate-bcd-definitions.patch
-git-acpi-up-fix.patch
-pnpacpi-fix-non-memory-address-space-descriptor-handling.patch
-pnpacpi-remove-some-code-duplication.patch
-pnpacpi-whitespace-cleanup.patch
-acpi-request-correct-fixed-hardware-resource-type-mmio-vs-i-o-port.patch
-acpi-add-acpi-to-motherboard-resources-in-proc-iomemport.patch
-acpi-update-asus_acpi-driver-registration.patch
-acpi-fix-sonypi-acpi-driver-registration.patch
-acpi-make-acpi_bus_register_driver-return-success-failure-not-device-count.patch
-acpi-simplify-scanc-coding.patch
-acpi-print-wakeup-device-list-on-same-line-as-label.patch
-acpi-fix-memory-hotplug-range-length-handling.patch
-hpet-fix-acpi-memory-range-length-handling.patch
-acpi_os_acquire_object-gfp_kernel-called-with-irqs.patch
-acpi-remove-__init-__exit-from-asus-add-remove-methods.patch
-acpi-signedness-fix-2.patch
-acpi-should-depend-on-not-select-pci.patch
-acpi-ec-acpi-ecdt-uid-hack.patch
-remove-entries-in-sys-firmware-acpi-for-processor-also.patch
-remove-unnecessary-lapic-definition-from-acpidefh.patch
-catch-notification-of-memory-add-event-of-acpi-via-container-driver-register-start-func-for-memory-device-tidy.patch
-catch-notification-of-memory-add-event-of-acpi-via-container-driveravoid-redundant-call-add_memory-tidy.patch
-kernel-crash-in-powernow-k8-after-lost-ticks-detected.patch
-drm-sis-fix-compile-warning.patch
-remove-drm_allocfree_pages.patch
-ia64-sn_hwperf-eliminate-use-of-num_online_cpus.patch
-input-adds-snes-mouse-support-to-gamecon.patch
-m25p80-printk-warning-fix.patch
-sem2mutex-mtd-doc2000c.patch
-sem2mutex-drivers-mtd.patch
-drivers-mtd-small-cleanups.patch
-mtd_nand_sharpsl-and-mtd_nand_nandsim-should-be-tristates.patch
-drivers-mtd-use-array_size-macro.patch
-mtd-cmdlinepart-allow-zero-offset-value.patch
-fix-debug-statement-in-inftlcorec.patch
-kill-ifdefs-in-mtdcorec.patch
-kill-ifdefs-in-mtdcorec-fix.patch
-dead-code-in-mtd-maps-pcic.patch
-add-chip-used-in-collie-to-jedec_probe.patch
-mtd-redboot-handle-holes-in-fis-table.patch
-mtd-fix-broken-name_to_dev_t-declaration.patch
-drivers_mtd_maps_vmax301c-fix-off-by-one-vmax_mtd.patch
-natsemi-support-oversized-eeproms.patch
-net-remove-config_net_cbus-conditional-for-ns8390.patch
-com90xx-kmalloc-fix.patch
-netfilter-rename-init-functions.patch
-net-fix-appletalk-compat_ioctl-oopses.patch
-deinline-200-byte-inlines-in-sockh.patch
-deinline-some-larger-functions-from-netdeviceh.patch
-git-powerpc-warn-was-a-dumb-idea.patch
-git-serial.patch
-serial-mystery-kbuild-fix.patch
-git-sym2.patch
-fix-pcmcia_device_remove-oops.patch
-aacraid-fix-the-comparison-with-sizeof.patch
-x86_64-mm-hangcheck-remove-message.patch
-x86_64-mm-lost-cli-debug.patch
-x86_64-mm-sis-agp.patch
-x86_64-mm-acpi-nolapic.patch
-x86_64-mm-extra-nodes_shift-definition.patch
-x86_64-mm-hotadd-reserve-fix.patch
-git-xfs-vn_to_inode-fix.patch
-mm-schedule-find_trylock_page-removal.patch
-remove-long-dead-i386-floppy-asm-code.patch
-i386-kdump-timer-vector-lockup-fix.patch
-uml-hotplug-memory-take-2.patch
-decrapify-asm-generic-localh.patch
-mark-unwind-info-for-signal-trampolines-in-vdsos.patch
-locks-dont-panic.patch
-document-linuxs-memory-barriers.patch
-synclink-remove-dead-code.patch
-synclink_gt-add-gpio-feature.patch
-synclink_gt-remove-uneeded-async-code.patch
-let-blk_dev_ram_count-depend-on-blk_dev_ram.patch
-kill-__init_timer_base-in-favor-of-boot_tvec_bases.patch
-__mod_timer-simplify-base-changing.patch
-paride-register_chrdev-fix.patch
-paride-pt-register_chrdev-fix.patch
-capi-register_chrdev-fix.patch
-symversion-warning-fix.patch
-simplify-proc-devices-and-fix-early-termination-regression.patch
-simplify-proc-devices-and-fix-early-termination-regression-tidy.patch
-simplify-proc-devices-and-fix-early-termination-regression-tidy-2.patch
-simplify-proc-devices-and-fix-early-termination-regression-tidy-3.patch
-dont-pass-boot-parameters-to-argv_init.patch
-add-oprofile_add_ext_sample.patch
-alpha-make-poll-flags-thesame-as-other-architectures.patch
-mqueue-comment-fix-fix.patch
-change-dash2underscore-return-value-to-char.patch
-drivers-block-paride-pdc-fix-an-off-by-one-error.patch
-fs-fat-proper-prototypes-for-two-functions.patch
-philip-gladstone-has-moved.patch
-edac_752x-needs-config_hotplug.patch
-make-tty_insert_flip_char-a-non-gpl-export.patch
-ipmi-fix-startup-race-condition.patch
-ipmi-fix-startup-race-condition-tidy.patch
-ipmi-tidy-up-various-things.patch
-ipmi-convert-from-semaphores-to-mutexes.patch
-mutex-some-cleanups.patch
-remove-relayfs_fsh.patch
-drivers-block-acsi_slmc-size_t-cant-be-0.patch
-autofs4-proper-prototype-for-autofs4_dentry_release.patch
-exec-allow-init-to-exec-from-any-thread.patch
-simplify-exec-from-inits-subthread.patch
-remove-dead-kill_sl-prototype-from-schedh.patch
-do_tty_hangup-use-group_send_sig_info-not.patch
-do_sak-dont-depend-on-session-id-0.patch
-pidhash-kill-switch_exec_pids.patch
-choose_new_parent-remove-unused-arg-sanitize-exit_state-check.patch
-remove-add_parents-parent-argument.patch
-dont-use-remove_links-set_links-for-reparenting.patch
-kill-set_links-remove_links.patch
-pidhash-dont-count-idle-threads.patch
-pidhash-dont-use-zero-pids.patch
-reparent_thread-use-remove_parent-add_parent.patch
-wait_for_helper-trivial-style-cleanup.patch
-release_task-replace-open-coded-ptrace_unlink.patch
-convert-sighand_cache-to-use-slab_destroy_by_rcu.patch
-introduce-lock_task_sighand-helper.patch
-introduce-sig_needs_tasklist-helper.patch
-copy_process-cleanup-bad_fork_cleanup_sighand.patch
-copy_process-cleanup-bad_fork_cleanup_signal.patch
-cleanup-__exit_signal.patch
-rename-__exit_sighand-to-cleanup_sighand.patch
-move-__exit_signal-to-kernel-exitc.patch
-revert-optimize-sys_times-for-a-single-thread-process.patch
-do-__unhash_process-under-siglock.patch
-sys_times-dont-take-tasklist_lock.patch
-relax-sig_needs_tasklist.patch
-do_signal_stop-dont-take-tasklist_lock.patch
-do_group_exit-dont-take-tasklist_lock.patch
-do_sigaction-dont-take-tasklist_lock.patch
-pids-kill-pidtype_tgid.patch
-make-fork-atomic-wrt-pgrp-session-signals.patch
-cleanup-__exit_signal-cleanup_sighand-path.patch
-simplify-do_signal_stop.patch
-finish_stop-dont-check-stop_count-0.patch
-do_notify_parent_cldstop-remove-to_self-param.patch
-send_sigqueue-simplify-and-fix-the-race.patch
-permit-dual-mit-gpl-licenses.patch
-led-class-documentation.patch
-led-add-led-class.patch
-led-add-led-trigger-support.patch
-led-add-led-timer-trigger.patch
-led-add-sharp-charger-status-led-trigger.patch
-led-add-led-device-support-for-the-zaurus-corgi-and.patch
-led-add-led-device-support-for-locomo-devices.patch
-led-add-led-device-support-for-ixp4xx-devices.patch
-led-add-device-support-for-tosa.patch
-led-add-nand-mtd-activity-led-trigger.patch
-led-add-ide-disk-activity-led-trigger.patch
-ensure-ide-taskfile-calls-any-driver-specific.patch
-hrtimer-create-generic-sleeper.patch
-hrtimer-use-generic-sleeper-for-nanosleep.patch
-sched-cleanup_task_activated.patch
-sched-make_task_noninteractive_use_sleep_type.patch
-sched-dont_decrease_idle_sleep_avg.patch
-sched-include_noninteractive_sleep_in_idle_detect.patch
-sched-remove-on-runqueue-requeueing.patch
-sched-activate-sched-batch-expired.patch
-sched-reduce-overhead-of-calc_load.patch
-sched-fix-interactive-task-starvation.patch
-futex-check-and-validate-timevals.patch
-rtc-m41t00-driver-should-use-workqueue-instead-of-tasklet.patch
-rtc-m41t00-driver-cleanup.patch
-rtc-add-support-for-m41t81-m41t85-chips-to-m41t00-driver.patch
-trivial-cleanup-to-proc_check_chroot.patch
-resurrect-__put_task_struct.patch
-task-rcu-protect-task-usage.patch
-make-setsid-more-robust.patch
-dcache-add-helper-d_hash_and_lookup.patch
-pidhash-refactor-the-pid-hash-table.patch
-ide-amd756-no-host-side-cable-detection.patch
-small-fixes-backported-to-old-ide-sis-driver.patch
-ide_generic_all_on-warning-fix.patch
-fbcon-save-current-display-during-initialization.patch
-w100fb-add-acceleration-support-to-ati-imageon.patch
-backlight-backlight-class-improvements.patch
-backlight-hp-jornada-680-backlight-driver-updates-fixes.patch
-backlight-corgi_bl-generalise-to-support-other-sharp.patch
-pxafb-minor-driver-fixes.patch
-fbcon-fix-big-endian-bogosity-in-slow_imageblit.patch
-optimize-select-poll-by-putting-small-data-sets-on-the-stack.patch
-use-fget_light-in-select-poll.patch
-fold-select_bits_alloc-free-into-caller-code.patch
-ia64-const-f_ops-fix.patch
-mark-f_ops-const-in-the-inode.patch
-make-most-file-operations-structs-in-fs-const.patch
-docs-update-missing-files-and-descriptions-for-filesystems-00-index.patch
-arch-i386-kernel-microcodec-remove-the-obsolete-microcode_ioctl.patch
-drivers-block-use-time_after-and-friends.patch
-nvidia-agp-use-time_before_eq.patch
-ide-tape-use-time_after-time_after_eq.patch
-drivers-scsi-use-time_after-and-friends.patch
-replace-0xff-with-correct-dma_xbit_mask.patch
-vfree-null-check-fixup-for-sb_card.patch
-maestro3-vfree-null-check-fixup.patch
-no-need-to-check-vfree-arg-for-null-in-oss-sequencer.patch
-vfree-does-its-own-null-check-no-need-to-be-explicit-in-oss-msndc.patch
-fix-signed-vs-unsigned-in-nmi-watchdog.patch
-trivial-typos-in-documentation-cputopologytxt.patch
-typos-grab-bag-of-the-month.patch
-unexport-get_wchan.patch
-fs-nameic-make-lookup_hash-static.patch
-decrease-number-of-pointer-derefs-in-jsm_ttyc.patch
-sound-remove-unneeded-kmalloc-return-value-casts.patch

 Merged into mainline or a subsystem tree

+selinux-build-fix.patch
+sched-fix-interactive-task-starvation.patch
+dont-awaken-rt-tasks-on-expired-array.patch
+select-warning-fixes.patch
+fix-null-pointer-dereference-in-node_read_numastat.patch
+dmi-move-dmi_scanc-from-arch-i386-to-drivers-firmware.patch
+config_net=n-build-fix.patch
+drm_pci-needs-dma-mappingh.patch

 2.6.17-rc2 queue (part thereof, many more 2.6.17 patches below)

+acpi-update-asus_acpi-driver-registration-fix.patch

 ACPI fix

+for_each_possible_cpu-under-drivers-acpi.patch
+acpi_bus_unregister_driver-make-void.patch
+acpi_os_wait_semaphore-dont-complain-about-timeout.patch

 ACPI updates

+for_each_possible_cpu-for-arm.patch

 ARM for_each_cpu() conversion.

+powernow-k8-crash-workaround.patch

 cpufreq non-fix.

+gregkh-driver-driver-core-safely-unbind-drivers-for-devices-not-on-a-bus.patch
+gregkh-driver-block-delay-all-uevents-until-partition-table-is-scanned.patch

 Driver tree updates.

-revert-gregkh-driver-fix-up-the-sysfs-pollable-patch.patch

 Dropped.

+spi-whitespace-fixes.patch
+spi-bounce-buffer-has-a-minimum-length.patch
+spi-add-david-as-the-spi-subsystem-maintainer.patch
+spi-renamed-bitbang_transfer_setup-to-spi_bitbang_setup_transfer.patch
+spi-busnum-==-0-needs-to-work.patch
+spi-devices-can-require-lsb-first-encodings.patch

 SPI updates.

+driver-core-fix-unnecessary-null-check-in-drivers-base-classc.patch

 driver core cleanup.

+drm-fix-issue-reported-by-coverity-in-drivers-char-drm-via_irqc.patch

 DRM fix.

+avermedia-6-eyes-avs6eyes-support.patch
+bt866-build-fix.patch

 New v4l driver, and a fix.

+gregkh-i2c-rtc-ds1374-convert-tasklet-to-workqueue.patch
+gregkh-i2c-rtc-m41t00-driver-should-use-workqueue-instead-of-tasklet.patch
+gregkh-i2c-hwmon-w83792d-quiet-on-misdetection.patch
+gregkh-i2c-i2c-sis96x-remove-init-log-message.patch
+gregkh-i2c-i2c-parport-require-type-parameter.patch
+gregkh-i2c-hwmon-lm83-add-lm82-support.patch
+gregkh-i2c-hwmon-w83627ehf-add-voltages.patch
+gregkh-i2c-hwmon-w83627ehf-add-alarms.patch
+gregkh-i2c-hwmon-smsc47m192-new-driver.patch
+gregkh-i2c-hwmon-f71805f-no-global-resource.patch
+gregkh-i2c-hwmon-sysfs-interface-individual-alarm-files.patch
+gregkh-i2c-i2c-piix4-add-ati-smbus-support.patch
+gregkh-i2c-rtc-m41t00-driver-cleanup.patch
+gregkh-i2c-w1-added-default-generic-read-write-operations.patch
+gregkh-i2c-w1-replace-dscore-and-ds_w1_bridge-with-ds2490-driver.patch
+gregkh-i2c-w1-userspace-communication-protocol-over-connector.patch
+gregkh-i2c-w1-move-w1-connector-definitions-into-linux-include-connector.h.patch
+gregkh-i2c-w1-netlink-mark-netlink-group-1-as-unused.patch

 I2C tree.

+connector-exports.patch
+w1-exports.patch

 Fix things in Greg's trees.

+scx200_acb-fix-for-cs5535-eratta.patch
+scx200_acb-use-pci-i-o-resource-when-appropriate.patch

 i2c driver updates.

+for_each_possible_cpu-ia64.patch

 ia64 for_each_cpu() conversion.

+wistron_btns-add-support-for-amilo-7400m.patch

 Additional device support.

+sata_mv-properly-print-hc-registers.patch

 SATA fix.

+for_each_possible_cpu-mips.patch

 MIPS for_each_cpu() conversion.

-pci-error-recovery-e1000-network-device-driver-tidy.patch

 Folded into pci-error-recovery-e1000-network-device-driver.patch

+e1000-prevent-statistics-from-getting-garbled-during-reset.patch
+net-drivers-fix-section-attributes-for-gcc.patch

 netdev fixes.

+for_each_possible_cpu-network-codes.patch

 net for_each_cpu() conversion.

+netfilter-fix-fragmentation-issues-with-bridge-netfilter.patch
+ebtables-fix-allocation-in-net-bridge-netfilter-ebtablesc.patch

 net fixes.

+gregkh-pci-msi-save-restore-for-suspend-resume.patch
+gregkh-pci-pci_ids.h-correct-naming-of-1022-7450.patch
+gregkh-pci-pci-fix-sparse-warning-about-pci_bus_flags.patch
+gregkh-pci-pci-rpaphp-remove-init-error-condition.patch
+gregkh-pci-re-arch-i386-pci-irq.c-new-via-chipsets.patch
+gregkh-pci-pci-add-pci-quirk-for-smbus-on-the-asus-a6va-notebook.patch

 PCI tree updates.

+64-bit-resources-drivers-pci-changes-sparc32-fix.patch

 Fix 64-bit-resources-drivers-pci-changes.patch.

+64-bit-resources-arch-powerpc-changes.patch
+64-bit-resources-more-drivers-others-changes.patch
+64-bit-resources-more-sound-changes.patch

 Updates to the 64-bit resource patches.

+for_each_possible_cpu-sparc.patch
+for_each_possible_cpu-sparc64.patch

 for_each_cpu() conversions.

+gregkh-usb-usb-net2282-and-net2280-software-compatibility.patch
+gregkh-usb-usb-cleanups-for-ohci-s3c2410.c.patch
+gregkh-usb-usb-ftdi_sio-add-support-for-eclo-com-to-1-wire-usb-adapter.patch
+gregkh-usb-usb-g_file_storage-set-short_not_ok-for-bulk-out-transfers.patch
+gregkh-usb-usb-g_file_storage-add-comment-about-buffer-allocation.patch
+gregkh-usb-usb-serial-converts-port-semaphore-to-mutexes.patch
+gregkh-usb-usb-pci-quirks.c-proper-prototypes.patch
+gregkh-usb-usb-input-proper-prototypes.patch
+gregkh-usb-usb-add-support-for-papouch-tmu.patch
+gregkh-usb-usb-usbtouchscreen-unified-usb-touchscreen-driver.patch
+gregkh-usb-usb-g_file_storage-use-module_param_array_named-macro.patch
+gregkh-usb-usb-wacom-tablet-driver-update.patch
+gregkh-usb-usb-add-new-wacom-devices-to-usb-hid-core-list.patch
+gregkh-usb-usb-pegasus-driver-bugfix.patch

 USB tree updates.

+hid-corec-fix-input-irq-status-32-received-for-silvercrest-usb-keyboard.patch

 USB fix.

+softmac-uses-wiress-ext.patch

 Wireless fix.

+x86_64-mm-execve-cleanup.patch
+x86_64-mm-clustered-check.patch
+x86_64-mm-nodes-shift-dummy.patch
+x86_64-mm-mce-nmi-watchdog.patch
+x86_64-mm-i386-up-generic-arch.patch
+x86_64-mm-i386-bigsmp-fadt.patch
+x86_64-mm-force-iret.patch
+x86_64-mm-strlen-export.patch
+x86_64-mm-hpet-return.patch
+x86_64-mm-vsmp-cache-boundary.patch
+x86_64-mm-mcfg-check-more-busses.patch
+x86_64-mm-mmconfig-error-value.patch
+x86_64-mm-memset-always-inline.patch
+x86_64-mm-hpet-drift.patch
+x86_64-mm-gs-leak.patch
+x86_64-mm-fix-config_reorder.patch

 x86_64 updates.

+arm-add_memory-build-fix.patch

 They broke arm.

+for_each_possible_cpu-x86_64.patch

 x86_64 for_each_cpu() conversion.

+for_each_possible_cpu-xfs.patch

 XFS for_each_cpu() conversion.

+mm-posix-memory-lock.patch
+slab-allocate-node-local-memory-for-off-slab-slabmanagement.patch
+slab-add-statistics-for-alien-cache-overflows.patch
+nommu-use-compound-page-in-slab-allocator.patch
+mm-fix-bug-in-brk.patch

 MM updates.

+frv-define-mmu-mode-specific-syscalls-as-cond_syscall-and-clean-up-unneeded-macros.patch

 FRV fix.

+x86-clean-up-subarch-definitions.patch
+x86-clean-up-subarch-definitions-update.patch
+arch-i386-kernel-apicc-make-modern_apic-static.patch
+enable-tsc-for-amd-geode-gx-lx.patch
+swsusp-dont-require-bigsmp.patch
+i386-print-eip-esp-last.patch
+menu-relocate-doublefault-option.patch

 x86 updates.

-swsusp-resume-parsing-fix.patch

 Dropped.

+uml-tls-fixlets.patch

 UML fix.

+s390-update-default-configuration.patch
+s390-ebdic-to-ascii-conversion-tables.patch
+s390-invalid-check-after-kzalloc.patch
+s390-wrong-return-codes-in-cio_ignore_proc_init.patch
+s390-increase-cio_trace-debug-event-size.patch
+s390-dasd-device-offline-messages.patch
+s390-fail-fast-requests-on-quiesced-devices.patch
+s390-dasd-proc-entries.patch
+s390-minor-tape-fixes.patch
+s390-fix-implicit-declaration-of-unlikely.patch

 s390 updates.

+hdaps-add-support-for-thinkpad-r52.patch
+configurable-nodes_shift.patch
+ext3-block-allocation-reservation-fixes-to-support.patch
+ext3-ext3-in-kernel-block-number-type-fixes.patch
+ext3-ext3-in-kernel-block-number-type-fixes-fix.patch
+unify-pxm_to_node-and-node_to_pxm.patch
+no-arch-specific-strpbrk-implementations.patch
+clean-up-arch-overrides-in-linux-stringh.patch
+sync_file_range-use-unsigned-for-flags.patch
+timer-initialisation-fix.patch
+timer-initialisation-fix-tidy.patch
+avoid-tasklist_lock-at-getrusage-for-multithreaded-case-too.patch
+the-scheduled-unexport-of-panic_timeout.patch
+s3c24xx-gpio-led-support.patch
+s3c24xx-gpio-led-support-tidy.patch
+leds-fix-ide-disk-trigger-name.patch
+leds-reorganise-kconfig.patch
+leds-re-layout-include-linux-ledsh.patch
+vfs-propagate-mnt_flags-into-do_loopback-vfsmount.patch
+build-kernel-irq-migrationc-only-if-config_generic_pending_irq-is-set.patch
+remove-sys_-prefix-of-new-syscalls-from-__nr_sys_.patch
+add-prctl-to-change-endian-of-a-task.patch
+#writeback-fix-range-handling.patch
+make-tty_insert_flip_string_flags-a-non-gpl-export.patch
+memory_hotplugh-cleanup.patch
+9p-handle-sget-failure.patch
+remove-extraneous-n-in-doubletalk-init-printk.patch
+missing-n-in-sc1200wdt-driver.patch
+reinstate-const-in-next_thread.patch
+select-dont-overflow-if-select_stack_alloc-%-sizeoflong-=-0.patch
+silence-a-const-vs-non-const-warning.patch
+kdump-proc-vmcore-size-oveflow-fix.patch
+hdaps-support-new-lenovo-machines.patch
+fix-dcache-race-during-umount.patch
+prune_one_dentry-tweaks.patch
+uniform-pollrdhup-handling-between-epoll-and-poll-select.patch
+add-cpu_relax-to-hrtimer_cancel.patch

 Misc.

+introduce-hlist_move_head.patch
+use-hlist_move_head.patch
+use-list_add_tail-instead-of-list_add.patch
+use-list_add_tail-instead-of-list_add-fix.patch
+arch-use-list_move.patch
+core-use-list_move.patch
+net-rxrpc-use-list_move.patch
+drivers-use-list_move.patch
+fs-use-list_move.patch

 list.h cleanups.

+rtc-subsystem-ds1672-oscillator-handling.patch
+rtc-subsystem-ds1672-cleanup.patch
+rtc-subsystem-x1205-sysfs-cleanup.patch
+rtc-subsystem-whitespaces-and-error-messages-cleanup.patch
+rtc-subsystem-fix-proc-output.patch
+rtc-subsystem-rs5c372-sysfs-fix.patch
+rtc-subsystem-compact-error-messages.patch
+rtc-subsystem-sa1100-cleanup.patch
+rtc-subsystem-vr41xx-driver.patch
+rtc-subsystem-vr41xx-cleanup.patch

 RTC system updates.

+fuse-fix-oops-in-fuse_send_readpages.patch
+fuse-fix-fuse_dev_poll-return-value.patch
+fuse-add-o_async-support-to-fuse-device.patch
+fuse-add-o_nonblock-support-to-fuse-device.patch
+fuse-simplify-locking.patch
+fuse-use-a-per-mount-spinlock.patch
+fuse-consolidate-device-errors.patch
+fuse-clean-up-request-accounting.patch
+fuse-account-background-requests.patch

 FUSE updates.

+isdn4linux-siemens-gigaset-drivers-code-cleanup.patch
+isdn4linux-siemens-gigaset-drivers-kconfig-correction.patch
+isdn4linux-siemens-gigaset-drivers-timer-usage.patch
+isdn4linux-siemens-gigaset-drivers-logging-usage.patch
+isdn4linux-siemens-gigaset-drivers-sysfs-usage.patch
+isdn4linux-siemens-gigaset-drivers-remove-ifnull-macros.patch
+isdn4linux-siemens-gigaset-drivers-uninline.patch
+isdn4linux-siemens-gigaset-drivers-elliminate-from_user-argument.patch
+isdn4linux-siemens-gigaset-drivers-mutex-conversion.patch
+isdn4linux-siemens-gigaset-drivers-remove-private-version-of-__skb_put.patch
+isdn4linux-siemens-gigaset-drivers-remove-forward-references.patch
+isdn4linux-siemens-gigaset-drivers-add-readme.patch
+isdn4linux-siemens-gigaset-drivers-make-some-variables-non-atomic.patch

 ISDN driver updates.

+knfsd-correct-reserved-reply-space-for-read-requests.patch
+knfsd-locks-flag-nfsv4-owned-locks.patch
+knfsd-nfsd4-wrong-error-handling-in-nfs4acl.patch
+knfsd-nfsd4-better-nfs4acl-errors.patch
+knfsd-nfsd4-fix-acl-xattr-length-return.patch
+knfsd-nfsd-oops-exporting-nonexistent-directory.patch
+knfsd-nfsd-nfsd_setuser-doesnt-really-need-to-modify-rqstp-rq_cred.patch
+knfsd-nfsd4-remove-nfsd_setuser-from-putrootfh.patch
+knfsd-nfsd4-fix-corruption-of-returned-data-when-using-64k-pages.patch
+knfsd-nfsd4-fix-corruption-on-readdir-encoding-with-64k-pages.patch
+knfsd-svcrpc-gss-dont-call-svc_take_page-unnecessarily.patch
+knfsd-svcrpc-warn-instead-of-returning-an-error-from-svc_take_page.patch
+knfsd-nfsd4-fix-laundromat-shutdown-race.patch
+knfsd-nfsd4-nfsd4_probe_callback-cleanup.patch
+knfsd-nfsd4-add-missing-rpciod_down.patch
+knfsd-nfsd4-limit-number-of-delegations-handed-out.patch
+knfsd-nfsd4-limit-number-of-delegations-handed-out-fix.patch
+knfsd-nfsd4-grant-delegations-more-frequently.patch

 knfsd updates.

+sched-prevent-high-load-weight-tasks-suppressing-balancing.patch
+sched-improve-stability-of-smpnice-load-balancing.patch
+sched_domain-handle-kmalloc-failure.patch
+sched_domain-dont-use-gfp_atomic.patch
+sched_domain-use-kmalloc_node.patch
+sched_domain-allocate-sched_group-structures-dynamically.patch

 CPU scheduler updates.

+pi-futex-futex-code-cleanups-fix.patch

 Fix pi-futex-futex-code-cleanups.patch

+pi-futex-rt-mutex-core-fix-timeout-race.patch

 Fix pi-futex-rt-mutex-core.patch

+pi-futex-patchset-v4.patch
+pi-futex-patchset-v4-update.patch

 PI-futex updates.

-reiser4-sb_sync_inodes-cleanup.patch
-reiser4-include-reiser4.patch
-reiser4-doc.patch
-reiser4-doc-fix-reiser4-links-in-documentation.patch
-reiser4-only.patch
-reiser4-cleanup_init_fake_inode.patch
-reiser4-only-stop-using-__put_page.patch
-reiser4-ver_linux-dont-print-reiser4progs-version-if-none-found.patch
-reiser4-fix-wundef-warnings.patch
-reiser4-swsusp-build-fix.patch
-reiser4-reboot-fix.patch
-reiser4-update-filesystems-for-new-delete_inode-behavior.patch
-reiser4-xattr-build-fix.patch
-reiser4-printk-warning-fix.patch
-reiser4-mm-remove-pg_highmem-fix.patch
-reiser4-kconfig-help-cleanup.patch
-reiser4-update.patch
-reiser4-fix-dependencies.patch
-reiser4-wundef-fix.patch
-reiser4-wundef-fix-2.patch
-reiser4-big-update.patch
-reiser4-big-update-bug-fix-for-readpage.patch
-reiser4-big-update-bug-fix-for-readpage-fix.patch
-reiser4-big-update-rename-print_address.patch
-reiser4-page-private-fixes.patch
-reiser4-big-update-div64-fix.patch
-reiser4-remove-c99isms.patch
-reiser4-use-try_to_freeze.patch
-reiser4-fix-endianess.patch
-reiser4-check-null.patch
-reiser4-fix-built_ptr.patch
-reiser4-key-init-cleanup.patch
-reiser4-fix-list_splice-usage.patch
-reiser4-big-update-spin_macros-fix.patch
-reiser4-spinlock-cleanup.patch
-reiser4-warnings-cleanup.patch
-reiser4_releasepage-gfp_t-fixes.patch
-reiser4-fix-kbuild.patch
-reiser4-remove-rwx-perm-plugin.patch
-reiser4-fix-link_common.patch
-reiser4-fix-readlink.patch
-reiser4-add-crc-sendfile.patch
-reiser4-back-to-one-makefile.patch
-reiser4-rename-cluster-files.patch
-reiser4-crypt2cipher-rename.patch
-reiser4-lock-ordering-fix.patch
-reiser4-improved-comment.patch
-reiser4-try_capture_block-update.patch
-reiser4-fix-zeroing-in-crc-files.patch
-reiser4-atime-update-fix.patch
-reiser4-big-update-update_atime-fixes.patch
-fs-reiser4-possible-cleanups.patch
-reiser4-bugfix-patch.patch
-reiser4-i_sem-mutex-switch.patch
-reiser4-do-not-use-get_user_pages-and-do-not-check.patch
+reiser4.patch
+reiser4fs-use-list_move.patch

 The reiser4 patches were all consolidated together.

+ide-claim-extra-dma-ports-regardless-of-channel.patch
+ide-remove-dma_base2-field-form-ide_hwif_t.patch
+ide-always-release-dma-engine.patch
+ide-ati-sb600-ide-support.patch
+ide-error-handling-fixes.patch
+hpt366-fix-segfault-during-init.patch

 IDE updates.

+md-dm-reduce-stack-usage-with-stacked-block-devices.patch

 MD update.

-kgdb-ga.patch
+kgdb-core-lite.patch
+kgdb-core-lite-add-reboot-command.patch
+kgdb-8250.patch
+kgdb-8250-fix.patch
+kgdb-netpoll_pass_skb_to_rx_hook.patch
+kgdb-eth.patch
+kgdb-i386-lite.patch
+kgdb-cfi_annotations.patch
+kgdb-sysrq_bugfix.patch
+kgdb-module.patch
+kgdb-core.patch
+kgdb-i386.patch

 New kgdb patchset.




All 539 patches:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc1/2.6.17-rc1-mm1/patch-list


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S932214AbWDDOar@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932214AbWDDOar (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 10:30:47 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932215AbWDDOar
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 10:30:47 -0400
Received: from nommos.sslcatacombnetworking.com ([67.18.224.114]:18742 "EHLO
	nommos.sslcatacombnetworking.com") by vger.kernel.org with ESMTP
	id S932214AbWDDOar (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 10:30:47 -0400
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B19E9BA0-E04C-46F2-AC22-113E4D6AC8D3@kernel.crashing.org>
Cc: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 7bit
From: Kumar Gala <galak@kernel.crashing.org>
Subject: Re: 2.6.17-rc1-mm1
Date: Tue, 4 Apr 2006 09:31:10 -0500
To: Andrew Morton <akpm@osdl.org>
X-Mailer: Apple Mail (2.746.3)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - nommos.sslcatacombnetworking.com
X-AntiAbuse: Original Domain - vger.kernel.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - kernel.crashing.org
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>
> Boilerplate:
>
> - See the `hot-fixes' directory for any important updates to this  
> patchset.
>
> - To fetch an -mm tree using git, use (for example)
>
>   git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/ 
> linux-trees.git v2.6.16-rc2-mm1

It doesn't seem like the git tree got updated correctly.  The 2.6.17- 
rc1-mm1 seems to be just 2.6.17-rc1 (just a quick spot check at  
Makefile and a few patches I expected in like the 64-bit resource  
change)

- kumar

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750728AbWDDQCZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750728AbWDDQCZ (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 12:02:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750729AbWDDQCZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 12:02:25 -0400
Received: from mailout.stusta.mhn.de ([141.84.69.5]:45325 "HELO
	mailout.stusta.mhn.de") by vger.kernel.org with SMTP
	id S1750728AbWDDQCZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 12:02:25 -0400
Date: Tue, 4 Apr 2006 18:02:23 +0200
From: Adrian Bunk <bunk@stusta.de>
To: Andrew Morton <akpm@osdl.org>, Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
       Greg Kroah-Hartman <gregkh@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: 2.6.17-mm1: drivers/w1/: patch undoes reasonable cleanups
Message-ID: <20060404160223.GG6529@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
User-Agent: Mutt/1.5.11+cvs20060126
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.16-mm2:
>...
> +gregkh-i2c-w1-userspace-communication-protocol-over-connector.patch
>...
>  I2C tree.
>...

Evgeniy Polyakov did ACK my patch 
a9fb1c7b950bed4afe208c9d67e20f086bb6abbb, and I'm therefore really 
pissed off seeing him silently reverting it for no good reason as part 
of this patch.

Greg, please drop this patch.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750734AbWDDQ31@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750734AbWDDQ31 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 12:29:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750737AbWDDQ31
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 12:29:27 -0400
Received: from mailout.stusta.mhn.de ([141.84.69.5]:65037 "HELO
	mailout.stusta.mhn.de") by vger.kernel.org with SMTP
	id S1750734AbWDDQ3W (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 12:29:22 -0400
Date: Tue, 4 Apr 2006 18:29:21 +0200
From: Adrian Bunk <bunk@stusta.de>
To: Andrew Morton <akpm@osdl.org>, Zachary Amsden <zach@vmware.com>
Cc: linux-kernel@vger.kernel.org, ebiederm@xmission.com, rdunlap@xenotime.net,
       fastboot@osdl.org
Subject: 2.6.17-rc1-mm1: KEXEC became SMP-only
Message-ID: <20060404162921.GK6529@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
User-Agent: Mutt/1.5.11+cvs20060126
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.16-mm2:
>...
> +x86-clean-up-subarch-definitions.patch
>...
>  x86 updates.
>...

The following looks bogus:

 config KEXEC
        bool "kexec system call (EXPERIMENTAL)"
-       depends on EXPERIMENTAL
+       depends on EXPERIMENTAL && (!X86_VOYAGER && SMP)

The dependencies do now say that KEXEC is only offered for machines that 
are _both_ non-Voyager and SMP.

Is the problem you wanted to express that a non-SMP Voyager config 
didn't compile?

AFAIR I recently sent a patch disallowing non-SMP Voyager configurations 
that wasn't yet applied.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750737AbWDDQ3n@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750737AbWDDQ3n (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 12:29:43 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750740AbWDDQ3m
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 12:29:42 -0400
Received: from mailout.stusta.mhn.de ([141.84.69.5]:1038 "HELO
	mailout.stusta.mhn.de") by vger.kernel.org with SMTP
	id S1750738AbWDDQ3h (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 12:29:37 -0400
Date: Tue, 4 Apr 2006 18:29:35 +0200
From: Adrian Bunk <bunk@stusta.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Zachary Amsden <zach@vmware.com>
Subject: [-mm patch] i386: pre_intr_init_hook optimization
Message-ID: <20060404162935.GL6529@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
User-Agent: Mutt/1.5.11+cvs20060126
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.16-mm2:
>...
> +x86-clean-up-subarch-definitions.patch
>...
>  x86 updates.
>...

Let's make the kernel smaller for everyone.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 arch/i386/kernel/i8259.c      |   13 ++++++++++++-
 include/asm-i386/arch_hooks.h |   14 --------------
 2 files changed, 12 insertions(+), 15 deletions(-)

--- linux-2.6.17-rc1-mm1-full/include/asm-i386/arch_hooks.h.old	2006-04-04 16:54:15.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/include/asm-i386/arch_hooks.h	2006-04-04 16:56:14.000000000 +0200
@@ -44,20 +44,6 @@
 /* these are the default hooks */
 
 /**
- * pre_intr_init_hook - initialisation prior to setting up interrupt vectors
- *
- * Description:
- *	Perform any necessary interrupt initialisation prior to setting up
- *	the "ordinary" interrupt call gates.  For legacy reasons, the ISA
- *	interrupts should be initialised here if the machine emulates a PC
- *	in any way.
- **/
-#ifndef pre_intr_init_hook
-#define pre_intr_init_hook() init_ISA_irqs()
-#endif
-
-
-/**
  * intr_init_hook - post gate setup interrupt initialisation
  *
  * Description:
--- linux-2.6.17-rc1-mm1-full/arch/i386/kernel/i8259.c.old	2006-04-04 16:55:01.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/arch/i386/kernel/i8259.c	2006-04-04 16:56:08.000000000 +0200
@@ -368,7 +368,17 @@
  */
 static struct irqaction fpu_irq = { math_error_irq, 0, CPU_MASK_NONE, "fpu", NULL, NULL };
 
-void __init init_ISA_irqs (void)
+/**
+ * pre_intr_init_hook - initialisation prior to setting up interrupt vectors
+ *
+ * Description:
+ *	Perform any necessary interrupt initialisation prior to setting up
+ *	the "ordinary" interrupt call gates.  For legacy reasons, the ISA
+ *	interrupts should be initialised here if the machine emulates a PC
+ *	in any way.
+ **/
+#ifndef pre_intr_init_hook
+static void __init pre_intr_init_hook(void)
 {
 	int i;
 
@@ -395,6 +405,7 @@
 		}
 	}
 }
+#endif  /*  pre_intr_init_hook  */
 
 void __init init_IRQ(void)
 {


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750738AbWDDQaq@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750738AbWDDQaq (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 12:30:46 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750751AbWDDQah
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 12:30:37 -0400
Received: from mailout.stusta.mhn.de ([141.84.69.5]:4366 "HELO
	mailout.stusta.mhn.de") by vger.kernel.org with SMTP
	id S1750738AbWDDQaD (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 12:30:03 -0400
Date: Tue, 4 Apr 2006 18:30:01 +0200
From: Adrian Bunk <bunk@stusta.de>
To: Andrew Morton <akpm@osdl.org>, Martin Samuelsson <sam@home.se>
Cc: linux-kernel@vger.kernel.org,
       Mauro Carvalho Chehab <mchehab@infradead.org>,
       Johannes Stezenbach <js@linuxtv.org>, v4l-dvb-maintainer@linuxtv.org
Subject: [-mm patch] drivers/media/video/bt866.c: small fixes
Message-ID: <20060404163001.GO6529@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
User-Agent: Mutt/1.5.11+cvs20060126
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.16-mm2:
>...
> +avermedia-6-eyes-avs6eyes-support.patch
>...
>  New v4l driver, and a fix.
>...

This patch contains the following fixes:
- no need to hide MODULE_LICENSE() behind an #ifdef
- use module_{init,exit}; this also fixes the bug that bt866_init()
  was never called

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/media/video/bt866.c |   15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

--- linux-2.6.17-rc1-mm1-full/drivers/media/video/bt866.c.old	2006-04-04 17:31:55.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/media/video/bt866.c	2006-04-04 17:33:38.000000000 +0200
@@ -51,9 +51,7 @@
 
 #include <linux/video_encoder.h>
 
-#ifdef MODULE_LICENSE
 MODULE_LICENSE("GPL");
-#endif
 
 #define DEBUG(x)   		/* Debug driver */
 
@@ -372,22 +370,19 @@
 /****************************************************************************
 * linux kernel module api
 ****************************************************************************/
-#ifdef MODULE
-int init_module(void)
-#else
-int bt866_init(void)
-#endif
+static int __devinit bt866_init(void)
 {
 	i2c_add_driver(&i2c_driver_bt866);
 	return 0;
 }
 
-#ifdef MODULE
-void cleanup_module(void)
+static void __devexit bt866_exit(void)
 {
 	i2c_del_driver(&i2c_driver_bt866);
 }
-#endif
+
+module_init(bt866_init);
+module_exit(bt866_exit);
 
 /*
  * Overrides for Emacs so that we follow Linus's tabbing style.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750746AbWDDQiz@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750746AbWDDQiz (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 12:38:55 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750751AbWDDQiz
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 12:38:55 -0400
Received: from relay.2ka.mipt.ru ([194.85.82.65]:14240 "EHLO 2ka.mipt.ru")
	by vger.kernel.org with ESMTP id S1750746AbWDDQiy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 12:38:54 -0400
Date: Tue, 4 Apr 2006 20:35:22 +0400
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Adrian Bunk <bunk@stusta.de>
Cc: Andrew Morton <akpm@osdl.org>, Greg Kroah-Hartman <gregkh@suse.de>,
       linux-kernel@vger.kernel.org
Subject: Re: 2.6.17-mm1: drivers/w1/: patch undoes reasonable cleanups
Message-ID: <20060404163522.GA29486@2ka.mipt.ru>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404160223.GG6529@stusta.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <20060404160223.GG6529@stusta.de>
User-Agent: Mutt/1.5.9i
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [0.0.0.0]); Tue, 04 Apr 2006 20:35:23 +0400 (MSD)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006 at 06:02:23PM +0200, Adrian Bunk (bunk@stusta.de) wrote:
> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.16-mm2:
> >...
> > +gregkh-i2c-w1-userspace-communication-protocol-over-connector.patch
> >...
> >  I2C tree.
> >...
> 
> Evgeniy Polyakov did ACK my patch 
> a9fb1c7b950bed4afe208c9d67e20f086bb6abbb, and I'm therefore really 
> pissed off seeing him silently reverting it for no good reason as part 
> of this patch.
> 
> Greg, please drop this patch.

I'm really sorry, Adrian, if you feel it this way.
I converted your patch to the new tree.

Peace? :)

----
Nice cleanup spotted by Adrian Bunk, which was lost due to moving to the
completely new functionality.
		Shame-shame-shame on me.

Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>

diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 6c23b38..174ac2b 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -214,11 +214,12 @@ struct device w1_master_device = {
 	.release = &w1_master_release
 };
 
-struct device_driver w1_slave_driver = {
+static struct device_driver w1_slave_driver = {
 	.name = "w1_slave_driver",
 	.bus = &w1_bus_type,
 };
 
+#if 0
 struct device w1_slave_device = {
 	.parent = NULL,
 	.bus = &w1_bus_type,
@@ -226,6 +227,7 @@ struct device w1_slave_device = {
 	.driver = &w1_slave_driver,
 	.release = &w1_slave_release
 };
+#endif  /*  0  */
 
 static ssize_t w1_master_attribute_show_name(struct device *dev, struct device_attribute *attr, char *buf)
 {
@@ -383,7 +385,7 @@ int w1_create_master_attributes(struct w
 	return sysfs_create_group(&master->dev.kobj, &w1_master_defattr_group);
 }
 
-void w1_destroy_master_attributes(struct w1_master *master)
+static void w1_destroy_master_attributes(struct w1_master *master)
 {
 	sysfs_remove_group(&master->dev.kobj, &w1_master_defattr_group);
 }
diff --git a/drivers/w1/w1.h b/drivers/w1/w1.h
index f5ad81d..deb3c13 100644
--- a/drivers/w1/w1.h
+++ b/drivers/w1/w1.h
@@ -213,6 +213,16 @@ static inline struct w1_master* dev_to_w
 	return container_of(dev, struct w1_master, dev);
 }
 
+extern struct device_driver w1_master_driver;
+extern struct bus_type w1_bus_type;
+extern struct device w1_master_device;
+extern int w1_max_slave_count;
+extern int w1_max_slave_ttl;
+extern struct list_head w1_masters;
+extern struct mutex w1_mlock;
+
+extern int w1_process(void *);
+
 #endif /* __KERNEL__ */
 
 #endif /* __W1_H */
diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
index 24e7c10..475996c 100644
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -30,16 +30,6 @@
 
 static u32 w1_ids = 1;
 
-extern struct device_driver w1_master_driver;
-extern struct bus_type w1_bus_type;
-extern struct device w1_master_device;
-extern int w1_max_slave_count;
-extern int w1_max_slave_ttl;
-extern struct list_head w1_masters;
-extern struct mutex w1_mlock;
-
-extern int w1_process(void *);
-
 static struct w1_master * w1_alloc_dev(u32 id, int slave_count, int slave_ttl,
 				       struct device_driver *driver,
 				       struct device *device)
@@ -96,7 +86,7 @@ static struct w1_master * w1_alloc_dev(u
 	return dev;
 }
 
-void w1_free_dev(struct w1_master *dev)
+static void w1_free_dev(struct w1_master *dev)
 {
 	device_unregister(&dev->dev);
 }

> cu
> Adrian

-- 
	Evgeniy Polyakov

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750743AbWDDQb0@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750743AbWDDQb0 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 12:31:26 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750755AbWDDQac
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 12:30:32 -0400
Received: from mailout.stusta.mhn.de ([141.84.69.5]:7438 "HELO
	mailout.stusta.mhn.de") by vger.kernel.org with SMTP
	id S1750752AbWDDQaM (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 12:30:12 -0400
Date: Tue, 4 Apr 2006 18:30:10 +0200
From: Adrian Bunk <bunk@stusta.de>
To: Andrew Morton <akpm@osdl.org>, NeilBrown <neilb@suse.de>
Cc: linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net
Subject: [-mm patch] fs/nfsd/nfs4state.c: make a struct static
Message-ID: <20060404163010.GQ6529@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
User-Agent: Mutt/1.5.11+cvs20060126
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.16-mm2:
>...
> +knfsd-locks-flag-nfsv4-owned-locks.patch
>...
>  knfsd updates.
>...

This patch makes the needlessly global struct nfsd_posix_mng_ops static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-rc1-mm1-full/fs/nfsd/nfs4state.c.old	2006-04-04 18:03:25.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/fs/nfsd/nfs4state.c	2006-04-04 18:03:38.000000000 +0200
@@ -2507,7 +2507,7 @@
 
 /* Hack!: For now, we're defining this just so we can use a pointer to it
  * as a unique cookie to identify our (NFSv4's) posix locks. */
-struct lock_manager_operations nfsd_posix_mng_ops  = {
+static struct lock_manager_operations nfsd_posix_mng_ops  = {
 };
 
 static inline void

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750766AbWDDRQR@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750766AbWDDRQR (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 13:16:17 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750769AbWDDRQQ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 13:16:16 -0400
Received: from mailout1.vmware.com ([65.113.40.130]:52485 "EHLO
	mailout1.vmware.com") by vger.kernel.org with ESMTP
	id S1750766AbWDDRQQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 13:16:16 -0400
Message-ID: <4432A9D2.7090503@vmware.com>
Date: Tue, 04 Apr 2006 10:16:02 -0700
From: Zachary Amsden <zach@vmware.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Adrian Bunk <bunk@stusta.de>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [-mm patch] i386: pre_intr_init_hook optimization
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404162935.GL6529@stusta.de>
In-Reply-To: <20060404162935.GL6529@stusta.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Adrian Bunk wrote:
> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>   
>> ...
>> Changes since 2.6.16-mm2:
>> ...
>> +x86-clean-up-subarch-definitions.patch
>> ...
>>  x86 updates.
>> ...
>>     
>
> Let's make the kernel smaller for everyone.
>
>   
Looks fine.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750771AbWDDRhS@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750771AbWDDRhS (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 13:37:18 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750751AbWDDRhS
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 13:37:18 -0400
Received: from mailout1.vmware.com ([65.113.40.130]:3341 "EHLO
	mailout1.vmware.com") by vger.kernel.org with ESMTP
	id S1750771AbWDDRhR (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 13:37:17 -0400
Message-ID: <4432AB57.1040006@vmware.com>
Date: Tue, 04 Apr 2006 10:22:31 -0700
From: Zachary Amsden <zach@vmware.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Adrian Bunk <bunk@stusta.de>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org,
       ebiederm@xmission.com, rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404162921.GK6529@stusta.de>
In-Reply-To: <20060404162921.GK6529@stusta.de>
Content-Type: multipart/mixed;
 boundary="------------040706000709010304070503"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

This is a multi-part message in MIME format.
--------------040706000709010304070503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Adrian Bunk wrote:
> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>   
>> ...
>> Changes since 2.6.16-mm2:
>> ...
>> +x86-clean-up-subarch-definitions.patch
>> ...
>>  x86 updates.
>> ...
>>     
>
> The following looks bogus:
>
>  config KEXEC
>         bool "kexec system call (EXPERIMENTAL)"
> -       depends on EXPERIMENTAL
> +       depends on EXPERIMENTAL && (!X86_VOYAGER && SMP)
>
> The dependencies do now say that KEXEC is only offered for machines that 
> are _both_ non-Voyager and SMP.
>
> Is the problem you wanted to express that a non-SMP Voyager config 
> didn't compile?
>   

Whoops, that should be

depends on EXPERIMENTAL && !(X86_VOYAGER && SMP)

Voyager SMP builds don't compile with kexec(), and it isn't clear how to 
shootdown CPUs using NMIs without an APIC.

--------------040706000709010304070503
Content-Type: text/plain;
 name="voyager-smp-bogosity"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="voyager-smp-bogosity"

Signed-off-by: Zachary Amsden <zach@vmware.com>

Index: linux-2.6.16.1/arch/i386/Kconfig
===================================================================
--- linux-2.6.16.1.orig/arch/i386/Kconfig	2006-04-03 12:37:11.000000000 -0700
+++ linux-2.6.16.1/arch/i386/Kconfig	2006-04-04 10:18:25.000000000 -0700
@@ -813,7 +813,7 @@ source kernel/Kconfig.hz
 
 config KEXEC
 	bool "kexec system call (EXPERIMENTAL)"
-	depends on EXPERIMENTAL && (!X86_VOYAGER && SMP)
+	depends on EXPERIMENTAL && !(X86_VOYAGER && SMP)
 	help
 	  kexec is a system call that implements the ability to shutdown your
 	  current kernel, and to start another kernel.  It is like a reboot

--------------040706000709010304070503--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750773AbWDDRoZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750773AbWDDRoZ (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 13:44:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750774AbWDDRoZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 13:44:25 -0400
Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:50062 "EHLO
	ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP
	id S1750773AbWDDRoZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 13:44:25 -0400
To: Adrian Bunk <bunk@stusta.de>
Cc: Andrew Morton <akpm@osdl.org>, Zachary Amsden <zach@vmware.com>,
       linux-kernel@vger.kernel.org, rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404162921.GK6529@stusta.de>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 04 Apr 2006 11:43:01 -0600
In-Reply-To: <20060404162921.GK6529@stusta.de> (Adrian Bunk's message of
 "Tue, 4 Apr 2006 18:29:21 +0200")
Message-ID: <m1acb15ja2.fsf@ebiederm.dsl.xmission.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Adrian Bunk <bunk@stusta.de> writes:

> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>>...
>> Changes since 2.6.16-mm2:
>>...
>> +x86-clean-up-subarch-definitions.patch
>>...
>>  x86 updates.
>>...
>
> The following looks bogus:

It is. 

>
>  config KEXEC
>         bool "kexec system call (EXPERIMENTAL)"
> -       depends on EXPERIMENTAL
> +       depends on EXPERIMENTAL && (!X86_VOYAGER && SMP)
>
> The dependencies do now say that KEXEC is only offered for machines that 
> are _both_ non-Voyager and SMP.
>
> Is the problem you wanted to express that a non-SMP Voyager config 
> didn't compile?
>
> AFAIR I recently sent a patch disallowing non-SMP Voyager configurations 
> that wasn't yet applied.

I think this cleanup patch is even going in the wrong direction.  The
subarch code right now is a real pain because it is never clear when
you are calling a function with multiple definitions.  Which makes it
really easy to break.

If we are going to refactor this can we please move in the direction
of a machine vector like alpha, ppc, and arm.  I don't see the current
this cleanup making it any easier to tell there is code in a subarch.

Eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750775AbWDDRvp@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750775AbWDDRvp (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 13:51:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750777AbWDDRvp
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 13:51:45 -0400
Received: from mailout1.vmware.com ([65.113.40.130]:29956 "EHLO
	mailout1.vmware.com") by vger.kernel.org with ESMTP
	id S1750775AbWDDRvp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 13:51:45 -0400
Message-ID: <4432B22F.6090803@vmware.com>
Date: Tue, 04 Apr 2006 10:51:43 -0700
From: Zachary Amsden <zach@vmware.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Adrian Bunk <bunk@stusta.de>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org, rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org>	<20060404162921.GK6529@stusta.de> <m1acb15ja2.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <m1acb15ja2.fsf@ebiederm.dsl.xmission.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Eric W. Biederman wrote:
> Adrian Bunk <bunk@stusta.de> writes:
>
>   
>> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>>     
>>> ...
>>> Changes since 2.6.16-mm2:
>>> ...
>>> +x86-clean-up-subarch-definitions.patch
>>> ...
>>>  x86 updates.
>>> ...
>>>       
>> The following looks bogus:
>>     
>
> It is. 
>
>   
>>  config KEXEC
>>         bool "kexec system call (EXPERIMENTAL)"
>> -       depends on EXPERIMENTAL
>> +       depends on EXPERIMENTAL && (!X86_VOYAGER && SMP)
>>
>> The dependencies do now say that KEXEC is only offered for machines that 
>> are _both_ non-Voyager and SMP.
>>
>> Is the problem you wanted to express that a non-SMP Voyager config 
>> didn't compile?
>>
>> AFAIR I recently sent a patch disallowing non-SMP Voyager configurations 
>> that wasn't yet applied.
>>     
>
> I think this cleanup patch is even going in the wrong direction.  The
> subarch code right now is a real pain because it is never clear when
> you are calling a function with multiple definitions.  Which makes it
> really easy to break.
>   
> If we are going to refactor this can we please move in the direction
> of a machine vector like alpha, ppc, and arm.  I don't see the current
> this cleanup making it any easier to tell there is code in a subarch.
>   

No, this cleanup only eliminates the need to duplicate redundant code.   
How does a machine vector make it any harder to break?  You still have a 
function with multiple definitions.  Duplicating code makes things 
really easy to break - twice.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750779AbWDDRwG@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750779AbWDDRwG (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 13:52:06 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750777AbWDDRwF
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 13:52:05 -0400
Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:57742 "EHLO
	ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP
	id S1750779AbWDDRwC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 13:52:02 -0400
To: Zachary Amsden <zach@vmware.com>
Cc: Adrian Bunk <bunk@stusta.de>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org, rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404162921.GK6529@stusta.de> <4432AB57.1040006@vmware.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 04 Apr 2006 11:50:49 -0600
In-Reply-To: <4432AB57.1040006@vmware.com> (Zachary Amsden's message of
 "Tue, 04 Apr 2006 10:22:31 -0700")
Message-ID: <m1vetp44cm.fsf@ebiederm.dsl.xmission.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Zachary Amsden <zach@vmware.com> writes:

> Adrian Bunk wrote:
>> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>>
>>> ...
>>> Changes since 2.6.16-mm2:
>>> ...
>>> +x86-clean-up-subarch-definitions.patch
>>> ...
>>>  x86 updates.
>>> ...
>>>
>>
>> The following looks bogus:
>>
>>  config KEXEC
>>         bool "kexec system call (EXPERIMENTAL)"
>> -       depends on EXPERIMENTAL
>> +       depends on EXPERIMENTAL && (!X86_VOYAGER && SMP)
>>
>> The dependencies do now say that KEXEC is only offered for machines that are
>> _both_ non-Voyager and SMP.
>>
>> Is the problem you wanted to express that a non-SMP Voyager config didn't
>> compile?
>>
>
> Whoops, that should be
>
> depends on EXPERIMENTAL && !(X86_VOYAGER && SMP)
>
> Voyager SMP builds don't compile with kexec(), and it isn't clear how to
> shootdown CPUs using NMIs without an APIC.

Well unless you need the crash dump functionality you don't need to
shot down CPUs using NMIs.

So I expect machine_crash_shutdown or at least a part of it
should be a call into the subarchitecture code.  Having
it be a noop on voyager would be perfectly fine.  


Eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750792AbWDDSg1@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750792AbWDDSg1 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 14:36:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750794AbWDDSg1
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 14:36:27 -0400
Received: from smtp1.home.se ([212.78.199.21]:30317 "EHLO smtp1.home.se")
	by vger.kernel.org with ESMTP id S1750792AbWDDSg0 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 14:36:26 -0400
Date: Tue, 4 Apr 2006 20:32:19 +0200
From: Martin Samuelsson <sam@home.se>
To: Adrian Bunk <bunk@stusta.de>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, mchehab@infradead.org,
       js@linuxtv.org, v4l-dvb-maintainer@linuxtv.org
Subject: Re: [-mm patch] drivers/media/video/bt866.c: small fixes
Message-Id: <20060404203219.40fe6b4c.sam@home.se>
In-Reply-To: <20060404163001.GO6529@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404163001.GO6529@stusta.de>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

An extension to Adrian's patch:
- Numerous coding style compliance fixes.
- Obscure defines moved to prominent places.
- sizeof(init) replaced by ARRAY_SIZE(init).
- schedule_timeout() replaced by schedule_timeout_interruptible().

Signed-off-by: Martin Samuelsson <sam@home.se>

---

 bt866.c |   67 +++++++++++++++++++++++++++-------------------------------------
 1 files changed, 29 insertions(+), 38 deletions(-)

This should fix all things Andrew pointed out when I first submitted the 
avs6eyes driver.

--- linux-2.6.17-rc1-mm1-ab-avs6eyes/drivers/media/video/bt866.c	2006-04-04 22:13:01.000000000 +0200
+++ linux-2.6.16-git15-avs6eyes/drivers/media/video/bt866.c	2006-04-04 22:00:32.000000000 +0200
@@ -51,9 +51,12 @@
 
 #include <linux/video_encoder.h>
 
+#define	BT866_DEVNAME	"bt866"
+#define I2C_BT866	0x88
+
 MODULE_LICENSE("GPL");
 
-#define DEBUG(x)   		/* Debug driver */
+#define DEBUG(x)		/* Debug driver */
 
 /* ----------------------------------------------------------------------- */
 
@@ -70,8 +73,6 @@ struct bt866 {
 	int sat;
 };
 
-#define   I2C_BT866	0x88
-
 static int bt866_write(struct bt866 *dev,
 			unsigned char subaddr, unsigned char data);
 
@@ -152,9 +153,8 @@ static int bt866_do_command(struct bt866
 		int i;
 		u8 val;
 
-		for (i = 0; i < sizeof(init) / 2; i += 2) {
+		for (i = 0; i < ARRAY_SIZE(init) / 2; i += 2)
 			bt866_write(encoder, init[i], init[i+1]);
-		}
 
 		val = encoder->reg[0xdc];
 
@@ -162,7 +162,6 @@ static int bt866_do_command(struct bt866
 			val |= 0x40; /* CBSWAP */
 		else
 			val &= ~0x40; /* !CBSWAP */
-		//debug printk("0xdc = 0x%02x\n", val);
 
 		bt866_write(encoder, 0xdc, val);
 
@@ -196,9 +195,8 @@ static int bt866_do_command(struct bt866
 			     encoder->i2c->name, *iarg));
 
 		/* not much choice of outputs */
-		if (*iarg != 0) {
+		if (*iarg != 0)
 			return -EINVAL;
-		}
 	}
 	break;
 
@@ -236,8 +234,6 @@ static int bt866_do_command(struct bt866
 	return 0;
 }
 
-#define	BT866_DEVNAME "bt866"
-
 static int bt866_write(struct bt866 *encoder,
 			unsigned char subaddr, unsigned char data)
 {
@@ -250,19 +246,20 @@ static int bt866_write(struct bt866 *enc
 	encoder->reg[subaddr] = data;
 
 	DEBUG(printk
-	      ( "%s: write 0x%02X = 0x%02X\n",
+	      ("%s: write 0x%02X = 0x%02X\n",
 	       encoder->i2c->name, subaddr, data));
 
 	for (err = 0; err < 3;) {
-		if (2 == i2c_master_send(encoder->i2c, buffer, 2))
+		if (i2c_master_send(encoder->i2c, buffer, 2) == 2)
 			break;
 		err++;
-		printk(KERN_WARNING "%s: I/O error #%d (write 0x%02x/0x%02x)\n",
+		printk(KERN_WARNING "%s: I/O error #%d "
+		       "(write 0x%02x/0x%02x)\n",
 		       encoder->i2c->name, err, encoder->addr, subaddr);
 		current->state = TASK_INTERRUPTIBLE;
-		schedule_timeout(HZ/10);
+		schedule_timeout_interruptible(HZ/10);
 	}
-	if (3 == err) {
+	if (err == 3) {
 		printk(KERN_WARNING "%s: giving up\n",
 		       encoder->i2c->name);
 		return -1;
@@ -273,13 +270,14 @@ static int bt866_write(struct bt866 *enc
 
 static int bt866_attach(struct i2c_adapter *adapter);
 static int bt866_detach(struct i2c_client *client);
-static int bt866_command(struct i2c_client *client, unsigned int cmd, void *arg );
+static int bt866_command(struct i2c_client *client,
+			 unsigned int cmd, void *arg);
 
 
 /* Addresses to scan */
-static unsigned short normal_i2c[]	=	{ I2C_BT866>>1, I2C_CLIENT_END };
-static unsigned short probe[2]		= 	{ I2C_CLIENT_END, I2C_CLIENT_END };
-static unsigned short ignore[2]		=	{ I2C_CLIENT_END, I2C_CLIENT_END };
+static unsigned short normal_i2c[]	= {I2C_BT866>>1, I2C_CLIENT_END};
+static unsigned short probe[2]		= {I2C_CLIENT_END, I2C_CLIENT_END};
+static unsigned short ignore[2]		= {I2C_CLIENT_END, I2C_CLIENT_END};
 
 static struct i2c_client_address_data addr_data = {
 	normal_i2c,
@@ -288,12 +286,8 @@ static struct i2c_client_address_data ad
 };
 
 static struct i2c_driver i2c_driver_bt866 = {
-	.driver = {
-		.name = BT866_DEVNAME,
-	},
-
+	.driver.name = BT866_DEVNAME,
 	.id = I2C_DRIVERID_BT866,
-
 	.attach_adapter = bt866_attach,
 	.detach_client = bt866_detach,
 	.command = bt866_command
@@ -302,11 +296,11 @@ static struct i2c_driver i2c_driver_bt86
 
 static struct i2c_client bt866_client_tmpl =
 {
-	name:		"(nil)",
-	addr:		0,
-	adapter:	NULL,
-	driver:		&i2c_driver_bt866,
-	usage_count:	0
+	.name = "(nil)",
+	.addr = 0,
+	.adapter = NULL,
+	.driver = &i2c_driver_bt866,
+	.usage_count = 0
 };
 
 static int bt866_found_proc(struct i2c_adapter *adapter,
@@ -316,13 +310,13 @@ static int bt866_found_proc(struct i2c_a
 	struct i2c_client *client;
 
 	client = kzalloc(sizeof(*client), GFP_KERNEL);
-	if(client == NULL)
+	if (client == NULL)
 		return -ENOMEM;
-	memcpy( client, &bt866_client_tmpl, sizeof(*client) );
+	memcpy(client, &bt866_client_tmpl, sizeof(*client));
 
-	encoder = kzalloc( sizeof(*encoder), GFP_KERNEL );
-	if( encoder == NULL ) {
-		kfree( client );
+	encoder = kzalloc(sizeof(*encoder), GFP_KERNEL);
+	if (encoder == NULL) {
+		kfree(client);
 		return -ENOMEM;
 	}
 
@@ -344,7 +338,7 @@ static int bt866_found_proc(struct i2c_a
 
 static int bt866_attach(struct i2c_adapter *adapter)
 {
-	if ( adapter->id == I2C_HW_B_ZR36067 )
+	if (adapter->id == I2C_HW_B_ZR36067)
 		return i2c_probe(adapter, &addr_data, bt866_found_proc);
 	return 0;
 }
@@ -367,9 +361,6 @@ static int bt866_command(struct i2c_clie
 	return bt866_do_command(encoder, cmd, arg);
 }
 
-/****************************************************************************
-* linux kernel module api
-****************************************************************************/
 static int __devinit bt866_init(void)
 {
 	i2c_add_driver(&i2c_driver_bt866);

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750798AbWDDSog@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750798AbWDDSog (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 14:44:36 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750797AbWDDSof
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 14:44:35 -0400
Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:31887 "EHLO
	ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP
	id S1750796AbWDDSoe (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 14:44:34 -0400
To: Zachary Amsden <zach@vmware.com>
Cc: Adrian Bunk <bunk@stusta.de>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org, rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404162921.GK6529@stusta.de>
	<m1acb15ja2.fsf@ebiederm.dsl.xmission.com>
	<4432B22F.6090803@vmware.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 04 Apr 2006 12:43:26 -0600
In-Reply-To: <4432B22F.6090803@vmware.com> (Zachary Amsden's message of
 "Tue, 04 Apr 2006 10:51:43 -0700")
Message-ID: <m1irpp41wx.fsf@ebiederm.dsl.xmission.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Zachary Amsden <zach@vmware.com> writes:

> No, this cleanup only eliminates the need to duplicate redundant code.   How
> does a machine vector make it any harder to break?  You still have a function
> with multiple definitions.  Duplicating code makes things really easy to break -
> twice.

Sharing functions is good, but if you don't share things carefully your code
becomes very brittle because it depends in non obvious ways on other
code.

A machine vector isn't exactly what is needed (although that allows building
all of the subarches at the same time).  What is needed are clear places
where the sub architectures get called.

The lack of visibility is what makes subarch code so easy to break right now.

I have had times where I have made a global change and fixed up the entire
kernel and all that broke was the i386 subarchitectures because there
was a dependency but it was totally invisible.  Despite testing on and
being most familiar with i386.

For example every other arch only has one implementation
of machine_restart, machine_halt, machine_power_off, and if they
have subarchitectures they have calls to subarch_restart, subarch_halt,
and subarch_power_off.  At which point it is trivial to see that
the code lives in a subarchitecture.

Even if that code turns right around and calls a common function on
all but one of the subarchitectures, at least the logic is visible when
you read the code.

If all you are doing is this one little clean up we can probably stop here.
But this looks like a start on getting a vmi or xen subarch working.

If this is really a prelude to introducing more subarchitectures we
need to fix the infrastructure, so it is obvious what is going on.
I would really like to see a machine vector, so we could compile in
multiple subarchitectures at the same time.  That makes building
a generic kernel easier, and the requirement that the we need
to build a generic kernel makes the structure of the subarchiteture
hooks hierarchical and you wind up with code whose dependencies
are visible.  Instead of the current linker and preprocessor magic.
Functions named hook are impossible to comprehend what they
are supposed to do while reading through the code.

Eric


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750824AbWDDT0V@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750824AbWDDT0V (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 15:26:21 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750825AbWDDT0V
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 15:26:21 -0400
Received: from mailout1.vmware.com ([65.113.40.130]:63499 "EHLO
	mailout1.vmware.com") by vger.kernel.org with ESMTP
	id S1750824AbWDDT0U (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 15:26:20 -0400
Message-ID: <4432C7AC.9020106@vmware.com>
Date: Tue, 04 Apr 2006 12:23:24 -0700
From: Zachary Amsden <zach@vmware.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Adrian Bunk <bunk@stusta.de>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org, rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org>	<20060404162921.GK6529@stusta.de>	<m1acb15ja2.fsf@ebiederm.dsl.xmission.com>	<4432B22F.6090803@vmware.com> <m1irpp41wx.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <m1irpp41wx.fsf@ebiederm.dsl.xmission.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Eric W. Biederman wrote:
>
> If all you are doing is this one little clean up we can probably stop here.
> But this looks like a start on getting a vmi or xen subarch working.
>   

Yes, that is certainly part of the purpose.  But the subarch layer 
really should be cleaned up, and getting rid of code duplication seems 
like a good first step.

> If this is really a prelude to introducing more subarchitectures we
> need to fix the infrastructure, so it is obvious what is going on.
> I would really like to see a machine vector, so we could compile in
> multiple subarchitectures at the same time.  That makes building
> a generic kernel easier, and the requirement that the we need
> to build a generic kernel makes the structure of the subarchiteture
> hooks hierarchical and you wind up with code whose dependencies
> are visible.  Instead of the current linker and preprocessor magic.
> Functions named hook are impossible to comprehend what they
> are supposed to do while reading through the code.
>   

I see your point.  Are you thinking of something like:

struct subarch_hooks subarch_hook_vector = {
     .machine_power_off = machine_power_off,
     .machine_halt = machine_halt,
     .machine_irq_setup = machine_irq_setup,
     .machine_subarch_setup = machine_subarch_probe
     ...
};

And machine_subarch_probe can dynamically change this vector if it 
confirms that the platform is appropriate?

This gets rid of both the code duplication and makes it somewhat more 
obvious what is going on - plus it is easy to extend to other functions, 
and as a bonus feature, you don't need to change any code in other 
subarchitectures if you need to add a new hook.


Zach

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750749AbWDDTjp@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750749AbWDDTjp (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 15:39:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750827AbWDDTjp
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 15:39:45 -0400
Received: from mtaout2.012.net.il ([84.95.2.4]:3250 "EHLO mtaout2.012.net.il")
	by vger.kernel.org with ESMTP id S1750749AbWDDTjp (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 15:39:45 -0400
Date: Tue, 04 Apr 2006 22:38:55 +0300
From: Muli Ben-Yehuda <mulix@mulix.org>
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
In-reply-to: <4432C7AC.9020106@vmware.com>
To: Zachary Amsden <zach@vmware.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>, Adrian Bunk <bunk@stusta.de>,
       Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org,
       rdunlap@xenotime.net, fastboot@osdl.org
Message-id: <20060404193855.GC1221@granada.merseine.nu>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <20060404014504.564bf45a.akpm@osdl.org>
 <20060404162921.GK6529@stusta.de> <m1acb15ja2.fsf@ebiederm.dsl.xmission.com>
 <4432B22F.6090803@vmware.com> <m1irpp41wx.fsf@ebiederm.dsl.xmission.com>
 <4432C7AC.9020106@vmware.com>
User-Agent: Mutt/1.5.11+cvs20060126
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006 at 12:23:24PM -0700, Zachary Amsden wrote:

> This gets rid of both the code duplication and makes it somewhat more 
> obvious what is going on - plus it is easy to extend to other functions, 
> and as a bonus feature, you don't need to change any code in other 
> subarchitectures if you need to add a new hook.

ppc has 'struct machdep_calls' (asm-powerpc/machdep.h) which serves
the same purpose, and it's indeed a clean way of doing this sort of
thing.

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750853AbWDDUaK@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750853AbWDDUaK (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 16:30:10 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750855AbWDDUaK
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 16:30:10 -0400
Received: from smtp.osdl.org ([65.172.181.4]:13518 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1750853AbWDDUaI (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 16:30:08 -0400
Date: Tue, 4 Apr 2006 13:25:46 -0700
From: Andrew Morton <akpm@osdl.org>
To: Zachary Amsden <zach@vmware.com>
Cc: ebiederm@xmission.com, bunk@stusta.de, linux-kernel@vger.kernel.org,
       rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
Message-Id: <20060404132546.565b3dae.akpm@osdl.org>
In-Reply-To: <4432C7AC.9020106@vmware.com>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404162921.GK6529@stusta.de>
	<m1acb15ja2.fsf@ebiederm.dsl.xmission.com>
	<4432B22F.6090803@vmware.com>
	<m1irpp41wx.fsf@ebiederm.dsl.xmission.com>
	<4432C7AC.9020106@vmware.com>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Zachary Amsden <zach@vmware.com> wrote:
>
> > If this is really a prelude to introducing more subarchitectures we
>  > need to fix the infrastructure, so it is obvious what is going on.
>  > I would really like to see a machine vector, so we could compile in
>  > multiple subarchitectures at the same time.  That makes building
>  > a generic kernel easier, and the requirement that the we need
>  > to build a generic kernel makes the structure of the subarchiteture
>  > hooks hierarchical and you wind up with code whose dependencies
>  > are visible.  Instead of the current linker and preprocessor magic.
>  > Functions named hook are impossible to comprehend what they
>  > are supposed to do while reading through the code.
>  >   
> 
>  I see your point.  Are you thinking of something like:
> 
>  struct subarch_hooks subarch_hook_vector = {
>       .machine_power_off = machine_power_off,
>       .machine_halt = machine_halt,
>       .machine_irq_setup = machine_irq_setup,
>       .machine_subarch_setup = machine_subarch_probe
>       ...
>  };
> 
>  And machine_subarch_probe can dynamically change this vector if it 
>  confirms that the platform is appropriate?

I don't recall anyone expressing any desire for the ability to set these
things at runtime.  Unless there is such a requirement I'd suggest that the
best way to address Eric's point is to simply rename the relevant functions
from foo() to subarch_foo().


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750881AbWDDVGq@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750881AbWDDVGq (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 17:06:46 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750878AbWDDVGq
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 17:06:46 -0400
Received: from ogre.sisk.pl ([217.79.144.158]:47754 "EHLO ogre.sisk.pl")
	by vger.kernel.org with ESMTP id S1750879AbWDDVGq (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 17:06:46 -0400
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Andrew Morton <akpm@osdl.org>
Subject: Re: 2.6.17-rc1-mm1: mlockall() regression on x86_64
Date: Tue, 4 Apr 2006 22:53:05 +0200
User-Agent: KMail/1.9.1
Cc: linux-kernel@vger.kernel.org
References: <20060404014504.564bf45a.akpm@osdl.org>
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200604042253.06378.rjw@sisk.pl>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tuesday 04 April 2006 10:45, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc1/2.6.17-rc1-mm1/

With this kernel mlockall(MCL_CURRENT | MCL_FUTURE) returns -EFAULT if called
by root (unconditionally, it seems) on x86_64.

On my box the output of:

#include <sys/mman.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

int main()
{
	int ret;

	ret = mlockall(MCL_CURRENT | MCL_FUTURE);
	if (ret < 0)
		printf("%s\n", strerror(errno));

	return 0;
}

is "Bad address", if run by root.

Greetings,
Rafael

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750769AbWDDVxo@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750769AbWDDVxo (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 17:53:44 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750762AbWDDVxn
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 17:53:43 -0400
Received: from threatwall.zlynx.org ([199.45.143.218]:17540 "EHLO zlynx.org")
	by vger.kernel.org with ESMTP id S1750778AbWDDVxn (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 17:53:43 -0400
Subject: Re: 2.6.17-rc1-mm1
From: Zan Lynx <zlynx@acm.org>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Roger Luethi <rl@hellgate.ch>
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eaeH9J7XTkjTyBWHyJco"
Date: Tue, 04 Apr 2006 15:53:37 -0600
Message-Id: <1144187618.26812.7.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
X-Envelope-From: zlynx@acm.org
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--=-eaeH9J7XTkjTyBWHyJco
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2006-04-04 at 01:45 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc1/=
2.6.17-rc1-mm1/

Has anyone seen this yet?

BUG: scheduling while atomic: mii-tool/0x00000001/2968
 <c02db7f7> schedule+0x43/0x540  =20
 <c02dc617> schedule_timeout+0x7a/0x95
 <c011d687> process_timeout+0x0/0x5  =20
 <c011e8a4> msleep+0x1a/0x1f
 <e09100c9> rhine_disable_linkmon+0x40/0xf1 [via_rhine]  =20
 <e09101a6> mdio_read+0x1f/0xab [via_rhine]
 <e08c7443> generic_mii_ioctl+0x6c/0x13f [mii]  =20
 <e0911900> netdev_ioctl+0x2e/0x4e [via_rhine]
 <e09118d2> netdev_ioctl+0x0/0x4e [via_rhine]  =20
 <c02890a7> dev_ifsioc+0x3b8/0x3d2
 <c0289438> dev_ioctl+0x34e/0x47a   =20
 <c027fc63> sock_ioctl+0x0/0x1c0
 <c015b694> do_ioctl+0x1c/0x5d =20
 <c015b917> vfs_ioctl+0x242/0x255
 <c015b954> sys_ioctl+0x2a/0x42 =20
 <c02dd80f> sysenter_past_esp+0x54/0x75

The system also has Intel Ethernet Pro 100 and SiS900 Ethernet
controllers, but only the VIA Rhine driver does this.
--=20
Zan Lynx <zlynx@acm.org>

--=-eaeH9J7XTkjTyBWHyJco
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEMurhG8fHaOLTWwgRAkOWAKCgB9j2PioADGukzf+rL6B0cF8v9ACfeGDG
/QlCwVjbG3kiBo7w7TElBws=
=84vg
-----END PGP SIGNATURE-----

--=-eaeH9J7XTkjTyBWHyJco--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750762AbWDDWC1@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750762AbWDDWC1 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 18:02:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750778AbWDDWC1
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 18:02:27 -0400
Received: from mailout1.vmware.com ([65.113.40.130]:3332 "EHLO
	mailout1.vmware.com") by vger.kernel.org with ESMTP
	id S1750762AbWDDWC0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 18:02:26 -0400
Message-ID: <4432ECF1.8040606@vmware.com>
Date: Tue, 04 Apr 2006 15:02:25 -0700
From: Zachary Amsden <zach@vmware.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Andrew Morton <akpm@osdl.org>
Cc: ebiederm@xmission.com, bunk@stusta.de, linux-kernel@vger.kernel.org,
       rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org>	<20060404162921.GK6529@stusta.de>	<m1acb15ja2.fsf@ebiederm.dsl.xmission.com>	<4432B22F.6090803@vmware.com>	<m1irpp41wx.fsf@ebiederm.dsl.xmission.com>	<4432C7AC.9020106@vmware.com> <20060404132546.565b3dae.akpm@osdl.org>
In-Reply-To: <20060404132546.565b3dae.akpm@osdl.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Andrew Morton wrote:
>
>>  struct subarch_hooks subarch_hook_vector = {
>>       .machine_power_off = machine_power_off,
>>       .machine_halt = machine_halt,
>>       .machine_irq_setup = machine_irq_setup,
>>       .machine_subarch_setup = machine_subarch_probe
>>       ...
>>  };
>>
>>  And machine_subarch_probe can dynamically change this vector if it 
>>  confirms that the platform is appropriate?
>>     
>
> I don't recall anyone expressing any desire for the ability to set these
> things at runtime.  Unless there is such a requirement I'd suggest that the
> best way to address Eric's point is to simply rename the relevant functions
> from foo() to subarch_foo().
>   

Avoiding the runtime assignment isn't possible if you want a generic 
subarch that truly can run on multiple different platforms.

I prefer runtime assignment not for this reason, but simply because it 
also eliminates two artifacts:

1) You can add new subarch hooks without breaking every other 
sub-architecture
2) You don't need #ifdef SUBARCH_FUNC_FOO goo to do this (renaming 
voyager_halt -> default)

Zach

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750782AbWDDWLA@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750782AbWDDWLA (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 18:11:00 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750783AbWDDWLA
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 18:11:00 -0400
Received: from smtp.osdl.org ([65.172.181.4]:28289 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1750782AbWDDWLA (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 18:11:00 -0400
Date: Tue, 4 Apr 2006 15:09:53 -0700
From: Andrew Morton <akpm@osdl.org>
To: Zan Lynx <zlynx@acm.org>
Cc: linux-kernel@vger.kernel.org, rl@hellgate.ch,
       "John W. Linville" <linville@tuxdriver.com>
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060404150953.41d7e04e.akpm@osdl.org>
In-Reply-To: <1144187618.26812.7.camel@localhost>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<1144187618.26812.7.camel@localhost>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Zan Lynx <zlynx@acm.org> wrote:
>
> On Tue, 2006-04-04 at 01:45 -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc1/2.6.17-rc1-mm1/
> 
> Has anyone seen this yet?
> 
> BUG: scheduling while atomic: mii-tool/0x00000001/2968
>  <c02db7f7> schedule+0x43/0x540   
>  <c02dc617> schedule_timeout+0x7a/0x95
>  <c011d687> process_timeout+0x0/0x5   
>  <c011e8a4> msleep+0x1a/0x1f
>  <e09100c9> rhine_disable_linkmon+0x40/0xf1 [via_rhine]   
>  <e09101a6> mdio_read+0x1f/0xab [via_rhine]
>  <e08c7443> generic_mii_ioctl+0x6c/0x13f [mii]   
>  <e0911900> netdev_ioctl+0x2e/0x4e [via_rhine]
>  <e09118d2> netdev_ioctl+0x0/0x4e [via_rhine]   
>  <c02890a7> dev_ifsioc+0x3b8/0x3d2
>  <c0289438> dev_ioctl+0x34e/0x47a    
>  <c027fc63> sock_ioctl+0x0/0x1c0
>  <c015b694> do_ioctl+0x1c/0x5d  
>  <c015b917> vfs_ioctl+0x242/0x255
>  <c015b954> sys_ioctl+0x2a/0x42  
>  <c02dd80f> sysenter_past_esp+0x54/0x75
> 
> The system also has Intel Ethernet Pro 100 and SiS900 Ethernet
> controllers, but only the VIA Rhine driver does this.

netdev_ioctl() does spin_lock_irq(), so the mdelay->msleep conversion (now
in mainline) was insufficient.

Someone needs to turn on those nice debugging options...

hmm, according to git-whatchanged, this bug has been in there since October
last year.  Weird that it hasn't been spotted before now.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750800AbWDDWXN@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750800AbWDDWXN (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 18:23:13 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750825AbWDDWXN
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 18:23:13 -0400
Received: from smtp.osdl.org ([65.172.181.4]:15237 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1750800AbWDDWXM (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 18:23:12 -0400
Date: Tue, 4 Apr 2006 15:19:04 -0700
From: Andrew Morton <akpm@osdl.org>
To: Zachary Amsden <zach@vmware.com>
Cc: ebiederm@xmission.com, bunk@stusta.de, linux-kernel@vger.kernel.org,
       rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
Message-Id: <20060404151904.764ad9f4.akpm@osdl.org>
In-Reply-To: <4432ECF1.8040606@vmware.com>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404162921.GK6529@stusta.de>
	<m1acb15ja2.fsf@ebiederm.dsl.xmission.com>
	<4432B22F.6090803@vmware.com>
	<m1irpp41wx.fsf@ebiederm.dsl.xmission.com>
	<4432C7AC.9020106@vmware.com>
	<20060404132546.565b3dae.akpm@osdl.org>
	<4432ECF1.8040606@vmware.com>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Zachary Amsden <zach@vmware.com> wrote:
>
> Andrew Morton wrote:
> >
> >>  struct subarch_hooks subarch_hook_vector = {
> >>       .machine_power_off = machine_power_off,
> >>       .machine_halt = machine_halt,
> >>       .machine_irq_setup = machine_irq_setup,
> >>       .machine_subarch_setup = machine_subarch_probe
> >>       ...
> >>  };
> >>
> >>  And machine_subarch_probe can dynamically change this vector if it 
> >>  confirms that the platform is appropriate?
> >>     
> >
> > I don't recall anyone expressing any desire for the ability to set these
> > things at runtime.  Unless there is such a requirement I'd suggest that the
> > best way to address Eric's point is to simply rename the relevant functions
> > from foo() to subarch_foo().
> >   
> 
> Avoiding the runtime assignment isn't possible if you want a generic 
> subarch that truly can run on multiple different platforms.

Well as I said - I haven't seen any requirement for this expressed.  That
doesn't mean that such a requirements doesn't exist, of course.

> I prefer runtime assignment not for this reason, but simply because it 
> also eliminates two artifacts:
> 
> 1) You can add new subarch hooks without breaking every other 
> sub-architecture

Is that useful?   If you need a new subarch_bar() then

a) Implement it in the subarch which needs it
b) Implement an attribute(weak) stub in a new subarch-stubs.c
c) call it.

That's a little more costly than a static inline stub, but not much.  Are
there likely to be any subarch calls which are a) called frequently and b)
not required on some subarchs?

> 2) You don't need #ifdef SUBARCH_FUNC_FOO goo to do this (renaming 
> voyager_halt -> default)

Why would one need that?  Isn't it simply a matter of renaming
machine_halt() to subarch_machine_halt() everywhere?

I'm just looking for the simplest option here.  Eric has identified a code
maintainability problem - it'd be good to fix that, but we shouldn't add
runtime cost/complexity unless we actually gain something from it.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750797AbWDDW0E@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750797AbWDDW0E (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 18:26:04 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750825AbWDDW0E
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 18:26:04 -0400
Received: from smtp.osdl.org ([65.172.181.4]:14470 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1750797AbWDDW0D (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 18:26:03 -0400
Date: Tue, 4 Apr 2006 15:24:54 -0700
From: Andrew Morton <akpm@osdl.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-kernel@vger.kernel.org, "Stone Wang" <pwstone@gmail.com>
Subject: Re: 2.6.17-rc1-mm1: mlockall() regression on x86_64
Message-Id: <20060404152454.6e7541ad.akpm@osdl.org>
In-Reply-To: <200604042253.06378.rjw@sisk.pl>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<200604042253.06378.rjw@sisk.pl>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> On Tuesday 04 April 2006 10:45, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc1/2.6.17-rc1-mm1/
> 
> With this kernel mlockall(MCL_CURRENT | MCL_FUTURE) returns -EFAULT if called
> by root (unconditionally, it seems) on x86_64.
> 
> On my box the output of:
> 
> #include <sys/mman.h>
> #include <stdio.h>
> #include <string.h>
> #include <errno.h>
> 
> int main()
> {
> 	int ret;
> 
> 	ret = mlockall(MCL_CURRENT | MCL_FUTURE);
> 	if (ret < 0)
> 		printf("%s\n", strerror(errno));
> 
> 	return 0;
> }
> 
> is "Bad address", if run by root.
> 

Yes, me too.  It works OK on x86_32.

It's due to mm-posix-memory-lock.patch.  I'd guess that
make_pages_present() is returning -EFAULT for some reason.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750840AbWDDWek@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750840AbWDDWek (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 18:34:40 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750850AbWDDWek
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 18:34:40 -0400
Received: from mailout1.vmware.com ([65.113.40.130]:37130 "EHLO
	mailout1.vmware.com") by vger.kernel.org with ESMTP
	id S1750840AbWDDWek (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 18:34:40 -0400
Message-ID: <4432F469.1040405@vmware.com>
Date: Tue, 04 Apr 2006 15:34:17 -0700
From: Zachary Amsden <zach@vmware.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Andrew Morton <akpm@osdl.org>
Cc: ebiederm@xmission.com, bunk@stusta.de, linux-kernel@vger.kernel.org,
       rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org>	<20060404162921.GK6529@stusta.de>	<m1acb15ja2.fsf@ebiederm.dsl.xmission.com>	<4432B22F.6090803@vmware.com>	<m1irpp41wx.fsf@ebiederm.dsl.xmission.com>	<4432C7AC.9020106@vmware.com>	<20060404132546.565b3dae.akpm@osdl.org>	<4432ECF1.8040606@vmware.com> <20060404151904.764ad9f4.akpm@osdl.org>
In-Reply-To: <20060404151904.764ad9f4.akpm@osdl.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Andrew Morton wrote:
> Zachary Amsden <zach@vmware.com> wrote:
>   
>> Andrew Morton wrote:
>>     
>>>>  struct subarch_hooks subarch_hook_vector = {
>>>>       .machine_power_off = machine_power_off,
>>>>       .machine_halt = machine_halt,
>>>>       .machine_irq_setup = machine_irq_setup,
>>>>       .machine_subarch_setup = machine_subarch_probe
>>>>       ...
>>>>  };
>>>>
>>>>  And machine_subarch_probe can dynamically change this vector if it 
>>>>  confirms that the platform is appropriate?
>>>>     
>>>>         
>>> I don't recall anyone expressing any desire for the ability to set these
>>> things at runtime.  Unless there is such a requirement I'd suggest that the
>>> best way to address Eric's point is to simply rename the relevant functions
>>> from foo() to subarch_foo().
>>>   
>>>       
>> Avoiding the runtime assignment isn't possible if you want a generic 
>> subarch that truly can run on multiple different platforms.
>>     
>
> Well as I said - I haven't seen any requirement for this expressed.  That
> doesn't mean that such a requirements doesn't exist, of course.
>
>   
>> I prefer runtime assignment not for this reason, but simply because it 
>> also eliminates two artifacts:
>>
>> 1) You can add new subarch hooks without breaking every other 
>> sub-architecture
>>     
>
> Is that useful?   If you need a new subarch_bar() then
>
> a) Implement it in the subarch which needs it
> b) Implement an attribute(weak) stub in a new subarch-stubs.c
> c) call it.
>
> That's a little more costly than a static inline stub, but not much.  Are
> there likely to be any subarch calls which are a) called frequently and b)
> not required on some subarchs?
>   

No, most of these are one time init calls.  The problem before was the 
default subarch couldn't define weak symbols, since setup.c was in the 
subarch itself and not in arch/i386/kernel.  Do weak symbols work with 
all tool chains?

>   
>> 2) You don't need #ifdef SUBARCH_FUNC_FOO goo to do this (renaming 
>> voyager_halt -> default)
>>     
>
> Why would one need that?  Isn't it simply a matter of renaming
> machine_halt() to subarch_machine_halt() everywhere?
>   

No - if you rename machine_halt to subarch_machine_halt, you again can't 
add a new subarch interface without changing all subarchitectures.  If I 
add voyager_smp_bless_voyage(), I now need to add #define 
visws_smp_bless_voyage default_smp_bless_voyage, ... or did you mean 
subarch_machine_halt literally?

> I'm just looking for the simplest option here.  Eric has identified a code
> maintainability problem - it'd be good to fix that, but we shouldn't add
> runtime cost/complexity unless we actually gain something from it.
>   

I think weak symbols are the best approach, if they indeed work with all 
tool chains.

Zach

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750887AbWDDWm5@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750887AbWDDWm5 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 18:42:57 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750885AbWDDWm5
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 18:42:57 -0400
Received: from smtp.osdl.org ([65.172.181.4]:30091 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1750825AbWDDWm4 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 18:42:56 -0400
Date: Tue, 4 Apr 2006 15:38:48 -0700
From: Andrew Morton <akpm@osdl.org>
To: Zachary Amsden <zach@vmware.com>
Cc: ebiederm@xmission.com, bunk@stusta.de, linux-kernel@vger.kernel.org,
       rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
Message-Id: <20060404153848.55c4811a.akpm@osdl.org>
In-Reply-To: <4432F469.1040405@vmware.com>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404162921.GK6529@stusta.de>
	<m1acb15ja2.fsf@ebiederm.dsl.xmission.com>
	<4432B22F.6090803@vmware.com>
	<m1irpp41wx.fsf@ebiederm.dsl.xmission.com>
	<4432C7AC.9020106@vmware.com>
	<20060404132546.565b3dae.akpm@osdl.org>
	<4432ECF1.8040606@vmware.com>
	<20060404151904.764ad9f4.akpm@osdl.org>
	<4432F469.1040405@vmware.com>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Zachary Amsden <zach@vmware.com> wrote:
>
> Do weak symbols work with all tool chains?
> 

I hope so.  `grep weak */*.c'.

> >   
> >> 2) You don't need #ifdef SUBARCH_FUNC_FOO goo to do this (renaming 
> >> voyager_halt -> default)
> >>     
> >
> > Why would one need that?  Isn't it simply a matter of renaming
> > machine_halt() to subarch_machine_halt() everywhere?
> >   
> 
> No - if you rename machine_halt to subarch_machine_halt, you again can't 
> add a new subarch interface without changing all subarchitectures.  If I 
> add voyager_smp_bless_voyage(), I now need to add #define 
> visws_smp_bless_voyage default_smp_bless_voyage, ... or did you mean 
> subarch_machine_halt literally?

Yes, I meant subarch_machine_halt() literally.

> > I'm just looking for the simplest option here.  Eric has identified a code
> > maintainability problem - it'd be good to fix that, but we shouldn't add
> > runtime cost/complexity unless we actually gain something from it.
> >   
> 
> I think weak symbols are the best approach, if they indeed work with all 
> tool chains.

They do.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750940AbWDDXix@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750940AbWDDXix (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 19:38:53 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750938AbWDDXix
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 19:38:53 -0400
Received: from mga02.intel.com ([134.134.136.20]:63390 "EHLO
	orsmga101-1.jf.intel.com") by vger.kernel.org with ESMTP
	id S1750934AbWDDXiw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 19:38:52 -0400
X-IronPort-AV: i="4.03,165,1141632000"; 
   d="scan'208"; a="19370404:sNHT15704206"
Date: Tue, 4 Apr 2006 16:38:51 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: Re: 2.6.17-rc1-mm1
Message-ID: <20060404233851.GA6411@agluck-lia64.sc.intel.com>
References: <20060404014504.564bf45a.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> - VGA on ia64 is broken - the screen comes up blank.  But ia64 otherwise
>   seems to work OK.  I didn't have time to investigate.

Broken in base 2.6.17-rc1 too :-(  VGA comes up and prints a
few messages, and then goes wonky and dies.  Comparing
what I _think_ I saw with the dmesg output, it appears to
die here:

[    6.416740] ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 18 (level, low) -> IRQ 48
[    6.708439] e1000: 0000:01:00.0: e1000_probe: (PCI:33MHz:32-bit) 00:03:47:fd:bb:42
[    6.754439] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
[    6.761547] netconsole: not configured, aborting
[    6.766195] initcall at 0xa0000001007c4c30: init_netconsole+0x0/0x140(): returned with error code -22
[    6.775520] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2

    DEAD DEAD DEAD

Should have gone on to say:
[    6.781924] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[    6.790052] ICH4: IDE controller at PCI slot 0000:00:1f.1
[    6.795513] PCI: Device 0000:00:1f.1 not available because of resource collisions
[    6.803100] ACPI: PCI Interrupt 0000:00:1f.1[A]: no GSI
[    6.808403] ICH4: BIOS configuration fixed.
[    6.812646] ICH4: chipset revision 1
[    6.816271] ICH4: not 100% native mode: will probe irqs later


But I might be off by a line or two, the last bit flashed by quite quickly.

I'll start bisecting tomorrow to see when it was broken.

-Tony

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751027AbWDEAV1@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751027AbWDEAV1 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 20:21:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751029AbWDEAV1
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 20:21:27 -0400
Received: from dvhart.com ([64.146.134.43]:48069 "EHLO dvhart.com")
	by vger.kernel.org with ESMTP id S1751026AbWDEAV0 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 20:21:26 -0400
Message-ID: <44330D7F.3070109@mbligh.org>
Date: Tue, 04 Apr 2006 17:21:19 -0700
From: Martin Bligh <mbligh@mbligh.org>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrew Morton <akpm@osdl.org>
Cc: Zachary Amsden <zach@vmware.com>, ebiederm@xmission.com, bunk@stusta.de,
       linux-kernel@vger.kernel.org, rdunlap@xenotime.net, fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org>	<20060404162921.GK6529@stusta.de>	<m1acb15ja2.fsf@ebiederm.dsl.xmission.com>	<4432B22F.6090803@vmware.com>	<m1irpp41wx.fsf@ebiederm.dsl.xmission.com>	<4432C7AC.9020106@vmware.com>	<20060404132546.565b3dae.akpm@osdl.org>	<4432ECF1.8040606@vmware.com> <20060404151904.764ad9f4.akpm@osdl.org>
In-Reply-To: <20060404151904.764ad9f4.akpm@osdl.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>>>I don't recall anyone expressing any desire for the ability to set these
>>>things at runtime.  Unless there is such a requirement I'd suggest that the
>>>best way to address Eric's point is to simply rename the relevant functions
>>>from foo() to subarch_foo().
>>>  
>>
>>Avoiding the runtime assignment isn't possible if you want a generic 
>>subarch that truly can run on multiple different platforms.
> 
> Well as I said - I haven't seen any requirement for this expressed.  That
> doesn't mean that such a requirements doesn't exist, of course.

I think there is a real requirement to do this at boot-time, yes. We 
don't want a proliferation of different kernel builds in distros,
but one kernel that installs and boots everywhere (think installer
kernels on boot CDs, etc ... plus testing requirements). Autoswitching,
without magic user-flags. That's what the generic subarch was always
for, and frankly the others all ought to die (apart from possibly really
specialised non-mainstream stuff like voyager and NUMA-Q).

M.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750722AbWDECqo@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750722AbWDECqo (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 22:46:44 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751079AbWDECqo
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 22:46:44 -0400
Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:56467 "EHLO
	ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP
	id S1750722AbWDECqn (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 22:46:43 -0400
To: Martin Bligh <mbligh@mbligh.org>
Cc: Andrew Morton <akpm@osdl.org>, Zachary Amsden <zach@vmware.com>,
       bunk@stusta.de, linux-kernel@vger.kernel.org, rdunlap@xenotime.net,
       fastboot@osdl.org
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404162921.GK6529@stusta.de>
	<m1acb15ja2.fsf@ebiederm.dsl.xmission.com>
	<4432B22F.6090803@vmware.com>
	<m1irpp41wx.fsf@ebiederm.dsl.xmission.com>
	<4432C7AC.9020106@vmware.com> <20060404132546.565b3dae.akpm@osdl.org>
	<4432ECF1.8040606@vmware.com> <20060404151904.764ad9f4.akpm@osdl.org>
	<44330D7F.3070109@mbligh.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 04 Apr 2006 20:45:21 -0600
In-Reply-To: <44330D7F.3070109@mbligh.org> (Martin Bligh's message of "Tue,
 04 Apr 2006 17:21:19 -0700")
Message-ID: <m1zmj0ivum.fsf@ebiederm.dsl.xmission.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Martin Bligh <mbligh@mbligh.org> writes:

>>>>I don't recall anyone expressing any desire for the ability to set these
>>>>things at runtime.  Unless there is such a requirement I'd suggest that the
>>>>best way to address Eric's point is to simply rename the relevant functions
>>>>from foo() to subarch_foo().
>>>>
>>>
>>> Avoiding the runtime assignment isn't possible if you want a generic subarch
>>> that truly can run on multiple different platforms.
>> Well as I said - I haven't seen any requirement for this expressed.  That
>> doesn't mean that such a requirements doesn't exist, of course.
>
> I think there is a real requirement to do this at boot-time, yes. We don't want
> a proliferation of different kernel builds in distros,
> but one kernel that installs and boots everywhere (think installer
> kernels on boot CDs, etc ... plus testing requirements). Autoswitching,
> without magic user-flags. That's what the generic subarch was always
> for, and frankly the others all ought to die (apart from possibly really
> specialised non-mainstream stuff like voyager and NUMA-Q).

Plus it is pretty simple if you compile for a single architecture to
kill the function pointers.  That is how the alpha is currently structured.

So for the people who don't want it switchable the code can just compile
out.

Getting this infrastructure now before i386 becomes primarily and embedded
architecture will be nice.

Eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750864AbWDEDrH@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750864AbWDEDrH (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 4 Apr 2006 23:47:07 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751094AbWDEDrG
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 4 Apr 2006 23:47:06 -0400
Received: from mga01.intel.com ([192.55.52.88]:35994 "EHLO
	fmsmga101-1.fm.intel.com") by vger.kernel.org with ESMTP
	id S1750864AbWDEDrF (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Apr 2006 23:47:05 -0400
X-IronPort-AV: i="4.03,165,1141632000"; 
   d="scan'208"; a="20040441:sNHT16378950"
Subject: Re: 2.6.17-rc1-mm1
From: Zou Nan hai <nanhai.zou@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>,
       linux-ia64@vger.kernel.org
In-Reply-To: <20060404233851.GA6411@agluck-lia64.sc.intel.com>
References: <20060404014504.564bf45a.akpm@osdl.org>
	 <20060404233851.GA6411@agluck-lia64.sc.intel.com>
Content-Type: text/plain
Organization: 
Message-Id: <1144202706.3197.11.camel@linux-znh>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 05 Apr 2006 10:05:06 +0800
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2006-04-05 at 07:38, Luck, Tony wrote:
> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> > - VGA on ia64 is broken - the screen comes up blank.  But ia64 otherwise
> >   seems to work OK.  I didn't have time to investigate.
> 
> Broken in base 2.6.17-rc1 too :-(  VGA comes up and prints a
> few messages, and then goes wonky and dies.  Comparing
> what I _think_ I saw with the dmesg output, it appears to
> die here:
> 

The wild VGA comes from the patch which changed ioremap.

Now ioremap would not remap memory to region 6 unless that memory is
marked as EFI_MEMORY_UC by EFI.

Unfortunately on the Tiger Machine, VGA ram base was marked as
EFI_MEMORY_WB instead of EFI_MEMORY_UC...

So you can see the problem disappear if change VGA_MAP_MEM to use
ioremap_nocache.

But I am not quite sure if we can fully trust EFI on this attribute.

Zou Nan hai

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751127AbWDEHCm@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751127AbWDEHCm (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 03:02:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751128AbWDEHCm
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 03:02:42 -0400
Received: from mail17.bluewin.ch ([195.186.18.64]:10439 "EHLO
	mail17.bluewin.ch") by vger.kernel.org with ESMTP id S1751127AbWDEHCl
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 03:02:41 -0400
Date: Wed, 5 Apr 2006 09:01:50 +0200
From: Roger Luethi <rl@hellgate.ch>
To: Andrew Morton <akpm@osdl.org>
Cc: Zan Lynx <zlynx@acm.org>, linux-kernel@vger.kernel.org,
       "John W. Linville" <linville@tuxdriver.com>
Subject: Re: 2.6.17-rc1-mm1
Message-ID: <20060405070150.GA10351@k3.hellgate.ch>
References: <20060404014504.564bf45a.akpm@osdl.org> <1144187618.26812.7.camel@localhost> <20060404150953.41d7e04e.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060404150953.41d7e04e.akpm@osdl.org>
X-Operating-System: Linux 2.6.16 on i686
X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95  24 4E 9E E7 5A 54 DC 1B
X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net
User-Agent: Mutt/1.5.11
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 04 Apr 2006 15:09:53 -0700, Andrew Morton wrote:
> Zan Lynx <zlynx@acm.org> wrote:
> > Has anyone seen this yet?
> > 
> > BUG: scheduling while atomic: mii-tool/0x00000001/2968
> >  <c02db7f7> schedule+0x43/0x540   
> >  <c02dc617> schedule_timeout+0x7a/0x95
> >  <c011d687> process_timeout+0x0/0x5   
> >  <c011e8a4> msleep+0x1a/0x1f
> >  <e09100c9> rhine_disable_linkmon+0x40/0xf1 [via_rhine]   
[...]
> 
> hmm, according to git-whatchanged, this bug has been in there since October
> last year.  Weird that it hasn't been spotted before now.

It has been spotted [1] and diagnosed [2] about two weeks ago. I guess the
reason it took so long is that in addition to the debugging options, you
need a kernel that does call the spinlock code _and_ you need to look at
the kernel log even though the behavior is unchanged.

Anyhow, the mdelay to msleep conversion is useful only for a corner case: a
user with Rhine-I hardware (ancient) who needs low latency even while
fiddling with the NIC's media settings. I am not sure it's worth the
trouble. Any suggestions for an elegant solution?

Roger

[1] http://marc.theaimsgroup.com/?l=linux-netdev&m=114321570402396
[2] http://marc.theaimsgroup.com/?l=linux-netdev&m=114349201223976

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751140AbWDEHaU@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751140AbWDEHaU (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 03:30:20 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751141AbWDEHaU
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 03:30:20 -0400
Received: from smtp.osdl.org ([65.172.181.4]:43682 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1751140AbWDEHaT (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 03:30:19 -0400
Date: Wed, 5 Apr 2006 00:29:09 -0700
From: Andrew Morton <akpm@osdl.org>
To: Roger Luethi <rl@hellgate.ch>
Cc: zlynx@acm.org, linux-kernel@vger.kernel.org, linville@tuxdriver.com
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060405002909.2ab4482b.akpm@osdl.org>
In-Reply-To: <20060405070150.GA10351@k3.hellgate.ch>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<1144187618.26812.7.camel@localhost>
	<20060404150953.41d7e04e.akpm@osdl.org>
	<20060405070150.GA10351@k3.hellgate.ch>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Roger Luethi <rl@hellgate.ch> wrote:
>
> Any suggestions for an elegant solution?

Move the locking down lower, so it just locks the stuff which needs locking?

It all depends on what the lock's role is, and so often that's a big secret.

If the intention is to prevent concurrent execution of mdio_read()
(reasonable) and we really need that 1 msec delay between writing the
registers and reading back the result then we're somewhat screwed.  Either
use a sleeping lock to protect that hardware state or go back to using
udelay().

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751152AbWDEHtk@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751152AbWDEHtk (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 03:49:40 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751055AbWDEHtk
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 03:49:40 -0400
Received: from smtp.osdl.org ([65.172.181.4]:38311 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1751062AbWDEHtj (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 03:49:39 -0400
Date: Wed, 5 Apr 2006 00:42:12 -0700
From: Andrew Morton <akpm@osdl.org>
To: Martin Samuelsson <sam@home.se>
Cc: bunk@stusta.de, linux-kernel@vger.kernel.org, mchehab@infradead.org,
       js@linuxtv.org, v4l-dvb-maintainer@linuxtv.org
Subject: Re: [-mm patch] drivers/media/video/bt866.c: small fixes
Message-Id: <20060405004212.47312021.akpm@osdl.org>
In-Reply-To: <20060404203219.40fe6b4c.sam@home.se>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404163001.GO6529@stusta.de>
	<20060404203219.40fe6b4c.sam@home.se>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Martin Samuelsson <sam@home.se> wrote:
>
> This should fix all things Andrew pointed out when I first submitted the 
>  avs6eyes driver.

We still have all that #ifdef MODULE stuff at the end of bt866.c. 
(Shouldn't it have module_init() and module_exit() handlers?)

All those ".input_mux = 0," lines you added to the struct initialisation
are unneeded - the compiler did that for you.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750823AbWDEIeL@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750823AbWDEIeL (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 04:34:11 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751178AbWDEIeL
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 04:34:11 -0400
Received: from allen.werkleitz.de ([80.190.251.108]:19082 "EHLO
	allen.werkleitz.de") by vger.kernel.org with ESMTP id S1750823AbWDEIeK
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 04:34:10 -0400
Date: Wed, 5 Apr 2006 10:32:04 +0200
From: Johannes Stezenbach <js@linuxtv.org>
To: Martin Samuelsson <sam@home.se>
Cc: Adrian Bunk <bunk@stusta.de>, akpm@osdl.org, linux-kernel@vger.kernel.org,
       mchehab@infradead.org, v4l-dvb-maintainer@linuxtv.org
Message-ID: <20060405083204.GA5058@linuxtv.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404163001.GO6529@stusta.de> <20060404203219.40fe6b4c.sam@home.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060404203219.40fe6b4c.sam@home.se>
User-Agent: Mutt/1.5.11+cvs20060330
X-SA-Exim-Connect-IP: 84.189.224.114
Subject: Re: [-mm patch] drivers/media/video/bt866.c: small fixes
X-SA-Exim-Version: 4.2 (built Thu, 16 Feb 2006 12:49:04 +1100)
X-SA-Exim-Scanned: Yes (on allen.werkleitz.de)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006, Martin Samuelsson wrote:
>  		current->state = TASK_INTERRUPTIBLE;
> -		schedule_timeout(HZ/10);
> +		schedule_timeout_interruptible(HZ/10);

schedule_timeout_interruptible() already sets current->state.

Johannes

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751179AbWDEJCU@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751179AbWDEJCU (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 05:02:20 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751180AbWDEJCU
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 05:02:20 -0400
Received: from emailhub.stusta.mhn.de ([141.84.69.5]:774 "HELO
	mailout.stusta.mhn.de") by vger.kernel.org with SMTP
	id S1751179AbWDEJCT (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 05:02:19 -0400
Date: Wed, 5 Apr 2006 11:02:18 +0200
From: Adrian Bunk <bunk@stusta.de>
To: Andrew Morton <akpm@osdl.org>
Cc: Martin Samuelsson <sam@home.se>, linux-kernel@vger.kernel.org,
       mchehab@infradead.org, js@linuxtv.org, v4l-dvb-maintainer@linuxtv.org
Subject: Re: [-mm patch] drivers/media/video/bt866.c: small fixes
Message-ID: <20060405090218.GA8673@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404163001.GO6529@stusta.de> <20060404203219.40fe6b4c.sam@home.se> <20060405004212.47312021.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060405004212.47312021.akpm@osdl.org>
User-Agent: Mutt/1.5.11+cvs20060126
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 05, 2006 at 12:42:12AM -0700, Andrew Morton wrote:
> Martin Samuelsson <sam@home.se> wrote:
> >
> > This should fix all things Andrew pointed out when I first submitted the 
> >  avs6eyes driver.
> 
> We still have all that #ifdef MODULE stuff at the end of bt866.c. 
> (Shouldn't it have module_init() and module_exit() handlers?)
>...

This is what my patch does.

Martin's patch does not include my patch, it is on top of it.

You should have seen a merge conflict when merging Martin's patch, and 
the reason is that you hadn't applied my patch before his patch.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750780AbWDENqy@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750780AbWDENqy (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 09:46:54 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751151AbWDENqy
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 09:46:54 -0400
Received: from smtp2.home.se ([212.78.199.22]:56453 "EHLO smtp2.home.se")
	by vger.kernel.org with ESMTP id S1750780AbWDENqy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 09:46:54 -0400
Date: Wed, 5 Apr 2006 15:44:45 +0200
From: Martin Samuelsson <sam@home.se>
To: Andrew Morton <akpm@osdl.org>
Cc: bunk@stusta.de, linux-kernel@vger.kernel.org, mchehab@infradead.org,
       js@linuxtv.org, v4l-dvb-maintainer@linuxtv.org
Subject: Re: [-mm patch] drivers/media/video/bt866.c: small fixes
Message-Id: <20060405154445.24c9bab5.sam@home.se>
In-Reply-To: <20060405004212.47312021.akpm@osdl.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404163001.GO6529@stusta.de>
	<20060404203219.40fe6b4c.sam@home.se>
	<20060405004212.47312021.akpm@osdl.org>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 5 Apr 2006 00:42:12 -0700
Andrew Morton <akpm@osdl.org> wrote:

> Martin Samuelsson <sam@home.se> wrote:
> >
> > This should fix all things Andrew pointed out when I first submitted the 
> >  avs6eyes driver.
> 
> We still have all that #ifdef MODULE stuff at the end of bt866.c. 
> (Shouldn't it have module_init() and module_exit() handlers?)

I'm sorry for the confusion. I simply didn't want to cause a conflict with Adrian's patch, and canceled out those things from my version.

> All those ".input_mux = 0," lines you added to the struct initialisation
> are unneeded - the compiler did that for you.

Ah. I didn't know that. It's noted, and will be used in the future. I added them mostly in an attempt to aim for clarity and completeness.

Regards,
/Sam

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750708AbWDEN4k@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750708AbWDEN4k (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 09:56:40 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750742AbWDEN4j
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 09:56:39 -0400
Received: from smtp1.home.se ([212.78.199.21]:21394 "EHLO smtp1.home.se")
	by vger.kernel.org with ESMTP id S1750708AbWDEN4j (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 09:56:39 -0400
Date: Wed, 5 Apr 2006 15:54:42 +0200
From: Martin Samuelsson <sam@home.se>
To: Johannes Stezenbach <js@linuxtv.org>
Cc: bunk@stusta.de, akpm@osdl.org, linux-kernel@vger.kernel.org,
       mchehab@infradead.org, v4l-dvb-maintainer@linuxtv.org
Subject: Re: [-mm patch] drivers/media/video/bt866.c: small fixes
Message-Id: <20060405155442.66d76b90.sam@home.se>
In-Reply-To: <20060405083204.GA5058@linuxtv.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404163001.GO6529@stusta.de>
	<20060404203219.40fe6b4c.sam@home.se>
	<20060405083204.GA5058@linuxtv.org>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 5 Apr 2006 10:32:04 +0200
Johannes Stezenbach <js@linuxtv.org> wrote:

> On Tue, Apr 04, 2006, Martin Samuelsson wrote:
> >  		current->state = TASK_INTERRUPTIBLE;
> > -		schedule_timeout(HZ/10);
> > +		schedule_timeout_interruptible(HZ/10);
> 
> schedule_timeout_interruptible() already sets current->state.

I have much to learn, it seems. I'll trim that off, too. Thanks!

Regards,
/Sam

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750812AbWDEQPk@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750812AbWDEQPk (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 12:15:40 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751226AbWDEQPk
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 12:15:40 -0400
Received: from atlrel7.hp.com ([156.153.255.213]:38096 "EHLO atlrel7.hp.com")
	by vger.kernel.org with ESMTP id S1750812AbWDEQPj (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 12:15:39 -0400
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Zou Nan hai <nanhai.zou@intel.com>
Subject: Re: 2.6.17-rc1-mm1
Date: Wed, 5 Apr 2006 10:15:34 -0600
User-Agent: KMail/1.8.3
Cc: "Luck, Tony" <tony.luck@intel.com>, Andrew Morton <akpm@osdl.org>,
       LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404233851.GA6411@agluck-lia64.sc.intel.com> <1144202706.3197.11.camel@linux-znh>
In-Reply-To: <1144202706.3197.11.camel@linux-znh>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200604051015.34217.bjorn.helgaas@hp.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tuesday 04 April 2006 20:05, Zou Nan hai wrote:
> On Wed, 2006-04-05 at 07:38, Luck, Tony wrote:
> > On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> > > - VGA on ia64 is broken - the screen comes up blank.  But ia64 otherwise
> > >   seems to work OK.  I didn't have time to investigate.
> > 
> > Broken in base 2.6.17-rc1 too :-(  VGA comes up and prints a
> > few messages, and then goes wonky and dies.  Comparing
> > what I _think_ I saw with the dmesg output, it appears to
> > die here:
> 
> The wild VGA comes from the patch which changed ioremap.
> 
> Now ioremap would not remap memory to region 6 unless that memory is
> marked as EFI_MEMORY_UC by EFI.
> 
> Unfortunately on the Tiger Machine, VGA ram base was marked as
> EFI_MEMORY_WB instead of EFI_MEMORY_UC...
> 
> So you can see the problem disappear if change VGA_MAP_MEM to use
> ioremap_nocache.
> 
> But I am not quite sure if we can fully trust EFI on this attribute.

Huh.  Intel firmware used to just not mention the VGA framebuffer
(0xa0000-0xc0000) at all in the EFI memory map.  I think that was
clearly a bug.  So maybe they fixed that by marking it WB (and
hopefully UC as well).

Tiger might support WB to the VGA framebuffer, but I don't think it
make much sense for us to use it that way.  If we did, writes to the
framebuffer would just sit in the cache until forced out by something
else.  Probably using WC would be the best, but we don't have a good
interface for that yet.

Tony, if you agree with this analysis and haven't fixed it yet, here's
a trivial patch.


[IA64] always map VGA framebuffer UC, even if it supports WB

EFI on some machines, e.g., Intel Tiger, reports that the VGA framebuffer
supports WB access.  ioremap() prefers WB when possible, so it can work
when mapping main memory.

But it doesn't make sense to map a framebuffer WB, because the driver
doesn't flush explicitly, so updates won't make it to the device
immediately.

This is due to Zou Nan hai <nanhai.zou@intel.com>.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: work-mm5/include/asm-ia64/vga.h
===================================================================
--- work-mm5.orig/include/asm-ia64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-ia64/vga.h	2006-04-05 09:57:55.000000000 -0600
@@ -17,7 +17,7 @@
 extern unsigned long vga_console_iobase;
 extern unsigned long vga_console_membase;
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x)	((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751173AbWDEVSE@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751173AbWDEVSE (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 17:18:04 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751171AbWDEVSE
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 17:18:04 -0400
Received: from mga01.intel.com ([192.55.52.88]:3473 "EHLO
	fmsmga101-1.fm.intel.com") by vger.kernel.org with ESMTP
	id S1751124AbWDEVSC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 17:18:02 -0400
X-IronPort-AV: i="4.04,91,1144047600"; 
   d="scan'208"; a="20408992:sNHT53647398"
Date: Wed, 5 Apr 2006 14:17:57 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>,
       LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org
Subject: Re: 2.6.17-rc1-mm1
Message-ID: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404233851.GA6411@agluck-lia64.sc.intel.com> <1144202706.3197.11.camel@linux-znh> <200604051015.34217.bjorn.helgaas@hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200604051015.34217.bjorn.helgaas@hp.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> Huh.  Intel firmware used to just not mention the VGA framebuffer
> (0xa0000-0xc0000) at all in the EFI memory map.  I think that was
> clearly a bug.  So maybe they fixed that by marking it WB (and
> hopefully UC as well).

Nope ... not fixed (at least not in the f/w that I'm running). The
VGA buffer is still simply not mentioned in the EFI memory map.

The problem looks to come from this code in vgacon.c:

	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
	vga_vram_size = vga_vram_end - vga_vram_base;

vga_vram_base is 0xb8000, and this call gets a UC return of
c0000000000b8000.  But vga_vram_end is 0xc0000 ... which is
the address of the start of a block of memory that is both
WB and UC capable.  So ioremap() gives us e0000000000c0000
(which means that vga_vram_size is 2000000000008000, surely
the biggest, baddest video card in the history of the world!).

Perhaps the right fix is to subtract 1 from vga_vram_end and pass
that into VGA_MAP_MEM(), and then add the 1 byte back when computing
the size?  But I don't know whether that might do something bad on
some other architecture that uses vgacon.c.  If this is not
acceptable, then we can fall back and use the Nanhai/Bjorn fix
of using ioremap_nocache().

Signed-off-by: Tony Luck <tony.luck@intel.com>

---

diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index d5a04b6..4ca9877 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -484,8 +484,8 @@ #endif
 	}
 
 	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
-	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
-	vga_vram_size = vga_vram_end - vga_vram_base;
+	vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1);
+	vga_vram_size = vga_vram_end - vga_vram_base + 1;
 
 	/*
 	 *      Find out if there is a graphics card present.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S932084AbWDEViq@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932084AbWDEViq (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 17:38:46 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932081AbWDEViq
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 17:38:46 -0400
Received: from smtp.osdl.org ([65.172.181.4]:47252 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1751081AbWDEVip (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 17:38:45 -0400
Date: Wed, 5 Apr 2006 14:37:27 -0700
From: Andrew Morton <akpm@osdl.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: bjorn.helgaas@hp.com, nanhai.zou@intel.com, linux-kernel@vger.kernel.org,
       linux-ia64@vger.kernel.org, "Antonino A. Daplas" <adaplas@pol.net>
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060405143727.2b2fde15.akpm@osdl.org>
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404233851.GA6411@agluck-lia64.sc.intel.com>
	<1144202706.3197.11.camel@linux-znh>
	<200604051015.34217.bjorn.helgaas@hp.com>
	<20060405211757.GA8536@agluck-lia64.sc.intel.com>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

"Luck, Tony" <tony.luck@intel.com> wrote:
>
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh.  Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map.  I think that was
> > clearly a bug.  So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
> 
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
> 
> The problem looks to come from this code in vgacon.c:
> 
> 	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> 	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> 	vga_vram_size = vga_vram_end - vga_vram_base;
> 
> vga_vram_base is 0xb8000, and this call gets a UC return of
> c0000000000b8000.  But vga_vram_end is 0xc0000 ... which is
> the address of the start of a block of memory that is both
> WB and UC capable.

OK, so it's really an off-by-one error.

>  So ioremap() gives us e0000000000c0000
> (which means that vga_vram_size is 2000000000008000, surely
> the biggest, baddest video card in the history of the world!).
> 
> Perhaps the right fix is to subtract 1 from vga_vram_end and pass
> that into VGA_MAP_MEM(), and then add the 1 byte back when computing
> the size?  But I don't know whether that might do something bad on
> some other architecture that uses vgacon.c.  If this is not
> acceptable, then we can fall back and use the Nanhai/Bjorn fix
> of using ioremap_nocache().
> 
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> 
> ---
> 
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index d5a04b6..4ca9877 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -484,8 +484,8 @@ #endif
>  	}
>  
>  	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> -	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> -	vga_vram_size = vga_vram_end - vga_vram_base;
> +	vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1);
> +	vga_vram_size = vga_vram_end - vga_vram_base + 1;
>  
>  	/*
>  	 *      Find out if there is a graphics card present.

Looks like the correct fix to me.

Tony (D), can you think of any problems with that approach?

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751189AbWDEVjX@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751189AbWDEVjX (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 17:39:23 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751185AbWDEVjX
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 17:39:23 -0400
Received: from cantor2.suse.de ([195.135.220.15]:38380 "EHLO mx2.suse.de")
	by vger.kernel.org with ESMTP id S1751081AbWDEVjW (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 17:39:22 -0400
From: Andreas Schwab <schwab@suse.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>, Zou Nan hai <nanhai.zou@intel.com>,
       Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>,
       linux-ia64@vger.kernel.org
Subject: Re: 2.6.17-rc1-mm1
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060404233851.GA6411@agluck-lia64.sc.intel.com>
	<1144202706.3197.11.camel@linux-znh>
	<200604051015.34217.bjorn.helgaas@hp.com>
	<20060405211757.GA8536@agluck-lia64.sc.intel.com>
X-Yow: Disco oil bussing will create a throbbing naugahide pipeline running
 straight to the tropics from the rug producing regions
 and devalue the dollar!
Date: Wed, 05 Apr 2006 23:39:16 +0200
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com> (Tony Luck's
	message of "Wed, 5 Apr 2006 14:17:57 -0700")
Message-ID: <jer74b7ldn.fsf@sykes.suse.de>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

"Luck, Tony" <tony.luck@intel.com> writes:

> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index d5a04b6..4ca9877 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -484,8 +484,8 @@ #endif
>  	}
>  
>  	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> -	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> -	vga_vram_size = vga_vram_end - vga_vram_base;
> +	vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1);
> +	vga_vram_size = vga_vram_end - vga_vram_base + 1;

Better use vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1) + 1, or you'll
screw up the other computations using vga_vram_end.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S932092AbWDEWCF@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932092AbWDEWCF (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 18:02:05 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932095AbWDEWCF
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 18:02:05 -0400
Received: from mail21.bluewin.ch ([195.186.18.66]:47239 "EHLO
	mail21.bluewin.ch") by vger.kernel.org with ESMTP id S932092AbWDEWCD
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 18:02:03 -0400
Date: Thu, 6 Apr 2006 00:01:18 +0200
From: Roger Luethi <rl@hellgate.ch>
To: Andrew Morton <akpm@osdl.org>
Cc: zlynx@acm.org, linux-kernel@vger.kernel.org, linville@tuxdriver.com
Subject: Re: 2.6.17-rc1-mm1
Message-ID: <20060405220117.GB15748@k3.hellgate.ch>
References: <20060404014504.564bf45a.akpm@osdl.org> <1144187618.26812.7.camel@localhost> <20060404150953.41d7e04e.akpm@osdl.org> <20060405070150.GA10351@k3.hellgate.ch> <20060405002909.2ab4482b.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060405002909.2ab4482b.akpm@osdl.org>
X-Operating-System: Linux 2.6.16 on i686
X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95  24 4E 9E E7 5A 54 DC 1B
X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net
User-Agent: Mutt/1.5.11
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 05 Apr 2006 00:29:09 -0700, Andrew Morton wrote:
> Roger Luethi <rl@hellgate.ch> wrote:
> >
> > Any suggestions for an elegant solution?
> 
> Move the locking down lower, so it just locks the stuff which needs locking?
> 
> It all depends on what the lock's role is, and so often that's a big secret.

Indeed.

Over a dozen drivers now use calls like mii_ethtool_gset or
generic_mii_ioctl, and only one (sis190) makes the call without grabbing
the lock to the driver private data.

Pushing that lock down is not something I'd do lightly.

> If the intention is to prevent concurrent execution of mdio_read()
> (reasonable) and we really need that 1 msec delay between writing the

I'm afraid that delay is not negotiable -- unless we want to go back to
polling the chip for link state changes.

Roger

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S932094AbWDEWBO@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932094AbWDEWBO (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 18:01:14 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932093AbWDEWBO
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 18:01:14 -0400
Received: from atlrel9.hp.com ([156.153.255.214]:3204 "EHLO atlrel9.hp.com")
	by vger.kernel.org with ESMTP id S932091AbWDEWBN (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 18:01:13 -0400
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: "Luck, Tony" <tony.luck@intel.com>
Subject: Re: 2.6.17-rc1-mm1
Date: Wed, 5 Apr 2006 16:01:08 -0600
User-Agent: KMail/1.8.3
Cc: Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>,
       LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org
References: <20060404014504.564bf45a.akpm@osdl.org> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com>
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200604051601.08776.bjorn.helgaas@hp.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wednesday 05 April 2006 15:17, Luck, Tony wrote:
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh.  Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map.  I think that was
> > clearly a bug.  So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
> 
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
> 
> The problem looks to come from this code in vgacon.c:
> 
> 	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> 	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> 	vga_vram_size = vga_vram_end - vga_vram_base;
> 
> vga_vram_base is 0xb8000, and this call gets a UC return of
> c0000000000b8000.  But vga_vram_end is 0xc0000 ... which is
> the address of the start of a block of memory that is both
> WB and UC capable.  So ioremap() gives us e0000000000c0000
> (which means that vga_vram_size is 2000000000008000, surely
> the biggest, baddest video card in the history of the world!).
> 
> Perhaps the right fix is to subtract 1 from vga_vram_end and pass
> that into VGA_MAP_MEM(), and then add the 1 byte back when computing
> the size?  But I don't know whether that might do something bad on
> some other architecture that uses vgacon.c.

I think the VGA_MAP_MEM(vga_vram_end) is just bogus -- it's not
that we need to map the memory starting at vga_vram_end.  I think
it would cleaner (though much more intrusive) to do something like
the patch below, which basically just hard-codes (base, size)
rather than (base, end).

> If this is not 
> acceptable, then we can fall back and use the Nanhai/Bjorn fix
> of using ioremap_nocache().

Regardless of how we solve the vga_vram_size issue, I still think
ioremap_nocache() is more appropriate in this case.  A framebuffer
won't work like we expect if it's mapped WB, will it?

(The patch below assumes the ioremap_nocache change precedes it.)


[PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use

VGA_MAP_MEM translates to ioremap() on some architectures.  It
makes sense to do this to vga_vram_base, because we're going to
access memory between vga_vram_base and vga_vram_end.

But it doesn't really make sense to map starting at vga_vram_end,
because we aren't going to access memory starting there.  On ia64,
which always has to be different, ioremapping vga_vram_end gives
you something completely incompatible with ioremapped vga_vram_start,
so vga_vram_size ends up being nonsense.

As a bonus, we often know the size up front, so we can use ioremap()
correctly, rather than giving it a zero size.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: work-mm5/drivers/video/console/vgacon.c
===================================================================
--- work-mm5.orig/drivers/video/console/vgacon.c	2006-04-03 15:04:48.000000000 -0600
+++ work-mm5/drivers/video/console/vgacon.c	2006-04-05 15:48:37.000000000 -0600
@@ -391,7 +391,7 @@
 			static struct resource ega_console_resource =
 			    { .name = "ega", .start = 0x3B0, .end = 0x3BF };
 			vga_video_type = VIDEO_TYPE_EGAM;
-			vga_vram_end = 0xb8000;
+			vga_vram_size = 0x8000;
 			display_desc = "EGA+";
 			request_resource(&ioport_resource,
 					 &ega_console_resource);
@@ -401,7 +401,7 @@
 			static struct resource mda2_console_resource =
 			    { .name = "mda", .start = 0x3BF, .end = 0x3BF };
 			vga_video_type = VIDEO_TYPE_MDA;
-			vga_vram_end = 0xb2000;
+			vga_vram_size = 0x2000;
 			display_desc = "*MDA";
 			request_resource(&ioport_resource,
 					 &mda1_console_resource);
@@ -418,7 +418,7 @@
 		if ((ORIG_VIDEO_EGA_BX & 0xff) != 0x10) {
 			int i;
 
-			vga_vram_end = 0xc0000;
+			vga_vram_size = 0x8000;
 
 			if (!ORIG_VIDEO_ISVGA) {
 				static struct resource ega_console_resource
@@ -443,7 +443,7 @@
 				 * and COE=1 isn't necessarily a good idea)
 				 */
 				vga_vram_base = 0xa0000;
-				vga_vram_end = 0xb0000;
+				vga_vram_size = 0x10000;
 				outb_p(6, VGA_GFX_I);
 				outb_p(6, VGA_GFX_D);
 #endif
@@ -475,7 +475,7 @@
 			static struct resource cga_console_resource =
 			    { .name = "cga", .start = 0x3D4, .end = 0x3D5 };
 			vga_video_type = VIDEO_TYPE_CGA;
-			vga_vram_end = 0xba000;
+			vga_vram_size = 0x2000;
 			display_desc = "*CGA";
 			request_resource(&ioport_resource,
 					 &cga_console_resource);
@@ -483,9 +483,8 @@
 		}
 	}
 
-	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
-	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
-	vga_vram_size = vga_vram_end - vga_vram_base;
+	vga_vram_base = VGA_MAP_MEM(vga_vram_base, vga_vram_size);
+	vga_vram_end = vga_vram_base + vga_vram_size;
 
 	/*
 	 *      Find out if there is a graphics card present.
@@ -1020,14 +1019,14 @@
 	char *charmap;
 	
 	if (vga_video_type != VIDEO_TYPE_EGAM) {
-		charmap = (char *) VGA_MAP_MEM(colourmap);
+		charmap = (char *) VGA_MAP_MEM(colourmap, 0);
 		beg = 0x0e;
 #ifdef VGA_CAN_DO_64KB
 		if (vga_video_type == VIDEO_TYPE_VGAC)
 			beg = 0x06;
 #endif
 	} else {
-		charmap = (char *) VGA_MAP_MEM(blackwmap);
+		charmap = (char *) VGA_MAP_MEM(blackwmap, 0);
 		beg = 0x0a;
 	}
 
Index: work-mm5/include/asm-alpha/vga.h
===================================================================
--- work-mm5.orig/include/asm-alpha/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-alpha/vga.h	2006-04-05 15:42:35.000000000 -0600
@@ -46,6 +46,6 @@
 #define vga_readb(a)	readb((u8 __iomem *)(a))
 #define vga_writeb(v,a)	writeb(v, (u8 __iomem *)(a))
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap(x, 0))
+#define VGA_MAP_MEM(x,s)	((unsigned long) ioremap(x, s))
 
 #endif
Index: work-mm5/include/asm-arm/vga.h
===================================================================
--- work-mm5.orig/include/asm-arm/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-arm/vga.h	2006-04-05 15:42:21.000000000 -0600
@@ -4,7 +4,7 @@
 #include <asm/hardware.h>
 #include <asm/io.h>
 
-#define VGA_MAP_MEM(x)	(PCIMEM_BASE + (x))
+#define VGA_MAP_MEM(x,s)	(PCIMEM_BASE + (x))
 
 #define vga_readb(x)	(*((volatile unsigned char *)x))
 #define vga_writeb(x,y)	(*((volatile unsigned char *)y) = (x))
Index: work-mm5/include/asm-i386/vga.h
===================================================================
--- work-mm5.orig/include/asm-i386/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-i386/vga.h	2006-04-05 15:42:49.000000000 -0600
@@ -12,7 +12,7 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-ia64/vga.h
===================================================================
--- work-mm5.orig/include/asm-ia64/vga.h	2006-04-05 09:57:55.000000000 -0600
+++ work-mm5/include/asm-ia64/vga.h	2006-04-05 15:43:09.000000000 -0600
@@ -17,7 +17,7 @@
 extern unsigned long vga_console_iobase;
 extern unsigned long vga_console_membase;
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x,s)	((unsigned long) ioremap_nocache(vga_console_membase + (x), s))
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/include/asm-m32r/vga.h
===================================================================
--- work-mm5.orig/include/asm-m32r/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-m32r/vga.h	2006-04-05 15:43:22.000000000 -0600
@@ -14,7 +14,7 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-mips/vga.h
===================================================================
--- work-mm5.orig/include/asm-mips/vga.h	2006-03-23 10:22:17.000000000 -0700
+++ work-mm5/include/asm-mips/vga.h	2006-04-05 15:43:32.000000000 -0600
@@ -13,7 +13,7 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x)	(0xb0000000L + (unsigned long)(x))
+#define VGA_MAP_MEM(x,s)	(0xb0000000L + (unsigned long)(x))
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/include/asm-powerpc/vga.h
===================================================================
--- work-mm5.orig/include/asm-powerpc/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-powerpc/vga.h	2006-04-05 15:43:57.000000000 -0600
@@ -42,9 +42,9 @@
 extern unsigned long vgacon_remap_base;
 
 #ifdef __powerpc64__
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap((x), 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
 #else
-#define VGA_MAP_MEM(x) (x + vgacon_remap_base)
+#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
 #endif
 
 #define vga_readb(x) (*(x))
Index: work-mm5/include/asm-sparc64/vga.h
===================================================================
--- work-mm5.orig/include/asm-sparc64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-sparc64/vga.h	2006-04-05 15:44:08.000000000 -0600
@@ -28,6 +28,6 @@
 	return *addr;
 }
 
-#define VGA_MAP_MEM(x) (x)
+#define VGA_MAP_MEM(x,s) (x)
 
 #endif
Index: work-mm5/include/asm-x86_64/vga.h
===================================================================
--- work-mm5.orig/include/asm-x86_64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-x86_64/vga.h	2006-04-05 15:44:18.000000000 -0600
@@ -12,7 +12,7 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-xtensa/vga.h
===================================================================
--- work-mm5.orig/include/asm-xtensa/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-xtensa/vga.h	2006-04-05 15:44:31.000000000 -0600
@@ -11,7 +11,7 @@
 #ifndef _XTENSA_VGA_H
 #define _XTENSA_VGA_H
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/drivers/video/console/mdacon.c
===================================================================
--- work-mm5.orig/drivers/video/console/mdacon.c	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/drivers/video/console/mdacon.c	2006-04-05 15:46:33.000000000 -0600
@@ -313,8 +313,8 @@
 	mda_num_columns = 80;
 	mda_num_lines   = 25;
 
-	mda_vram_base = VGA_MAP_MEM(0xb0000);
 	mda_vram_len  = 0x01000;
+	mda_vram_base = VGA_MAP_MEM(0xb0000, mda_vram_len);
 
 	mda_index_port  = 0x3b4;
 	mda_value_port  = 0x3b5;
Index: work-mm5/drivers/video/vga16fb.c
===================================================================
--- work-mm5.orig/drivers/video/vga16fb.c	2006-03-23 10:22:16.000000000 -0700
+++ work-mm5/drivers/video/vga16fb.c	2006-04-05 15:49:34.000000000 -0600
@@ -1351,7 +1351,7 @@
 	}
 
 	/* XXX share VGA_FB_PHYS and I/O region with vgacon and others */
-	info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS);
+	info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS, 0);
 
 	if (!info->screen_base) {
 		printk(KERN_ERR "vga16fb: unable to map device\n");

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S932116AbWDEWuf@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932116AbWDEWuf (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 18:50:35 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932115AbWDEWuf
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 18:50:35 -0400
Received: from mga01.intel.com ([192.55.52.88]:25099 "EHLO
	fmsmga101-1.fm.intel.com") by vger.kernel.org with ESMTP
	id S932096AbWDEWue convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 18:50:34 -0400
X-IronPort-AV: i="4.04,91,1144047600"; 
   d="scan'208"; a="20445385:sNHT37330734"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: RE: 2.6.17-rc1-mm1
Date: Wed, 5 Apr 2006 15:50:30 -0700
Message-ID: <B8E391BBE9FE384DAA4C5C003888BE6F06290233@scsmsx401.amr.corp.intel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 2.6.17-rc1-mm1
Thread-Index: AcZY/HfZ87ohMQBARrmZvtfEnA+DKAABsFAw
From: "Luck, Tony" <tony.luck@intel.com>
To: "Bjorn Helgaas" <bjorn.helgaas@hp.com>
Cc: "Zou, Nanhai" <nanhai.zou@intel.com>, "Andrew Morton" <akpm@osdl.org>,
       "LKML" <linux-kernel@vger.kernel.org>, <linux-ia64@vger.kernel.org>
X-OriginalArrivalTime: 05 Apr 2006 22:50:33.0662 (UTC) FILETIME=[58D2C5E0:01C65903]
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> I think the VGA_MAP_MEM(vga_vram_end) is just bogus -- it's not
> that we need to map the memory starting at vga_vram_end.  I think
> it would cleaner (though much more intrusive) to do something like
> the patch below, which basically just hard-codes (base, size)
> rather than (base, end).

This patch works for me on ia64/Tiger

-Tony

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751293AbWDFBuv@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751293AbWDFBuv (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 5 Apr 2006 21:50:51 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751327AbWDFBuv
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 5 Apr 2006 21:50:51 -0400
Received: from xproxy.gmail.com ([66.249.82.200]:31118 "EHLO xproxy.gmail.com")
	by vger.kernel.org with ESMTP id S1751293AbWDFBuu (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Apr 2006 21:50:50 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=KDyLx0vSDOtpzVxJ2KWvZh+jKxugg6nJGUO+M1bxS4gkhg9zS7jl6XbAsYPCUJrdOsh1QPq2qi0NTXhD0Kizi1Lqtzy7wCbjiVtjlGy8xgF1nxes+BlV1Nz/uI1iHZdqZq6B4zkXvPuPJ4lrTAFlHsi+5pCLhwTunu7gPhD++AQ=
Message-ID: <443473C3.4050807@gmail.com>
Date: Thu, 06 Apr 2006 09:49:55 +0800
From: "Antonino A. Daplas" <adaplas@gmail.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: "Luck, Tony" <tony.luck@intel.com>, Zou Nan hai <nanhai.zou@intel.com>,
       Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>,
       linux-ia64@vger.kernel.org
Subject: Re: 2.6.17-rc1-mm1
References: <20060404014504.564bf45a.akpm@osdl.org> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com> <200604051601.08776.bjorn.helgaas@hp.com>
In-Reply-To: <200604051601.08776.bjorn.helgaas@hp.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Bjorn Helgaas wrote:
> On Wednesday 05 April 2006 15:17, Luck, Tony wrote:
>> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:

> [PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use
> 
> VGA_MAP_MEM translates to ioremap() on some architectures.  It
> makes sense to do this to vga_vram_base, because we're going to
> access memory between vga_vram_base and vga_vram_end.
> 
> But it doesn't really make sense to map starting at vga_vram_end,
> because we aren't going to access memory starting there.  On ia64,
> which always has to be different, ioremapping vga_vram_end gives
> you something completely incompatible with ioremapped vga_vram_start,
> so vga_vram_size ends up being nonsense.
> 
> As a bonus, we often know the size up front, so we can use ioremap()
> correctly, rather than giving it a zero size.

I definitely prefer this patch.

> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Antonino Daplas <adaplas@pol.net>

Tony

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751150AbWDFKQO@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751150AbWDFKQO (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 6 Apr 2006 06:16:14 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751144AbWDFKQO
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 6 Apr 2006 06:16:14 -0400
Received: from caramon.arm.linux.org.uk ([212.18.232.186]:29194 "EHLO
	caramon.arm.linux.org.uk") by vger.kernel.org with ESMTP
	id S1751150AbWDFKQN (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 6 Apr 2006 06:16:13 -0400
Date: Thu, 6 Apr 2006 11:16:05 +0100
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>, Zou Nan hai <nanhai.zou@intel.com>,
       Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>,
       linux-ia64@vger.kernel.org
Subject: Re: 2.6.17-rc1-mm1
Message-ID: <20060406101604.GA28056@flint.arm.linux.org.uk>
Mail-Followup-To: "Luck, Tony" <tony.luck@intel.com>,
	Bjorn Helgaas <bjorn.helgaas@hp.com>,
	Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>,
	LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404233851.GA6411@agluck-lia64.sc.intel.com> <1144202706.3197.11.camel@linux-znh> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 05, 2006 at 02:17:57PM -0700, Luck, Tony wrote:
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh.  Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map.  I think that was
> > clearly a bug.  So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
> 
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
> 
> The problem looks to come from this code in vgacon.c:
> 
> 	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> 	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> 	vga_vram_size = vga_vram_end - vga_vram_base;

Wouldn't it be better to do:

	vga_vram_size = vga_vram_end - vga_vram_base;
	vga_vram_base = VGA_IOREMAP(vga_vram_base, vga_vram_size);
	vga_vram_end = vga_vram_base + vga_vram_size;

and for compatibility:

#define VGA_IOREMAP(base,size)	VGA_MAP_MEM(base)

?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S932162AbWDFKWD@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932162AbWDFKWD (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 6 Apr 2006 06:22:03 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932165AbWDFKWB
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 6 Apr 2006 06:22:01 -0400
Received: from caramon.arm.linux.org.uk ([212.18.232.186]:39439 "EHLO
	caramon.arm.linux.org.uk") by vger.kernel.org with ESMTP
	id S932162AbWDFKWA (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 6 Apr 2006 06:22:00 -0400
Date: Thu, 6 Apr 2006 11:21:54 +0100
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Luck, Tony" <tony.luck@intel.com>, Zou Nan hai <nanhai.zou@intel.com>,
       Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>,
       linux-ia64@vger.kernel.org
Subject: Re: 2.6.17-rc1-mm1
Message-ID: <20060406102154.GB28056@flint.arm.linux.org.uk>
Mail-Followup-To: Bjorn Helgaas <bjorn.helgaas@hp.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>,
	LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org
References: <20060404014504.564bf45a.akpm@osdl.org> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com> <200604051601.08776.bjorn.helgaas@hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200604051601.08776.bjorn.helgaas@hp.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 05, 2006 at 04:01:08PM -0600, Bjorn Helgaas wrote:
> [PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use

Ah, seems to be what I just suggested...

> @@ -1020,14 +1019,14 @@
>  	char *charmap;
>  	
>  	if (vga_video_type != VIDEO_TYPE_EGAM) {
> -		charmap = (char *) VGA_MAP_MEM(colourmap);
> +		charmap = (char *) VGA_MAP_MEM(colourmap, 0);

Don't like this though - can't we pass a real size here rather than zero?
There seems to be several clues as to the maximum size:

#define cmapsz 8192

        if (!vga_font_is_default)
                charmap += 4 * cmapsz;

                        charmap += 2 * cmapsz;
                                for (i = 0; i < cmapsz; i++)
                                        vga_writeb(arg[i], charmap + i);

so that's about 7 * cmapsz - call that 8 for completeness, which is 64K.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751144AbWDFKeh@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751144AbWDFKeh (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 6 Apr 2006 06:34:37 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751156AbWDFKeh
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 6 Apr 2006 06:34:37 -0400
Received: from caramon.arm.linux.org.uk ([212.18.232.186]:18451 "EHLO
	caramon.arm.linux.org.uk") by vger.kernel.org with ESMTP
	id S1751144AbWDFKeg (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 6 Apr 2006 06:34:36 -0400
Date: Thu, 6 Apr 2006 11:34:27 +0100
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>, "Luck, Tony" <tony.luck@intel.com>,
       Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>,
       LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org
Subject: Re: 2.6.17-rc1-mm1
Message-ID: <20060406103427.GC28056@flint.arm.linux.org.uk>
Mail-Followup-To: Bjorn Helgaas <bjorn.helgaas@hp.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	Zou Nan hai <nanhai.zou@intel.com>, Andrew Morton <akpm@osdl.org>,
	LKML <linux-kernel@vger.kernel.org>, linux-ia64@vger.kernel.org
References: <20060404014504.564bf45a.akpm@osdl.org> <200604051015.34217.bjorn.helgaas@hp.com> <20060405211757.GA8536@agluck-lia64.sc.intel.com> <200604051601.08776.bjorn.helgaas@hp.com> <20060406102154.GB28056@flint.arm.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060406102154.GB28056@flint.arm.linux.org.uk>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Apr 06, 2006 at 11:21:54AM +0100, Russell King wrote:
> On Wed, Apr 05, 2006 at 04:01:08PM -0600, Bjorn Helgaas wrote:
> > [PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use
> 
> Ah, seems to be what I just suggested...
> 
> > @@ -1020,14 +1019,14 @@
> >  	char *charmap;
> >  	
> >  	if (vga_video_type != VIDEO_TYPE_EGAM) {
> > -		charmap = (char *) VGA_MAP_MEM(colourmap);
> > +		charmap = (char *) VGA_MAP_MEM(colourmap, 0);
> 
> Don't like this though - can't we pass a real size here rather than zero?
> There seems to be several clues as to the maximum size:
> 
> #define cmapsz 8192
> 
>         if (!vga_font_is_default)
>                 charmap += 4 * cmapsz;
> 
>                         charmap += 2 * cmapsz;
>                                 for (i = 0; i < cmapsz; i++)
>                                         vga_writeb(arg[i], charmap + i);
> 
> so that's about 7 * cmapsz - call that 8 for completeness, which is 64K.

Oh, and obviously, can we also have a VGA_UNMAP_MEM() macro as well please?
8)  IOW, something like this (which I cobbled together from your patch, some
of it by hand-edits - couldn't get it to apply cleanly to current -git.)

diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -391,7 +391,7 @@ static const char __init *vgacon_startup
 			static struct resource ega_console_resource =
 			    { .name = "ega", .start = 0x3B0, .end = 0x3BF };
 			vga_video_type = VIDEO_TYPE_EGAM;
-			vga_vram_end = 0xb8000;
+			vga_vram_size = 0x8000;
 			display_desc = "EGA+";
 			request_resource(&ioport_resource,
 					 &ega_console_resource);
@@ -401,7 +401,7 @@ static const char __init *vgacon_startup
 			static struct resource mda2_console_resource =
 			    { .name = "mda", .start = 0x3BF, .end = 0x3BF };
 			vga_video_type = VIDEO_TYPE_MDA;
-			vga_vram_end = 0xb2000;
+			vga_vram_size = 0x2000;
 			display_desc = "*MDA";
 			request_resource(&ioport_resource,
 					 &mda1_console_resource);
@@ -418,7 +418,7 @@ static const char __init *vgacon_startup
 		if ((ORIG_VIDEO_EGA_BX & 0xff) != 0x10) {
 			int i;
 
-			vga_vram_end = 0xc0000;
+			vga_vram_size = 0x8000;
 
 			if (!ORIG_VIDEO_ISVGA) {
 				static struct resource ega_console_resource
@@ -443,7 +443,7 @@ static const char __init *vgacon_startup
 				 * and COE=1 isn't necessarily a good idea)
 				 */
 				vga_vram_base = 0xa0000;
-				vga_vram_end = 0xb0000;
+				vga_vram_size = 0x10000;
 				outb_p(6, VGA_GFX_I);
 				outb_p(6, VGA_GFX_D);
 #endif
@@ -475,7 +475,7 @@ static const char __init *vgacon_startup
 			static struct resource cga_console_resource =
 			    { .name = "cga", .start = 0x3D4, .end = 0x3D5 };
 			vga_video_type = VIDEO_TYPE_CGA;
-			vga_vram_end = 0xba000;
+			vga_vram_size = 0x2000;
 			display_desc = "*CGA";
 			request_resource(&ioport_resource,
 					 &cga_console_resource);
@@ -483,9 +483,8 @@ static const char __init *vgacon_startup
 		}
 	}
 
-	vga_vram_base = VGA_MAP_MEM(vga_vram_base);
-	vga_vram_end = VGA_MAP_MEM(vga_vram_end);
-	vga_vram_size = vga_vram_end - vga_vram_base;
+	vga_vram_base = VGA_MAP_MEM(vga_vram_base, vga_vram_size);
+	vga_vram_end = vga_vram_base + vga_vram_size;
 
 	/*
 	 *      Find out if there is a graphics card present.
@@ -1020,14 +1019,14 @@ static int vgacon_do_font_op(struct vgas
 	char *charmap;
 	
 	if (vga_video_type != VIDEO_TYPE_EGAM) {
-		charmap = (char *) VGA_MAP_MEM(colourmap);
+		charmap = (char *) VGA_MAP_MEM(colourmap, 8 * cmapsz);
 		beg = 0x0e;
 #ifdef VGA_CAN_DO_64KB
 		if (vga_video_type == VIDEO_TYPE_VGAC)
 			beg = 0x06;
 #endif
 	} else {
-		charmap = (char *) VGA_MAP_MEM(blackwmap);
+		charmap = (char *) VGA_MAP_MEM(blackwmap, 8 * cmapsz);
 		beg = 0x0a;
 	}
 
@@ -1102,6 +1101,8 @@ static int vgacon_do_font_op(struct vgas
 		}
 	}
 
+	VGA_UNMAP_MEM(charmap, 8 * cmapsz);
+
 	spin_lock_irq(&vga_lock);
 	/* First, the sequencer, Synchronous reset */
 	vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x01);	
Index: work-mm5/include/asm-alpha/vga.h
===================================================================
--- work-mm5.orig/include/asm-alpha/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-alpha/vga.h	2006-04-05 15:42:35.000000000 -0600
@@ -46,6 +46,7 @@
 #define vga_readb(a)	readb((u8 __iomem *)(a))
 #define vga_writeb(v,a)	writeb(v, (u8 __iomem *)(a))
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap(x, 0))
+#define VGA_MAP_MEM(x,s)	((unsigned long) ioremap(x, s))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #endif
Index: work-mm5/include/asm-arm/vga.h
===================================================================
--- work-mm5.orig/include/asm-arm/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-arm/vga.h	2006-04-05 15:42:21.000000000 -0600
@@ -4,7 +4,8 @@
 #include <asm/hardware.h>
 #include <asm/io.h>
 
-#define VGA_MAP_MEM(x)	(PCIMEM_BASE + (x))
+#define VGA_MAP_MEM(x,s)	(PCIMEM_BASE + (x))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x)	(*((volatile unsigned char *)x))
 #define vga_writeb(x,y)	(*((volatile unsigned char *)y) = (x))
Index: work-mm5/include/asm-i386/vga.h
===================================================================
--- work-mm5.orig/include/asm-i386/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-i386/vga.h	2006-04-05 15:42:49.000000000 -0600
@@ -12,7 +12,8 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-ia64/vga.h
===================================================================
--- work-mm5.orig/include/asm-ia64/vga.h	2006-04-05 09:57:55.000000000 -0600
+++ work-mm5/include/asm-ia64/vga.h	2006-04-05 15:43:09.000000000 -0600
@@ -17,7 +17,8 @@
 extern unsigned long vga_console_iobase;
 extern unsigned long vga_console_membase;
 
-#define VGA_MAP_MEM(x)	((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x,s)	((unsigned long) ioremap_nocache(vga_console_membase + (x), s))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/include/asm-m32r/vga.h
===================================================================
--- work-mm5.orig/include/asm-m32r/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-m32r/vga.h	2006-04-05 15:43:22.000000000 -0600
@@ -14,7 +14,8 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-mips/vga.h
===================================================================
--- work-mm5.orig/include/asm-mips/vga.h	2006-03-23 10:22:17.000000000 -0700
+++ work-mm5/include/asm-mips/vga.h	2006-04-05 15:43:32.000000000 -0600
@@ -13,7 +13,8 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x)	(0xb0000000L + (unsigned long)(x))
+#define VGA_MAP_MEM(x,s)	(0xb0000000L + (unsigned long)(x))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/include/asm-powerpc/vga.h
===================================================================
--- work-mm5.orig/include/asm-powerpc/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-powerpc/vga.h	2006-04-05 15:43:57.000000000 -0600
@@ -42,9 +42,11 @@
 extern unsigned long vgacon_remap_base;
 
 #ifdef __powerpc64__
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap((x), 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 #else
-#define VGA_MAP_MEM(x) (x + vgacon_remap_base)
+#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 #endif
 
 #define vga_readb(x) (*(x))
Index: work-mm5/include/asm-sparc64/vga.h
===================================================================
--- work-mm5.orig/include/asm-sparc64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-sparc64/vga.h	2006-04-05 15:44:08.000000000 -0600
@@ -28,6 +28,7 @@
 	return *addr;
 }
 
-#define VGA_MAP_MEM(x) (x)
+#define VGA_MAP_MEM(x,s) (x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #endif
Index: work-mm5/include/asm-x86_64/vga.h
===================================================================
--- work-mm5.orig/include/asm-x86_64/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-x86_64/vga.h	2006-04-05 15:44:18.000000000 -0600
@@ -12,7 +12,8 @@
  *	access the videoram directly without any black magic.
  */
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-xtensa/vga.h
===================================================================
--- work-mm5.orig/include/asm-xtensa/vga.h	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-xtensa/vga.h	2006-04-05 15:44:31.000000000 -0600
@@ -11,7 +11,8 @@
 #ifndef _XTENSA_VGA_H
 #define _XTENSA_VGA_H
 
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
+#define VGA_UNMAP_MEM(x,s)	do { } while (0)
 
 #define vga_readb(x)	(*(x))
 #define vga_writeb(x,y)	(*(y) = (x))
Index: work-mm5/drivers/video/console/mdacon.c
===================================================================
--- work-mm5.orig/drivers/video/console/mdacon.c	2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/drivers/video/console/mdacon.c	2006-04-05 15:46:33.000000000 -0600
@@ -313,8 +313,8 @@
 	mda_num_columns = 80;
 	mda_num_lines   = 25;
 
-	mda_vram_base = VGA_MAP_MEM(0xb0000);
 	mda_vram_len  = 0x01000;
+	mda_vram_base = VGA_MAP_MEM(0xb0000, mda_vram_len);
 
 	mda_index_port  = 0x3b4;
 	mda_value_port  = 0x3b5;
Index: work-mm5/drivers/video/vga16fb.c
===================================================================
--- work-mm5.orig/drivers/video/vga16fb.c	2006-03-23 10:22:16.000000000 -0700
+++ work-mm5/drivers/video/vga16fb.c	2006-04-05 15:49:34.000000000 -0600
@@ -1351,7 +1351,7 @@
 	}
 
 	/* XXX share VGA_FB_PHYS and I/O region with vgacon and others */
-	info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS);
+	info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS, VGA_FB_PHYS_LEN);
 
 	if (!info->screen_base) {
 		printk(KERN_ERR "vga16fb: unable to map device\n");

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S932172AbWDFOzg@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932172AbWDFOzg (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 6 Apr 2006 10:55:36 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932175AbWDFOzf
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 6 Apr 2006 10:55:35 -0400
Received: from atlrel6.hp.com ([156.153.255.205]:19648 "EHLO atlrel6.hp.com")
	by vger.kernel.org with ESMTP id S932172AbWDFOze (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 6 Apr 2006 10:55:34 -0400
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Subject: Re: 2.6.17-rc1-mm1
Date: Thu, 6 Apr 2006 08:55:27 -0600
User-Agent: KMail/1.8.3
Cc: "Luck, Tony" <tony.luck@intel.com>, Zou Nan hai <nanhai.zou@intel.com>,
       Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>,
       linux-ia64@vger.kernel.org
References: <20060404014504.564bf45a.akpm@osdl.org> <20060406102154.GB28056@flint.arm.linux.org.uk> <20060406103427.GC28056@flint.arm.linux.org.uk>
In-Reply-To: <20060406103427.GC28056@flint.arm.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200604060855.27673.bjorn.helgaas@hp.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thursday 06 April 2006 04:34, Russell King wrote:
> On Thu, Apr 06, 2006 at 11:21:54AM +0100, Russell King wrote:
> > On Wed, Apr 05, 2006 at 04:01:08PM -0600, Bjorn Helgaas wrote:
> > > [PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use
> > 
> > Ah, seems to be what I just suggested...
> > 
> > > @@ -1020,14 +1019,14 @@
> > >  	char *charmap;
> > >  	
> > >  	if (vga_video_type != VIDEO_TYPE_EGAM) {
> > > -		charmap = (char *) VGA_MAP_MEM(colourmap);
> > > +		charmap = (char *) VGA_MAP_MEM(colourmap, 0);
> > 
> > Don't like this though - can't we pass a real size here rather than zero?
> > There seems to be several clues as to the maximum size:

I didn't like it either, but was too lazy to work out the actual size,
so I just preserved the previous behavior.

Andrew's put my first patch in -mm already, so I'll put this size
issue and your unmap suggestion on my to-do list.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S932180AbWDFWhU@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932180AbWDFWhU (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 6 Apr 2006 18:37:20 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932188AbWDFWhU
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 6 Apr 2006 18:37:20 -0400
Received: from mailout.stusta.mhn.de ([141.84.69.5]:7431 "HELO
	mailout.stusta.mhn.de") by vger.kernel.org with SMTP
	id S932180AbWDFWhS (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 6 Apr 2006 18:37:18 -0400
Date: Fri, 7 Apr 2006 00:37:16 +0200
From: Adrian Bunk <bunk@stusta.de>
To: Zachary Amsden <zach@vmware.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org,
       ebiederm@xmission.com, rdunlap@xenotime.net, fastboot@osdl.org,
       James.Bottomley@HansenPartnership.com
Subject: Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
Message-ID: <20060406223716.GB7118@stusta.de>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060404162921.GK6529@stusta.de> <4432AB57.1040006@vmware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4432AB57.1040006@vmware.com>
User-Agent: Mutt/1.5.11+cvs20060126
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 04, 2006 at 10:22:31AM -0700, Zachary Amsden wrote:
>...
> Voyager SMP builds don't compile with kexec(), and it isn't clear how to 
> shootdown CPUs using NMIs without an APIC.
>...
>  config KEXEC
>  	bool "kexec system call (EXPERIMENTAL)"
> -	depends on EXPERIMENTAL && (!X86_VOYAGER && SMP)
> +	depends on EXPERIMENTAL && !(X86_VOYAGER && SMP)
>...

Unless James disagrees with me, I'd prefer to let X86_VOYAGER depend on 
SMP (the CONFIG_SMP=n case is anyways not compiling), and you could 
express this simply as "&& !X86_VOYAGER".

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S964834AbWDGU6e@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S964834AbWDGU6e (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 7 Apr 2006 16:58:34 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964841AbWDGU6e
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 7 Apr 2006 16:58:34 -0400
Received: from uproxy.gmail.com ([66.249.92.173]:28552 "EHLO uproxy.gmail.com")
	by vger.kernel.org with ESMTP id S964834AbWDGU6d (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 7 Apr 2006 16:58:33 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=EW/+/hWpWZvyXtPuZ9EqxyUEiFuGlJhEKgu/ufKK/u4mSmpvmMje1qLfq015xOv7u1CkfQWR5RBr4CvO/9WnOnKVzus6p29HBNEze+Drnol9cwGAEk9BhjOahWR3aqL+HFVOWm8e0haL9JeGFnWsuPBsCY2gIAr5HtHZB7qktCQ=
Message-ID: <4436D275.2010402@gmail.com>
Date: Fri, 07 Apr 2006 16:58:29 -0400
From: Jim Cromie <jim.cromie@gmail.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
CC: john stultz <johnstul@us.ibm.com>
Subject: Re: 2.6.17-rc1-mm1 - detects buggy TSC on GEODE
References: <20060404014504.564bf45a.akpm@osdl.org>
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


FYI, 

as the 2 syslog extracts show;
1.   the new kernel is now detecting the buggy TSC on the GEODE-sc1100
2.    the bug is apparently correctable by passing 'idle=poll' on kernel 
boot-line.

Heres one vendor's bug/erratta description:
    http://soekris.com/Issue0003.htm


Apr  7 11:42:01 truck kernel: [   19.160016] Kernel command line: 
console=ttyS0,115200n81 root=/dev/nfs 
nfsroot=192.168.42.1:/nfshost/soekris 
nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0 
panic=5   BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
Apr  7 11:42:01 truck kernel: [   24.314851] Time: tsc clocksource has 
been installed.
Apr  7 11:42:01 truck kernel: [   29.977802] TSC appears to be running 
slowly. Marking it as unstable
Apr  7 11:42:01 truck kernel: [   20.460000] Time: pit clocksource has 
been installed.


Apr  7 12:35:56 truck kernel: [   21.562573] Kernel command line: 
console=ttyS0,115200n81 root=/dev/nfs 
nfsroot=192.168.42.1:/nfshost/soekris 
nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0 
panic=5  idle=poll BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
Apr  7 12:35:56 truck kernel: [   21.563049] using polling idle threads.
Apr  7 12:35:56 truck kernel: [   28.393469] Time: tsc clocksource has 
been installed.


Its nice to see the buggy TSC detector detect, and the work-around work.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751366AbWDHAEp@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751366AbWDHAEp (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 7 Apr 2006 20:04:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751367AbWDHAEo
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 7 Apr 2006 20:04:44 -0400
Received: from smtp.osdl.org ([65.172.181.4]:26582 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1751366AbWDHAEo (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 7 Apr 2006 20:04:44 -0400
Date: Fri, 7 Apr 2006 17:07:06 -0700
From: Andrew Morton <akpm@osdl.org>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: linux-kernel@vger.kernel.org, johnstul@us.ibm.com
Subject: Re: 2.6.17-rc1-mm1 - detects buggy TSC on GEODE
Message-Id: <20060407170706.1ae11ea1.akpm@osdl.org>
In-Reply-To: <4436D275.2010402@gmail.com>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<4436D275.2010402@gmail.com>
X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Jim Cromie <jim.cromie@gmail.com> wrote:
>
> 
> FYI, 
> 
> as the 2 syslog extracts show;
> 1.   the new kernel is now detecting the buggy TSC on the GEODE-sc1100
> 2.    the bug is apparently correctable by passing 'idle=poll' on kernel 
> boot-line.
> 
> Heres one vendor's bug/erratta description:
>     http://soekris.com/Issue0003.htm
> 
> 
> Apr  7 11:42:01 truck kernel: [   19.160016] Kernel command line: 
> console=ttyS0,115200n81 root=/dev/nfs 
> nfsroot=192.168.42.1:/nfshost/soekris 
> nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0 
> panic=5   BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
> Apr  7 11:42:01 truck kernel: [   24.314851] Time: tsc clocksource has 
> been installed.
> Apr  7 11:42:01 truck kernel: [   29.977802] TSC appears to be running 
> slowly. Marking it as unstable
> Apr  7 11:42:01 truck kernel: [   20.460000] Time: pit clocksource has 
> been installed.
> 
> 
> Apr  7 12:35:56 truck kernel: [   21.562573] Kernel command line: 
> console=ttyS0,115200n81 root=/dev/nfs 
> nfsroot=192.168.42.1:/nfshost/soekris 
> nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0 
> panic=5  idle=poll BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
> Apr  7 12:35:56 truck kernel: [   21.563049] using polling idle threads.
> Apr  7 12:35:56 truck kernel: [   28.393469] Time: tsc clocksource has 
> been installed.
> 
> 
> Its nice to see the buggy TSC detector detect, and the work-around work.

hm.

John, does this mean that enable-tsc-for-amd-geode-gx-lx.patch is only safe
to merge after all your time-management patches have gone in?

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751378AbWDHAZn@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751378AbWDHAZn (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 7 Apr 2006 20:25:43 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751379AbWDHAZn
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 7 Apr 2006 20:25:43 -0400
Received: from e32.co.us.ibm.com ([32.97.110.150]:33679 "EHLO
	e32.co.us.ibm.com") by vger.kernel.org with ESMTP id S1751378AbWDHAZm
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 7 Apr 2006 20:25:42 -0400
Subject: Re: 2.6.17-rc1-mm1 - detects buggy TSC on GEODE
From: john stultz <johnstul@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Jim Cromie <jim.cromie@gmail.com>, linux-kernel@vger.kernel.org
In-Reply-To: <20060407170706.1ae11ea1.akpm@osdl.org>
References: <20060404014504.564bf45a.akpm@osdl.org>
	 <4436D275.2010402@gmail.com>  <20060407170706.1ae11ea1.akpm@osdl.org>
Content-Type: text/plain
Date: Fri, 07 Apr 2006 17:25:44 -0700
Message-Id: <1144455945.16269.3.camel@leatherman>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 (2.6.0-1) 
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 2006-04-07 at 17:07 -0700, Andrew Morton wrote:
> Jim Cromie <jim.cromie@gmail.com> wrote:
> > as the 2 syslog extracts show;
> > 1.   the new kernel is now detecting the buggy TSC on the GEODE-sc1100
> > 2.    the bug is apparently correctable by passing 'idle=poll' on kernel 
> > boot-line.
>
> John, does this mean that enable-tsc-for-amd-geode-gx-lx.patch is only safe
> to merge after all your time-management patches have gone in?

Hmmm. That would look to be the case from Jim's mail, although I'm not
very familiar with the hardware in question, so I could be wrong. 

thanks
-john


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751387AbWDHBPM@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751387AbWDHBPM (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 7 Apr 2006 21:15:12 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751388AbWDHBPM
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 7 Apr 2006 21:15:12 -0400
Received: from xproxy.gmail.com ([66.249.82.207]:4118 "EHLO xproxy.gmail.com")
	by vger.kernel.org with ESMTP id S1751387AbWDHBPK (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 7 Apr 2006 21:15:10 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=XAgeP0UVqdPQp78EC+wBcYNsXUgIHQs1dKCot2pYPQleAg5L6EXQPZ2O5nYmCESD7jmiCwEb6fTJg3/LPZ2gbZE80Inmtpn+WdIPBxu1szizRF5d4TuTHfsLMbO2LBJhUkcAa8CJnV7QpLJo3iSElRGe2He42+WU0k/Ts0TQzMs=
Message-ID: <44370E9B.8060309@gmail.com>
Date: Fri, 07 Apr 2006 21:15:07 -0400
From: Jim Cromie <jim.cromie@gmail.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Andrew Morton <akpm@osdl.org>
CC: linux-kernel@vger.kernel.org, johnstul@us.ibm.com
Subject: Re: 2.6.17-rc1-mm1 - detects buggy TSC on GEODE
References: <20060404014504.564bf45a.akpm@osdl.org>	<4436D275.2010402@gmail.com> <20060407170706.1ae11ea1.akpm@osdl.org>
In-Reply-To: <20060407170706.1ae11ea1.akpm@osdl.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Andrew Morton wrote:
> Jim Cromie <jim.cromie@gmail.com> wrote:
>   
>> FYI, 
>>
>> as the 2 syslog extracts show;
>> 1.   the new kernel is now detecting the buggy TSC on the GEODE-sc1100
>> 2.    the bug is apparently correctable by passing 'idle=poll' on kernel 
>> boot-line.
>>
>> Heres one vendor's bug/erratta description:
>>     http://soekris.com/Issue0003.htm
>>
>>
>> Apr  7 11:42:01 truck kernel: [   19.160016] Kernel command line: 
>> console=ttyS0,115200n81 root=/dev/nfs 
>> nfsroot=192.168.42.1:/nfshost/soekris 
>> nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0 
>> panic=5   BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
>> Apr  7 11:42:01 truck kernel: [   24.314851] Time: tsc clocksource has 
>> been installed.
>> Apr  7 11:42:01 truck kernel: [   29.977802] TSC appears to be running 
>> slowly. Marking it as unstable
>> Apr  7 11:42:01 truck kernel: [   20.460000] Time: pit clocksource has 
>> been installed.
>>
>>
>> Apr  7 12:35:56 truck kernel: [   21.562573] Kernel command line: 
>> console=ttyS0,115200n81 root=/dev/nfs 
>> nfsroot=192.168.42.1:/nfshost/soekris 
>> nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0 
>> panic=5  idle=poll BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
>> Apr  7 12:35:56 truck kernel: [   21.563049] using polling idle threads.
>> Apr  7 12:35:56 truck kernel: [   28.393469] Time: tsc clocksource has 
>> been installed.
>>
>>
>> Its nice to see the buggy TSC detector detect, and the work-around work.
>>     
>
> hm.
>
> John, does this mean that enable-tsc-for-amd-geode-gx-lx.patch is only safe
> to merge after all your time-management patches have gone in?
>
>   

that patch adds only MGEODE_LX, MGEODEGX1 was already there.

per the soekris link:

The net4801 board use a new single chip x86 processor from National 
Semiconductor, the SC1100. It is based on the Cyrix GX1 core and the 
CS5530 support chip, but has some difference. So far we have identified 
the following issues that might need a patch to the operating system:

So, by a narrow reading, the current Kconfig already enables the TSC for 
my board.
IOW, the patch doesnt worsen the situation.  I dont know whether the bug 
affects MGEODE_LX,
but it sounds like it could be a different core, w/o the bug.

The only folks possibly hurt by this patch are those who have 
mis-selected MGEODE_LX
when they have a MGEODEGX1, and are currently protected from using the 
buggy TSC.

my $.02, keep it in.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S964822AbWDMHkK@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S964822AbWDMHkK (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 13 Apr 2006 03:40:10 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964823AbWDMHkK
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 13 Apr 2006 03:40:10 -0400
Received: from mtagate3.de.ibm.com ([195.212.29.152]:59100 "EHLO
	mtagate3.de.ibm.com") by vger.kernel.org with ESMTP id S964822AbWDMHkI
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 13 Apr 2006 03:40:08 -0400
Date: Thu, 13 Apr 2006 09:39:58 +0200
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.17-rc1-mm1
Message-ID: <20060413073958.GB9428@osiris.boeblingen.de.ibm.com>
References: <20060404014504.564bf45a.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060404014504.564bf45a.akpm@osdl.org>
User-Agent: mutt-ng/devel-r796 (Linux)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> +md-dm-reduce-stack-usage-with-stacked-block-devices.patch
>  MD update.

Any chance to see this merged? I think this one is pending for quite a while.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751147AbWDMINh@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751147AbWDMINh (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 13 Apr 2006 04:13:37 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751152AbWDMINh
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 13 Apr 2006 04:13:37 -0400
Received: from smtp.osdl.org ([65.172.181.4]:5601 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S1751147AbWDMINg (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 13 Apr 2006 04:13:36 -0400
Date: Thu, 13 Apr 2006 01:13:03 -0700
From: Andrew Morton <akpm@osdl.org>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, Alasdair G Kergon <agk@redhat.com>
Subject: Re: 2.6.17-rc1-mm1
Message-Id: <20060413011303.668fe5c1.akpm@osdl.org>
In-Reply-To: <20060413073958.GB9428@osiris.boeblingen.de.ibm.com>
References: <20060404014504.564bf45a.akpm@osdl.org>
	<20060413073958.GB9428@osiris.boeblingen.de.ibm.com>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> > +md-dm-reduce-stack-usage-with-stacked-block-devices.patch
> >  MD update.
> 
> Any chance to see this merged? I think this one is pending for quite a while.

Last time I broached it with Alasdair (10 Jan) he said

  I can see nothing wrong with this in principle.

  For device-mapper at the moment though it's essential that, while the
  bio mappings may now get delayed, they still get processed in exactly the
  same order as they were passed to generic_make_request().

  My main concern is whether the timing changes implicit in this patch
  will make the rare data-corrupting races in the existing snapshot code
  more likely.  (I'm working on a fix for these races, but the unfinished
  patch is already several hundred lines long.)

  It would be helpful if some people on this mailing list would test this
  patch in various scenarios and report back.


yes, it has been around for rather a while.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751256AbWDNQIK@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751256AbWDNQIK (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 14 Apr 2006 12:08:10 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751258AbWDNQIK
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 14 Apr 2006 12:08:10 -0400
Received: from mx1.redhat.com ([66.187.233.31]:59297 "EHLO mx1.redhat.com")
	by vger.kernel.org with ESMTP id S1751256AbWDNQIJ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 14 Apr 2006 12:08:09 -0400
Date: Fri, 14 Apr 2006 17:07:56 +0100
From: Alasdair G Kergon <agk@redhat.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: 2.6.17-rc1-mm1
Message-ID: <20060414160756.GG10725@agk.surrey.redhat.com>
Mail-Followup-To: Alasdair G Kergon <agk@redhat.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
References: <20060404014504.564bf45a.akpm@osdl.org> <20060413073958.GB9428@osiris.boeblingen.de.ibm.com> <20060413011303.668fe5c1.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060413011303.668fe5c1.akpm@osdl.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Apr 13, 2006 at 01:13:03AM -0700, Andrew Morton wrote:
> Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> >
> > > +md-dm-reduce-stack-usage-with-stacked-block-devices.patch
> > >  MD update.
> > 
> > Any chance to see this merged? I think this one is pending for quite a while.
 
I looked at this in detail last month, hoping to get it
out of the way, but unfortunately found that, in dm-crypt:

  Instead of the stack growing, we'll be allocating successive
  bios out of the *same* mempool and, without the recursion, we'll
  have lost the possibility of a later allocation waiting for an
  earlier one to be released after its endio.

In other words, I think part of dm-crypt needs re-writing to avoid problems
under memory pressure after this patch is applied.  And on the face of it,
__clone_and_map() may suffer from similar problems should a bio need to be
split into several pieces.

Alasdair
-- 
agk@redhat.com

