Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Randy Dunlap]

akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/
> 
> and will soon be available at
> 
>    git://git.zen-sources.org/zen/mmotm.git


10 randconfigs on i386, 1 good build.

The other 9 ended with either of these build errors:

init/main.c:876: error: 'struct task_struct' has no member named 'mems_allowed'
CONFIG_CPUSETS=n


or

kernel/printk.c:142: error: implicit declaration of function 'VMCOREINFO_SYMBOL'
# CONFIG_KEXEC is not set

-- 
~Randy

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Andrew Morton]

On Wed, 28 Jan 2009 08:56:31 -0800
Randy Dunlap <randy.dunlap@oracle.com> wrote:

> akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> > 
> > and will soon be available at
> > 
> >    git://git.zen-sources.org/zen/mmotm.git
> 
> 
> 10 randconfigs on i386, 1 good build.
> 
> The other 9 ended with either of these build errors:
> 
> init/main.c:876: error: 'struct task_struct' has no member named 'mems_allowed'
> CONFIG_CPUSETS=n

Well that sucks a bit.

--- a/init/main.c~cpuset-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set-fix
+++ a/init/main.c
@@ -873,7 +873,9 @@ static int __init kernel_init(void * unu
 	 */
 	init_pid_ns.child_reaper = current;
 
+#ifdef CONFIG_CPUSETS
 	current->mems_allowed = node_possible_map;
+#endif
 
 	cad_pid = task_pid(current);
 
_

> 
> or
> 
> kernel/printk.c:142: error: implicit declaration of function 'VMCOREINFO_SYMBOL'
> # CONFIG_KEXEC is not set
> 

So does that.

--- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix-fix
+++ a/kernel/printk.c
@@ -137,11 +137,13 @@ static char *log_buf = __log_buf;
 static int log_buf_len = __LOG_BUF_LEN;
 static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
 
+#ifdef CONFIG_KEXEC
 void log_buf_kexec_setup(void)
 {
 	VMCOREINFO_SYMBOL(log_buf);
 	VMCOREINFO_SYMBOL(log_end);
 }
+#endif
 
 static int __init log_buf_len_setup(char *str)
 {
_

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Simon Horman]

On Wed, Jan 28, 2009 at 04:30:40PM -0800, Andrew Morton wrote:
> On Wed, 28 Jan 2009 08:56:31 -0800
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
> > akpm@linux-foundation.org wrote:
> > > The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> > > 
> > >    http://userweb.kernel.org/~akpm/mmotm/
> > > 
> > > and will soon be available at
> > > 
> > >    git://git.zen-sources.org/zen/mmotm.git
> > 
> > 
> > 10 randconfigs on i386, 1 good build.
> > 
> > The other 9 ended with either of these build errors:
> > 

[snip]

> So does that.
> 
> --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix-fix
> +++ a/kernel/printk.c
> @@ -137,11 +137,13 @@ static char *log_buf = __log_buf;
>  static int log_buf_len = __LOG_BUF_LEN;
>  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
>  
> +#ifdef CONFIG_KEXEC
>  void log_buf_kexec_setup(void)
>  {
>  	VMCOREINFO_SYMBOL(log_buf);
>  	VMCOREINFO_SYMBOL(log_end);
>  }
> +#endif
>  
>  static int __init log_buf_len_setup(char *str)
>  {
> _

Weird, I thought I checked that just now. In any case this email
was already in my inbox. In any case, I can now produce the problem,
and this patch resolves it.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

Re: mmotm 2009-01-28-02-17 uploaded

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

On Wed, 28 Jan 2009 02:19:09 PST, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/

cpuset-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set.patch

breaks compiles with CONFIG_CPUSETS=n

  CC      init/main.o
init/main.c: In function 'kernel_init':
init/main.c:876: error: 'struct task_struct' has no member named 'mems_allowed'
make[1]: *** [init/main.o] Error 1

Looks like it adds a reference to task->mems_allowed to kernel/main.c
and kernel/kthreads.c and neither one is wrapped with #ifdef CONFIG_CPUSETS
or anything.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: mmotm 2009-01-28-02-17 uploaded

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Wed, 28 Jan 2009 02:19:09 PST, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/

kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists.patch

breaks the compile with CONFIG_KEXEC=n

  CC      kernel/printk.o
kernel/printk.c: In function 'log_buf_kexec_setup':
kernel/printk.c:142: error: implicit declaration of function 'VMCOREINFO_SYMBOL'
make[1]: *** [kernel/printk.o] Error 1
make: *** [kernel] Error 2


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Neil Horman]

On Thu, Jan 29, 2009 at 11:28:50AM +0900, Simon Horman wrote:
> On Wed, Jan 28, 2009 at 04:30:40PM -0800, Andrew Morton wrote:
> > On Wed, 28 Jan 2009 08:56:31 -0800
> > Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > 
> > > akpm@linux-foundation.org wrote:
> > > > The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> > > > 
> > > >    http://userweb.kernel.org/~akpm/mmotm/
> > > > 
> > > > and will soon be available at
> > > > 
> > > >    git://git.zen-sources.org/zen/mmotm.git
> > > 
> > > 
> > > 10 randconfigs on i386, 1 good build.
> > > 
> > > The other 9 ended with either of these build errors:
> > > 
> 
> [snip]
> 
> > So does that.
> > 
> > --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix-fix
> > +++ a/kernel/printk.c
> > @@ -137,11 +137,13 @@ static char *log_buf = __log_buf;
> >  static int log_buf_len = __LOG_BUF_LEN;
> >  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
> >  
> > +#ifdef CONFIG_KEXEC
> >  void log_buf_kexec_setup(void)
> >  {
> >  	VMCOREINFO_SYMBOL(log_buf);
> >  	VMCOREINFO_SYMBOL(log_end);
> >  }
> > +#endif
> >  
> >  static int __init log_buf_len_setup(char *str)
> >  {
> > _
> 
> Weird, I thought I checked that just now. In any case this email
> was already in my inbox. In any case, I can now produce the problem,
> and this patch resolves it.
> 

Sorry, i didn't think to check on conditions when CONFIG_KEXEC wasn't set.  I
assumed we had a stub for all the VMCOREINFO defines.  Why don't we fix it in
that manner?  I mean we have serveral arch specific additions to vmcoreinfo, all
of which apparently must be ifdefd for this to work.  Why not just fix it in
conditional definition?

Neil

> -- 
> Simon Horman
>   VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
>   H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en
> 
> 

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Vivek Goyal]

On Thu, Jan 29, 2009 at 07:09:35AM -0500, Neil Horman wrote:
> On Thu, Jan 29, 2009 at 11:28:50AM +0900, Simon Horman wrote:
> > On Wed, Jan 28, 2009 at 04:30:40PM -0800, Andrew Morton wrote:
> > > On Wed, 28 Jan 2009 08:56:31 -0800
> > > Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > > 
> > > > akpm@linux-foundation.org wrote:
> > > > > The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> > > > > 
> > > > >    http://userweb.kernel.org/~akpm/mmotm/
> > > > > 
> > > > > and will soon be available at
> > > > > 
> > > > >    git://git.zen-sources.org/zen/mmotm.git
> > > > 
> > > > 
> > > > 10 randconfigs on i386, 1 good build.
> > > > 
> > > > The other 9 ended with either of these build errors:
> > > > 
> > 
> > [snip]
> > 
> > > So does that.
> > > 
> > > --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix-fix
> > > +++ a/kernel/printk.c
> > > @@ -137,11 +137,13 @@ static char *log_buf = __log_buf;
> > >  static int log_buf_len = __LOG_BUF_LEN;
> > >  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
> > >  
> > > +#ifdef CONFIG_KEXEC
> > >  void log_buf_kexec_setup(void)
> > >  {
> > >  	VMCOREINFO_SYMBOL(log_buf);
> > >  	VMCOREINFO_SYMBOL(log_end);
> > >  }
> > > +#endif
> > >  
> > >  static int __init log_buf_len_setup(char *str)
> > >  {
> > > _
> > 
> > Weird, I thought I checked that just now. In any case this email
> > was already in my inbox. In any case, I can now produce the problem,
> > and this patch resolves it.
> > 
> 
> Sorry, i didn't think to check on conditions when CONFIG_KEXEC wasn't set.  I
> assumed we had a stub for all the VMCOREINFO defines.  Why don't we fix it in
> that manner?  I mean we have serveral arch specific additions to vmcoreinfo, all
> of which apparently must be ifdefd for this to work.  Why not just fix it in
> conditional definition?
> 

This kind of makes sense. We probably should be taken care in kexec.h with
empty definition of VMCOREINFO_SYMBOL so that we can get rid of #ifdef
KEXEC in printk.c

Neil, do you want to throw in a patch for that.

Thanks
Vivek

Re: mmotm 2009-01-28-02-17 uploaded - docking station issues.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Wed, 28 Jan 2009 02:19:09 PST, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/

% ls -l /sys/devices/platform/dock.0/docked
-r--r--r-- 1 root root 4096 2009-01-29 10:49 /sys/devices/platform/dock.0/docked
% cat /sys/devices/platform/dock.0/docked
ñÞcat: write error: Bad address

strace of the cat shows:

open("/sys/devices/platform/dock.0/docked", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1812586496

Under 2.6.29-rc2-mmotm0116, this would return either "0" or "1", not 4K
of nulls.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: mmotm 2009-01-28-02-17 uploaded

[Andrew Morton]

On Wed, 28 Jan 2009 22:43:24 -0500 Valdis.Kletnieks@vt.edu wrote:

> On Wed, 28 Jan 2009 02:19:09 PST, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> 
> cpuset-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set.patch
> 
> breaks compiles with CONFIG_CPUSETS=n
> 
>   CC      init/main.o
> init/main.c: In function 'kernel_init':
> init/main.c:876: error: 'struct task_struct' has no member named 'mems_allowed'
> make[1]: *** [init/main.o] Error 1
> 
> Looks like it adds a reference to task->mems_allowed to kernel/main.c
> and kernel/kthreads.c and neither one is wrapped with #ifdef CONFIG_CPUSETS
> or anything.
> 

yup.  mmotm-2009-01-29-02-29 has

diff -puN include/linux/cpuset.h~cpuset-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set-fix-2 include/linux/cpuset.h
--- a/include/linux/cpuset.h~cpuset-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set-fix-2
+++ a/include/linux/cpuset.h
@@ -79,6 +79,11 @@ extern void rebuild_sched_domains(void);
 
 extern void cpuset_print_task_mems_allowed(struct task_struct *p);
 
+static inline void set_mems_allowed(nodemask_t nodemask)
+{
+	current->mems_allowed = nodemask;
+}
+
 #else /* !CONFIG_CPUSETS */
 
 static inline int cpuset_init(void) { return 0; }
@@ -163,6 +168,10 @@ static inline void cpuset_print_task_mem
 {
 }
 
+static inline void set_mems_allowed(nodemask_t nodemask)
+{
+}
+
 #endif /* !CONFIG_CPUSETS */
 
 #endif /* _LINUX_CPUSET_H */
diff -puN init/main.c~cpuset-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set-fix-2 init/main.c
--- a/init/main.c~cpuset-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set-fix-2
+++ a/init/main.c
@@ -873,7 +873,7 @@ static int __init kernel_init(void * unu
 	 */
 	init_pid_ns.child_reaper = current;
 
-	current->mems_allowed = node_possible_map;
+	set_mems_allowed(node_possible_map);
 
 	cad_pid = task_pid(current);
 
diff -puN kernel/kthread.c~cpuset-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set-fix-2 kernel/kthread.c
--- a/kernel/kthread.c~cpuset-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set-fix-2
+++ a/kernel/kthread.c
@@ -13,6 +13,8 @@
 #include <linux/file.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <linux/cpuset.h>
+
 #include <trace/sched.h>
 
 #define KTHREAD_NICE_LEVEL (-5)
@@ -242,7 +244,7 @@ int kthreadd(void *unused)
 	set_user_nice(tsk, KTHREAD_NICE_LEVEL);
 	set_cpus_allowed_ptr(tsk, CPU_MASK_ALL_PTR);
 
-	current->mems_allowed = node_possible_map;
+	set_mems_allowed(node_possible_map);
 	current->flags |= PF_NOFREEZE | PF_FREEZER_NOSIG;
 
 	for (;;) {
_

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Andrew Morton]

On Thu, 29 Jan 2009 07:09:35 -0500 Neil Horman <nhorman@tuxdriver.com> wrote:

> > > So does that.
> > > 
> > > --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix-fix
> > > +++ a/kernel/printk.c
> > > @@ -137,11 +137,13 @@ static char *log_buf = __log_buf;
> > >  static int log_buf_len = __LOG_BUF_LEN;
> > >  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
> > >  
> > > +#ifdef CONFIG_KEXEC
> > >  void log_buf_kexec_setup(void)
> > >  {
> > >  	VMCOREINFO_SYMBOL(log_buf);
> > >  	VMCOREINFO_SYMBOL(log_end);
> > >  }
> > > +#endif
> > >  
> > >  static int __init log_buf_len_setup(char *str)
> > >  {
> > > _
> > 
> > Weird, I thought I checked that just now. In any case this email
> > was already in my inbox. In any case, I can now produce the problem,
> > and this patch resolves it.
> > 
> 
> Sorry, i didn't think to check on conditions when CONFIG_KEXEC wasn't set.  I
> assumed we had a stub for all the VMCOREINFO defines.  Why don't we fix it in
> that manner?  I mean we have serveral arch specific additions to vmcoreinfo, all
> of which apparently must be ifdefd for this to work.  Why not just fix it in
> conditional definition?

I didn't do that because then we'd have an empty function log_buf_kexec_setup()
floating about in every vmlinux.

Hardly a big issue, but a bit regrettable.

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Neil Horman]

On Thu, Jan 29, 2009 at 10:01:57AM -0800, Andrew Morton wrote:
> On Thu, 29 Jan 2009 07:09:35 -0500 Neil Horman <nhorman@tuxdriver.com> wrote:
> 
> > > > So does that.
> > > > 
> > > > --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix-fix
> > > > +++ a/kernel/printk.c
> > > > @@ -137,11 +137,13 @@ static char *log_buf = __log_buf;
> > > >  static int log_buf_len = __LOG_BUF_LEN;
> > > >  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
> > > >  
> > > > +#ifdef CONFIG_KEXEC
> > > >  void log_buf_kexec_setup(void)
> > > >  {
> > > >  	VMCOREINFO_SYMBOL(log_buf);
> > > >  	VMCOREINFO_SYMBOL(log_end);
> > > >  }
> > > > +#endif
> > > >  
> > > >  static int __init log_buf_len_setup(char *str)
> > > >  {
> > > > _
> > > 
> > > Weird, I thought I checked that just now. In any case this email
> > > was already in my inbox. In any case, I can now produce the problem,
> > > and this patch resolves it.
> > > 
> > 
> > Sorry, i didn't think to check on conditions when CONFIG_KEXEC wasn't set.  I
> > assumed we had a stub for all the VMCOREINFO defines.  Why don't we fix it in
> > that manner?  I mean we have serveral arch specific additions to vmcoreinfo, all
> > of which apparently must be ifdefd for this to work.  Why not just fix it in
> > conditional definition?
> 
> I didn't do that because then we'd have an empty function log_buf_kexec_setup()
> floating about in every vmlinux.
> 
> Hardly a big issue, but a bit regrettable.
> 
Won't the compiler just eliminate that symbol during final link, given that its
not an exported symbol?
Neil

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Neil Horman]

On Thu, Jan 29, 2009 at 09:20:49AM -0500, Vivek Goyal wrote:
> On Thu, Jan 29, 2009 at 07:09:35AM -0500, Neil Horman wrote:
> > On Thu, Jan 29, 2009 at 11:28:50AM +0900, Simon Horman wrote:
> > > On Wed, Jan 28, 2009 at 04:30:40PM -0800, Andrew Morton wrote:
> > > > On Wed, 28 Jan 2009 08:56:31 -0800
> > > > Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > > > 
> > > > > akpm@linux-foundation.org wrote:
> > > > > > The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> > > > > > 
> > > > > >    http://userweb.kernel.org/~akpm/mmotm/
> > > > > > 
> > > > > > and will soon be available at
> > > > > > 
> > > > > >    git://git.zen-sources.org/zen/mmotm.git
> > > > > 
> > > > > 
> > > > > 10 randconfigs on i386, 1 good build.
> > > > > 
> > > > > The other 9 ended with either of these build errors:
> > > > > 
> > > 
> > > [snip]
> > > 
> > > > So does that.
> > > > 
> > > > --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix-fix
> > > > +++ a/kernel/printk.c
> > > > @@ -137,11 +137,13 @@ static char *log_buf = __log_buf;
> > > >  static int log_buf_len = __LOG_BUF_LEN;
> > > >  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
> > > >  
> > > > +#ifdef CONFIG_KEXEC
> > > >  void log_buf_kexec_setup(void)
> > > >  {
> > > >  	VMCOREINFO_SYMBOL(log_buf);
> > > >  	VMCOREINFO_SYMBOL(log_end);
> > > >  }
> > > > +#endif
> > > >  
> > > >  static int __init log_buf_len_setup(char *str)
> > > >  {
> > > > _
> > > 
> > > Weird, I thought I checked that just now. In any case this email
> > > was already in my inbox. In any case, I can now produce the problem,
> > > and this patch resolves it.
> > > 
> > 
> > Sorry, i didn't think to check on conditions when CONFIG_KEXEC wasn't set.  I
> > assumed we had a stub for all the VMCOREINFO defines.  Why don't we fix it in
> > that manner?  I mean we have serveral arch specific additions to vmcoreinfo, all
> > of which apparently must be ifdefd for this to work.  Why not just fix it in
> > conditional definition?
> > 
> 
> This kind of makes sense. We probably should be taken care in kexec.h with
> empty definition of VMCOREINFO_SYMBOL so that we can get rid of #ifdef
> KEXEC in printk.c
> 
> Neil, do you want to throw in a patch for that.
> 

I'd be happy to put this together, I'll do so shortly.
Neil

> Thanks
> Vivek
> 

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Andrew Morton]

On Thu, 29 Jan 2009 14:27:34 -0500
Neil Horman <nhorman@tuxdriver.com> wrote:

> On Thu, Jan 29, 2009 at 10:01:57AM -0800, Andrew Morton wrote:
> > On Thu, 29 Jan 2009 07:09:35 -0500 Neil Horman <nhorman@tuxdriver.com> wrote:
> > 
> > > > > So does that.
> > > > > 
> > > > > --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix-fix
> > > > > +++ a/kernel/printk.c
> > > > > @@ -137,11 +137,13 @@ static char *log_buf = __log_buf;
> > > > >  static int log_buf_len = __LOG_BUF_LEN;
> > > > >  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
> > > > >  
> > > > > +#ifdef CONFIG_KEXEC
> > > > >  void log_buf_kexec_setup(void)
> > > > >  {
> > > > >  	VMCOREINFO_SYMBOL(log_buf);
> > > > >  	VMCOREINFO_SYMBOL(log_end);
> > > > >  }
> > > > > +#endif
> > > > >  
> > > > >  static int __init log_buf_len_setup(char *str)
> > > > >  {
> > > > > _
> > > > 
> > > > Weird, I thought I checked that just now. In any case this email
> > > > was already in my inbox. In any case, I can now produce the problem,
> > > > and this patch resolves it.
> > > > 
> > > 
> > > Sorry, i didn't think to check on conditions when CONFIG_KEXEC wasn't set.  I
> > > assumed we had a stub for all the VMCOREINFO defines.  Why don't we fix it in
> > > that manner?  I mean we have serveral arch specific additions to vmcoreinfo, all
> > > of which apparently must be ifdefd for this to work.  Why not just fix it in
> > > conditional definition?
> > 
> > I didn't do that because then we'd have an empty function log_buf_kexec_setup()
> > floating about in every vmlinux.
> > 
> > Hardly a big issue, but a bit regrettable.
> > 
> Won't the compiler just eliminate that symbol during final link, given that its
> not an exported symbol?

I don't think it's that smart.

akpm:/home/akpm> cat t.c

void foo(void)
{
}
	
main()
{
}
akpm:/home/akpm> gcc -O2 t.c
akpm:/home/akpm> nm a.out|grep foo
08048300 T foo

With -ffunction-sections or other fancy options, maybe.  And it'll be
version-dependent.

Re: mmotm 2009-01-28-02-17 uploaded (i386 build errors: cpusets & kexec)

[Neil Horman]

On Thu, Jan 29, 2009 at 11:48:59AM -0800, Andrew Morton wrote:
> On Thu, 29 Jan 2009 14:27:34 -0500
> Neil Horman <nhorman@tuxdriver.com> wrote:
> 
> > On Thu, Jan 29, 2009 at 10:01:57AM -0800, Andrew Morton wrote:
> > > On Thu, 29 Jan 2009 07:09:35 -0500 Neil Horman <nhorman@tuxdriver.com> wrote:
> > > 
> > > > > > So does that.
> > > > > > 
> > > > > > --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix-fix
> > > > > > +++ a/kernel/printk.c
> > > > > > @@ -137,11 +137,13 @@ static char *log_buf = __log_buf;
> > > > > >  static int log_buf_len = __LOG_BUF_LEN;
> > > > > >  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
> > > > > >  
> > > > > > +#ifdef CONFIG_KEXEC
> > > > > >  void log_buf_kexec_setup(void)
> > > > > >  {
> > > > > >  	VMCOREINFO_SYMBOL(log_buf);
> > > > > >  	VMCOREINFO_SYMBOL(log_end);
> > > > > >  }
> > > > > > +#endif
> > > > > >  
> > > > > >  static int __init log_buf_len_setup(char *str)
> > > > > >  {
> > > > > > _
> > > > > 
> > > > > Weird, I thought I checked that just now. In any case this email
> > > > > was already in my inbox. In any case, I can now produce the problem,
> > > > > and this patch resolves it.
> > > > > 
> > > > 
> > > > Sorry, i didn't think to check on conditions when CONFIG_KEXEC wasn't set.  I
> > > > assumed we had a stub for all the VMCOREINFO defines.  Why don't we fix it in
> > > > that manner?  I mean we have serveral arch specific additions to vmcoreinfo, all
> > > > of which apparently must be ifdefd for this to work.  Why not just fix it in
> > > > conditional definition?
> > > 
> > > I didn't do that because then we'd have an empty function log_buf_kexec_setup()
> > > floating about in every vmlinux.
> > > 
> > > Hardly a big issue, but a bit regrettable.
> > > 
> > Won't the compiler just eliminate that symbol during final link, given that its
> > not an exported symbol?
> 
> I don't think it's that smart.
> 
> akpm:/home/akpm> cat t.c
> 
> void foo(void)
> {
> }
> 	
> main()
> {
> }
> akpm:/home/akpm> gcc -O2 t.c
> akpm:/home/akpm> nm a.out|grep foo
> 08048300 T foo
> 
> With -ffunction-sections or other fancy options, maybe.  And it'll be
> version-dependent.
> 
huh, how about that.  I always thought we stripped out empty functions.  Perhaps
that a later stage in most of the build processes I've used (a strip or
something later on perhaps).  Anywho, I stand corrected.  In light of this, its
probably best that we keep what we have, and just ifdef out the callers.

Thanks Andrew!
Neil

> 

Re: mmotm 2009-01-28-02-17 uploaded - docking station issues.

[Andrew Morton]

On Thu, 29 Jan 2009 11:25:43 -0500 Valdis.Kletnieks@vt.edu wrote:

> On Wed, 28 Jan 2009 02:19:09 PST, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> 
> % ls -l /sys/devices/platform/dock.0/docked
> -r--r--r-- 1 root root 4096 2009-01-29 10:49 /sys/devices/platform/dock.0/docked
> % cat /sys/devices/platform/dock.0/docked
> ñÞcat: write error: Bad address
> 
> strace of the cat shows:
> 
> open("/sys/devices/platform/dock.0/docked", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1812586496
> 
> Under 2.6.29-rc2-mmotm0116, this would return either "0" or "1", not 4K
> of nulls.
> 

Is it due to 

acpi-dock-dont-eval-_sta-on-every-show_docked-sysfs-read.patch

and/or

acpi-dock-dont-eval-_sta-on-every-show_docked-sysfs-read-simplification.patch

?

Re: mmotm 2009-01-28-02-17 uploaded - docking station issues.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

On Fri, 30 Jan 2009 21:03:52 PST, Andrew Morton said:
> On Thu, 29 Jan 2009 11:25:43 -0500 Valdis.Kletnieks@vt.edu wrote:
> 
> > On Wed, 28 Jan 2009 02:19:09 PST, akpm@linux-foundation.org said:
> > > The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> > >    http://userweb.kernel.org/~akpm/mmotm/

> > % ls -l /sys/devices/platform/dock.0/docked
> > -r--r--r-- 1 root root 4096 2009-01-29 10:49 /sys/devices/platform/dock.0/docked
> > % cat /sys/devices/platform/dock.0/docked
> > =F1=DEcat: write error: Bad address
> >
> > strace of the cat shows:
> >
> > open("/sys/devices/platform/dock.0/docked", O_RDONLY) = 3
> > fstat(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> > read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1812586496

> > Under 2.6.29-rc2-mmotm0116, this would return either "0" or "1", not 4K
> > of nulls.

> Is it due to
>
> acpi-dock-dont-eval-_sta-on-every-show_docked-sysfs-read.patch

Bingo. Reverting that patch and the sysfs-read-simplified.patch fixed it.

So obviously something in there doesn't agree with the innards of my laptop -

Dell Latitude D820, BIOS is A09 (current), if that helps anybody...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: mmotm 2009-01-28-02-17 uploaded - docking station issues.

[Andrew Morton]

On Sat, 31 Jan 2009 03:40:14 -0500 Valdis.Kletnieks@vt.edu wrote:

> On Fri, 30 Jan 2009 21:03:52 PST, Andrew Morton said:
> > On Thu, 29 Jan 2009 11:25:43 -0500 Valdis.Kletnieks@vt.edu wrote:
> > 
> > > On Wed, 28 Jan 2009 02:19:09 PST, akpm@linux-foundation.org said:
> > > > The mm-of-the-moment snapshot 2009-01-28-02-17 has been uploaded to
> > > >    http://userweb.kernel.org/~akpm/mmotm/
> 
> > > % ls -l /sys/devices/platform/dock.0/docked
> > > -r--r--r-- 1 root root 4096 2009-01-29 10:49 /sys/devices/platform/dock.0/docked
> > > % cat /sys/devices/platform/dock.0/docked
> > > =F1=DEcat: write error: Bad address
> > >
> > > strace of the cat shows:
> > >
> > > open("/sys/devices/platform/dock.0/docked", O_RDONLY) = 3
> > > fstat(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> > > read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1812586496
> 
> > > Under 2.6.29-rc2-mmotm0116, this would return either "0" or "1", not 4K
> > > of nulls.
> 
> > Is it due to
> >
> > acpi-dock-dont-eval-_sta-on-every-show_docked-sysfs-read.patch
> 
> Bingo. Reverting that patch and the sysfs-read-simplified.patch fixed it.
> 
> So obviously something in there doesn't agree with the innards of my laptop -
> 

urgh,
acpi-dock-dont-eval-_sta-on-every-show_docked-sysfs-read-simplification.patch
is completely wrong (return value) and the insane warning storm which
kernel builds create hid that from me.

I dropped it.