LinuxLists.cc - 2.6.18-rc4-mm3

[permalink] [raw]

Subject: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
> git-nfs.patch
>...
> git trees
>...

This breaks CONFIG_ROOT_NFS=y:

<-- snip -->

...
CC fs/nfs/mount_clnt.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c: In function ‘mnt_create’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82: error: implicit declaration of function ‘xprt_create_proto’
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82: warning: assignment makes pointer from integer without a cast
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:86: error: implicit declaration of function ‘rpc_create_client’
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:88: warning: assignment makes pointer from integer without a cast
make[3]: *** [fs/nfs/mount_clnt.o] Error 1

<-- snip -->

cu
Adrian

--

Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).

There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli

2006-08-27 02:00:00

[permalink] [raw]

Subject: [-mm patch] drivers/i2c/busses/scx200_i2c.c: update struct scx200_i2c_data

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
> +gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
>...
> I2C tree updates
>...

drivers/i2c/busses/scx200_i2c.c was forgotten:

<-- snip -->

...
CC drivers/i2c/busses/scx200_i2c.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c:79: warning: excess elements in struct initializer
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c:79: warning: (near initialization for ‘scx200_i2c_data’)
...

<-- snip -->

While fixing it, I also converted the struct to C99 initializers.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c.old 2006-08-27 03:57:50.000000000 +0200
+++ linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c 2006-08-27 03:51:50.000000000 +0200
@@ -71,12 +71,12 @@
*/

static struct i2c_algo_bit_data scx200_i2c_data = {
- NULL,
- scx200_i2c_setsda,
- scx200_i2c_setscl,
- scx200_i2c_getsda,
- scx200_i2c_getscl,
- 10, 10, 100, /* waits, timeout */
+ .setsda = scx200_i2c_setsda,
+ .setscl = scx200_i2c_setscl,
+ .getsda = scx200_i2c_getsda,
+ .getscl = scx200_i2c_getscl,
+ .udelay = 10,
+ .timeout = 100,
};

static struct i2c_adapter scx200_i2c_ops = {

2006-08-27 02:42:21

[permalink] [raw]

Subject: 2.6.18-rc4-mm3: NF_CONNTRACK_FTP=y compile error

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
> git-net.patch
>...
> git trees
>...

<-- snip -->

...
CC net/netfilter/nf_conntrack_ftp.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c: In function ‘get_ipv6_addr’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: warning: implicit declaration of function ‘in6_pton’
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: ‘end’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: for each function it appears in.)
make[3]: *** [net/netfilter/nf_conntrack_ftp.o] Error 1

<-- snip -->

cu
Adrian

--

Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).

There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli

2006-08-27 02:47:06

[permalink] [raw]

Subject: [-mm patch] struct i2c_algo_pcf_data: remove the mdelay member

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
> +gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
>...
> I2C tree updates
>...

This patch also removes the only usage of the mdelay member in
struct i2c_algo_pcf_data, but doesn't remove the struct member itself.

Is seems this patch was also intended?

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h.old 2006-08-27 04:01:35.000000000 +0200
+++ linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h 2006-08-27 04:01:40.000000000 +0200
@@ -35,7 +35,6 @@ struct i2c_algo_pcf_data {

/* local settings */
int udelay;
- int mdelay;
int timeout;
};

2006-08-27 02:49:22

by David Miller

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3: NF_CONNTRACK_FTP=y compile error

From: Adrian Bunk <[email protected]>
Date: Sun, 27 Aug 2006 04:42:19 +0200

> CC net/netfilter/nf_conntrack_ftp.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c: In function $,1rx(Bget_ipv6_addr$,1ry(B:
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: warning: implicit declaration of function $,1rx(Bin6_pton$,1ry(B
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: $,1rx(Bend$,1ry(B undeclared (first use in this function)
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: (Each undeclared identifier is reported only once
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: for each function it appears in.)
> make[3]: *** [net/netfilter/nf_conntrack_ftp.o] Error 1

So the one single place where we call this new in6_pton() thing,
it doesn't even compile.

Yoshifuji, what tree are you testing your builds against? This
is the second build failure introduced by this in6_pton()
changeset.

I'm going to butcher it like this so at least it builds.

commit 32677088bc145cf7d45466e39286f1a8c7bf2d67
Author: David S. Miller <[email protected]>
Date: Sat Aug 26 19:48:49 2006 -0700

[NETFILTER]: Fix nf_conntrack_ftp.c build.

Noticed by Adrian Bunk.

Signed-off-by: David S. Miller <[email protected]>

diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c
index 9dccb40..0c17a5b 100644
--- a/net/netfilter/nf_conntrack_ftp.c
+++ b/net/netfilter/nf_conntrack_ftp.c
@@ -21,6 +21,7 @@ #include <linux/netfilter.h>
#include <linux/ip.h>
#include <linux/ipv6.h>
#include <linux/ctype.h>
+#include <linux/inet.h>
#include <net/checksum.h>
#include <net/tcp.h>

@@ -114,7 +115,8 @@ static struct ftp_search {
static int
get_ipv6_addr(const char *src, size_t dlen, struct in6_addr *dst, u_int8_t term)
{
- int ret = in6_pton(src, min_t(size_t, dlen, 0xffff), dst, term, &end);
+ const char *end;
+ int ret = in6_pton(src, min_t(size_t, dlen, 0xffff), (u8 *)dst, term, &end);
if (ret > 0)
return (int)(end - src);
return 0;

2006-08-27 08:20:06

by Jean Delvare

[permalink] [raw]

Subject: Re: [-mm patch] drivers/i2c/busses/scx200_i2c.c: update struct scx200_i2c_data

Hi Adrian,

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm2:
> >...
> > +gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
> >...
> > I2C tree updates
> >...
>
> drivers/i2c/busses/scx200_i2c.c was forgotten:
>
> <-- snip -->
>
> ...
> CC drivers/i2c/busses/scx200_i2c.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c:79: warning: excess elements in struct initializer
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c:79: warning: (near initialization for ‘scx200_i2c_data’)
> ...
>
> <-- snip -->
>
> While fixing it, I also converted the struct to C99 initializers.
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> --- linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c.old 2006-08-27 03:57:50.000000000 +0200
> +++ linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c 2006-08-27 03:51:50.000000000 +0200
> @@ -71,12 +71,12 @@
> */
>
> static struct i2c_algo_bit_data scx200_i2c_data = {
> - NULL,
> - scx200_i2c_setsda,
> - scx200_i2c_setscl,
> - scx200_i2c_getsda,
> - scx200_i2c_getscl,
> - 10, 10, 100, /* waits, timeout */
> + .setsda = scx200_i2c_setsda,
> + .setscl = scx200_i2c_setscl,
> + .getsda = scx200_i2c_getsda,
> + .getscl = scx200_i2c_getscl,
> + .udelay = 10,
> + .timeout = 100,
> };
>
> static struct i2c_adapter scx200_i2c_ops = {

Good catch, thanks for fixing that. I tried to catch and fix all users
when dropping mdelay from struct i2c_algo_bit_data, but obviously I
missed this one.

Patch applied.

--
Jean Delvare

2006-08-27 08:44:13

by Jean Delvare

[permalink] [raw]

Subject: Re: [-mm patch] struct i2c_algo_pcf_data: remove the mdelay member

Hi Adrian,

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm2:
> >...
> > +gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
> >...
> > I2C tree updates
> >...
>
> This patch also removes the only usage of the mdelay member in
> struct i2c_algo_pcf_data, but doesn't remove the struct member itself.
>
> Is seems this patch was also intended?
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> --- linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h.old 2006-08-27 04:01:35.000000000 +0200
> +++ linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h 2006-08-27 04:01:40.000000000 +0200
> @@ -35,7 +35,6 @@ struct i2c_algo_pcf_data {
>
> /* local settings */
> int udelay;
> - int mdelay;
> int timeout;
> };

I removed mdelay from i2c-elektor thinking that it was using
i2c-algo-bit, I didn't realize it was using a different i2c algorithm.
And I didn't know i2c-algo-pcf also had an unused mdelay.

I will send an updated i2c-algo-bit-kill-mdelay.patch to Greg which
doesn't affect i2c-elektor. Then we can stack a second patch doing the
same for i2c-algo-pcf, which will include your change above, and my
change to i2c-elektor.

I agree it doesn't matter much, in the end we end up removing
everything and it was dead code anyway, but let's still have clean
separate patches doing just one thing at a time.

I just found that i2c-algo-ite has the same unused mdelay member in its
algorithm data structure... But I wouldn't bother cleaning it up, given
that it is planed for removal next month anyway.

Thanks,
--
Jean Delvare

2006-08-27 12:50:22

by Benoit Boissinot

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On 8/27/06, Andrew Morton <[email protected]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
>
> Changes since 2.6.18-rc4-mm2:
>
> git-net.patch

It introduces a new warning for me:
net/netfilter/xt_CONNMARK.c: In function 'target':
net/netfilter/xt_CONNMARK.c:59: warning: implicit declaration of
function 'nf_conntrack_event_cache'

The warning is due to the following .config:
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
CONFIG_IP_NF_CONNTRACK_NETLINK=m

This change was introduced by:
http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.19.git;a=commit;h=76e4b41009b8a2e9dd246135cf43c7fe39553aa5

Proposed solution (based on the define in
include/net/netfilter/nf_conntrack_compat.h:

Signed-off-by: Benoit Boissinot <[email protected]>

Index: linux/net/netfilter/xt_CONNMARK.c
===================================================================
--- linux.orig/net/netfilter/xt_CONNMARK.c
+++ linux/net/netfilter/xt_CONNMARK.c
@@ -53,7 +53,7 @@ target(struct sk_buff **pskb,
newmark = (*ctmark & ~markinfo->mask) | markinfo->mark;
if (newmark != *ctmark) {
*ctmark = newmark;
-#ifdef CONFIG_IP_NF_CONNTRACK_EVENTS
+#if defined(CONFIG_IP_NF_CONNTRACK) || defined(CONFIG_IP_NF_CONNTRACK_MODULE)
ip_conntrack_event_cache(IPCT_MARK, *pskb);
#else
nf_conntrack_event_cache(IPCT_MARK, *pskb);
@@ -65,7 +65,7 @@ target(struct sk_buff **pskb,
((*pskb)->nfmark & markinfo->mask);
if (*ctmark != newmark) {
*ctmark = newmark;
-#ifdef CONFIG_IP_NF_CONNTRACK_EVENTS
+#if defined(CONFIG_IP_NF_CONNTRACK) || defined(CONFIG_IP_NF_CONNTRACK_MODULE)
ip_conntrack_event_cache(IPCT_MARK, *pskb);
#else
nf_conntrack_event_cache(IPCT_MARK, *pskb);

2006-08-27 16:00:15

by Benoit Boissinot

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On 8/27/06, Andrew Morton <[email protected]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
>
> git-acpi.patch

commit f62d31ee2f2f453b07107465fea54540cab418eb broke my laptop
(pentium M, dell D600).
I can reliably get a hard lockup (no sysrq) when modprobing ehci_hcd
and uhci_hci. It works when reverting the changeset.

I can provide cpuinfo or dmesg if necessary.

regards,

Benoit

2006-08-27 16:53:35

by Pallipadi, Venkatesh

[permalink] [raw]

Subject: RE: 2.6.18-rc4-mm3

OK. This is the second system on which failure has happened. Can you
please send me the acpidump output (You can get latest pmtools from here
- http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ ).
Unfortunately I am not able to reproduce this failure on my local
systems yet. I will try to find out what may be going wrong.

Andrew: Can you revert the below patch until the issue is resolved.

Thanks,
Venki

>-----Original Message-----
>From: Benoit Boissinot [mailto:[email protected]]
>Sent: Sunday, August 27, 2006 9:00 AM
>To: Andrew Morton
>Cc: [email protected]; Pallipadi, Venkatesh; Brown, Len
>Subject: Re: 2.6.18-rc4-mm3
>
>On 8/27/06, Andrew Morton <[email protected]> wrote:
>>
>>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>.6.18-rc4/2.6.18-rc4-mm3/
>>
>> git-acpi.patch
>
>commit f62d31ee2f2f453b07107465fea54540cab418eb broke my laptop
>(pentium M, dell D600).
>I can reliably get a hard lockup (no sysrq) when modprobing ehci_hcd
>and uhci_hci. It works when reverting the changeset.
>
>I can provide cpuinfo or dmesg if necessary.
>
>regards,
>
>Benoit
>

2006-08-27 18:28:49

by Chuck Lever

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

----- Original Message -----
From: "Adrian Bunk" <[email protected]>
To: "Andrew Morton" <[email protected]>; "Chuck Lever" <[email protected]>;
"Trond Myklebust" <[email protected]>
Cc: <[email protected]>
Sent: Saturday, August 26, 2006 7:56 PM
Subject: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>>...
>> Changes since 2.6.18-rc4-mm2:
>>...
>> git-nfs.patch
>>...
>> git trees
>>...
>
> This breaks CONFIG_ROOT_NFS=y:
>
> <-- snip -->
>
> ...
> CC fs/nfs/mount_clnt.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c: In
> function ‘mnt_create’:
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82:
> error: implicit declaration of function ‘xprt_create_proto’
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82:
> warning: assignment makes pointer from integer without a cast
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:86:
> error: implicit declaration of function ‘rpc_create_client’
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:88:
> warning: assignment makes pointer from integer without a cast
> make[3]: *** [fs/nfs/mount_clnt.o] Error 1
>
> <-- snip -->

Looks like a patch got misapplied somewhere. All my copies of this patch
series has this change, but Andrew's doesn't. Trond, let's hook up Monday
and work this out.

2006-08-27 21:00:40

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

On Sun, 27 Aug 2006 14:25:21 -0400
"Chuck Lever" <[email protected]> wrote:

> > CC fs/nfs/mount_clnt.o
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c: In
> > function ‘mnt_create’:
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82:
> > error: implicit declaration of function ‘xprt_create_proto’
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82:
> > warning: assignment makes pointer from integer without a cast
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:86:
> > error: implicit declaration of function ‘rpc_create_client’
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:88:
> > warning: assignment makes pointer from integer without a cast
> > make[3]: *** [fs/nfs/mount_clnt.o] Error 1
> >
> > <-- snip -->
>
> Looks like a patch got misapplied somewhere.

That's quite possible.

> All my copies of this patch
> series has this change, but Andrew's doesn't.

What is "this change"? The only change I see in Trond's mount_clnt.c is the
removal of the xprt.h include.

2006-08-28 07:30:15

by Pablo Neira Ayuso

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

Benoit Boissinot wrote:
> On 8/27/06, Andrew Morton <[email protected]> wrote:
>
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
>>
>>
>> Changes since 2.6.18-rc4-mm2:
>>
>> git-net.patch
>
>
> It introduces a new warning for me:
> net/netfilter/xt_CONNMARK.c: In function 'target':
> net/netfilter/xt_CONNMARK.c:59: warning: implicit declaration of
> function 'nf_conntrack_event_cache'
>
> The warning is due to the following .config:
> CONFIG_IP_NF_CONNTRACK=m
> CONFIG_IP_NF_CONNTRACK_MARK=y
> # CONFIG_IP_NF_CONNTRACK_EVENTS is not set
> CONFIG_IP_NF_CONNTRACK_NETLINK=m
>
> This change was introduced by:
> http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.19.git;a=commit;h=76e4b41009b8a2e9dd246135cf43c7fe39553aa5
>
> Proposed solution (based on the define in
> include/net/netfilter/nf_conntrack_compat.h:

That is my fault, thanks for catching up this Benoit.

Acked-by: Pablo Neira Ayuso <[email protected]>

--
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

2006-08-28 09:07:56

by mel

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On (26/08/06 16:09), Andrew Morton didst pronounce:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
>

This failed to build on two x86_64 machines I have access to with (one
on test.kernel.org);

OBJCOPY arch/x86_64/boot/compressed/vmlinux.bin
BFD: Warning: Writing section `.data.percpu' to huge (ie negative)
file offset 0x80471000.
/usr/local/autobench/sources/x86_64-cross/gcc-3.4.0-glibc-2.3.2/bin/x86_64-unknown-linux-gnu-objcopy:
arch/x86_64/boot/compressed/vmlinux.bin: File truncated
make[2]: *** [arch/x86_64/boot/compressed/vmlinux.bin] Error 1
make[1]: *** [arch/x86_64/boot/compressed/vmlinux] Error 2
make: *** [bzImage] Error 2
08/26/06-17:16:14 Build the kernel. Failed rc = 2
08/26/06-17:16:14 build: kernel build Failed rc = 1
08/26/06-17:16:14 command complete: (2) rc=126
Failed and terminated the run
Fatal error, aborting autorun

CONFIG_NR_CPUS was 8. The build log can be seen at
http://test.kernel.org/abat/45342/debug/test.log.0 and the .config is at
http://test.kernel.org/abat/45342/build/dotconfig . I haven't done any
further investigation in case this is a known problem. If it's new, I'll
start digging.

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab

2006-08-28 17:40:10

by Chuck Lever

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

----- Original Message -----
From: "Andrew Morton" <[email protected]>
To: "Chuck Lever" <[email protected]>
Cc: "Adrian Bunk" <[email protected]>; "Trond Myklebust"
<[email protected]>; <[email protected]>
Sent: Sunday, August 27, 2006 4:56 PM
Subject: Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

>> All my copies of this patch
>> series has this change, but Andrew's doesn't.
>
> What is "this change"? The only change I see in Trond's mount_clnt.c is
> the
> removal of the xprt.h include.

Found the problem. Because of changes Trond had included already in his
tree, my patches didn't fit on his repository. When I ported my patches to
his tree, I accidentally left out the hunk that updates fs/nfs/mount_clnt.c.

Trond should be sending out the missing hunk soon.

2006-08-28 17:43:53

by Myklebust, Trond

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

On Mon, 2006-08-28 at 13:36 -0400, Chuck Lever wrote:
> ----- Original Message -----
> From: "Andrew Morton" <[email protected]>
> To: "Chuck Lever" <[email protected]>
> Cc: "Adrian Bunk" <[email protected]>; "Trond Myklebust"
> <[email protected]>; <[email protected]>
> Sent: Sunday, August 27, 2006 4:56 PM
> Subject: Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error
>
> >> All my copies of this patch
> >> series has this change, but Andrew's doesn't.
> >
> > What is "this change"? The only change I see in Trond's mount_clnt.c is
> > the
> > removal of the xprt.h include.
>
> Found the problem. Because of changes Trond had included already in his
> tree, my patches didn't fit on his repository. When I ported my patches to
> his tree, I accidentally left out the hunk that updates fs/nfs/mount_clnt.c.
>
> Trond should be sending out the missing hunk soon.

Already merged into the NFS git tree. See

http://linux-nfs.org/cgi-bin/gitweb.cgi?p=nfs-2.6.git;a=commitdiff;h=f0d01cd34daccb47b7eeab03f80fe7986485528e

The raw patch can also be found on

http://client.linux-nfs.org/Linux-2.6.x/2.6.18-rc5/linux-2.6.18-056-fix_nfsroot.dif

Cheers,
Trond

2006-08-28 18:34:23

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On Mon, 28 Aug 2006 10:07:54 +0100
[email protected] (Mel Gorman) wrote:

> On (26/08/06 16:09), Andrew Morton didst pronounce:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
> >
>
> This failed to build on two x86_64 machines I have access to with (one
> on test.kernel.org);
>
> OBJCOPY arch/x86_64/boot/compressed/vmlinux.bin
> BFD: Warning: Writing section `.data.percpu' to huge (ie negative)
> file offset 0x80471000.
> /usr/local/autobench/sources/x86_64-cross/gcc-3.4.0-glibc-2.3.2/bin/x86_64-unknown-linux-gnu-objcopy:
> arch/x86_64/boot/compressed/vmlinux.bin: File truncated
> make[2]: *** [arch/x86_64/boot/compressed/vmlinux.bin] Error 1
> make[1]: *** [arch/x86_64/boot/compressed/vmlinux] Error 2
> make: *** [bzImage] Error 2
> 08/26/06-17:16:14 Build the kernel. Failed rc = 2
> 08/26/06-17:16:14 build: kernel build Failed rc = 1
> 08/26/06-17:16:14 command complete: (2) rc=126
> Failed and terminated the run
> Fatal error, aborting autorun
>
> CONFIG_NR_CPUS was 8. The build log can be seen at
> http://test.kernel.org/abat/45342/debug/test.log.0 and the .config is at
> http://test.kernel.org/abat/45342/build/dotconfig . I haven't done any
> further investigation in case this is a known problem. If it's new, I'll
> start digging.
>

hm. It works for me.

BINUTILS_DIR=binutils-2.16.1
GCC_DIR=gcc-4.0.2
GLIBC_DIR=glibc-2.3.6

I guess one could poke around in vmlinux, find out what's happened to the
.data.percpu section. `readelf --sections vmlinux', etc?

2006-08-28 20:08:25

by Mattia Dongili

[permalink] [raw]

Subject: divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
[...]
> git-net.patch

got this one when starting sshd:

[ 44.412000] divide error: 0000 [#1]
[ 44.412000] 4K_STACKS PREEMPT
[ 44.412000] last sysfs file: /devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
[ 44.412000] Modules linked in: nfsd exportfs lockd sunrpc ipt_MASQUERADE iptable_nat ip_nat xt_tcpudp xt_state ip_conntrack iptable_filter ip_tables x_tables ipv6 jfs aes dm_crypt dm_mod rtc sony_acpi tun psmouse sonypi speedstep_ich speedstep_lib cpufreq_conservative cpufreq_ondemand freq_table cpufreq_powersave sd_mod usb_storage scsi_mod usbhid pcmcia snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer intel_agp agpgart i2c_i801 snd soundcore snd_page_alloc yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd usbcore evdev e100 mii pcspkr
[ 44.412000] CPU: 0
[ 44.412000] EIP: 0060:[<d1516aca>] Not tainted VLI
[ 44.412000] EFLAGS: 00210246 (2.6.18-rc4-mm3-1 #6)
[ 44.412000] EIP is at fib6_rule_match+0x7a/0x150 [ipv6]
[ 44.412000] eax: 00000000 ebx: cd9d4e30 ecx: d15290e0 edx: 00000000
[ 44.412000] esi: cd7d9e08 edi: cd9d4e30 ebp: cd9d4d34 esp: cd9d4d0c
[ 44.412000] ds: 007b es: 007b ss: 0068
[ 44.412000] Process sshd (pid: 3780, ti=cd9d4000 task=cf131590 task.ti=cd9d4000)
[ 44.412000] Stack: 00000003 c018b200 00000000 ced9df60 cd9d4d6c 00000000 ced9df60 d15290e0
[ 44.412000] cd7d9e08 cd9d4e30 cd9d4d58 c02c198e d15290e0 cd9d4e30 00000000 c123f380
[ 44.412000] cd9d4e30 cd7d9e08 cd9d4e30 cd9d4d80 d15169dc d15290a0 cd9d4e30 00000000
[ 44.412000] Call Trace:
[ 44.412000] [<c02c198e>] fib_rules_lookup+0x5e/0xe0
[ 44.412000] [<d15169dc>] fib6_rule_lookup+0x3c/0xb0 [ipv6]
[ 44.412000] [<d14f8702>] ip6_route_output+0x32/0x40 [ipv6]
[ 44.412000] [<d14ed155>] ip6_dst_lookup_tail+0x95/0xd0 [ipv6]
[ 44.412000] [<d14ed1a7>] ip6_dst_lookup+0x17/0x20 [ipv6]
[ 44.412000] [<d15120ce>] ip6_datagram_connect+0x36e/0x6c0 [ipv6]
[ 44.412000] [<c02f6829>] inet_dgram_connect+0x39/0x80
[ 44.412000] [<c02a6ceb>] sys_connect+0x6b/0x90
[ 44.412000] [<c02a846f>] sys_socketcall+0x9f/0x260
[ 44.412000] [<c010325b>] syscall_call+0x7/0xb
[ 44.412000] [<b7c7c93c>] 0xb7c7c93c
[ 44.412000] =======================
[ 44.412000] Code: 00 00 00 89 d8 83 e0 1f 0f 85 9a 00 00 00 8b 5d 08 0f b6 53 68 84 d2 75 78 8b 55 08 8b 5d 0c 8b 4a 60 8b 43 28 31 c8 89 d1 31 d2 <f7> 71 64 85 c0 0f 94 c0 0f b6 c0 8b 5d f4 8b 75 f8 8b 7d fc 89
[ 44.412000] EIP: [<d1516aca>] fib6_rule_match+0x7a/0x150 [ipv6] SS:ESP 0068:cd9d4d0c
[ 44.412000] <6>note: sshd[3780] exited with preempt_count 1

config and full dmesg:
http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1

it's at fib6_rules.c:132 but since I can't tell why r->fwmask is 0 I'll
avoid proposing a wrong patch :)

--
mattia
:wq!

2006-08-28 20:25:18

by Mattia Dongili

[permalink] [raw]

Subject: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
[...]
> git-acpi.patch

Sorry for reporting separately, I deleted the other thread on the issue.
Here we go:
[ 9.386644] PCI: Using ACPI for IRQ routing
[ 9.386688] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
[ 9.391209] ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
[ 9.391521] [<c0103a9f>] dump_trace+0x1ef/0x230
[ 9.391626] [<c0103b06>] show_trace_log_lvl+0x26/0x40
[ 9.391724] [<c01042bb>] show_trace+0x1b/0x20
[ 9.391820] [<c01043a4>] dump_stack+0x24/0x30
[ 9.391918] [<c0249f15>] acpi_format_exception+0xa3/0xb0
[ 9.392729] [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
[ 9.393453] [<c0243352>] acpi_walk_resources+0x10e/0x11b
[ 9.394174] [<c025697e>] acpi_motherboard_add+0x22/0x31
[ 9.394977] [<c0255890>] acpi_bus_driver_init+0x2b/0x7c
[ 9.395742] [<c02568da>] acpi_bus_register_driver+0xa1/0x123
[ 9.396507] [<c0418adb>] acpi_motherboard_init+0x17/0xfb
[ 9.397268] [<c01003d0>] init+0x80/0x290
[ 9.397343] [<c0103593>] kernel_thread_helper+0x7/0x14
[ 9.397439] =======================

full dmesg: http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
config: http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
DSDT: http://oioio.altervista.org/linux/DSDT.aml
http://oioio.altervista.org/linux/DSDT.dsl
lspci: http://oioio.altervista.org/linux/lspci-v

--
mattia
:wq!

2006-08-28 20:28:35

[permalink] [raw]

Subject: Re: divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

On Mon, 28 Aug 2006 22:07:16 +0200
Mattia Dongili <[email protected]> wrote:

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
> [...]
> > git-net.patch
>
> got this one when starting sshd:
>
> [ 44.412000] divide error: 0000 [#1]
> [ 44.412000] 4K_STACKS PREEMPT
> [ 44.412000] last sysfs file: /devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
> [ 44.412000] Modules linked in: nfsd exportfs lockd sunrpc ipt_MASQUERADE iptable_nat ip_nat xt_tcpudp xt_state ip_conntrack iptable_filter ip_tables x_tables ipv6 jfs aes dm_crypt dm_mod rtc sony_acpi tun psmouse sonypi speedstep_ich speedstep_lib cpufreq_conservative cpufreq_ondemand freq_table cpufreq_powersave sd_mod usb_storage scsi_mod usbhid pcmcia snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer intel_agp agpgart i2c_i801 snd soundcore snd_page_alloc yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd usbcore evdev e100 mii pcspkr
> [ 44.412000] CPU: 0
> [ 44.412000] EIP: 0060:[<d1516aca>] Not tainted VLI
> [ 44.412000] EFLAGS: 00210246 (2.6.18-rc4-mm3-1 #6)
> [ 44.412000] EIP is at fib6_rule_match+0x7a/0x150 [ipv6]
> [ 44.412000] eax: 00000000 ebx: cd9d4e30 ecx: d15290e0 edx: 00000000
> [ 44.412000] esi: cd7d9e08 edi: cd9d4e30 ebp: cd9d4d34 esp: cd9d4d0c
> [ 44.412000] ds: 007b es: 007b ss: 0068
> [ 44.412000] Process sshd (pid: 3780, ti=cd9d4000 task=cf131590 task.ti=cd9d4000)
> [ 44.412000] Stack: 00000003 c018b200 00000000 ced9df60 cd9d4d6c 00000000 ced9df60 d15290e0
> [ 44.412000] cd7d9e08 cd9d4e30 cd9d4d58 c02c198e d15290e0 cd9d4e30 00000000 c123f380
> [ 44.412000] cd9d4e30 cd7d9e08 cd9d4e30 cd9d4d80 d15169dc d15290a0 cd9d4e30 00000000
> [ 44.412000] Call Trace:
> [ 44.412000] [<c02c198e>] fib_rules_lookup+0x5e/0xe0
> [ 44.412000] [<d15169dc>] fib6_rule_lookup+0x3c/0xb0 [ipv6]
> [ 44.412000] [<d14f8702>] ip6_route_output+0x32/0x40 [ipv6]
> [ 44.412000] [<d14ed155>] ip6_dst_lookup_tail+0x95/0xd0 [ipv6]
> [ 44.412000] [<d14ed1a7>] ip6_dst_lookup+0x17/0x20 [ipv6]
> [ 44.412000] [<d15120ce>] ip6_datagram_connect+0x36e/0x6c0 [ipv6]
> [ 44.412000] [<c02f6829>] inet_dgram_connect+0x39/0x80
> [ 44.412000] [<c02a6ceb>] sys_connect+0x6b/0x90
> [ 44.412000] [<c02a846f>] sys_socketcall+0x9f/0x260
> [ 44.412000] [<c010325b>] syscall_call+0x7/0xb
> [ 44.412000] [<b7c7c93c>] 0xb7c7c93c
> [ 44.412000] =======================
> [ 44.412000] Code: 00 00 00 89 d8 83 e0 1f 0f 85 9a 00 00 00 8b 5d 08 0f b6 53 68 84 d2 75 78 8b 55 08 8b 5d 0c 8b 4a 60 8b 43 28 31 c8 89 d1 31 d2 <f7> 71 64 85 c0 0f 94 c0 0f b6 c0 8b 5d f4 8b 75 f8 8b 7d fc 89
> [ 44.412000] EIP: [<d1516aca>] fib6_rule_match+0x7a/0x150 [ipv6] SS:ESP 0068:cd9d4d0c

I cannot work out how the heck you got a divide instruction in
fib6_rule_match().

Can you please do `make net/ipv6/fib6_rules.s', find the code which
implements fib6_rule_match() (line starting with "fib6_rule_match:") and
send that plus the next 200-odd lines? Or just stick fib6_rules.s on a
server somewhere? Or mail me fib6_rules.s off-list.

Thanks.

2006-08-28 21:23:22

by Andi Kleen

[permalink] [raw]

Subject: Re: divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

> I cannot work out how the heck you got a divide instruction in
> fib6_rule_match().

This might be another symptom of the broken smp-alternatives patch.
It tended to randomly corrupt some instructions by inserting different
bytes which then crash in interesting ways.

I already sent a fix for that, but it's not in yet.

-Andi

2006-08-28 21:30:16

[permalink] [raw]

Subject: Re: divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

On Mon, 28 Aug 2006 22:07:16 +0200
Mattia Dongili <[email protected]> wrote:

> [ 44.412000] =======================
> [ 44.412000] Code: 00 00 00 89 d8 83 e0 1f 0f 85 9a 00 00 00 8b 5d 08 0f b6 53 68 84 d2 75 78 8b 55 08 8b 5d 0c 8b 4a 60 8b 43 28 31 c8 89 d1 31 d2 <f7> 71 64 85 c0 0f 94 c0 0f b6 c0 8b 5d f4 8b 75 f8 8b 7d fc 89
> [ 44.412000] EIP: [<d1516aca>] fib6_rule_match+0x7a/0x150 [ipv6] SS:ESP 0068:cd9d4d0c
> [ 44.412000] <6>note: sshd[3780] exited with preempt_count 1
>
> config and full dmesg:
> http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
>
> it's at fib6_rules.c:132 but since I can't tell why r->fwmask is 0 I'll
> avoid proposing a wrong patch :)

Oh. It looks like this has already been fixed:

#ifdef CONFIG_IPV6_ROUTE_FWMARK
if ((r->fwmark ^ fl->fl6_fwmark) & r->fwmask)
return 0;
#endif

there's no divide in there now.

2006-08-28 21:51:22

by David Miller

[permalink] [raw]

Subject: Re: divide error: 0000 in fib6_rule_match

From: Andrew Morton <[email protected]>
Date: Mon, 28 Aug 2006 14:30:03 -0700

> Oh. It looks like this has already been fixed:
>
> #ifdef CONFIG_IPV6_ROUTE_FWMARK
> if ((r->fwmark ^ fl->fl6_fwmark) & r->fwmask)
> return 0;
> #endif
>
> there's no divide in there now.

That's right there used to be a typo there.

2006-08-28 22:13:17

by Rafael J. Wysocki

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On Sunday 27 August 2006 01:09, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/

I get things like the appended one on a regular basis at the system startup.

IIRC it has been reported for one of the previous -mm kernels, but it's still
there.

Adding 2104504k swap on /dev/hdc3. Priority:-1 extents:1 across:2104504k
skge eth0: enabling interface
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.

Call Trace:
[<ffffffff8020b119>] dump_trace+0xb9/0x3d0
[<ffffffff8020b473>] show_trace+0x43/0x60
[<ffffffff8020b785>] dump_stack+0x15/0x20
[<ffffffff802489a6>] save_trace+0xd6/0xf0
[<ffffffff80248ad1>] add_lock_to_list+0x91/0xc0
[<ffffffff8024ad31>] __lock_acquire+0xb01/0xd30
[<ffffffff8024b2fb>] lock_acquire+0x8b/0xc0
[<ffffffff80475b05>] _spin_lock_irq+0x35/0x50
[<ffffffff80472aec>] schedule+0x16c/0x5ef
[<ffffffff804734b7>] preempt_schedule_irq+0x57/0x90
[<ffffffff8020a3f6>] retint_kernel+0x26/0x30
[<ffffffff804740fb>] __mutex_lock_slowpath+0x23b/0x270
[<ffffffff80474139>] mutex_lock+0x9/0x10
[<ffffffff8821801a>] :snd_seq_device:snd_seq_device_info+0x1a/0xd0
[<ffffffff8806be5e>] :snd:snd_info_entry_open+0x27e/0x360
[<ffffffff8028d19c>] __dentry_open+0x13c/0x290
[<ffffffff8028d39d>] nameidata_to_filp+0x2d/0x50
[<ffffffff8028d3fd>] do_filp_open+0x3d/0x50
[<ffffffff8028d46a>] do_sys_open+0x5a/0xf0
[<ffffffff8028d52b>] sys_open+0x1b/0x20
[<ffffffff80209d2e>] system_call+0x7e/0x83
[<00002ab9c19f1722>]
[<ffffffff802489a6>] save_trace+0xd6/0xf0
[<ffffffff80248ad1>] add_lock_to_list+0x91/0xc0
[<ffffffff8024ad31>] __lock_acquire+0xb01/0xd30
[<ffffffff80472aec>] schedule+0x16c/0x5ef
[<ffffffff8024b2fb>] lock_acquire+0x8b/0xc0
[<ffffffff80472aec>] schedule+0x16c/0x5ef
[<ffffffff80475b05>] _spin_lock_irq+0x35/0x50
[<ffffffff80472aec>] schedule+0x16c/0x5ef
[<ffffffff8024b3a9>] mark_held_locks+0x79/0xa0
[<ffffffff804734b1>] preempt_schedule_irq+0x51/0x90
[<ffffffff804734b7>] preempt_schedule_irq+0x57/0x90
[<ffffffff8020a3f6>] retint_kernel+0x26/0x30
[<ffffffff804740fb>] __mutex_lock_slowpath+0x23b/0x270
[<ffffffff8047411d>] __mutex_lock_slowpath+0x25d/0x270
[<ffffffff80474139>] mutex_lock+0x9/0x10
[<ffffffff8821801a>] :snd_seq_device:snd_seq_device_info+0x1a/0xd0
[<ffffffff8806be5e>] :snd:snd_info_entry_open+0x27e/0x360
[<ffffffff8806bbe0>] :snd:snd_info_entry_open+0x0/0x360
[<ffffffff8028d19c>] __dentry_open+0x13c/0x290
[<ffffffff8028d39d>] nameidata_to_filp+0x2d/0x50
[<ffffffff8028d3fd>] do_filp_open+0x3d/0x50
[<ffffffff80475960>] _spin_unlock+0x30/0x60
[<ffffffff8028cb58>] get_unused_fd+0xf8/0x110
[<ffffffff803581fa>] strncpy_from_user+0x3a/0x50
[<ffffffff8028d46a>] do_sys_open+0x5a/0xf0
[<ffffffff8028d52b>] sys_open+0x1b/0x20
[<ffffffff80209d2e>] system_call+0x7e/0x83

NET: Registered protocol family 17

2006-08-29 02:00:36

by Pallipadi, Venkatesh

[permalink] [raw]

Subject: RE: 2.6.18-rc4-mm3

>-----Original Message-----
>From: Benoit Boissinot [mailto:[email protected]]
>Sent: Sunday, August 27, 2006 9:00 AM
>To: Andrew Morton
>Cc: [email protected]; Pallipadi, Venkatesh; Brown, Len
>Subject: Re: 2.6.18-rc4-mm3
>
>On 8/27/06, Andrew Morton <[email protected]> wrote:
>>
>>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>.6.18-rc4/2.6.18-rc4-mm3/
>>
>> git-acpi.patch
>
>commit f62d31ee2f2f453b07107465fea54540cab418eb broke my laptop
>(pentium M, dell D600).
>I can reliably get a hard lockup (no sysrq) when modprobing ehci_hcd
>and uhci_hci. It works when reverting the changeset.
>
>I can provide cpuinfo or dmesg if necessary.
>
>regards,
>
>Benoit

Thanks Benoit for identifying the problem with this patch and reporting
it. I was able to reproduce it on a system locally and I have tracked
down the problem. I will send out the updated patch soon and cc it to
you.

Thanks,
Venki

2006-08-29 02:06:21

[permalink] [raw]

Subject: RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

>-----Original Message-----
>From: [email protected] [mailto:linux-kernel-
>[email protected]] On Behalf Of Mattia Dongili
>Sent: Tuesday, August 29, 2006 4:24 AM
>To: Andrew Morton
>Cc: [email protected]; [email protected]
>Subject: one more ACPI Error (utglobal-0125): Unknown exception code:
>0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
>
>On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
>rc4/2.6.18-rc4-mm3/
>[...]
>> git-acpi.patch
>
>Sorry for reporting separately, I deleted the other thread on the
issue.
>Here we go:
>[ 9.386644] PCI: Using ACPI for IRQ routing
>[ 9.386688] PCI: If a device doesn't work, try "pci=routeirq". If
it
>helps, post a report
>[ 9.391209] ACPI Error (utglobal-0125): Unknown exception code:
>0xFFFFFFEA [20060707]
>[ 9.391521] [<c0103a9f>] dump_trace+0x1ef/0x230
>[ 9.391626] [<c0103b06>] show_trace_log_lvl+0x26/0x40
>[ 9.391724] [<c01042bb>] show_trace+0x1b/0x20
>[ 9.391820] [<c01043a4>] dump_stack+0x24/0x30
>[ 9.391918] [<c0249f15>] acpi_format_exception+0xa3/0xb0
>[ 9.392729] [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
>[ 9.393453] [<c0243352>] acpi_walk_resources+0x10e/0x11b
>[ 9.394174] [<c025697e>] acpi_motherboard_add+0x22/0x31
>[ 9.394977] [<c0255890>] acpi_bus_driver_init+0x2b/0x7c
>[ 9.395742] [<c02568da>] acpi_bus_register_driver+0xa1/0x123
>[ 9.396507] [<c0418adb>] acpi_motherboard_init+0x17/0xfb
>[ 9.397268] [<c01003d0>] init+0x80/0x290
>[ 9.397343] [<c0103593>] kernel_thread_helper+0x7/0x14
>[ 9.397439] =======================
>
>full dmesg: http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
>config: http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
>DSDT: http://oioio.altervista.org/linux/DSDT.aml
> http://oioio.altervista.org/linux/DSDT.dsl
>lspci: http://oioio.altervista.org/linux/lspci-v
Below patch is the root cause.
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc
4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patc
h

motherboard driver is expected to reserve resources used by motherboard,
so hotplug will not fail. I don't know why memory hotplug guys change
it.

Thanks,
Shaohua

2006-08-29 06:33:21

by Mattia Dongili

[permalink] [raw]

Subject: Re: divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

On Mon, August 28, 2006 11:30 pm, Andrew Morton said:
> On Mon, 28 Aug 2006 22:07:16 +0200
> Mattia Dongili <[email protected]> wrote:
[...]
>> it's at fib6_rules.c:132 but since I can't tell why r->fwmask is 0 I'll
>> avoid proposing a wrong patch :)
>
> Oh. It looks like this has already been fixed:
>
> #ifdef CONFIG_IPV6_ROUTE_FWMARK
> if ((r->fwmark ^ fl->fl6_fwmark) & r->fwmask)
> return 0;
> #endif
>
> there's no divide in there now.

Ok, great, I have a division instead of the bitwise and there in fact.

thanks
--
mattia
:wq!

2006-08-29 13:36:48

by Haavard Skinnemoen

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On Sat, 26 Aug 2006 16:09:22 -0700
Andrew Morton <[email protected]> wrote:

> +namespaces-add-nsproxy-move-init_nsproxy-into-kernel-nsproxyc.patch

This causes a multiple definition of init_nsproxy on AVR32. Reverting
namespaces-add-nsproxy-avr32-fix.patch fixes it.

Haavard

2006-08-29 14:44:37

by Mel Gorman

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On Mon, 28 Aug 2006, Andrew Morton wrote:

> On Mon, 28 Aug 2006 10:07:54 +0100
> [email protected] (Mel Gorman) wrote:
>
>> On (26/08/06 16:09), Andrew Morton didst pronounce:
>>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
>>>
>>
>> This failed to build on two x86_64 machines I have access to with (one
>> on test.kernel.org);
>>
>> OBJCOPY arch/x86_64/boot/compressed/vmlinux.bin
>> BFD: Warning: Writing section `.data.percpu' to huge (ie negative)
>> file offset 0x80471000.
>> /usr/local/autobench/sources/x86_64-cross/gcc-3.4.0-glibc-2.3.2/bin/x86_64-unknown-linux-gnu-objcopy:
>> arch/x86_64/boot/compressed/vmlinux.bin: File truncated
>> make[2]: *** [arch/x86_64/boot/compressed/vmlinux.bin] Error 1
>> make[1]: *** [arch/x86_64/boot/compressed/vmlinux] Error 2
>> make: *** [bzImage] Error 2
>> 08/26/06-17:16:14 Build the kernel. Failed rc = 2
>> 08/26/06-17:16:14 build: kernel build Failed rc = 1
>> 08/26/06-17:16:14 command complete: (2) rc=126
>> Failed and terminated the run
>> Fatal error, aborting autorun
>>
>> CONFIG_NR_CPUS was 8. The build log can be seen at
>> http://test.kernel.org/abat/45342/debug/test.log.0 and the .config is at
>> http://test.kernel.org/abat/45342/build/dotconfig . I haven't done any
>> further investigation in case this is a known problem. If it's new, I'll
>> start digging.
>>
>
> hm. It works for me.
>
> BINUTILS_DIR=binutils-2.16.1
> GCC_DIR=gcc-4.0.2
> GLIBC_DIR=glibc-2.3.6
>
> I guess one could poke around in vmlinux, find out what's happened to the
> .data.percpu section. `readelf --sections vmlinux', etc?

There didn't seem to be anything unusual about the .data.percpu section It
turned out to be a binutils version problem. On the two test machines, the
cross-compiler from
http://developer.osdl.org/dev/plm/cross_compile/x86_64-unknown-linux-gnu.tar.bz2
was being used. When later versions were used, the problem disappeared.

Thanks

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab

2006-08-29 15:19:11

by Cédric Le Goater

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

Haavard Skinnemoen wrote:
> On Sat, 26 Aug 2006 16:09:22 -0700
> Andrew Morton <[email protected]> wrote:
>
>> +namespaces-add-nsproxy-move-init_nsproxy-into-kernel-nsproxyc.patch
>
> This causes a multiple definition of init_nsproxy on AVR32. Reverting
> namespaces-add-nsproxy-avr32-fix.patch fixes it.

Could you try this ?

thanks,

C.

Signed-off-by: Cedric Le Goater <[email protected]>

---
arch/avr32/kernel/init_task.c | 2 --
1 file changed, 2 deletions(-)

Index: 2.6.18-rc4-mm3/arch/avr32/kernel/init_task.c
===================================================================
--- 2.6.18-rc4-mm3.orig/arch/avr32/kernel/init_task.c
+++ 2.6.18-rc4-mm3/arch/avr32/kernel/init_task.c
@@ -10,7 +10,6 @@
#include <linux/sched.h>
#include <linux/init_task.h>
#include <linux/mqueue.h>
-#include <linux/nsproxy.h>

#include <asm/pgtable.h>

@@ -19,7 +18,6 @@ static struct files_struct init_files =
static struct signal_struct init_signals = INIT_SIGNALS(init_signals);
static struct sighand_struct init_sighand = INIT_SIGHAND(init_sighand);
struct mm_struct init_mm = INIT_MM(init_mm);
-struct nsproxy init_nsproxy = INIT_NSPROXY(init_nsproxy);

EXPORT_SYMBOL(init_mm);

2006-08-29 15:42:35

by Haavard Skinnemoen

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On Tue, 29 Aug 2006 17:18:58 +0200
Cedric Le Goater <[email protected]> wrote:

> Haavard Skinnemoen wrote:
> > On Sat, 26 Aug 2006 16:09:22 -0700
> > Andrew Morton <[email protected]> wrote:
> >
> >> +namespaces-add-nsproxy-move-init_nsproxy-into-kernel-nsproxyc.patch
> >
> > This causes a multiple definition of init_nsproxy on AVR32.
> > Reverting namespaces-add-nsproxy-avr32-fix.patch fixes it.
>
> Could you try this ?

Yes, this works fine. This does in fact revert
namespaces-add-nsproxy-avr32-fix.patch, so it would work equally well
to just drop that patch.

Thanks,

Haavard

2006-08-29 20:04:30

by Moore, Robert

[permalink] [raw]

Subject: RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

As far as the unknown exception,

>[ 9.392729] [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
>[ 9.393453] [<c0243352>] acpi_walk_resources+0x10e/0x11b
>[ 9.394174] [<c025697e>] acpi_motherboard_add+0x22/0x31

I would guess that the callback routine for walk_resources is returning
a non-zero status value which is causing an immediate abort of the walk
with that value -- and the value is bogus.

Bob

> -----Original Message-----
> From: [email protected] [mailto:linux-acpi-
> [email protected]] On Behalf Of Li, Shaohua
> Sent: Monday, August 28, 2006 7:06 PM
> To: Mattia Dongili; Andrew Morton
> Cc: [email protected]; [email protected]
> Subject: RE: one more ACPI Error (utglobal-0125): Unknown exception
code:
> 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
>
>
>
> >-----Original Message-----
> >From: [email protected] [mailto:linux-kernel-
> >[email protected]] On Behalf Of Mattia Dongili
> >Sent: Tuesday, August 29, 2006 4:24 AM
> >To: Andrew Morton
> >Cc: [email protected]; [email protected]
> >Subject: one more ACPI Error (utglobal-0125): Unknown exception code:
> >0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> >
> >On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >>
> >>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
> >rc4/2.6.18-rc4-mm3/
> >[...]
> >> git-acpi.patch
> >
> >Sorry for reporting separately, I deleted the other thread on the
> issue.
> >Here we go:
> >[ 9.386644] PCI: Using ACPI for IRQ routing
> >[ 9.386688] PCI: If a device doesn't work, try "pci=routeirq". If
> it
> >helps, post a report
> >[ 9.391209] ACPI Error (utglobal-0125): Unknown exception code:
> >0xFFFFFFEA [20060707]
> >[ 9.391521] [<c0103a9f>] dump_trace+0x1ef/0x230
> >[ 9.391626] [<c0103b06>] show_trace_log_lvl+0x26/0x40
> >[ 9.391724] [<c01042bb>] show_trace+0x1b/0x20
> >[ 9.391820] [<c01043a4>] dump_stack+0x24/0x30
> >[ 9.391918] [<c0249f15>] acpi_format_exception+0xa3/0xb0
> >[ 9.392729] [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> >[ 9.393453] [<c0243352>] acpi_walk_resources+0x10e/0x11b
> >[ 9.394174] [<c025697e>] acpi_motherboard_add+0x22/0x31
> >[ 9.394977] [<c0255890>] acpi_bus_driver_init+0x2b/0x7c
> >[ 9.395742] [<c02568da>] acpi_bus_register_driver+0xa1/0x123
> >[ 9.396507] [<c0418adb>] acpi_motherboard_init+0x17/0xfb
> >[ 9.397268] [<c01003d0>] init+0x80/0x290
> >[ 9.397343] [<c0103593>] kernel_thread_helper+0x7/0x14
> >[ 9.397439] =======================
> >
> >full dmesg: http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
> >config: http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
> >DSDT: http://oioio.altervista.org/linux/DSDT.aml
> > http://oioio.altervista.org/linux/DSDT.dsl
> >lspci: http://oioio.altervista.org/linux/lspci-v
> Below patch is the root cause.
>
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc
>
4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patc
> h
>
> motherboard driver is expected to reserve resources used by
motherboard,
> so hotplug will not fail. I don't know why memory hotplug guys change
> it.
>
> Thanks,
> Shaohua
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2006-08-30 18:37:57

by Pallipadi, Venkatesh

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On Mon, Aug 28, 2006 at 07:00:33PM -0700, Pallipadi, Venkatesh wrote:
>
>
> >-----Original Message-----
> >From: Benoit Boissinot [mailto:[email protected]]
> >Sent: Sunday, August 27, 2006 9:00 AM
> >To: Andrew Morton
> >Cc: [email protected]; Pallipadi, Venkatesh; Brown, Len
> >Subject: Re: 2.6.18-rc4-mm3
> >
> >On 8/27/06, Andrew Morton <[email protected]> wrote:
> >>
> >>
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
> >.6.18-rc4/2.6.18-rc4-mm3/
> >>
> >> git-acpi.patch
> >
> >commit f62d31ee2f2f453b07107465fea54540cab418eb broke my laptop
> >(pentium M, dell D600).
> >I can reliably get a hard lockup (no sysrq) when modprobing ehci_hcd
> >and uhci_hci. It works when reverting the changeset.
> >
> >I can provide cpuinfo or dmesg if necessary.
> >
> >regards,
> >
> >Benoit
>
> Thanks Benoit for identifying the problem with this patch and reporting
> it. I was able to reproduce it on a system locally and I have tracked
> down the problem. I will send out the updated patch soon and cc it to
> you.
>
> Thanks,
> Venki

Benoit,

Attached is the updated patch. Please test it on your system whenever you get
a chance. ACPI C-states and /proc/acpi/processor/*/power should show similar
numbers with or without this patch. It should not hang as before.

Thanks,
Venki

Below is tha patch to support Processor Native C-state using "mwait"
instruction on Intel processors.

Background:
Newer Intel processors (eg: Core Duo), support processor native C-state using
mwait instructions.
Refer: Intel Architecture Software Developer's Manual
http://www.intel.com/design/Pentium4/manuals/253668.htm

Platform firmware exports the support for Native C-state to OS using
ACPI _PDC and _CST methods.
Refer: Intel Processor Vendor-Specific ACPI: Interface Specification
http://www.intel.com/technology/iapc/acpi/downloads/302223.htm

With Processor Native C-state, we use 'mwait' instruction on the processor to
enter different C-states (C1, C2, C3). We won't use the special IO ports to
enter C-state and no SMM mode etc required to enter C-state. Overall this
will mean better C-state support.
One major advantage of using mwait for all C-states is, with this and
"treat interrupt as break event" feature of mwait, we can now get
accurate timing for the time spent in C1, C2, .. states.

The patch below adds support for both i386 and x86-64 kernels.

Patch against 2.6.18-rc4.

Signed-off-by: Venkatesh Pallipadi <[email protected]>

Index: linux-2.6.18-rc4/arch/i386/kernel/acpi/cstate.c
===================================================================
--- linux-2.6.18-rc4.orig/arch/i386/kernel/acpi/cstate.c
+++ linux-2.6.18-rc4/arch/i386/kernel/acpi/cstate.c
@@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/acpi.h>
+#include <linux/cpu.h>

#include <acpi/processor.h>
#include <asm/acpi.h>
@@ -41,5 +42,124 @@ void acpi_processor_power_init_bm_check(
flags->bm_check = 1;
}
}
-
EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
+
+/* The code below handles cstate entry with monitor-mwait pair on Intel*/
+
+struct cstate_entry_s {
+ struct {
+ unsigned int eax;
+ unsigned int ecx;
+ } states[ACPI_PROCESSOR_MAX_POWER];
+};
+static struct cstate_entry_s *cpu_cstate_entry; /* per CPU ptr */
+
+static short mwait_supported[ACPI_PROCESSOR_MAX_POWER];
+
+#define MWAIT_SUBSTATE_MASK (0xf)
+#define MWAIT_SUBSTATE_SIZE (4)
+
+#define CPUID_MWAIT_LEAF (5)
+#define CPUID5_ECX_EXTENSIONS_SUPPORTED (0x1)
+#define CPUID5_ECX_INTERRUPT_BREAK (0x2)
+
+#define MWAIT_ECX_INTERRUPT_BREAK (0x1)
+
+#define NATIVE_CSTATE_BEYOND_HALT (2)
+
+int acpi_processor_ffh_cstate_probe(unsigned int cpu,
+ struct acpi_processor_cx *cx, struct acpi_power_register *reg)
+{
+ struct cstate_entry_s *percpu_entry;
+ struct cpuinfo_x86 *c = cpu_data + cpu;
+
+ cpumask_t saved_mask;
+ int retval;
+ unsigned int eax, ebx, ecx, edx;
+ unsigned int edx_part;
+ unsigned int cstate_type; /* C-state type and not ACPI C-state type */
+ unsigned int num_cstate_subtype;
+
+ if (!cpu_cstate_entry || c->cpuid_level < CPUID_MWAIT_LEAF )
+ return -1;
+
+ if (reg->bit_offset != NATIVE_CSTATE_BEYOND_HALT)
+ return -1;
+
+ percpu_entry = per_cpu_ptr(cpu_cstate_entry, cpu);
+ percpu_entry->states[cx->index].eax = 0;
+ percpu_entry->states[cx->index].ecx = 0;
+
+ /* Make sure we are running on right CPU */
+ saved_mask = current->cpus_allowed;
+ retval = set_cpus_allowed(current, cpumask_of_cpu(cpu));
+ if (retval)
+ return -1;
+
+ cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &edx);
+
+ /* Check whether this particular cx_type (in CST) is supported or not */
+ cstate_type = (cx->address >> MWAIT_SUBSTATE_SIZE) + 1;
+ edx_part = edx >> (cstate_type * MWAIT_SUBSTATE_SIZE);
+ num_cstate_subtype = edx_part & MWAIT_SUBSTATE_MASK;
+
+ retval = 0;
+ if (num_cstate_subtype < (cx->address & MWAIT_SUBSTATE_MASK)) {
+ retval = -1;
+ goto out;
+ }
+
+ /* mwait ecx extensions INTERRUPT_BREAK should be supported for C2/C3 */
+ if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||
+ !(ecx & CPUID5_ECX_INTERRUPT_BREAK)) {
+ retval = -1;
+ goto out;
+ }
+ percpu_entry->states[cx->index].ecx = MWAIT_ECX_INTERRUPT_BREAK;
+
+ /* Use the hint in CST */
+ percpu_entry->states[cx->index].eax = cx->address;
+
+ if (!mwait_supported[cstate_type]) {
+ mwait_supported[cstate_type] = 1;
+ printk(KERN_DEBUG "Monitor-Mwait will be used to enter C-%d "
+ "state\n", cx->type);
+ }
+
+out:
+ set_cpus_allowed(current, saved_mask);
+ return retval;
+}
+EXPORT_SYMBOL_GPL(acpi_processor_ffh_cstate_probe);
+
+void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cx)
+{
+ unsigned int cpu = smp_processor_id();
+ struct cstate_entry_s *percpu_entry;
+
+ percpu_entry = per_cpu_ptr(cpu_cstate_entry, cpu);
+ mwait_idle_with_hints(percpu_entry->states[cx->index].eax,
+ percpu_entry->states[cx->index].ecx);
+}
+EXPORT_SYMBOL_GPL(acpi_processor_ffh_cstate_enter);
+
+static int __init ffh_cstate_init(void)
+{
+ struct cpuinfo_x86 *c = &boot_cpu_data;
+ if (c->x86_vendor != X86_VENDOR_INTEL)
+ return -1;
+
+ cpu_cstate_entry = alloc_percpu(struct cstate_entry_s);
+ return 0;
+}
+
+static void __exit ffh_cstate_exit(void)
+{
+ if (cpu_cstate_entry) {
+ free_percpu(cpu_cstate_entry);
+ cpu_cstate_entry = NULL;
+ }
+}
+
+arch_initcall(ffh_cstate_init);
+__exitcall(ffh_cstate_exit);
Index: linux-2.6.18-rc4/arch/i386/kernel/process.c
===================================================================
--- linux-2.6.18-rc4.orig/arch/i386/kernel/process.c
+++ linux-2.6.18-rc4/arch/i386/kernel/process.c
@@ -235,20 +235,28 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
* We execute MONITOR against need_resched and enter optimized wait state
* through MWAIT. Whenever someone changes need_resched, we would be woken
* up from MWAIT (without an IPI).
+ *
+ * New with Core Duo processors, MWAIT can take some hints based on CPU
+ * capability.
*/
-static void mwait_idle(void)
+void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
{
- local_irq_enable();
-
- while (!need_resched()) {
+ if (!need_resched()) {
__monitor((void *)&current_thread_info()->flags, 0, 0);
smp_mb();
- if (need_resched())
- break;
- __mwait(0, 0);
+ if (!need_resched())
+ __mwait(eax, ecx);
}
}

+/* Default MONITOR/MWAIT with no hints, used for default C1 state */
+static void mwait_idle(void)
+{
+ local_irq_enable();
+ while (!need_resched())
+ mwait_idle_with_hints(0, 0);
+}
+
void __devinit select_idle_routine(const struct cpuinfo_x86 *c)
{
if (cpu_has(c, X86_FEATURE_MWAIT)) {
Index: linux-2.6.18-rc4/arch/x86_64/kernel/process.c
===================================================================
--- linux-2.6.18-rc4.orig/arch/x86_64/kernel/process.c
+++ linux-2.6.18-rc4/arch/x86_64/kernel/process.c
@@ -235,20 +235,28 @@ void cpu_idle (void)
* We execute MONITOR against need_resched and enter optimized wait state
* through MWAIT. Whenever someone changes need_resched, we would be woken
* up from MWAIT (without an IPI).
+ *
+ * New with Core Duo processors, MWAIT can take some hints based on CPU
+ * capability.
*/
-static void mwait_idle(void)
+void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
{
- local_irq_enable();
-
- while (!need_resched()) {
+ if (!need_resched()) {
__monitor((void *)&current_thread_info()->flags, 0, 0);
smp_mb();
- if (need_resched())
- break;
- __mwait(0, 0);
+ if (!need_resched())
+ __mwait(eax, ecx);
}
}

+/* Default MONITOR/MWAIT with no hints, used for default C1 state */
+static void mwait_idle(void)
+{
+ local_irq_enable();
+ while (!need_resched())
+ mwait_idle_with_hints(0,0);
+}
+
void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
{
static int printed;
Index: linux-2.6.18-rc4/drivers/acpi/processor_idle.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.18-rc4/drivers/acpi/processor_idle.c
@@ -218,6 +218,23 @@ static void acpi_safe_halt(void)

static atomic_t c3_cpu_count;

+/* Common C-state entry for C2, C3, .. */
+static void acpi_cstate_enter(struct acpi_processor_cx *cstate)
+{
+ if (cstate->space_id == ACPI_CSTATE_FFH) {
+ /* Call into architectural FFH based C-state */
+ acpi_processor_ffh_cstate_enter(cstate);
+ } else {
+ int unused;
+ /* IO port based C-state */
+ inb(cstate->address);
+ /* Dummy wait op - must do something useless after P_LVL2 read
+ because chipsets cannot guarantee that STPCLK# signal
+ gets asserted in time to freeze execution properly. */
+ unused = inl(acpi_fadt.xpm_tmr_blk.address);
+ }
+}
+
static void acpi_processor_idle(void)
{
struct acpi_processor *pr = NULL;
@@ -360,11 +377,7 @@ static void acpi_processor_idle(void)
/* Get start time (ticks) */
t1 = inl(acpi_fadt.xpm_tmr_blk.address);
/* Invoke C2 */
- inb(cx->address);
- /* Dummy wait op - must do something useless after P_LVL2 read
- because chipsets cannot guarantee that STPCLK# signal
- gets asserted in time to freeze execution properly. */
- t2 = inl(acpi_fadt.xpm_tmr_blk.address);
+ acpi_cstate_enter(cx);
/* Get end time (ticks) */
t2 = inl(acpi_fadt.xpm_tmr_blk.address);

@@ -400,9 +413,7 @@ static void acpi_processor_idle(void)
/* Get start time (ticks) */
t1 = inl(acpi_fadt.xpm_tmr_blk.address);
/* Invoke C3 */
- inb(cx->address);
- /* Dummy wait op (see above) */
- t2 = inl(acpi_fadt.xpm_tmr_blk.address);
+ acpi_cstate_enter(cx);
/* Get end time (ticks) */
t2 = inl(acpi_fadt.xpm_tmr_blk.address);
if (pr->flags.bm_check) {
@@ -624,20 +635,16 @@ static int acpi_processor_get_power_info
return 0;
}

-static int acpi_processor_get_power_info_default_c1(struct acpi_processor *pr)
+static int acpi_processor_get_power_info_default(struct acpi_processor *pr)
{
-
- /* Zero initialize all the C-states info. */
- memset(pr->power.states, 0, sizeof(pr->power.states));
-
- /* set the first C-State to C1 */
- pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
-
- /* the C0 state only exists as a filler in our array,
- * and all processors need to support C1 */
+ if (!pr->power.states[ACPI_STATE_C1].valid) {
+ /* set the first C-State to C1 */
+ /* all processors need to support C1 */
+ pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
+ pr->power.states[ACPI_STATE_C1].valid = 1;
+ }
+ /* the C0 state only exists as a filler in our array */
pr->power.states[ACPI_STATE_C0].valid = 1;
- pr->power.states[ACPI_STATE_C1].valid = 1;
-
return 0;
}

@@ -654,12 +661,7 @@ static int acpi_processor_get_power_info
if (nocst)
return -ENODEV;

- current_count = 1;
-
- /* Zero initialize C2 onwards and prepare for fresh CST lookup */
- for (i = 2; i < ACPI_PROCESSOR_MAX_POWER; i++)
- memset(&(pr->power.states[i]), 0,
- sizeof(struct acpi_processor_cx));
+ current_count = 0;

status = acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer);
if (ACPI_FAILURE(status)) {
@@ -714,22 +716,39 @@ static int acpi_processor_get_power_info
(reg->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE))
continue;

- cx.address = (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) ?
- 0 : reg->address;
-
/* There should be an easy way to extract an integer... */
obj = (union acpi_object *)&(element->package.elements[1]);
if (obj->type != ACPI_TYPE_INTEGER)
continue;

cx.type = obj->integer.value;
+ /*
+ * Some buggy BIOSes won't list C1 in _CST -
+ * Let acpi_processor_get_power_info_default() handle them later
+ */
+ if (i == 1 && cx.type != ACPI_STATE_C1)
+ current_count++;

- if ((cx.type != ACPI_STATE_C1) &&
- (reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO))
- continue;
+ cx.address = reg->address;
+ cx.index = current_count + 1;

- if ((cx.type < ACPI_STATE_C2) || (cx.type > ACPI_STATE_C3))
- continue;
+ cx.space_id = ACPI_CSTATE_SYSTEMIO;
+ if (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) {
+ if (acpi_processor_ffh_cstate_probe
+ (pr->id, &cx, reg) == 0) {
+ cx.space_id = ACPI_CSTATE_FFH;
+ } else if (cx.type != ACPI_STATE_C1) {
+ /*
+ * C1 is a special case where FIXED_HARDWARE
+ * can be handled in non-MWAIT way as well.
+ * In that case, save this _CST entry info.
+ * That is, we retain space_id of SYSTEM_IO for
+ * halt based C1.
+ * Otherwise, ignore this info and continue.
+ */
+ continue;
+ }
+ }

obj = (union acpi_object *)&(element->package.elements[2]);
if (obj->type != ACPI_TYPE_INTEGER)
@@ -934,12 +953,18 @@ static int acpi_processor_get_power_info
/* NOTE: the idle thread may not be running while calling
* this function */

- /* Adding C1 state */
- acpi_processor_get_power_info_default_c1(pr);
+ /* Zero initialize all the C-states info. */
+ memset(pr->power.states, 0, sizeof(pr->power.states));
+
result = acpi_processor_get_power_info_cst(pr);
if (result == -ENODEV)
acpi_processor_get_power_info_fadt(pr);

+ if (result)
+ return result;
+
+ acpi_processor_get_power_info_default(pr);
+
pr->power.count = acpi_processor_power_verify(pr);

/*
Index: linux-2.6.18-rc4/include/acpi/pdc_intel.h
===================================================================
--- linux-2.6.18-rc4.orig/include/acpi/pdc_intel.h
+++ linux-2.6.18-rc4/include/acpi/pdc_intel.h
@@ -13,6 +13,7 @@
#define ACPI_PDC_SMP_C_SWCOORD (0x0040)
#define ACPI_PDC_SMP_T_SWCOORD (0x0080)
#define ACPI_PDC_C_C1_FFH (0x0100)
+#define ACPI_PDC_C_C2C3_FFH (0x0200)

#define ACPI_PDC_EST_CAPABILITY_SMP (ACPI_PDC_SMP_C1PT | \
ACPI_PDC_C_C1_HALT | \
@@ -23,8 +24,10 @@
ACPI_PDC_SMP_P_SWCOORD | \
ACPI_PDC_P_FFH)

-#define ACPI_PDC_C_CAPABILITY_SMP (ACPI_PDC_SMP_C2C3 | \
- ACPI_PDC_SMP_C1PT | \
- ACPI_PDC_C_C1_HALT)
+#define ACPI_PDC_C_CAPABILITY_SMP (ACPI_PDC_SMP_C2C3 | \
+ ACPI_PDC_SMP_C1PT | \
+ ACPI_PDC_C_C1_HALT | \
+ ACPI_PDC_C_C1_FFH | \
+ ACPI_PDC_C_C2C3_FFH)

#endif /* __PDC_INTEL_H__ */
Index: linux-2.6.18-rc4/include/acpi/processor.h
===================================================================
--- linux-2.6.18-rc4.orig/include/acpi/processor.h
+++ linux-2.6.18-rc4/include/acpi/processor.h
@@ -29,6 +29,9 @@
#define DOMAIN_COORD_TYPE_SW_ANY 0xfd
#define DOMAIN_COORD_TYPE_HW_ALL 0xfe

+#define ACPI_CSTATE_SYSTEMIO (0)
+#define ACPI_CSTATE_FFH (1)
+
/* Power Management */

struct acpi_processor_cx;
@@ -58,6 +61,8 @@ struct acpi_processor_cx {
u8 valid;
u8 type;
u32 address;
+ u8 space_id;
+ u8 index;
u32 latency;
u32 latency_ticks;
u32 power;
@@ -206,6 +211,9 @@ void arch_acpi_processor_init_pdc(struct
#ifdef ARCH_HAS_POWER_INIT
void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flags,
unsigned int cpu);
+int acpi_processor_ffh_cstate_probe(unsigned int cpu,
+ struct acpi_processor_cx *cx, struct acpi_power_register *reg);
+void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cstate);
#else
static inline void acpi_processor_power_init_bm_check(struct
acpi_processor_flags
@@ -214,6 +222,16 @@ static inline void acpi_processor_power_
flags->bm_check = 1;
return;
}
+static inline int acpi_processor_ffh_cstate_probe(unsigned int cpu,
+ struct acpi_processor_cx *cx, struct acpi_power_register *reg)
+{
+ return -1;
+}
+static inline void acpi_processor_ffh_cstate_enter(
+ struct acpi_processor_cx *cstate)
+{
+ return;
+}
#endif

/* in processor_perflib.c */
Index: linux-2.6.18-rc4/include/asm-i386/processor.h
===================================================================
--- linux-2.6.18-rc4.orig/include/asm-i386/processor.h
+++ linux-2.6.18-rc4/include/asm-i386/processor.h
@@ -312,6 +312,8 @@ static inline void __mwait(unsigned long
: :"a" (eax), "c" (ecx));
}

+extern void mwait_idle_with_hints(unsigned long eax, unsigned long ecx);
+
/* from system description table in BIOS. Mostly for MCA use, but
others may find it useful. */
extern unsigned int machine_id;
Index: linux-2.6.18-rc4/include/asm-x86_64/processor.h
===================================================================
--- linux-2.6.18-rc4.orig/include/asm-x86_64/processor.h
+++ linux-2.6.18-rc4/include/asm-x86_64/processor.h
@@ -469,6 +469,8 @@ static inline void __mwait(unsigned long
: :"a" (eax), "c" (ecx));
}

+extern void mwait_idle_with_hints(unsigned long eax, unsigned long ecx);
+
#define stack_current() \
({ \
struct thread_info *ti; \

2006-08-30 20:35:23

[permalink] [raw]

Subject: [-mm patch] drivers/input/misc/wistron_btns.c: fix section mismatch

This patch fixes the following section mismatch
(dmi_matched() is referenced from struct dmi_ids):

<-- snip -->

...
Building modules, stage 2.
MODPOST 1956 modules
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x1e0) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x20c) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x238) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x264) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x290) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x2bc) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x2e8) and '__param_str_force'
...

<-- snip -->

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.18-rc4-mm3/drivers/input/misc/wistron_btns.c.old 2006-08-30 21:47:00.000000000 +0200
+++ linux-2.6.18-rc4-mm3/drivers/input/misc/wistron_btns.c 2006-08-30 21:47:57.000000000 +0200
@@ -242,7 +242,7 @@
static int have_wifi;
static int have_bluetooth;

-static int __init dmi_matched(struct dmi_system_id *dmi)
+static int dmi_matched(struct dmi_system_id *dmi)
{
const struct key_entry *key;

2006-08-30 20:35:44

[permalink] [raw]

Subject: [-mm patch] improve SECURITY_SELINUX_POLICYDB_VERSION_MAX{,_VALUE} help texts

We can't expect everyone to know what "FC3" is.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.18-rc4-mm3/security/selinux/Kconfig.old 2006-08-30 21:56:31.000000000 +0200
+++ linux-2.6.18-rc4-mm3/security/selinux/Kconfig 2006-08-30 21:58:21.000000000 +0200
@@ -135,8 +135,10 @@ config SECURITY_SELINUX_POLICYDB_VERSION
It can be adjusted downward to support legacy userland (init) that
does not correctly handle kernels that support newer policy versions.

- Examples: For FC3 or FC4, enable this option and set the value via
- the next option. For FC5 and later, do not enable this option.
+ Examples:
+ For the Fedora Core 3 or 4 Linux distributions, enable this option
+ and set the value via the next option. For Fedore Core 5 and later,
+ do not enable this option.

If you are unsure how to answer this question, answer N.

@@ -149,7 +151,9 @@ config SECURITY_SELINUX_POLICYDB_VERSION
This option sets the value for the maximum policy format version
supported by SELinux.

- Examples: For FC3, use 18. For FC4, use 19.
+ Examples:
+ For Fedora Core 3, use 18.
+ For Fedora Core 4, use 19.

If you are unsure how to answer this question, look for the
policy format version supported by your policy toolchain, by

2006-08-30 20:35:11

[permalink] [raw]

Subject: [-mm patch] net/sched/act_simple.c: make struct simp_hash_info static

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
> git-net.patch
>...
> git trees
>...

This patch makes the needlessly global struct simp_hash_info static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.18-rc4-mm3/net/sched/act_simple.c.old 2006-08-30 20:54:20.000000000 +0200
+++ linux-2.6.18-rc4-mm3/net/sched/act_simple.c 2006-08-30 20:54:43.000000000 +0200
@@ -28,7 +28,7 @@
static u32 simp_idx_gen;
static DEFINE_RWLOCK(simp_lock);

-struct tcf_hashinfo simp_hash_info = {
+static struct tcf_hashinfo simp_hash_info = {
.htab = tcf_simp_ht,
.hmask = SIMP_TAB_MASK,
.lock = &simp_lock,

2006-08-30 22:03:37

by David Miller

[permalink] [raw]

Subject: Re: [-mm patch] net/sched/act_simple.c: make struct simp_hash_info static

From: Adrian Bunk <[email protected]>
Date: Wed, 30 Aug 2006 22:35:07 +0200

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm2:
> >...
> > git-net.patch
> >...
> > git trees
> >...
>
> This patch makes the needlessly global struct simp_hash_info static.
>
> Signed-off-by: Adrian Bunk <[email protected]>

Applied, thanks Adrian.

2006-08-30 23:26:41

by Dmitry Torokhov

[permalink] [raw]

Subject: Re: [-mm patch] drivers/input/misc/wistron_btns.c: fix section mismatch

On Wednesday 30 August 2006 16:35, Adrian Bunk wrote:
> This patch fixes the following section mismatch
> (dmi_matched() is referenced from struct dmi_ids):
>

dmi_ids is only used in select_keymap, which is __init. Moreover,
dmi_ids is marked __initdata so I do not see what the problem is...

--
Dmitry

2006-08-30 23:36:19

[permalink] [raw]

Subject: Re: [-mm patch] drivers/input/misc/wistron_btns.c: fix section mismatch

On Wed, Aug 30, 2006 at 07:26:37PM -0400, Dmitry Torokhov wrote:
> On Wednesday 30 August 2006 16:35, Adrian Bunk wrote:
> > This patch fixes the following section mismatch
> > (dmi_matched() is referenced from struct dmi_ids):
> >
>
> dmi_ids is only used in select_keymap, which is __init. Moreover,
> dmi_ids is marked __initdata so I do not see what the problem is...

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/revert-input-wistron-fix-section-reference-mismatches.patch

> Dmitry

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

2006-08-31 02:54:45

by Dmitry Torokhov

[permalink] [raw]

Subject: Re: [-mm patch] drivers/input/misc/wistron_btns.c: fix section mismatch

On Wednesday 30 August 2006 19:36, Adrian Bunk wrote:
> On Wed, Aug 30, 2006 at 07:26:37PM -0400, Dmitry Torokhov wrote:
> > On Wednesday 30 August 2006 16:35, Adrian Bunk wrote:
> > > This patch fixes the following section mismatch
> > > (dmi_matched() is referenced from struct dmi_ids):
> > >
> >
> > dmi_ids is only used in select_keymap, which is __init. Moreover,
> > dmi_ids is marked __initdata so I do not see what the problem is...
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/revert-input-wistron-fix-section-reference-mismatches.patch
>

Ah, I see. I think it is fixed properly in Linus' tree.

--
Dmitry

2006-08-31 06:46:47

by Brown, Len

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> As far as the unknown exception,
>
> >[ 9.392729] [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> >[ 9.393453] [<c0243352>] acpi_walk_resources+0x10e/0x11b
> >[ 9.394174] [<c025697e>] acpi_motherboard_add+0x22/0x31
>
> I would guess that the callback routine for walk_resources is returning
> a non-zero status value which is causing an immediate abort of the walk
> with that value -- and the value is bogus.

Yep, see -EINVAL below.

-Len

http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch

From: Keith Mannthey <[email protected]>

This patch set allow SPARSEMEM and RESERVE based hot-add to work. I have
test both options and they work as expected. I am adding memory to the
2nd node of a numa system (x86_64).

Major changes from last set is the config change and RESERVE enablment.

This patch:

Make ACPI motherboard driver not attach to devices/handles it dosen't expect.
Fix a bug where the motherboard driver attached to hot-add memory event and
caused the add memory call to fail.

Signed-off-by: Keith Mannthey<[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
Cc: Andi Kleen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---

diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix drivers/acpi/motherboard.c
--- a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
+++ a/drivers/acpi/motherboard.c
@@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
}
} else {
/* Memory mapped IO? */
+ return -EINVAL;
}

if (requested_res)
@@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range

static int acpi_motherboard_add(struct acpi_device *device)
{
+ acpi_status status;
if (!device)
return -EINVAL;
- acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+
+ status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
acpi_reserve_io_ranges, NULL);

+ if (ACPI_FAILURE(status))
+ return -ENODEV;
+
return 0;
}

_

2006-08-31 08:58:23

by Benoit Boissinot

[permalink] [raw]

Subject: Re: 2.6.18-rc4-mm3

On Wed, Aug 30, 2006 at 11:15:08AM -0700, Venkatesh Pallipadi wrote:
> On Mon, Aug 28, 2006 at 07:00:33PM -0700, Pallipadi, Venkatesh wrote:
> >
> >
> > >-----Original Message-----
> > >From: Benoit Boissinot [mailto:[email protected]]
> > >Sent: Sunday, August 27, 2006 9:00 AM
> > >To: Andrew Morton
> > >Cc: [email protected]; Pallipadi, Venkatesh; Brown, Len
> > >Subject: Re: 2.6.18-rc4-mm3
> > >
> > >On 8/27/06, Andrew Morton <[email protected]> wrote:
> > >>
> > >>
> > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
> > >.6.18-rc4/2.6.18-rc4-mm3/
> > >>
> > >> git-acpi.patch
> > >
> > >commit f62d31ee2f2f453b07107465fea54540cab418eb broke my laptop
> > >(pentium M, dell D600).
> > >I can reliably get a hard lockup (no sysrq) when modprobing ehci_hcd
> > >and uhci_hci. It works when reverting the changeset.
> > >
> > >I can provide cpuinfo or dmesg if necessary.
> > >
>
> Attached is the updated patch. Please test it on your system whenever you get
> a chance. ACPI C-states and /proc/acpi/processor/*/power should show similar
> numbers with or without this patch. It should not hang as before.
>

It looks like it's running fine! So far I didn't have any hang whereas
it was completely reproducable before.

thanks,

Benoit
--
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS

2006-08-31 16:48:41

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > As far as the unknown exception,
> >
> > >[ 9.392729] [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > >[ 9.393453] [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > >[ 9.394174] [<c025697e>] acpi_motherboard_add+0x22/0x31
> >
> > I would guess that the callback routine for walk_resources is returning
> > a non-zero status value which is causing an immediate abort of the walk
> > with that value -- and the value is bogus.

Before I put this check in acpi_motherboard_add always attached itself
to any resource type. I simply changed it so if the type is not
ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
and can continue to find the correct device to attach to.

Perhaps the motherboard device needs to attach to more device types?

It was suggest by acpi folks to return -EINVAL. Should something else
be returned?

Thanks,
Keith

> Yep, see -EINVAL below.
>
> -Len
>
> http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
>
>
>
> From: Keith Mannthey <[email protected]>
>
> This patch set allow SPARSEMEM and RESERVE based hot-add to work. I have
> test both options and they work as expected. I am adding memory to the
> 2nd node of a numa system (x86_64).
>
> Major changes from last set is the config change and RESERVE enablment.
>
>
> This patch:
>
>
> Make ACPI motherboard driver not attach to devices/handles it dosen't expect.
> Fix a bug where the motherboard driver attached to hot-add memory event and
> caused the add memory call to fail.
>
> Signed-off-by: Keith Mannthey<[email protected]>
> Cc: KAMEZAWA Hiroyuki <[email protected]>
> Cc: Andi Kleen <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
>
> diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix drivers/acpi/motherboard.c
> --- a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> +++ a/drivers/acpi/motherboard.c
> @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
> }
> } else {
> /* Memory mapped IO? */
> + return -EINVAL;
> }
>
> if (requested_res)
> @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
>
> static int acpi_motherboard_add(struct acpi_device *device)
> {
> + acpi_status status;
> if (!device)
> return -EINVAL;
> - acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> +
> + status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> acpi_reserve_io_ranges, NULL);
>
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> return 0;
> }
>
> _

2006-08-31 23:06:32

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thursday 31 August 2006 10:48, keith mannthey wrote:
> On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> > On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > > As far as the unknown exception,
> > >
> > > >[ 9.392729] [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > > >[ 9.393453] [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > > >[ 9.394174] [<c025697e>] acpi_motherboard_add+0x22/0x31
> > >
> > > I would guess that the callback routine for walk_resources is returning
> > > a non-zero status value which is causing an immediate abort of the walk
> > > with that value -- and the value is bogus.
>
> Before I put this check in acpi_motherboard_add always attached itself
> to any resource type. I simply changed it so if the type is not
> ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
> and can continue to find the correct device to attach to.
>
> Perhaps the motherboard device needs to attach to more device types?
>
> It was suggest by acpi folks to return -EINVAL. Should something else
> be returned?

Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status
like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.

Problem 2: I don't understand how your patch works. An ACPI device
has a list of resources it uses. Are you saying that claiming all
the IO port resources of a PNP0C01 or PNP0C02 device causes the ACPI
memory hotplug driver to fail?

Is there some conflict between those PNP0C01 resources and the
resources of a hotplug memory device? Can you figure out exactly
what the conflict is by disassembling the DSDT for those devices?

We should understand this better before introducing special cases
to the motherboard driver. We should be able to trust the ACPI
description of the motherboard resources. The motherboard driver
currently claims only I/O port resources, but it really should
claim MMIO resources as well.

> > http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> >
> > From: Keith Mannthey <[email protected]>
> > ...
> > Make ACPI motherboard driver not attach to devices/handles it dosen't expect.
> > Fix a bug where the motherboard driver attached to hot-add memory event and
> > caused the add memory call to fail.
> >
> > Signed-off-by: Keith Mannthey<[email protected]>
> > Cc: KAMEZAWA Hiroyuki <[email protected]>
> > Cc: Andi Kleen <[email protected]>
> > Signed-off-by: Andrew Morton <[email protected]>
> > ---
> > diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix drivers/acpi/motherboard.c
> > --- a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> > +++ a/drivers/acpi/motherboard.c
> > @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
> > }
> > } else {
> > /* Memory mapped IO? */
> > + return -EINVAL;
> > }
> >
> > if (requested_res)
> > @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
> >
> > static int acpi_motherboard_add(struct acpi_device *device)
> > {
> > + acpi_status status;
> > if (!device)
> > return -EINVAL;
> > - acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > +
> > + status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > acpi_reserve_io_ranges, NULL);
> >
> > + if (ACPI_FAILURE(status))
> > + return -ENODEV;
> > +
> > return 0;
> > }

2006-09-06 20:04:34

[permalink] [raw]

Subject: RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote:
> From one of the ACPI guys:
>
> > Get hid
> > Look for driver
> > If you find a match, load it
> > If no match, get CID
> > Look for driver
> > If you find a match, load it
> > If you did not find an hid or cid match, punt

I think this is what my patch is doing.

when looking for a driver: (acpi_bus_find_driver)
I check against the HID
return if found
Then I check against the CID
return if found
else
punt

Any objections to pushing this into -mm and dropping the motherboard
change?

Thanks,
Keith

2006-09-06 19:08:13

by Moore, Robert

[permalink] [raw]

Subject: RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

>From one of the ACPI guys:

> Get hid
> Look for driver
> If you find a match, load it
> If no match, get CID
> Look for driver
> If you find a match, load it
> If you did not find an hid or cid match, punt

> -----Original Message-----
> From: [email protected] [mailto:linux-acpi-
> [email protected]] On Behalf Of keith mannthey
> Sent: Wednesday, September 06, 2006 11:14 AM
> To: Bjorn Helgaas
> Cc: Len Brown; Moore, Robert; Li, Shaohua; Mattia Dongili; Andrew
Morton;
> lkml; linux acpi; KAMEZAWA Hiroyuki
> Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception
code:
> 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
>
> On Fri, 2006-09-01 at 17:20 -0600, Bjorn Helgaas wrote:
> > On Friday 01 September 2006 17:01, keith mannthey wrote:
> > > On Thu, 2006-08-31 at 21:15 -0600, Bjorn Helgaas wrote:
> > > > The current ACPI driver binding algorithm in
acpi_bus_find_driver()
> > > > looks at each driver, checking whether it can match either the
_HID
> > > > or the _CID of a device. Since we try the motherboard driver
first,
> > > > it matches the memory device _CID.
> > >
> > > Ok I reverted the motherboard driver patch and cooked up the
following
> > > patch that works for my issue.
> > >
> > > It creates the idea that acpi_match_ids has a type of request to
> check
> > > against for _HID, _CID or both. See acpi_bus_match_req. I then
fix up
> > > all the needed callers to change the API to acpi_match_ids and
> > > acpi_bus_match and have callers can say what they want to match
> > > against.
> > >
> > > Then in acpi_bus_find_driver I have it do 2 passes to search for
> _HID
> > > first then the _CID.
> > >
> > > Does this look like it is in the right ballpark or should we be
doing
> > > something else? Built/tested against 2.6.18-rc4-mm3.
> >
> > Conceptually I like this much better than mucking with the
motherboard
> > driver. I'm not sure the important people have signed off on this
> > strategy of binding with _HID first, then _CID (hi, Len :-)) Maybe
> > there are ramifications that we need to consider. But I think it
> > is a better match for "what people expect should happen."
>
> ACPI folks can we get some response to this? This problem has been
> reported a few times against the -mm tree and I would like to get the
> proper fix (whatever it is) upstream sometime soon.
>
> Bjorn thanks for the help and for pointing the error reports in the
> right direction.
>
> Thanks,
> Keith
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2006-09-07 02:07:37

[permalink] [raw]

Subject: RE: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote:
> On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote:
> > From one of the ACPI guys:
> >
> > > Get hid
> > > Look for driver
> > > If you find a match, load it
> > > If no match, get CID
> > > Look for driver
> > > If you find a match, load it
> > > If you did not find an hid or cid match, punt
>
> I think this is what my patch is doing.
>
> when looking for a driver: (acpi_bus_find_driver)
> I check against the HID
> return if found
> Then I check against the CID
> return if found
> else
> punt
>
> Any objections to pushing this into -mm and dropping the motherboard
> change?
I'd prefer not take this way. The ACPI driver model is already mess
enough, let's don't make it worse. We are converting the ACPI driver
model to Linux driver model, this will make the attempt difficult.

We can let the motherboard driver not bind to your device (say we didn't
register the motherboard driver, but just reserve the resource of the
deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the
mem region of the device too).

Thanks,
Shaohua

2006-09-07 15:25:59

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Wednesday 06 September 2006 20:03, Shaohua Li wrote:
> On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote:
> > On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote:
> > > From one of the ACPI guys:
> > >
> > > > Get hid
> > > > Look for driver
> > > > If you find a match, load it
> > > > If no match, get CID
> > > > Look for driver
> > > > If you find a match, load it
> > > > If you did not find an hid or cid match, punt
> >
> > I think this is what my patch is doing.
> >
> > when looking for a driver: (acpi_bus_find_driver)
> > I check against the HID
> > return if found
> > Then I check against the CID
> > return if found
> > else
> > punt
> >
> > Any objections to pushing this into -mm and dropping the motherboard
> > change?

> I'd prefer not take this way. The ACPI driver model is already mess
> enough, let's don't make it worse. We are converting the ACPI driver
> model to Linux driver model, this will make the attempt difficult.

I see that driver_bind() and driver_probe_device() don't mesh well
with the idea that multiple drivers might be able to claim a device,
because there doesn't seem to be a way to prioritize one driver
over another. Is that the problem you're referring to?

If we decide that "try HID first, then try CID" is the right thing,
I think we should figure out how to make that work. Maybe that
means extending the driver model somehow.

> We can let the motherboard driver not bind to your device (say we didn't
> register the motherboard driver, but just reserve the resource of the
> deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the
> mem region of the device too).

My point was that ACPI tells us what resources the device uses,
and we should reserve all of them so we accurately model the system.

Reserving resources without registering the driver sounds like a hack
to work around broken behavior elsewhere, so I don't think it's a
good idea.

Bjorn

2006-09-08 01:01:04

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> On Wednesday 06 September 2006 20:03, Shaohua Li wrote:
> > On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote:
> > > On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote:
> > > > From one of the ACPI guys:
> > > >
> > > > > Get hid
> > > > > Look for driver
> > > > > If you find a match, load it
> > > > > If no match, get CID
> > > > > Look for driver
> > > > > If you find a match, load it
> > > > > If you did not find an hid or cid match, punt
> > >
> > > I think this is what my patch is doing.
> > >
> > > when looking for a driver: (acpi_bus_find_driver)
> > > I check against the HID
> > > return if found
> > > Then I check against the CID
> > > return if found
> > > else
> > > punt
> > >
> > > Any objections to pushing this into -mm and dropping the motherboard
> > > change?
>
> > I'd prefer not take this way. The ACPI driver model is already mess
> > enough, let's don't make it worse. We are converting the ACPI driver
> > model to Linux driver model, this will make the attempt difficult.
>
> I see that driver_bind() and driver_probe_device() don't mesh well
> with the idea that multiple drivers might be able to claim a device,
> because there doesn't seem to be a way to prioritize one driver
> over another. Is that the problem you're referring to?
Yes.

> If we decide that "try HID first, then try CID" is the right thing,
> I think we should figure out how to make that work. Maybe that
> means extending the driver model somehow.
Don't think it's easy, especially no other bus needs it I guess.

> > We can let the motherboard driver not bind to your device (say we didn't
> > register the motherboard driver, but just reserve the resource of the
> > deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the
> > mem region of the device too).
>
> My point was that ACPI tells us what resources the device uses,
> and we should reserve all of them so we accurately model the system.
>
> Reserving resources without registering the driver sounds like a hack
> to work around broken behavior elsewhere, so I don't think it's a
> good idea.
Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
What's the purpose?

Thanks,
Shaohua

2006-09-08 02:28:06

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

> On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
>> If we decide that "try HID first, then try CID" is the right thing,
>> I think we should figure out how to make that work. Maybe that
>> means extending the driver model somehow.
> Don't think it's easy, especially no other bus needs it I guess.

I agree it's probably not easy, but I think having the right
semantics is more important than fitting cleanly into the
driver model. But I know that without code, I'm just venting
hot air, not contributing to a solution.

How's the ACPI driver model integration going, anyway? I seem
to recall some patches a while back, but I don't think they're
in the tree yet.

> Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
> What's the purpose?

I don't know. But I think Keith already determined that a BIOS change
is not likely. I hate to ask for BIOS changes like this because it
feels like asking them to avoid broken things in Linux.

2006-09-13 01:27:44

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> >> If we decide that "try HID first, then try CID" is the right thing,
> >> I think we should figure out how to make that work. Maybe that
> >> means extending the driver model somehow.
> > Don't think it's easy, especially no other bus needs it I guess.
>
> I agree it's probably not easy, but I think having the right
> semantics is more important than fitting cleanly into the
> driver model. But I know that without code, I'm just venting
> hot air, not contributing to a solution.
>
> How's the ACPI driver model integration going, anyway? I seem
> to recall some patches a while back, but I don't think they're
> in the tree yet.
>
> > Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
> > What's the purpose?
>
> I don't know. But I think Keith already determined that a BIOS change
> is not likely. I hate to ask for BIOS changes like this because it
> feels like asking them to avoid broken things in Linux.

Ok my motherboard patch was dropped from -mm so I am broken again but
others are fixed. Is the answer that we do nothing about this issues?

I am pretty sure my SSDT table is valid if someone *cannot* point out
in the spec where my device is malformed by having both HID and CID I
will not be able even start the request to change the BIOS (it would be
a waste of my time). Sure having the CID of the memory device may be
overkill but is it wrong?

Unless someone can show me a alternate solution I am going to push the
check HID before CID patch to -mm in the next day or two.

Thanks,
Keith

2006-09-13 14:51:24

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> > >> If we decide that "try HID first, then try CID" is the right thing,
> > >> I think we should figure out how to make that work. Maybe that
> > >> means extending the driver model somehow.
> > > Don't think it's easy, especially no other bus needs it I guess.
> >
> > I agree it's probably not easy, but I think having the right
> > semantics is more important than fitting cleanly into the
> > driver model. But I know that without code, I'm just venting
> > hot air, not contributing to a solution.
> >
> > How's the ACPI driver model integration going, anyway? I seem
> > to recall some patches a while back, but I don't think they're
> > in the tree yet.
> >
> > > Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
> > > What's the purpose?
> >
> > I don't know. But I think Keith already determined that a BIOS change
> > is not likely. I hate to ask for BIOS changes like this because it
> > feels like asking them to avoid broken things in Linux.
>
> Ok my motherboard patch was dropped from -mm so I am broken again but
> others are fixed. Is the answer that we do nothing about this issues?
>
> I am pretty sure my SSDT table is valid if someone *cannot* point out
> in the spec where my device is malformed by having both HID and CID I
> will not be able even start the request to change the BIOS (it would be
> a waste of my time). Sure having the CID of the memory device may be
> overkill but is it wrong?

I think that your SSDT is valid. I can't point to a specific
reference in the spec, but I think the "try _HID first, then try
_CID" strategy is clearly the intent. Otherwise, there would be
no reason to separate _HID from _CID.

> Unless someone can show me a alternate solution I am going to push the
> check HID before CID patch to -mm in the next day or two.

I support this, although I do understand that it will make it more
difficult to integrate ACPI into the driver model because the driver
model currently only does one pass to check whether a driver can claim
a device.

Bjorn

2006-09-14 03:02:13

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> > > >> If we decide that "try HID first, then try CID" is the right
> thing,
> > > >> I think we should figure out how to make that work. Maybe that
> > > >> means extending the driver model somehow.
> > > > Don't think it's easy, especially no other bus needs it I guess.
> > >
> > > I agree it's probably not easy, but I think having the right
> > > semantics is more important than fitting cleanly into the
> > > driver model. But I know that without code, I'm just venting
> > > hot air, not contributing to a solution.
> > >
> > > How's the ACPI driver model integration going, anyway? I seem
> > > to recall some patches a while back, but I don't think they're
> > > in the tree yet.
> > >
> > > > Do we really need the memory hotplug device returns
> pnp0c01/pnp0c02?
> > > > What's the purpose?
> > >
> > > I don't know. But I think Keith already determined that a BIOS
> change
> > > is not likely. I hate to ask for BIOS changes like this because
> it
> > > feels like asking them to avoid broken things in Linux.
> >
> > Ok my motherboard patch was dropped from -mm so I am broken again
> but
> > others are fixed. Is the answer that we do nothing about this
> issues?
> >
> > I am pretty sure my SSDT table is valid if someone *cannot* point
> out
> > in the spec where my device is malformed by having both HID and CID
> I
> > will not be able even start the request to change the BIOS (it would
> be
> > a waste of my time). Sure having the CID of the memory device may
> be
> > overkill but is it wrong?
>
> I think that your SSDT is valid. I can't point to a specific
> reference in the spec, but I think the "try _HID first, then try
> _CID" strategy is clearly the intent. Otherwise, there would be
> no reason to separate _HID from _CID.
The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
is valid or invalid.

The 'try _HID first then _CID' has another downside. It highly depends
on the driver is loaded first and then load the device. See motherboard
driver loads first and the mem hotplug driver isn't loaded, in this
situation if you scan the mem hotplug device, the mechanism will fail as
the two pass search will still bind motherboard driver to the device.

If you take the two pass search, I have a feeling this will make acpi
never be able to convert Linux driver model.

If you really want to workaround the issue, I prefer have a blacklist or
something to let ACPI not use the _CID for your device, but please don't
mess the ACPI core itself.

Thanks,
Shaohua

2006-09-14 16:36:15

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Wednesday 13 September 2006 21:01, Shaohua Li wrote:
> On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > I think that your SSDT is valid. I can't point to a specific
> > reference in the spec, but I think the "try _HID first, then try
> > _CID" strategy is clearly the intent. Otherwise, there would be
> > no reason to separate _HID from _CID.

> The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> is valid or invalid.

This problem is more general than just Keith's situation. This
could happen with any device that has both _HID and _CID. As
soon as you have both _HID and _CID, you can have a driver that
claims the _HID and another that claims the _CID.

The spec obviously anticipates this situation, which is why I
think the SSDT is valid from the ACPI spec point of view.

Now, if you have some definition of the programming model of
PNP0C01/PNP0C02, and the memory device doesn't conform to that
model, then I would agree that the SSDT is invalid. But I
don't know where a PNP0C01/PNP0C02 programming model is defined.

The linux driver does nothing more than reserve the resources
of the device, so it doesn't use any programming model at all.
The memory device (in fact, any ACPI device at all) trivially
conforms to this "null programming model."

> The 'try _HID first then _CID' has another downside. It highly depends
> on the driver is loaded first and then load the device. See motherboard
> driver loads first and the mem hotplug driver isn't loaded, in this
> situation if you scan the mem hotplug device, the mechanism will fail as
> the two pass search will still bind motherboard driver to the device.

I agree, this is a problem that will have to be resolved. And it's
really not just an ACPI problem. A PCI driver can claim devices based
on a class or a vendor/device/subvendor/subdevice with wildcards.
Another driver can claim devices with a specific vendor/device/etc.
Some devices may match with both drivers.

PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
driver to release a device and bind another driver to it. Maybe we
could do something similar for ACPI.

Bjorn

2006-09-14 17:55:14

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thu, 2006-09-14 at 11:01 +0800, Shaohua Li wrote:
> On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:

> > I think that your SSDT is valid. I can't point to a specific
> > reference in the spec, but I think the "try _HID first, then try
> > _CID" strategy is clearly the intent. Otherwise, there would be
> > no reason to separate _HID from _CID.
> The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> is valid or invalid.

Lets work on the assumption it is valid until someone points out in a
spec that says it isn't.

> The 'try _HID first then _CID' has another downside. It highly depends
> on the driver is loaded first and then load the device. See motherboard
> driver loads first and the mem hotplug driver isn't loaded, in this
> situation if you scan the mem hotplug device, the mechanism will fail as
> the two pass search will still bind motherboard driver to the device.
Any solution depends on the mem hotplug device being loaded. This
doesn't appear to be _HID before _CID specific issue .

> If you take the two pass search, I have a feeling this will make acpi
> never be able to convert Linux driver model.

I am not trying to break forward work but what I do want is a solution
to my problem.

> If you really want to workaround the issue, I prefer have a blacklist or
> something to let ACPI not use the _CID for your device, but please don't
> mess the ACPI core itself.

My fist pass to fix the problem was I guess a hack of sorts that caused
others problems (motherboard add return != 0 on unknown devices). I
don't want another Keith grown hack that breaks other people.

Can you elaborate on what you think would be safe way to do what you
propose since the ACPI core (can't/won't?) be fixed? I can imagine a
couple of different ways to fix this but I would like some feedback
before I go off and work on the 3rd pass of this fix.

1. Make the memory device get scanned before the motherboard device
somehow. Implicitly reorder the devices in the list. Perhaps a priority
sorted of sorts to have _HID device always before _CID devices during
the scan?

2. Have the motherboard device (if it finds the right acpi device type)
hook into the memory device somehow.

3. Some special blacklist of the motherboard device on my specific
system.

Thanks,
Keith

2006-09-15 01:39:33

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thu, 2006-09-14 at 10:36 -0600, Bjorn Helgaas wrote:
> On Wednesday 13 September 2006 21:01, Shaohua Li wrote:
> > On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > > I think that your SSDT is valid. I can't point to a specific
> > > reference in the spec, but I think the "try _HID first, then try
> > > _CID" strategy is clearly the intent. Otherwise, there would be
> > > no reason to separate _HID from _CID.
>
> > The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> > is valid or invalid.
>
> This problem is more general than just Keith's situation. This
> could happen with any device that has both _HID and _CID. As
> soon as you have both _HID and _CID, you can have a driver that
> claims the _HID and another that claims the _CID.
We don't see such issue before, don't think it's generic. We did have
some devices with _CID, like a pcie root bridge claims pnp0a03 (pci root
bridge), but they are really compatible.

> The spec obviously anticipates this situation, which is why I
> think the SSDT is valid from the ACPI spec point of view.
>
> Now, if you have some definition of the programming model of
> PNP0C01/PNP0C02, and the memory device doesn't conform to that
> model, then I would agree that the SSDT is invalid. But I
> don't know where a PNP0C01/PNP0C02 programming model is defined.
>
> The linux driver does nothing more than reserve the resources
> of the device, so it doesn't use any programming model at all.
> The memory device (in fact, any ACPI device at all) trivially
> conforms to this "null programming model."
>
> > The 'try _HID first then _CID' has another downside. It highly depends
> > on the driver is loaded first and then load the device. See motherboard
> > driver loads first and the mem hotplug driver isn't loaded, in this
> > situation if you scan the mem hotplug device, the mechanism will fail as
> > the two pass search will still bind motherboard driver to the device.
>
> I agree, this is a problem that will have to be resolved. And it's
> really not just an ACPI problem. A PCI driver can claim devices based
> on a class or a vendor/device/subvendor/subdevice with wildcards.
> Another driver can claim devices with a specific vendor/device/etc.
> Some devices may match with both drivers.
I'd prefer don't do ACPI core change in this stage and just workaround
Keith's issue till we find this is really a generic problem.

> PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
> driver to release a device and bind another driver to it. Maybe we
> could do something similar for ACPI.
After we convert acpi core to Linux driver model, we have the
capability. But not sure if this can help Keith.

Thanks,
Shaohua

2006-09-15 01:52:29

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thu, 2006-09-14 at 10:55 -0700, keith mannthey wrote:
> On Thu, 2006-09-14 at 11:01 +0800, Shaohua Li wrote:
> > On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > > On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > > > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
>
> > > I think that your SSDT is valid. I can't point to a specific
> > > reference in the spec, but I think the "try _HID first, then try
> > > _CID" strategy is clearly the intent. Otherwise, there would be
> > > no reason to separate _HID from _CID.
> > The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> > is valid or invalid.
>
> Lets work on the assumption it is valid until someone points out in a
> spec that says it isn't.
>
> > The 'try _HID first then _CID' has another downside. It highly depends
> > on the driver is loaded first and then load the device. See motherboard
> > driver loads first and the mem hotplug driver isn't loaded, in this
> > situation if you scan the mem hotplug device, the mechanism will fail as
> > the two pass search will still bind motherboard driver to the device.
> Any solution depends on the mem hotplug device being loaded. This
> doesn't appear to be _HID before _CID specific issue .
>
> > If you take the two pass search, I have a feeling this will make acpi
> > never be able to convert Linux driver model.
>
> I am not trying to break forward work but what I do want is a solution
> to my problem.
>
> > If you really want to workaround the issue, I prefer have a blacklist or
> > something to let ACPI not use the _CID for your device, but please don't
> > mess the ACPI core itself.
>
> My fist pass to fix the problem was I guess a hack of sorts that caused
> others problems (motherboard add return != 0 on unknown devices). I
> don't want another Keith grown hack that breaks other people.
>
> Can you elaborate on what you think would be safe way to do what you
> propose since the ACPI core (can't/won't?) be fixed? I can imagine a
> couple of different ways to fix this but I would like some feedback
> before I go off and work on the 3rd pass of this fix.
>
> 1. Make the memory device get scanned before the motherboard device
> somehow. Implicitly reorder the devices in the list. Perhaps a priority
> sorted of sorts to have _HID device always before _CID devices during
> the scan?
This will change the scan order of ACPI device, and sounds too hack to me.

> 2. Have the motherboard device (if it finds the right acpi device type)
> hook into the memory device somehow.
>
> 3. Some special blacklist of the motherboard device on my specific
> system.
Either one of the two looks ok.

Thanks,
Shaohua

2006-09-19 10:22:16

[permalink] [raw]

Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thursday 14 September 2006 19:39, Shaohua Li wrote:
> > PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
> > driver to release a device and bind another driver to it. Maybe we
> > could do something similar for ACPI.
> After we convert acpi core to Linux driver model, we have the
> capability. But not sure if this can help Keith.

When will the conversion to the Linux driver model happen?

2006-09-21 00:27:11