Re: [patch] ipvs: force read of atomic_t in while loop

[Horms]

On Wed, Aug 08, 2007 at 11:33:00AM +0200, Heiko Carstens wrote:
> From: Heiko Carstens <[EMAIL PROTECTED]>
> 
> For architectures that don't have a volatile atomic_ts constructs like
> while (atomic_read()); might result in endless loops since a
> barrier() is missing which forces the compiler to generate code that
> actually reads memory contents.
> Fix this in ipvs by using the IP_VS_WAIT_WHILE macro which resolves to
> while (expr) { cpu_relax(); }
> (why isn't this open coded btw?)
> 
> Cc: Wensong Zhang <[EMAIL PROTECTED]>
> Cc: Simon Horman <[EMAIL PROTECTED]>
> Cc: David Miller <[EMAIL PROTECTED]>
> Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
> ---
> 
> Just saw this while grepping for atomic_reads in a while loops.
> Maybe we should re-add the volatile to atomic_t. Not sure.

This looks good to me. A little wile back I noticed a few places
where IP_VS_WAIT_WHILE seemed to be curiously unused, then I got
distracted...

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

> 
>  net/ipv4/ipvs/ip_vs_ctl.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
> ===
> --- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ctl.c
> +++ linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
> @@ -909,7 +909,7 @@ ip_vs_edit_dest(struct ip_vs_service *sv
>   write_lock_bh(&__ip_vs_svc_lock);
>  
>   /* Wait until all other svc users go away */
> - while (atomic_read(>usecnt) > 1) {};
> + IP_VS_WAIT_WHILE(atomic_read(>usecnt) > 1);
>  
>   /* call the update_service, because server weight may be changed */
>   svc->scheduler->update_service(svc);

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] ipvs: force read of atomic_t in while loop

[Horms]

On Wed, Aug 08, 2007 at 11:33:00AM +0200, Heiko Carstens wrote:
 From: Heiko Carstens [EMAIL PROTECTED]
 
 For architectures that don't have a volatile atomic_ts constructs like
 while (atomic_read(something)); might result in endless loops since a
 barrier() is missing which forces the compiler to generate code that
 actually reads memory contents.
 Fix this in ipvs by using the IP_VS_WAIT_WHILE macro which resolves to
 while (expr) { cpu_relax(); }
 (why isn't this open coded btw?)
 
 Cc: Wensong Zhang [EMAIL PROTECTED]
 Cc: Simon Horman [EMAIL PROTECTED]
 Cc: David Miller [EMAIL PROTECTED]
 Cc: Martin Schwidefsky [EMAIL PROTECTED]
 Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
 ---
 
 Just saw this while grepping for atomic_reads in a while loops.
 Maybe we should re-add the volatile to atomic_t. Not sure.

This looks good to me. A little wile back I noticed a few places
where IP_VS_WAIT_WHILE seemed to be curiously unused, then I got
distracted...

Signed-off-by: Simon Horman [EMAIL PROTECTED]

 
  net/ipv4/ipvs/ip_vs_ctl.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 Index: linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
 ===
 --- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ctl.c
 +++ linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
 @@ -909,7 +909,7 @@ ip_vs_edit_dest(struct ip_vs_service *sv
   write_lock_bh(__ip_vs_svc_lock);
  
   /* Wait until all other svc users go away */
 - while (atomic_read(svc-usecnt)  1) {};
 + IP_VS_WAIT_WHILE(atomic_read(svc-usecnt)  1);
  
   /* call the update_service, because server weight may be changed */
   svc-scheduler-update_service(svc);

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2/2] 2.6.23-rc1: known regressions

[Horms]

> IA64
> 
> Subject : Regression in serial console on ia64 after 2.6.22
> References  : http://marc.info/?l=linux-ia64=118483645914066=2
> Last known good : ?
> Submitter   : Horms <[EMAIL PROTECTED]>
> Caused-By   : Yinghai Lu <[EMAIL PROTECTED]>
>   commit 18a8bd949d6adb311ea816125ff65050df1f3f6e
> Handled-By  : ?
> Status  : unknown

This was fixed by ensuring that machvex is set up before the
serial console

a07ee86205808d36973440e68c7277f9ed63b87f in Linus' tree

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2/2] 2.6.23-rc1: known regressions

[Horms]

 IA64
 
 Subject : Regression in serial console on ia64 after 2.6.22
 References  : http://marc.info/?l=linux-ia64m=118483645914066w=2
 Last known good : ?
 Submitter   : Horms [EMAIL PROTECTED]
 Caused-By   : Yinghai Lu [EMAIL PROTECTED]
   commit 18a8bd949d6adb311ea816125ff65050df1f3f6e
 Handled-By  : ?
 Status  : unknown

This was fixed by ensuring that machvex is set up before the
serial console

a07ee86205808d36973440e68c7277f9ed63b87f in Linus' tree

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression in serial console on ia64 after 2.6.22

[Horms]

On Tue, Jul 24, 2007 at 04:57:32PM -0700, Yinghai Lu wrote:
> 
> IA64
> 
> Subject : Regression in serial console on ia64 after 2.6.22
> References  : http://marc.info/?l=linux-ia64=118483645914066=2
> Last known good : ?
> Submitter   : Horms <[EMAIL PROTECTED]>
> Caused-By   : Yinghai Lu <[EMAIL PROTECTED]>
>   commit 18a8bd949d6adb311ea816125ff65050df1f3f6e
> Handled-By  : ?
> Status  : unknown
> 
> 
> please test this patch.
> 
> YH

I just posted a similar patch (sorry, I didn't see your post until
afterwards). I guess that we both have the same ideas :)

> 
> 
> [PATCH] ia64: move machvec_init before parse_early_param
> 
> So ia64_mv is initialized before early console
> 
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
> 
> diff --git a/arch/ia64/kernel/machvec.c b/arch/ia64/kernel/machvec.c
> index 13df337..a94feaa 100644
> --- a/arch/ia64/kernel/machvec.c
> +++ b/arch/ia64/kernel/machvec.c
> @@ -14,12 +14,6 @@ struct ia64_machine_vector ia64_mv;
>  EXPORT_SYMBOL(ia64_mv);
>  
>  static __initdata const char *mvec_name;
> -static __init int setup_mvec(char *s)
> -{
> - mvec_name = s;
> - return 0;
> -}
> -early_param("machvec", setup_mvec);
>  
>  static struct ia64_machine_vector * __init
>  lookup_machvec (const char *name)
> @@ -42,6 +36,10 @@ machvec_init (const char *name)
>  
>   if (!name)
>   name = mvec_name ? mvec_name : acpi_get_sysname();

I think that mvec_name can be disposed of all together as
its only used by the line above and setup_mvec(), which in
turn is only used by early_param. I got rid of mvec_name in
my incantation of this patch, and it seemed to work quite well.

> +
> + if (!mvec_name)
> + mvec_name = name;
> +
>   mv = lookup_machvec(name);
>   if (!mv)
>   panic("generic kernel failed to find machine vector for"
> diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
> index cf06fe7..b06d7b7 100644
> --- a/arch/ia64/kernel/setup.c
> +++ b/arch/ia64/kernel/setup.c
> @@ -481,6 +481,9 @@ int __init reserve_elfcorehdr(unsigned long *start, 
> unsigned long *end)
>  void __init
>  setup_arch (char **cmdline_p)
>  {
> +#ifdef CONFIG_IA64_GENERIC
> + char *mvstr;
> +#endif
>   unw_init();
>  
>   ia64_patch_vtop((u64) __start___vtop_patchlist, (u64) 
> __end___vtop_patchlist);
> @@ -491,12 +494,15 @@ setup_arch (char **cmdline_p)
>   efi_init();
>   io_port_init();
>  
> - parse_early_param();
> -
>  #ifdef CONFIG_IA64_GENERIC
> - machvec_init(NULL);
> + mvstr = strstr(*cmd_line_p, "machvec=")
> + if (mvstr)
> + mvstr = strchr(mvstr, '=') + 1;
> + machvec_init(mvstr);
>  #endif

Do you need to copy and truncate mvstr on ' ' in the case
that machvec= isn't the last argument on the command line?
I did this in my patch, though I didn't test to see if
it was uneccessary.


>  
> + parse_early_param();
> +
>   if (early_console_setup(*cmdline_p) == 0)
>   mark_bsp_online();
>  
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression in serial console on ia64 after 2.6.22

[Horms]

On Tue, Jul 24, 2007 at 04:57:32PM -0700, Yinghai Lu wrote:
 
 IA64
 
 Subject : Regression in serial console on ia64 after 2.6.22
 References  : http://marc.info/?l=linux-ia64m=118483645914066w=2
 Last known good : ?
 Submitter   : Horms [EMAIL PROTECTED]
 Caused-By   : Yinghai Lu [EMAIL PROTECTED]
   commit 18a8bd949d6adb311ea816125ff65050df1f3f6e
 Handled-By  : ?
 Status  : unknown
 
 
 please test this patch.
 
 YH

I just posted a similar patch (sorry, I didn't see your post until
afterwards). I guess that we both have the same ideas :)

 
 
 [PATCH] ia64: move machvec_init before parse_early_param
 
 So ia64_mv is initialized before early console
 
 Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
 
 diff --git a/arch/ia64/kernel/machvec.c b/arch/ia64/kernel/machvec.c
 index 13df337..a94feaa 100644
 --- a/arch/ia64/kernel/machvec.c
 +++ b/arch/ia64/kernel/machvec.c
 @@ -14,12 +14,6 @@ struct ia64_machine_vector ia64_mv;
  EXPORT_SYMBOL(ia64_mv);
  
  static __initdata const char *mvec_name;
 -static __init int setup_mvec(char *s)
 -{
 - mvec_name = s;
 - return 0;
 -}
 -early_param(machvec, setup_mvec);
  
  static struct ia64_machine_vector * __init
  lookup_machvec (const char *name)
 @@ -42,6 +36,10 @@ machvec_init (const char *name)
  
   if (!name)
   name = mvec_name ? mvec_name : acpi_get_sysname();

I think that mvec_name can be disposed of all together as
its only used by the line above and setup_mvec(), which in
turn is only used by early_param. I got rid of mvec_name in
my incantation of this patch, and it seemed to work quite well.

 +
 + if (!mvec_name)
 + mvec_name = name;
 +
   mv = lookup_machvec(name);
   if (!mv)
   panic(generic kernel failed to find machine vector for
 diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
 index cf06fe7..b06d7b7 100644
 --- a/arch/ia64/kernel/setup.c
 +++ b/arch/ia64/kernel/setup.c
 @@ -481,6 +481,9 @@ int __init reserve_elfcorehdr(unsigned long *start, 
 unsigned long *end)
  void __init
  setup_arch (char **cmdline_p)
  {
 +#ifdef CONFIG_IA64_GENERIC
 + char *mvstr;
 +#endif
   unw_init();
  
   ia64_patch_vtop((u64) __start___vtop_patchlist, (u64) 
 __end___vtop_patchlist);
 @@ -491,12 +494,15 @@ setup_arch (char **cmdline_p)
   efi_init();
   io_port_init();
  
 - parse_early_param();
 -
  #ifdef CONFIG_IA64_GENERIC
 - machvec_init(NULL);
 + mvstr = strstr(*cmd_line_p, machvec=)
 + if (mvstr)
 + mvstr = strchr(mvstr, '=') + 1;
 + machvec_init(mvstr);
  #endif

Do you need to copy and truncate mvstr on ' ' in the case
that machvec= isn't the last argument on the command line?
I did this in my patch, though I didn't test to see if
it was uneccessary.


  
 + parse_early_param();
 +
   if (early_console_setup(*cmdline_p) == 0)
   mark_bsp_online();
  
 
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-ia64 in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kdump/kexec: calculate note size at compile time

[Horms]

On Wed, Mar 28, 2007 at 12:13:53PM +0530, Vivek Goyal wrote:
> On Wed, Mar 28, 2007 at 03:18:58PM +0900, Simon Horman wrote:
> > Currently the size of the per-cpu region reserved to save crash
> > notes is set by the per-architecture value MAX_NOTE_BYTES. Which
> > in turn is currently set to 1024 on all supported architectures.
> > 
> > While testing ia64 I recently discovered that this value is
> > in fact too small. The particular setup I was using actually
> > needs 1172 bytes. This lead to very tedious failure mode
> > where the tail of one elf note would overwrite the head of 
> > another if they ended up being alocated sequentially by kmalloc,
> > which was often the case.
> > 
> > It seems to me that a far better approach is to caclculate the size
> > that the area needs to be. This patch does just that.
> > 
> > If a simpler stop-gap patch for ia64 to be squeezed into 2.6.21(.X) 
> > is needed then this should be as easy as making MAX_NOTE_BYTES
> > larger in arch/asm-ia64/kexec.h. Perhaps 2048 would be a good choice.
> > However, I think that the approach in this patch is a much more robust idea.
> > 
> 
> Makes sense to me. Calculating the size based on elf_prstatus is better
> than hardcoding it to some value.
> 
> A minor query is inlined below.
> 
> [..]
> > ===
> > --- linux-2.6.orig/include/linux/kexec.h2007-03-28 09:42:14.0 
> > +0900
> > +++ linux-2.6/include/linux/kexec.h 2007-03-28 12:32:50.0 +0900
> > @@ -7,6 +7,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > 
> >  /* Verify architecture specific macros are defined */
> > @@ -31,6 +33,13 @@
> >  #error KEXEC_ARCH not defined
> >  #endif
> > 
> > +#define KEXEC_NOTE_NAME "CORE"
> > +#define KEXEC_NOTE_HEAD_BYTES ALIGN(sizeof(struct elf_note), 4)
> > +#define KEXEC_NOTE_NAME_BYTES ALIGN(strlen(KEXEC_NOTE_NAME) + 1, 4)
> > +#define KEXEC_NOTE_BODY_BYTES ALIGN(sizeof(struct elf_prstatus), 4)

DESC is probably a better name that BODY here, I meant to update
that before posting. An updated version is below.

> > +#define KEXEC_NOTE_BYTES ( (KEXEC_NOTE_HEAD_BYTES * 2) + \
> 
> Why are we multiplying KEXEC_NOTE_HEAD_BYTES with 2?

The way that the note merging code works in vmcore it assumes that
the area is a list of notes. And there is a terminating note that
has all the header values set to 0, and nothing else. So the time 2
is for the space to store the terminating note.

This structure isn't entirely neccessary, and if we were to modify the
mergeing code in vmcore (which runs in the second kernel) it could be
changed.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

[PATCH] kdump/kexec: calculate note size at compile time

Currently the size of the per-cpu region reserved to save crash
notes is set by the per-architecture value MAX_NOTE_BYTES. Which
in turn is currently set to 1024 on all supported architectures.

While testing ia64 I recently discovered that this value is
in fact too small. The particular setup I was using actually
needs 1172 bytes. This lead to very tedious failure mode
where the tail of one elf note would overwrite the head of 
another if they ended up being alocated sequentially by kmalloc,
which was often the case.

It seems to me that a far better approach is to caclculate the size
that the area needs to be. This patch does just that.

If a simpler stop-gap patch for ia64 to be squeezed into 2.6.21(.X) 
is needed then this should be as easy as making MAX_NOTE_BYTES
larger in arch/asm-ia64/kexec.h. Perhaps 2048 would be a good choice.
However, I think that the approach in this patch is a much more robust idea.

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

 include/asm-arm/kexec.h |2 --
 include/asm-i386/kexec.h|2 --
 include/asm-ia64/kexec.h|2 --
 include/asm-mips/kexec.h|2 --
 include/asm-powerpc/kexec.h |2 --
 include/asm-s390/kexec.h|2 --
 include/asm-sh/kexec.h  |2 --
 include/asm-x86_64/kexec.h  |2 --
 include/linux/kexec.h   |   11 ++-
 9 files changed, 10 insertions(+), 17 deletions(-)

Index: linux-2.6/include/asm-ia64/kexec.h
===
--- linux-2.6.orig/include/asm-ia64/kexec.h 2007-03-28 15:57:15.0 
+0900
+++ linux-2.6/include/asm-ia64/kexec.h  2007-03-28 15:57:17.0 +0900
@@ -14,8 +14,6 @@
 /* The native architecture */
 #define KEXEC_ARCH KEXEC_ARCH_IA_64
 
-#define MAX_NOTE_BYTES 1024
-
 #define kexec_flush_icache_page(page) do { \
 unsigned long page_addr = (unsigned long)page_add

Re: [PATCH] kdump/kexec: calculate note size at compile time

[Horms]

On Wed, Mar 28, 2007 at 12:13:53PM +0530, Vivek Goyal wrote:
 On Wed, Mar 28, 2007 at 03:18:58PM +0900, Simon Horman wrote:
  Currently the size of the per-cpu region reserved to save crash
  notes is set by the per-architecture value MAX_NOTE_BYTES. Which
  in turn is currently set to 1024 on all supported architectures.
  
  While testing ia64 I recently discovered that this value is
  in fact too small. The particular setup I was using actually
  needs 1172 bytes. This lead to very tedious failure mode
  where the tail of one elf note would overwrite the head of 
  another if they ended up being alocated sequentially by kmalloc,
  which was often the case.
  
  It seems to me that a far better approach is to caclculate the size
  that the area needs to be. This patch does just that.
  
  If a simpler stop-gap patch for ia64 to be squeezed into 2.6.21(.X) 
  is needed then this should be as easy as making MAX_NOTE_BYTES
  larger in arch/asm-ia64/kexec.h. Perhaps 2048 would be a good choice.
  However, I think that the approach in this patch is a much more robust idea.
  
 
 Makes sense to me. Calculating the size based on elf_prstatus is better
 than hardcoding it to some value.
 
 A minor query is inlined below.
 
 [..]
  ===
  --- linux-2.6.orig/include/linux/kexec.h2007-03-28 09:42:14.0 
  +0900
  +++ linux-2.6/include/linux/kexec.h 2007-03-28 12:32:50.0 +0900
  @@ -7,6 +7,8 @@
   #include linux/linkage.h
   #include linux/compat.h
   #include linux/ioport.h
  +#include linux/elfcore.h
  +#include linux/elf.h
   #include asm/kexec.h
  
   /* Verify architecture specific macros are defined */
  @@ -31,6 +33,13 @@
   #error KEXEC_ARCH not defined
   #endif
  
  +#define KEXEC_NOTE_NAME CORE
  +#define KEXEC_NOTE_HEAD_BYTES ALIGN(sizeof(struct elf_note), 4)
  +#define KEXEC_NOTE_NAME_BYTES ALIGN(strlen(KEXEC_NOTE_NAME) + 1, 4)
  +#define KEXEC_NOTE_BODY_BYTES ALIGN(sizeof(struct elf_prstatus), 4)

DESC is probably a better name that BODY here, I meant to update
that before posting. An updated version is below.

  +#define KEXEC_NOTE_BYTES ( (KEXEC_NOTE_HEAD_BYTES * 2) + \
 
 Why are we multiplying KEXEC_NOTE_HEAD_BYTES with 2?

The way that the note merging code works in vmcore it assumes that
the area is a list of notes. And there is a terminating note that
has all the header values set to 0, and nothing else. So the time 2
is for the space to store the terminating note.

This structure isn't entirely neccessary, and if we were to modify the
mergeing code in vmcore (which runs in the second kernel) it could be
changed.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

[PATCH] kdump/kexec: calculate note size at compile time

Currently the size of the per-cpu region reserved to save crash
notes is set by the per-architecture value MAX_NOTE_BYTES. Which
in turn is currently set to 1024 on all supported architectures.

While testing ia64 I recently discovered that this value is
in fact too small. The particular setup I was using actually
needs 1172 bytes. This lead to very tedious failure mode
where the tail of one elf note would overwrite the head of 
another if they ended up being alocated sequentially by kmalloc,
which was often the case.

It seems to me that a far better approach is to caclculate the size
that the area needs to be. This patch does just that.

If a simpler stop-gap patch for ia64 to be squeezed into 2.6.21(.X) 
is needed then this should be as easy as making MAX_NOTE_BYTES
larger in arch/asm-ia64/kexec.h. Perhaps 2048 would be a good choice.
However, I think that the approach in this patch is a much more robust idea.

Signed-off-by: Simon Horman [EMAIL PROTECTED]

 include/asm-arm/kexec.h |2 --
 include/asm-i386/kexec.h|2 --
 include/asm-ia64/kexec.h|2 --
 include/asm-mips/kexec.h|2 --
 include/asm-powerpc/kexec.h |2 --
 include/asm-s390/kexec.h|2 --
 include/asm-sh/kexec.h  |2 --
 include/asm-x86_64/kexec.h  |2 --
 include/linux/kexec.h   |   11 ++-
 9 files changed, 10 insertions(+), 17 deletions(-)

Index: linux-2.6/include/asm-ia64/kexec.h
===
--- linux-2.6.orig/include/asm-ia64/kexec.h 2007-03-28 15:57:15.0 
+0900
+++ linux-2.6/include/asm-ia64/kexec.h  2007-03-28 15:57:17.0 +0900
@@ -14,8 +14,6 @@
 /* The native architecture */
 #define KEXEC_ARCH KEXEC_ARCH_IA_64
 
-#define MAX_NOTE_BYTES 1024
-
 #define kexec_flush_icache_page(page) do { \
 unsigned long page_addr = (unsigned long)page_address(page); \
 flush_icache_range(page_addr, page_addr + PAGE_SIZE); \
Index: linux-2.6/include/linux/kexec.h
===
--- linux-2.6.orig/include/linux/kexec.h2007-03-28 15:57:15.0 
+0900
+++ linux-2.6/include/linux/kexec.h

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Fri, Mar 16, 2007 at 07:17:43AM +, Ian Campbell wrote:
> On Fri, 2007-03-16 at 08:48 +0900, Horms wrote:
> > > > 
> > > > Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> > > > 
> > > > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> > > > index d960507..523e109 100644
> > > > --- a/fs/proc/vmcore.c
> > > > +++ b/fs/proc/vmcore.c
> > > > @@ -514,7 +514,7 @@ static int __init parse_crash_elf64_headers(void)
> > > > /* Do some basic Verification. */
> > > > if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
> > > > (ehdr.e_type != ET_CORE) ||
> > > > -   !elf_check_arch() ||
> > > > +   !vmcore_elf_check_arch() ||
> > > > ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
> > > > ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
> > > > ehdr.e_version != EV_CURRENT ||
> > > > diff --git a/include/asm-i386/kexec.h b/include/asm-i386/kexec.h
> > > > index 4dfc9f5..c76737e 100644
> > > > --- a/include/asm-i386/kexec.h
> > > > +++ b/include/asm-i386/kexec.h
> > > > @@ -47,6 +47,9 @@
> > > >  /* The native architecture */
> > > >  #define KEXEC_ARCH KEXEC_ARCH_386
> > > > 
> > > > +/* We can also handle crash dumps from 64 bit kernel. */
> > > > +#define vmcore_elf_check_arch_cross(x) ((x)->e_machine == EM_X86_64)
> > > > +
> > > 
> > > Ideal place for this probably should have been arch dependent crash_dump.h
> > > file. But we don't have one and no point introducing one just for this 
> > > macro.
> > > 
> > > This change looks good to me.
> > 
> > Won't the above change break non i386 archtectures as
> > vmcore_elf_check_arch_cross isn't defined for them?
> 
> No, because of this hunk:

Thanks, silly me :(

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Fri, Mar 16, 2007 at 08:52:30AM +0530, Vivek Goyal wrote:
> On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
> > On 3/16/07, Horms <[EMAIL PROTECTED]> wrote:
> > >On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> > >> On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> > >> > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > >> > > > > But I think changing this macro might run into issues. It is
> > >> > > > > being used at few places in kernel, for example while loading
> > >> > > > > module. This will essentially mean that we allow loading 64bit
> > >> > > > > x86_64 modules on 32bit i386 systems?
> > >> >
> > >> > Yes, not sure how I missed that fact...
> > >> >
> > >> > > Kexec will also not allow loading an x86_64 kernel on a 32bit 
> > >machine.
> > >> >
> > >> > For crash kernel only or for regular kexec too?
> > >> >
> > >>
> > >> I think for both. One of the possible reasons I think is that one never
> > >> knows is underlying machine has got 64bit extensions or not. So even if
> > >> we load the kernel it will never boot. Secondly, we might not be able to
> > >> handle 64bit address in 32bit kernel/user space?
> > >
> > >Perhaps I am miss-understanding what you are saying, but I do
> > >recally kexecing from 32->64 and 64->32 bit kernels on x86_64 hardware.
> > >I can run these checks again if it helps.
> > 
> 
> I stand corrected. I can kexec an bzImage 32->64bit. That's a different
> thing that it ran into some initrd issues later but fundamentally kexec
> could load 64bit kernel bzImage and do the successful transition.
> 
> So it will now be left to the user. If he tries to kexec to a 64bit kernel
> on a machine not supporting 32bit extensions, then kexec will not give
> any advance warning.

I feel comfortable with that. Well for now anyway.
But I think that Magnus has other ideas.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Fri, Mar 16, 2007 at 07:17:43AM +, Ian Campbell wrote:
 On Fri, 2007-03-16 at 08:48 +0900, Horms wrote:

Signed-off-by: Ian Campbell [EMAIL PROTECTED]

diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index d960507..523e109 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -514,7 +514,7 @@ static int __init parse_crash_elf64_headers(void)
/* Do some basic Verification. */
if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
(ehdr.e_type != ET_CORE) ||
-   !elf_check_arch(ehdr) ||
+   !vmcore_elf_check_arch(ehdr) ||
ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
ehdr.e_version != EV_CURRENT ||
diff --git a/include/asm-i386/kexec.h b/include/asm-i386/kexec.h
index 4dfc9f5..c76737e 100644
--- a/include/asm-i386/kexec.h
+++ b/include/asm-i386/kexec.h
@@ -47,6 +47,9 @@
 /* The native architecture */
 #define KEXEC_ARCH KEXEC_ARCH_386

+/* We can also handle crash dumps from 64 bit kernel. */
+#define vmcore_elf_check_arch_cross(x) ((x)-e_machine == EM_X86_64)
+
   
   Ideal place for this probably should have been arch dependent crash_dump.h
   file. But we don't have one and no point introducing one just for this 
   macro.
   
   This change looks good to me.
  
  Won't the above change break non i386 archtectures as
  vmcore_elf_check_arch_cross isn't defined for them?
 
 No, because of this hunk:

Thanks, silly me :(

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Fri, Mar 16, 2007 at 08:52:30AM +0530, Vivek Goyal wrote:
 On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
  On 3/16/07, Horms [EMAIL PROTECTED] wrote:
  On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
   On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
   But I think changing this macro might run into issues. It is
   being used at few places in kernel, for example while loading
   module. This will essentially mean that we allow loading 64bit
   x86_64 modules on 32bit i386 systems?
   
Yes, not sure how I missed that fact...
   
 Kexec will also not allow loading an x86_64 kernel on a 32bit 
  machine.
   
For crash kernel only or for regular kexec too?
   
  
   I think for both. One of the possible reasons I think is that one never
   knows is underlying machine has got 64bit extensions or not. So even if
   we load the kernel it will never boot. Secondly, we might not be able to
   handle 64bit address in 32bit kernel/user space?
  
  Perhaps I am miss-understanding what you are saying, but I do
  recally kexecing from 32-64 and 64-32 bit kernels on x86_64 hardware.
  I can run these checks again if it helps.
  
 
 I stand corrected. I can kexec an bzImage 32-64bit. That's a different
 thing that it ran into some initrd issues later but fundamentally kexec
 could load 64bit kernel bzImage and do the successful transition.
 
 So it will now be left to the user. If he tries to kexec to a 64bit kernel
 on a machine not supporting 32bit extensions, then kexec will not give
 any advance warning.

I feel comfortable with that. Well for now anyway.
But I think that Magnus has other ideas.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Thu, Mar 15, 2007 at 01:42:39PM +, Ian Campbell wrote:
> On Thu, 2007-03-15 at 18:56 +0530, Vivek Goyal wrote:
> > 
> > Ideal place for this probably should have been arch dependent
> > crash_dump.h file. But we don't have one and no point introducing one
> > just for this  macro.
> 
> Agreed.
> 
> > This change looks good to me. 
> 
> Is there a kdump tree which you'll apply to or shall I resend CCing
> apkm? (I'll add an Acked-by if that's ok).

There isn't a kexec tree at this time (though I am happy to entertain
creating one). For now most patches go in either through Andrew or the
relevant architecture maintainers.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > > > > But I think changing this macro might run into issues. It is
> > > > > being used at few places in kernel, for example while loading
> > > > > module. This will essentially mean that we allow loading 64bit
> > > > > x86_64 modules on 32bit i386 systems?
> > 
> > Yes, not sure how I missed that fact...
> > 
> > > Kexec will also not allow loading an x86_64 kernel on a 32bit machine.
> > 
> > For crash kernel only or for regular kexec too?
> > 
> 
> I think for both. One of the possible reasons I think is that one never
> knows is underlying machine has got 64bit extensions or not. So even if
> we load the kernel it will never boot. Secondly, we might not be able to
> handle 64bit address in 32bit kernel/user space?

Perhaps I am miss-understanding what you are saying, but I do
recally kexecing from 32->64 and 64->32 bit kernels on x86_64 hardware.
I can run these checks again if it helps.

> > > So how about something like vmcore_elf_allowed_cross_arch()? Vmcore
> > > code can continue to check elf_check_arch() and if that fails it can
> > > invoke vmcore_elf_allowed_cross_arch() to find out what cross arch are
> > > allowed for vmcore. 
> > 
> > Something like this?
> > 
> > Ian.
> > 
> > ---  
> > 
> > Allow i386 crash kernels to handle x86_64 dumps.
> > 
> > The specific case I am encountering is kdump under Xen with a 64 bit
> > hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit
> > due to the hypervisor but the dump kernel is 32 bit in for maximum
> > compatibility.
> > 
> > It's possibly less likely to be useful in a purely native scenario but
> > I see no reason to disallow it.
> > 
> > Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> > 
> > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> > index d960507..523e109 100644
> > --- a/fs/proc/vmcore.c
> > +++ b/fs/proc/vmcore.c
> > @@ -514,7 +514,7 @@ static int __init parse_crash_elf64_headers(void)
> > /* Do some basic Verification. */
> > if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
> > (ehdr.e_type != ET_CORE) ||
> > -   !elf_check_arch() ||
> > +   !vmcore_elf_check_arch() ||
> > ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
> > ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
> > ehdr.e_version != EV_CURRENT ||
> > diff --git a/include/asm-i386/kexec.h b/include/asm-i386/kexec.h
> > index 4dfc9f5..c76737e 100644
> > --- a/include/asm-i386/kexec.h
> > +++ b/include/asm-i386/kexec.h
> > @@ -47,6 +47,9 @@
> >  /* The native architecture */
> >  #define KEXEC_ARCH KEXEC_ARCH_386
> > 
> > +/* We can also handle crash dumps from 64 bit kernel. */
> > +#define vmcore_elf_check_arch_cross(x) ((x)->e_machine == EM_X86_64)
> > +
> 
> Ideal place for this probably should have been arch dependent crash_dump.h
> file. But we don't have one and no point introducing one just for this 
> macro.
> 
> This change looks good to me.

Won't the above change break non i386 archtectures as
vmcore_elf_check_arch_cross isn't defined for them?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Thu, Mar 15, 2007 at 11:17:26AM +0530, Vivek Goyal wrote:
> On Thu, Mar 15, 2007 at 02:07:56PM +0900, Horms wrote:
> > On Thu, Mar 15, 2007 at 10:25:36AM +0530, Vivek Goyal wrote:
> > > On Thu, Mar 15, 2007 at 10:46:38AM +0900, Horms wrote:
> > > > On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
> > > > > The specific case I am encountering is kdump under Xen with a 64 bit
> > > > > hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit 
> > > > > due
> > > > > to the hypervisor but the dump kernel is 32 bit to match the domain 0
> > > > > kernel.
> > > > > 
> > > > > It's possibly less likely to be useful in a purely native scenario 
> > > > > but I
> > > > > see no reason to disallow it.
> > > > 
> > > > For native Linux, would this cover the case where the pre-crash kernel
> > > > is 64bit and the crashdump (post-crash) kernel is 32bit?
> > > > 
> > > 
> > > I think so. Though I have never tried this.
> > > 
> > > > > Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> > > > > 
> > > > > --- pristine-linux-2.6.18/include/asm-i386/elf.h  2006-09-20 
> > > > > 04:42:06.0 +0100
> > > > > +++ linux-2.6.18-xen/include/asm-i386/elf.h   2007-03-14 
> > > > > 16:42:30.0 +
> > > > > @@ -36,7 +36,7 @@
> > > > >   * This is used to ensure we don't load something for the wrong 
> > > > > architecture.
> > > > >   */
> > > > >  #define elf_check_arch(x) \
> > > > > - (((x)->e_machine == EM_386) || ((x)->e_machine == EM_486))
> > > > > + (((x)->e_machine == EM_386) || ((x)->e_machine == EM_486) || 
> > > > > ((x)->e_machine == EM_X86_64))
> > > 
> > > But I think changing this macro might run into issues. It is being used at
> > > few places in kernel, for example while loading module. This will 
> > > essentially
> > > mean that we allow loading 64bit x86_64 modules on 32bit i386 systems?
> > > 
> > > Similarly, load_elf_interp() is using it, again will we allow loading a 
> > > interp written for X86_64 on a 32bit i386 machine?
> > > 
> > > Should we create a separate macro something like elf_check_allowed_arch(),
> > > to take care of such corner cases?
> > 
> > That sounds reasonable to me. Though perhaps it could just be
> > kexec_elf_check_arch() for now, as I don't think there are any
> > other consumers of it.
> 
> Kexec will also not allow loading an x86_64 kernel on a 32bit machine.
> So how about something like vmcore_elf_allowed_cross_arch()? Vmcore code
> can continue to check elf_check_arch() and if that fails it can invoke
> vmcore_elf_allowed_cross_arch() to find out what cross arch are allowed
> for vmcore.

That sounds a little messy, though perhaps it is a good solution anyway.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Thu, Mar 15, 2007 at 11:17:26AM +0530, Vivek Goyal wrote:
 On Thu, Mar 15, 2007 at 02:07:56PM +0900, Horms wrote:
  On Thu, Mar 15, 2007 at 10:25:36AM +0530, Vivek Goyal wrote:
   On Thu, Mar 15, 2007 at 10:46:38AM +0900, Horms wrote:
On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
 The specific case I am encountering is kdump under Xen with a 64 bit
 hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit 
 due
 to the hypervisor but the dump kernel is 32 bit to match the domain 0
 kernel.
 
 It's possibly less likely to be useful in a purely native scenario 
 but I
 see no reason to disallow it.

For native Linux, would this cover the case where the pre-crash kernel
is 64bit and the crashdump (post-crash) kernel is 32bit?

   
   I think so. Though I have never tried this.
   
 Signed-off-by: Ian Campbell [EMAIL PROTECTED]
 
 --- pristine-linux-2.6.18/include/asm-i386/elf.h  2006-09-20 
 04:42:06.0 +0100
 +++ linux-2.6.18-xen/include/asm-i386/elf.h   2007-03-14 
 16:42:30.0 +
 @@ -36,7 +36,7 @@
   * This is used to ensure we don't load something for the wrong 
 architecture.
   */
  #define elf_check_arch(x) \
 - (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486))
 + (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486) || 
 ((x)-e_machine == EM_X86_64))
   
   But I think changing this macro might run into issues. It is being used at
   few places in kernel, for example while loading module. This will 
   essentially
   mean that we allow loading 64bit x86_64 modules on 32bit i386 systems?
   
   Similarly, load_elf_interp() is using it, again will we allow loading a 
   interp written for X86_64 on a 32bit i386 machine?
   
   Should we create a separate macro something like elf_check_allowed_arch(),
   to take care of such corner cases?
  
  That sounds reasonable to me. Though perhaps it could just be
  kexec_elf_check_arch() for now, as I don't think there are any
  other consumers of it.
 
 Kexec will also not allow loading an x86_64 kernel on a 32bit machine.
 So how about something like vmcore_elf_allowed_cross_arch()? Vmcore code
 can continue to check elf_check_arch() and if that fails it can invoke
 vmcore_elf_allowed_cross_arch() to find out what cross arch are allowed
 for vmcore.

That sounds a little messy, though perhaps it is a good solution anyway.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Thu, Mar 15, 2007 at 01:42:39PM +, Ian Campbell wrote:
 On Thu, 2007-03-15 at 18:56 +0530, Vivek Goyal wrote:
  
  Ideal place for this probably should have been arch dependent
  crash_dump.h file. But we don't have one and no point introducing one
  just for this  macro.
 
 Agreed.
 
  This change looks good to me. 
 
 Is there a kdump tree which you'll apply to or shall I resend CCing
 apkm? (I'll add an Acked-by if that's ok).

There isn't a kexec tree at this time (though I am happy to entertain
creating one). For now most patches go in either through Andrew or the
relevant architecture maintainers.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
 On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
  On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
 But I think changing this macro might run into issues. It is
 being used at few places in kernel, for example while loading
 module. This will essentially mean that we allow loading 64bit
 x86_64 modules on 32bit i386 systems?
  
  Yes, not sure how I missed that fact...
  
   Kexec will also not allow loading an x86_64 kernel on a 32bit machine.
  
  For crash kernel only or for regular kexec too?
  
 
 I think for both. One of the possible reasons I think is that one never
 knows is underlying machine has got 64bit extensions or not. So even if
 we load the kernel it will never boot. Secondly, we might not be able to
 handle 64bit address in 32bit kernel/user space?

Perhaps I am miss-understanding what you are saying, but I do
recally kexecing from 32-64 and 64-32 bit kernels on x86_64 hardware.
I can run these checks again if it helps.

   So how about something like vmcore_elf_allowed_cross_arch()? Vmcore
   code can continue to check elf_check_arch() and if that fails it can
   invoke vmcore_elf_allowed_cross_arch() to find out what cross arch are
   allowed for vmcore. 
  
  Something like this?
  
  Ian.
  
  ---  
  
  Allow i386 crash kernels to handle x86_64 dumps.
  
  The specific case I am encountering is kdump under Xen with a 64 bit
  hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit
  due to the hypervisor but the dump kernel is 32 bit in for maximum
  compatibility.
  
  It's possibly less likely to be useful in a purely native scenario but
  I see no reason to disallow it.
  
  Signed-off-by: Ian Campbell [EMAIL PROTECTED]
  
  diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
  index d960507..523e109 100644
  --- a/fs/proc/vmcore.c
  +++ b/fs/proc/vmcore.c
  @@ -514,7 +514,7 @@ static int __init parse_crash_elf64_headers(void)
  /* Do some basic Verification. */
  if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
  (ehdr.e_type != ET_CORE) ||
  -   !elf_check_arch(ehdr) ||
  +   !vmcore_elf_check_arch(ehdr) ||
  ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
  ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
  ehdr.e_version != EV_CURRENT ||
  diff --git a/include/asm-i386/kexec.h b/include/asm-i386/kexec.h
  index 4dfc9f5..c76737e 100644
  --- a/include/asm-i386/kexec.h
  +++ b/include/asm-i386/kexec.h
  @@ -47,6 +47,9 @@
   /* The native architecture */
   #define KEXEC_ARCH KEXEC_ARCH_386
  
  +/* We can also handle crash dumps from 64 bit kernel. */
  +#define vmcore_elf_check_arch_cross(x) ((x)-e_machine == EM_X86_64)
  +
 
 Ideal place for this probably should have been arch dependent crash_dump.h
 file. But we don't have one and no point introducing one just for this 
 macro.
 
 This change looks good to me.

Won't the above change break non i386 archtectures as
vmcore_elf_check_arch_cross isn't defined for them?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Thu, Mar 15, 2007 at 10:25:36AM +0530, Vivek Goyal wrote:
> On Thu, Mar 15, 2007 at 10:46:38AM +0900, Horms wrote:
> > On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
> > > The specific case I am encountering is kdump under Xen with a 64 bit
> > > hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit due
> > > to the hypervisor but the dump kernel is 32 bit to match the domain 0
> > > kernel.
> > > 
> > > It's possibly less likely to be useful in a purely native scenario but I
> > > see no reason to disallow it.
> > 
> > For native Linux, would this cover the case where the pre-crash kernel
> > is 64bit and the crashdump (post-crash) kernel is 32bit?
> > 
> 
> I think so. Though I have never tried this.
> 
> > > Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> > > 
> > > --- pristine-linux-2.6.18/include/asm-i386/elf.h  2006-09-20 
> > > 04:42:06.0 +0100
> > > +++ linux-2.6.18-xen/include/asm-i386/elf.h   2007-03-14 
> > > 16:42:30.0 +
> > > @@ -36,7 +36,7 @@
> > >   * This is used to ensure we don't load something for the wrong 
> > > architecture.
> > >   */
> > >  #define elf_check_arch(x) \
> > > - (((x)->e_machine == EM_386) || ((x)->e_machine == EM_486))
> > > + (((x)->e_machine == EM_386) || ((x)->e_machine == EM_486) || 
> > > ((x)->e_machine == EM_X86_64))
> 
> But I think changing this macro might run into issues. It is being used at
> few places in kernel, for example while loading module. This will essentially
> mean that we allow loading 64bit x86_64 modules on 32bit i386 systems?
> 
> Similarly, load_elf_interp() is using it, again will we allow loading a 
> interp written for X86_64 on a 32bit i386 machine?
> 
> Should we create a separate macro something like elf_check_allowed_arch(),
> to take care of such corner cases?

That sounds reasonable to me. Though perhaps it could just be
kexec_elf_check_arch() for now, as I don't think there are any
other consumers of it.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
> The specific case I am encountering is kdump under Xen with a 64 bit
> hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit due
> to the hypervisor but the dump kernel is 32 bit to match the domain 0
> kernel.
> 
> It's possibly less likely to be useful in a purely native scenario but I
> see no reason to disallow it.

For native Linux, would this cover the case where the pre-crash kernel
is 64bit and the crashdump (post-crash) kernel is 32bit?

> Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> 
> --- pristine-linux-2.6.18/include/asm-i386/elf.h  2006-09-20 
> 04:42:06.0 +0100
> +++ linux-2.6.18-xen/include/asm-i386/elf.h   2007-03-14 16:42:30.0 
> +
> @@ -36,7 +36,7 @@
>   * This is used to ensure we don't load something for the wrong architecture.
>   */
>  #define elf_check_arch(x) \
> - (((x)->e_machine == EM_386) || ((x)->e_machine == EM_486))
> + (((x)->e_machine == EM_386) || ((x)->e_machine == EM_486) || 
> ((x)->e_machine == EM_X86_64))

I think it would be a bit nicer if this was < 80col wide,
though obviously this doesn't affect the funtionality.

diff --git a/include/asm-i386/elf.h b/include/asm-i386/elf.h
index 8d33c9b..cd894dd 100644
--- a/include/asm-i386/elf.h
+++ b/include/asm-i386/elf.h
@@ -36,7 +36,8 @@ typedef struct user_fxsr_struct elf_fpxregset_t;
  * This is used to ensure we don't load something for the wrong architecture.
  */
 #define elf_check_arch(x) \
-   (((x)->e_machine == EM_386) || ((x)->e_machine == EM_486))
+   (((x)->e_machine == EM_386) || ((x)->e_machine == EM_486) || \
+((x)->e_machine == EM_X86_64))
 
 /*
  * These are used to set parameters in the core dumps.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
 The specific case I am encountering is kdump under Xen with a 64 bit
 hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit due
 to the hypervisor but the dump kernel is 32 bit to match the domain 0
 kernel.
 
 It's possibly less likely to be useful in a purely native scenario but I
 see no reason to disallow it.

For native Linux, would this cover the case where the pre-crash kernel
is 64bit and the crashdump (post-crash) kernel is 32bit?

 Signed-off-by: Ian Campbell [EMAIL PROTECTED]
 
 --- pristine-linux-2.6.18/include/asm-i386/elf.h  2006-09-20 
 04:42:06.0 +0100
 +++ linux-2.6.18-xen/include/asm-i386/elf.h   2007-03-14 16:42:30.0 
 +
 @@ -36,7 +36,7 @@
   * This is used to ensure we don't load something for the wrong architecture.
   */
  #define elf_check_arch(x) \
 - (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486))
 + (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486) || 
 ((x)-e_machine == EM_X86_64))

I think it would be a bit nicer if this was  80col wide,
though obviously this doesn't affect the funtionality.

diff --git a/include/asm-i386/elf.h b/include/asm-i386/elf.h
index 8d33c9b..cd894dd 100644
--- a/include/asm-i386/elf.h
+++ b/include/asm-i386/elf.h
@@ -36,7 +36,8 @@ typedef struct user_fxsr_struct elf_fpxregset_t;
  * This is used to ensure we don't load something for the wrong architecture.
  */
 #define elf_check_arch(x) \
-   (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486))
+   (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486) || \
+((x)-e_machine == EM_X86_64))
 
 /*
  * These are used to set parameters in the core dumps.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Horms]

On Thu, Mar 15, 2007 at 10:25:36AM +0530, Vivek Goyal wrote:
 On Thu, Mar 15, 2007 at 10:46:38AM +0900, Horms wrote:
  On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
   The specific case I am encountering is kdump under Xen with a 64 bit
   hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit due
   to the hypervisor but the dump kernel is 32 bit to match the domain 0
   kernel.
   
   It's possibly less likely to be useful in a purely native scenario but I
   see no reason to disallow it.
  
  For native Linux, would this cover the case where the pre-crash kernel
  is 64bit and the crashdump (post-crash) kernel is 32bit?
  
 
 I think so. Though I have never tried this.
 
   Signed-off-by: Ian Campbell [EMAIL PROTECTED]
   
   --- pristine-linux-2.6.18/include/asm-i386/elf.h  2006-09-20 
   04:42:06.0 +0100
   +++ linux-2.6.18-xen/include/asm-i386/elf.h   2007-03-14 
   16:42:30.0 +
   @@ -36,7 +36,7 @@
 * This is used to ensure we don't load something for the wrong 
   architecture.
 */
#define elf_check_arch(x) \
   - (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486))
   + (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486) || 
   ((x)-e_machine == EM_X86_64))
 
 But I think changing this macro might run into issues. It is being used at
 few places in kernel, for example while loading module. This will essentially
 mean that we allow loading 64bit x86_64 modules on 32bit i386 systems?
 
 Similarly, load_elf_interp() is using it, again will we allow loading a 
 interp written for X86_64 on a 32bit i386 machine?
 
 Should we create a separate macro something like elf_check_allowed_arch(),
 to take care of such corner cases?

That sounds reasonable to me. Though perhaps it could just be
kexec_elf_check_arch() for now, as I don't think there are any
other consumers of it.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul

[Horms]

On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> With the advent of kdump, the assumption that the boot CPU when running
> an UP kernel is always the CPU with a hardware ID of 0 (usually referred
> to as BSP on some architectures) does not hold true anymore. The reason
> being that the dump capture kernel boots on the crashed CPU (the CPU
> that invoked crash_kexec).
> 
> As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> systems (see "linux/smp.h") is not correct.
> 
> This patch-set does the following:
> 
> 1- Remove hardcoding of hard_smp_processor_id on UP systems.
> 
> 2- Ask the hardware when possible to obtain the hardware processor id on
> i386, x86_64, and ia64, independently of whether CONFIG_SMP is set or
> not.
> 
> 3- Move definition of hard_smp_processor_id for the UP case to asm/smp.h
> on alpha, m32r, powerpc, s390, sparc, sparc64, and um architectures. I
> guess that hardware features could be used to implement
> hard_smp_processor_id even in the UP case, but since I am not an expert
> in this architectures I just move the definition.
> 
> The patches have been tested on i386, x86_64, and ia64.

Hi Fernando,

These patches seem find to me. Tested on ia64 (Tiger2)

Acked: Simon Horman <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul

[Horms]

On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
 With the advent of kdump, the assumption that the boot CPU when running
 an UP kernel is always the CPU with a hardware ID of 0 (usually referred
 to as BSP on some architectures) does not hold true anymore. The reason
 being that the dump capture kernel boots on the crashed CPU (the CPU
 that invoked crash_kexec).
 
 As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
 systems (see linux/smp.h) is not correct.
 
 This patch-set does the following:
 
 1- Remove hardcoding of hard_smp_processor_id on UP systems.
 
 2- Ask the hardware when possible to obtain the hardware processor id on
 i386, x86_64, and ia64, independently of whether CONFIG_SMP is set or
 not.
 
 3- Move definition of hard_smp_processor_id for the UP case to asm/smp.h
 on alpha, m32r, powerpc, s390, sparc, sparc64, and um architectures. I
 guess that hardware features could be used to implement
 hard_smp_processor_id even in the UP case, but since I am not an expert
 in this architectures I just move the definition.
 
 The patches have been tested on i386, x86_64, and ia64.

Hi Fernando,

These patches seem find to me. Tested on ia64 (Tiger2)

Acked: Simon Horman [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH 1/1] - platform_kernel_launch_event is noop on generic kernel

[Horms]

On Wed, Feb 28, 2007 at 01:45:17PM -0600, John Keller wrote:
> Add a missing #define for the platform_kernel_launch_event.
> Without this fix, a call to platform_kernel_launch_event()
> becomes a noop on generic kernels. SN systems require this
> fix to successfully kdump/kexec from certain hardware errors.
>
> Signed-off-by: John Keller <[EMAIL PROTECTED]>

I made a similar change when porting to xen, but I hadn't thought
to see if mainline linux needs it to.

Acked-by: Simon Horman <[EMAIL PROTECTED]>

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH 1/1] - platform_kernel_launch_event is noop on generic kernel

[Horms]

On Wed, Feb 28, 2007 at 01:45:17PM -0600, John Keller wrote:
 Add a missing #define for the platform_kernel_launch_event.
 Without this fix, a call to platform_kernel_launch_event()
 becomes a noop on generic kernels. SN systems require this
 fix to successfully kdump/kexec from certain hardware errors.

 Signed-off-by: John Keller [EMAIL PROTECTED]

I made a similar change when porting to xen, but I hadn't thought
to see if mainline linux needs it to.

Acked-by: Simon Horman [EMAIL PROTECTED]

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.19.2 1/1] kexec: update IO-APIC dest field to 8-bit for APIC

[Horms]

On Fri, Jan 19, 2007 at 12:12:28PM -0500, Benjamin Romer wrote:
> On the Unisys ES7000/ONE system, we encountered a problem where performing
> a kexec reboot or dump on any cell other than cell 0 causes the system
> timer to stop working, resulting in a hang during timer calibration in the
> new kernel.
> 
> We traced the problem to one line of code in disable_IO_APIC(), which needs
> to restore the timer's IO-APIC configuration before rebooting.  The code is
> currently using the 4-bit physical destination field, rather than using the
> 8-bit logical destination field, and it cuts off the upper 4 bits of the
> timer's APIC ID.  If we change this to use the logical destination field,
> the timer works and we can kexec on the upper cells.  This was tested on
> two different cells (0 and 2) in an ES7000/ONE system.
> 
> For reference, the relevant Intel xAPIC spec is kept at
> ftp://download.intel.com/design/chipsets/e8501/datashts/30962001.pdf,
> specifically on page 334.
> 
> Signed-off-by: Benjamin M Romer <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
> Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
> Cc: Vivek Goyal <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>

Hi,

I don't seem to be able to get this patch to apply 
(to the current Linus tree) due to some whitespace issues
in the 6th Fragment.

This is resolved in the version of the patch below.

*** Only whitespace changes + rediff ***

 arch/x86_64/kernel/io_apic.c |   24 +++-
 include/asm-x86_64/io_apic.h |   14 ++
 2 files changed, 13 insertions(+), 25 deletions(-)

Index: linux-2.6/arch/x86_64/kernel/io_apic.c
===
--- linux-2.6.orig/arch/x86_64/kernel/io_apic.c 2007-02-14 15:17:18.0 
+0900
+++ linux-2.6/arch/x86_64/kernel/io_apic.c  2007-02-14 15:19:02.0 
+0900
@@ -831,7 +831,7 @@
entry.delivery_mode = INT_DELIVERY_MODE;
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* enable IRQ */
-   entry.dest.logical.logical_dest = cpu_mask_to_apicid(TARGET_CPUS);
+   entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
 
entry.trigger = irq_trigger(idx);
entry.polarity = irq_polarity(idx);
@@ -839,7 +839,7 @@
if (irq_trigger(idx)) {
entry.trigger = 1;
entry.mask = 1;
-   entry.dest.logical.logical_dest = 
cpu_mask_to_apicid(TARGET_CPUS);
+   entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
}
 
if (!apic && !IO_APIC_IRQ(irq))
@@ -851,7 +851,7 @@
if (vector < 0)
return;
 
-   entry.dest.logical.logical_dest = cpu_mask_to_apicid(mask);
+   entry.dest = cpu_mask_to_apicid(mask);
entry.vector = vector;
 
ioapic_register_intr(irq, vector, IOAPIC_AUTO);
@@ -920,7 +920,7 @@
 */
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* unmask IRQ now */
-   entry.dest.logical.logical_dest = cpu_mask_to_apicid(TARGET_CPUS);
+   entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
entry.delivery_mode = INT_DELIVERY_MODE;
entry.polarity = 0;
entry.trigger = 0;
@@ -1020,18 +1020,17 @@
 
printk(KERN_DEBUG " IRQ redirection table:\n");
 
-   printk(KERN_DEBUG " NR Log Phy Mask Trig IRR Pol"
- " Stat Dest Deli Vect:   \n");
+   printk(KERN_DEBUG " NR Dst Mask Trig IRR Pol"
+ " Stat Dmod Deli Vect:   \n");
 
for (i = 0; i <= reg_01.bits.entries; i++) {
struct IO_APIC_route_entry entry;
 
entry = ioapic_read_entry(apic, i);
 
-   printk(KERN_DEBUG " %02x %03X %02X  ",
+   printk(KERN_DEBUG " %02x %03X ",
i,
-   entry.dest.logical.logical_dest,
-   entry.dest.physical.physical_dest
+   entry.dest
);
 
printk("%1d%1d%1d   %1d   %1d%1d%1d%02X\n",
@@ -1293,8 +1292,7 @@
entry.dest_mode   = 0; /* Physical */
entry.delivery_mode   = dest_ExtINT; /* ExtInt */
entry.vector  = 0;
-   entry.dest.physical.physical_dest =
-   GET_APIC_ID(apic_read(APIC_ID));
+   entry.dest= GET_APIC_ID(apic_read(APIC_ID));
 
/*
 * Add it to the IO-APIC irq-routing table:
@@ -1556,7 +1554,7 @@
 
entry1.dest_mode = 0;   /* physical delivery */
entry1.mask = 0;/* unmask IRQ now */
-   entry1.dest.physical.physical_dest = hard_smp_processor_id();
+   entry1.dest = hard_smp_processor_id();
entry1.delivery_mode = dest_ExtINT;
entry1.polarity = 

Re: [PATCH 2.6.19.2 1/1] kexec: update IO-APIC dest field to 8-bit for APIC

[Horms]

On Fri, Jan 19, 2007 at 12:12:28PM -0500, Benjamin Romer wrote:
 On the Unisys ES7000/ONE system, we encountered a problem where performing
 a kexec reboot or dump on any cell other than cell 0 causes the system
 timer to stop working, resulting in a hang during timer calibration in the
 new kernel.
 
 We traced the problem to one line of code in disable_IO_APIC(), which needs
 to restore the timer's IO-APIC configuration before rebooting.  The code is
 currently using the 4-bit physical destination field, rather than using the
 8-bit logical destination field, and it cuts off the upper 4 bits of the
 timer's APIC ID.  If we change this to use the logical destination field,
 the timer works and we can kexec on the upper cells.  This was tested on
 two different cells (0 and 2) in an ES7000/ONE system.
 
 For reference, the relevant Intel xAPIC spec is kept at
 ftp://download.intel.com/design/chipsets/e8501/datashts/30962001.pdf,
 specifically on page 334.
 
 Signed-off-by: Benjamin M Romer [EMAIL PROTECTED]
 Cc: Andi Kleen [EMAIL PROTECTED]
 Cc: Eric W. Biederman [EMAIL PROTECTED]
 Cc: Vivek Goyal [EMAIL PROTECTED]
 Signed-off-by: Andrew Morton [EMAIL PROTECTED]

Hi,

I don't seem to be able to get this patch to apply 
(to the current Linus tree) due to some whitespace issues
in the 6th Fragment.

This is resolved in the version of the patch below.

*** Only whitespace changes + rediff ***

 arch/x86_64/kernel/io_apic.c |   24 +++-
 include/asm-x86_64/io_apic.h |   14 ++
 2 files changed, 13 insertions(+), 25 deletions(-)

Index: linux-2.6/arch/x86_64/kernel/io_apic.c
===
--- linux-2.6.orig/arch/x86_64/kernel/io_apic.c 2007-02-14 15:17:18.0 
+0900
+++ linux-2.6/arch/x86_64/kernel/io_apic.c  2007-02-14 15:19:02.0 
+0900
@@ -831,7 +831,7 @@
entry.delivery_mode = INT_DELIVERY_MODE;
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* enable IRQ */
-   entry.dest.logical.logical_dest = cpu_mask_to_apicid(TARGET_CPUS);
+   entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
 
entry.trigger = irq_trigger(idx);
entry.polarity = irq_polarity(idx);
@@ -839,7 +839,7 @@
if (irq_trigger(idx)) {
entry.trigger = 1;
entry.mask = 1;
-   entry.dest.logical.logical_dest = 
cpu_mask_to_apicid(TARGET_CPUS);
+   entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
}
 
if (!apic  !IO_APIC_IRQ(irq))
@@ -851,7 +851,7 @@
if (vector  0)
return;
 
-   entry.dest.logical.logical_dest = cpu_mask_to_apicid(mask);
+   entry.dest = cpu_mask_to_apicid(mask);
entry.vector = vector;
 
ioapic_register_intr(irq, vector, IOAPIC_AUTO);
@@ -920,7 +920,7 @@
 */
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* unmask IRQ now */
-   entry.dest.logical.logical_dest = cpu_mask_to_apicid(TARGET_CPUS);
+   entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
entry.delivery_mode = INT_DELIVERY_MODE;
entry.polarity = 0;
entry.trigger = 0;
@@ -1020,18 +1020,17 @@
 
printk(KERN_DEBUG  IRQ redirection table:\n);
 
-   printk(KERN_DEBUG  NR Log Phy Mask Trig IRR Pol
-  Stat Dest Deli Vect:   \n);
+   printk(KERN_DEBUG  NR Dst Mask Trig IRR Pol
+  Stat Dmod Deli Vect:   \n);
 
for (i = 0; i = reg_01.bits.entries; i++) {
struct IO_APIC_route_entry entry;
 
entry = ioapic_read_entry(apic, i);
 
-   printk(KERN_DEBUG  %02x %03X %02X  ,
+   printk(KERN_DEBUG  %02x %03X ,
i,
-   entry.dest.logical.logical_dest,
-   entry.dest.physical.physical_dest
+   entry.dest
);
 
printk(%1d%1d%1d   %1d   %1d%1d%1d%02X\n,
@@ -1293,8 +1292,7 @@
entry.dest_mode   = 0; /* Physical */
entry.delivery_mode   = dest_ExtINT; /* ExtInt */
entry.vector  = 0;
-   entry.dest.physical.physical_dest =
-   GET_APIC_ID(apic_read(APIC_ID));
+   entry.dest= GET_APIC_ID(apic_read(APIC_ID));
 
/*
 * Add it to the IO-APIC irq-routing table:
@@ -1556,7 +1554,7 @@
 
entry1.dest_mode = 0;   /* physical delivery */
entry1.mask = 0;/* unmask IRQ now */
-   entry1.dest.physical.physical_dest = hard_smp_processor_id();
+   entry1.dest = hard_smp_processor_id();
entry1.delivery_mode = dest_ExtINT;
entry1.polarity = entry0.polarity;
entry1.trigger = 0;
@@ -2131,7 

Re: [Fastboot] [PATCH] free initrds boot option

[Horms]

On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote:
> On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
> > > >Is there a kexec-tools patch too? How does second kernel know about
> > > >the location of the first kernel's initrd to be reused?
> > > >  
> > > >
> > > kexec-tools has to be modified to pass the first kernel initrd. On 
> > > powerpc, initrd locations are exported using device-tree. At present, 
> > > kexec-tool ignores the first kernel initrd property values and creates 
> > > new initrd properties if the user passes '--initrd' option to the kexec 
> > > command. So, will be an issue unless first kernel device-tree is passed 
> > > as buffer.
> > 
> > We've been using the --devicetreeblob kexec-tools option available for
> > POWERPC.  This enables you to setup the device tree (and hence, the
> > initrd points) as you like.
> > 
> > I'm happy to put together a patch for kexec-tools. 
> 
> Please do. And please cc me on a copy that applies against 
> kexec-tools-testing.
> 
> > Unfortunately this
> > is arch specific.  A quick look through the x86, ia64, s390 and ppc64
> > code shows the --initrd option for all these just reads the specified
> > initrd file, pushes it out to memory and uses the base and size pointers
> > to setup the next boot.  We'd obviously just skip to the last stage.
> > 
> > So what's the kexec-tools option called?  --initrd-location  ?
> 
> That sounds fine to me. I think its ok to make it arch specific for
> starters and then move it out to generic code later. That said, if
> you're feeling particularly entergetic, feel free to do the generic
> stuff now and just add null stubs for the other architectures (does
> that makes sense?).

Did anything ever come of this?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] free initrds boot option

[Horms]

On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote:
 On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
   Is there a kexec-tools patch too? How does second kernel know about
   the location of the first kernel's initrd to be reused?
 
   
   kexec-tools has to be modified to pass the first kernel initrd. On 
   powerpc, initrd locations are exported using device-tree. At present, 
   kexec-tool ignores the first kernel initrd property values and creates 
   new initrd properties if the user passes '--initrd' option to the kexec 
   command. So, will be an issue unless first kernel device-tree is passed 
   as buffer.
  
  We've been using the --devicetreeblob kexec-tools option available for
  POWERPC.  This enables you to setup the device tree (and hence, the
  initrd points) as you like.
  
  I'm happy to put together a patch for kexec-tools. 
 
 Please do. And please cc me on a copy that applies against 
 kexec-tools-testing.
 
  Unfortunately this
  is arch specific.  A quick look through the x86, ia64, s390 and ppc64
  code shows the --initrd option for all these just reads the specified
  initrd file, pushes it out to memory and uses the base and size pointers
  to setup the next boot.  We'd obviously just skip to the last stage.
  
  So what's the kexec-tools option called?  --initrd-location base size?
 
 That sounds fine to me. I think its ok to make it arch specific for
 starters and then move it out to generic code later. That said, if
 you're feeling particularly entergetic, feel free to do the generic
 stuff now and just add null stubs for the other architectures (does
 that makes sense?).

Did anything ever come of this?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [IA64] Include kexec.h in arch/ia64/kernel/process.c

[Horms]

On Wed, Feb 07, 2007 at 09:07:40AM -0800, Luck, Tony wrote:
> > kexec.h is needed by arch/ia64/kernel/process.c so for the
> > declaration of kexec_disable_iosapic() which is used in
> > machine_shutdown().
> 
> > +#include 
> 
> I merged this into your earlier change (moving machine_shutdown() into
> process.c).  Linus pulled it last night.

Thanks

> I also added a "#ifdef CONFIG_KEXEC" around the call to
> kexec_disable_iosapic() (because I first noticed that this was
> undefined when building non-KEXEC kernels).  But perhaps it might have
> been better to #define an empty stub for this function inside kexec.h
> for the #ifndef CONFIG_KEXEC case?

Good catch :)

I think that #define in the process.c vs an empty stub inside
asm/kexec.h is really a style issue. I'm quite ok with things
the way they are. But If you are more comfortable with the stub
approach, I have no objections.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] workqueue: make cancel_rearming_delayed_workqueue() work on idle dwork

[Horms]

On Wed, Feb 07, 2007 at 08:43:55PM +0300, Oleg Nesterov wrote:
> On 02/07, Oleg Nesterov wrote:
> > 
> > The following code
> > 
> > schedule_delayed_work(dw);
> > cancel_rearming_delayed_workqueue(dw);  // OK
> > cancel_rearming_delayed_workqueue(dw);  // HANGS!
> > 
> > still doesn't work.
> 
> I think we have another problem with delayed_works.
> 
> cancel_rearming_delayed_workqueue() doesn't garantee that the ->func() is not
> running upon return. I don't know if it is bug or not, the comment says 
> nothing
> about that.
> 
> However, we have the callers which seem to assume the opposite, example
> 
>   net/ipv4/ipvs/ip_vs_core.c
> 
>   module_exit
>   ip_vs_cleanup
>   ip_vs_control_cleanup
>   cancel_rearming_delayed_work
>   // done
> 
> This is unsafe. The module may be unloaded and the memory may be freed
> while defense_work_handler() is still running/preempted.
> 
> Unless I missed something, which side should be fixed?

Assuming the decision is to fix the ipvs side, is the fix
just to remove the call to cancel_rearming_delayed_work() in
ip_vs_control_cleanup() ?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] workqueue: make cancel_rearming_delayed_workqueue() work on idle dwork

[Horms]

On Wed, Feb 07, 2007 at 08:43:55PM +0300, Oleg Nesterov wrote:
 On 02/07, Oleg Nesterov wrote:
  
  The following code
  
  schedule_delayed_work(dw);
  cancel_rearming_delayed_workqueue(dw);  // OK
  cancel_rearming_delayed_workqueue(dw);  // HANGS!
  
  still doesn't work.
 
 I think we have another problem with delayed_works.
 
 cancel_rearming_delayed_workqueue() doesn't garantee that the -func() is not
 running upon return. I don't know if it is bug or not, the comment says 
 nothing
 about that.
 
 However, we have the callers which seem to assume the opposite, example
 
   net/ipv4/ipvs/ip_vs_core.c
 
   module_exit
   ip_vs_cleanup
   ip_vs_control_cleanup
   cancel_rearming_delayed_work
   // done
 
 This is unsafe. The module may be unloaded and the memory may be freed
 while defense_work_handler() is still running/preempted.
 
 Unless I missed something, which side should be fixed?

Assuming the decision is to fix the ipvs side, is the fix
just to remove the call to cancel_rearming_delayed_work() in
ip_vs_control_cleanup() ?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [IA64] Include kexec.h in arch/ia64/kernel/process.c

[Horms]

On Wed, Feb 07, 2007 at 09:07:40AM -0800, Luck, Tony wrote:
  kexec.h is needed by arch/ia64/kernel/process.c so for the
  declaration of kexec_disable_iosapic() which is used in
  machine_shutdown().
 
  +#include asm/kexec.h
 
 I merged this into your earlier change (moving machine_shutdown() into
 process.c).  Linus pulled it last night.

Thanks

 I also added a #ifdef CONFIG_KEXEC around the call to
 kexec_disable_iosapic() (because I first noticed that this was
 undefined when building non-KEXEC kernels).  But perhaps it might have
 been better to #define an empty stub for this function inside kexec.h
 for the #ifndef CONFIG_KEXEC case?

Good catch :)

I think that #define in the process.c vs an empty stub inside
asm/kexec.h is really a style issue. I'm quite ok with things
the way they are. But If you are more comfortable with the stub
approach, I have no objections.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [ PATCH ] fix to documentation for kexec

[Horms]

On Thu, Feb 01, 2007 at 01:25:04PM -0500, Robert P. J. Day wrote:
> On Thu, 1 Feb 2007, Judith Lebzelter wrote:
> 
> > Hello,
> >
> > I've noticed that the boot options are not correct for in
> > the documentation for kdump. The "init" keyword is not
> > necessary, and causes a kernel panic when booting with an
> > initrd on Fedora 5.
> >
> > Thanks;
> > Judith Lebzelter
> >
> > ---
> > Signed-off-by: Judith Lebzelter <[EMAIL PROTECTED]>
> > ---
> >
> >
> > Index: linux/Documentation/kdump/kdump.txt
> > ===
> > --- linux.orig/Documentation/kdump/kdump.txt
> > +++ linux/Documentation/kdump/kdump.txt
> > @@ -207,7 +207,7 @@ the following command:
> >
> > kexec -p  \
> > --initrd= --args-linux \
> > -   --append="root= init 1 irqpoll"
> > +   --append="root= 1 irqpoll"
> >
> >
> >  Notes on loading the dump-capture kernel:
> > @@ -228,8 +228,8 @@ Notes on loading the dump-capture kernel
> >  * You must specify  in the format corresponding to the root
> >device name in the output of mount command.
> >
> > -* "init 1" boots the dump-capture kernel into single-user mode without
> > -  networking. If you want networking, use "init 3."
> > +* Boot parameter "1" boots the dump-capture kernel into single-user mode
> > +  without networking. If you want networking, use "3".
> 
> i'm not sure you want to totally remove those first two lines, they
> appear to talk about getting to run level 1 *from a running system*.

I think that it is refering to a kernel command line parameter,
not a shell command executed on a running system, so I think the patch
is correct in that respect.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] kexec: fix references to init in documentation for kexe

[Horms]

On Fri, Feb 02, 2007 at 01:32:40PM +0530, Vivek Goyal wrote:
> On Thu, Feb 01, 2007 at 10:58:08AM -0800, Judith Lebzelter wrote:
> > > 
> > > I did notice that my patch is out of date for the latest kernel, 
> > > however.  I can send an up to date one.
> > > 
> > This applies to 2.6.20-rc7
> > 
> > Signed-off-by: Judith Lebzeelter <[EMAIL PROTECTED]>
> > ---
> > 
> > Stop recommending incorrect/superfluous "init" boot parameter.
> > 
> 
> This looks good. The intention here is just to boot into run level 1, so
> that minimum scripts run in user space and probability of capturing the
> dump increases.
> 
> Fedora doc does say that appending "1" on command line will boot it
> into runlevel 1. I hope same is true for other distributions too.
> 
> Thanks
> Vivek

This seems fine to me. Lets see if we can get it included.

-- 
Simon Horman (Horms)
  [EMAIL PROTECTED]
  http://verge.net.au/~horms/

kexec: fix references to init in documentation for kexec

I've noticed that the boot options are not correct for in
the documentation for kdump. The "init" keyword is not
necessary, and causes a kernel panic when booting with an
initrd on Fedora 5.

Signed-off-by: Judith Lebzeelter <[EMAIL PROTECTED]>
Acked-by: Vivek Goyal <[EMAIL PROTECTED]>

Put original comment with the latest version of the patch

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

Index: linux-2.6.20-rc7/Documentation/kdump/kdump.txt
===
--- linux-2.6.20-rc7.orig/Documentation/kdump/kdump.txt
+++ linux-2.6.20-rc7/Documentation/kdump/kdump.txt
@@ -311,10 +311,10 @@ Following are the arch specific command 
 loading dump-capture kernel.
 
 For i386, x86_64 and ia64:
-   "init 1 irqpoll maxcpus=1"
+   "1 irqpoll maxcpus=1"
 
 For ppc64:
-   "init 1 maxcpus=1 noirqdistrib"
+   "1 maxcpus=1 noirqdistrib"
 
 
 Notes on loading the dump-capture kernel:
@@ -332,8 +332,8 @@ Notes on loading the dump-capture kernel
 * You must specify  in the format corresponding to the root
   device name in the output of mount command.
 
-* "init 1" boots the dump-capture kernel into single-user mode without
-  networking. If you want networking, use "init 3."
+* Boot parameter "1" boots the dump-capture kernel into single-user 
+  mode without networking. If you want networking, use "3".
 
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [IA64] whitespace fixes for include/asm-ia64/sal.h

[Horms]

* Make use of spaces and tabs consistent
* Make long line < 80col

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

Index: linux-2.6/include/asm-ia64/sal.h
===
--- linux-2.6.orig/include/asm-ia64/sal.h   2007-02-07 11:53:12.0 
+0900
+++ linux-2.6/include/asm-ia64/sal.h2007-02-07 12:46:57.0 +0900
@@ -860,12 +867,13 @@
  */
 struct sal_to_os_boot {
u64 rr[8];  /* Region Registers */
-   u64 br[6];  /* br0: return addr into SAL boot rendez 
routine */
+   u64 br[6];  /* br0:
+* return addr into SAL boot rendez routine */
u64 gr1;/* SAL:GP */
u64 gr12;   /* SAL:SP */
u64 gr13;   /* SAL: Task Pointer */
u64 fpsr;
-   u64 pfs;
+   u64 pfs;
u64 rnat;
u64 unat;
u64 bspstore;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [IA64] Include kexec.h in arch/ia64/kernel/process.c

[Horms]

kexec.h is needed by arch/ia64/kernel/process.c so for the
declaration of kexec_disable_iosapic() which is used in machine_shutdown().

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

Index: linux-2.6/arch/ia64/kernel/process.c
===
--- linux-2.6.orig/arch/ia64/kernel/process.c   2007-02-07 12:43:09.0 
+0900
+++ linux-2.6/arch/ia64/kernel/process.c2007-02-07 12:43:16.0 
+0900
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "entry.h"
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] kexec: fix references to init in documentation for kexe

[Horms]

On Fri, Feb 02, 2007 at 01:32:40PM +0530, Vivek Goyal wrote:
 On Thu, Feb 01, 2007 at 10:58:08AM -0800, Judith Lebzelter wrote:
   
   I did notice that my patch is out of date for the latest kernel, 
   however.  I can send an up to date one.
   
  This applies to 2.6.20-rc7
  
  Signed-off-by: Judith Lebzeelter [EMAIL PROTECTED]
  ---
  
  Stop recommending incorrect/superfluous init boot parameter.
  
 
 This looks good. The intention here is just to boot into run level 1, so
 that minimum scripts run in user space and probability of capturing the
 dump increases.
 
 Fedora doc does say that appending 1 on command line will boot it
 into runlevel 1. I hope same is true for other distributions too.
 
 Thanks
 Vivek

This seems fine to me. Lets see if we can get it included.

-- 
Simon Horman (Horms)
  [EMAIL PROTECTED]
  http://verge.net.au/~horms/

kexec: fix references to init in documentation for kexec

I've noticed that the boot options are not correct for in
the documentation for kdump. The init keyword is not
necessary, and causes a kernel panic when booting with an
initrd on Fedora 5.

Signed-off-by: Judith Lebzeelter [EMAIL PROTECTED]
Acked-by: Vivek Goyal [EMAIL PROTECTED]

Put original comment with the latest version of the patch

Signed-off-by: Simon Horman [EMAIL PROTECTED]

Index: linux-2.6.20-rc7/Documentation/kdump/kdump.txt
===
--- linux-2.6.20-rc7.orig/Documentation/kdump/kdump.txt
+++ linux-2.6.20-rc7/Documentation/kdump/kdump.txt
@@ -311,10 +311,10 @@ Following are the arch specific command 
 loading dump-capture kernel.
 
 For i386, x86_64 and ia64:
-   init 1 irqpoll maxcpus=1
+   1 irqpoll maxcpus=1
 
 For ppc64:
-   init 1 maxcpus=1 noirqdistrib
+   1 maxcpus=1 noirqdistrib
 
 
 Notes on loading the dump-capture kernel:
@@ -332,8 +332,8 @@ Notes on loading the dump-capture kernel
 * You must specify root-dev in the format corresponding to the root
   device name in the output of mount command.
 
-* init 1 boots the dump-capture kernel into single-user mode without
-  networking. If you want networking, use init 3.
+* Boot parameter 1 boots the dump-capture kernel into single-user 
+  mode without networking. If you want networking, use 3.
 
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [ PATCH ] fix to documentation for kexec

[Horms]

On Thu, Feb 01, 2007 at 01:25:04PM -0500, Robert P. J. Day wrote:
 On Thu, 1 Feb 2007, Judith Lebzelter wrote:
 
  Hello,
 
  I've noticed that the boot options are not correct for in
  the documentation for kdump. The init keyword is not
  necessary, and causes a kernel panic when booting with an
  initrd on Fedora 5.
 
  Thanks;
  Judith Lebzelter
 
  ---
  Signed-off-by: Judith Lebzelter [EMAIL PROTECTED]
  ---
 
 
  Index: linux/Documentation/kdump/kdump.txt
  ===
  --- linux.orig/Documentation/kdump/kdump.txt
  +++ linux/Documentation/kdump/kdump.txt
  @@ -207,7 +207,7 @@ the following command:
 
  kexec -p dump-capture-kernel \
  --initrd=initrd-for-dump-capture-kernel --args-linux \
  -   --append=root=root-dev init 1 irqpoll
  +   --append=root=root-dev 1 irqpoll
 
 
   Notes on loading the dump-capture kernel:
  @@ -228,8 +228,8 @@ Notes on loading the dump-capture kernel
   * You must specify root-dev in the format corresponding to the root
 device name in the output of mount command.
 
  -* init 1 boots the dump-capture kernel into single-user mode without
  -  networking. If you want networking, use init 3.
  +* Boot parameter 1 boots the dump-capture kernel into single-user mode
  +  without networking. If you want networking, use 3.
 
 i'm not sure you want to totally remove those first two lines, they
 appear to talk about getting to run level 1 *from a running system*.

I think that it is refering to a kernel command line parameter,
not a shell command executed on a running system, so I think the patch
is correct in that respect.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [IA64] whitespace fixes for include/asm-ia64/sal.h

[Horms]

* Make use of spaces and tabs consistent
* Make long line  80col

Signed-off-by: Simon Horman [EMAIL PROTECTED]

Index: linux-2.6/include/asm-ia64/sal.h
===
--- linux-2.6.orig/include/asm-ia64/sal.h   2007-02-07 11:53:12.0 
+0900
+++ linux-2.6/include/asm-ia64/sal.h2007-02-07 12:46:57.0 +0900
@@ -860,12 +867,13 @@
  */
 struct sal_to_os_boot {
u64 rr[8];  /* Region Registers */
-   u64 br[6];  /* br0: return addr into SAL boot rendez 
routine */
+   u64 br[6];  /* br0:
+* return addr into SAL boot rendez routine */
u64 gr1;/* SAL:GP */
u64 gr12;   /* SAL:SP */
u64 gr13;   /* SAL: Task Pointer */
u64 fpsr;
-   u64 pfs;
+   u64 pfs;
u64 rnat;
u64 unat;
u64 bspstore;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [IA64] Include kexec.h in arch/ia64/kernel/process.c

[Horms]

kexec.h is needed by arch/ia64/kernel/process.c so for the
declaration of kexec_disable_iosapic() which is used in machine_shutdown().

Signed-off-by: Simon Horman [EMAIL PROTECTED]

Index: linux-2.6/arch/ia64/kernel/process.c
===
--- linux-2.6.orig/arch/ia64/kernel/process.c   2007-02-07 12:43:09.0 
+0900
+++ linux-2.6/arch/ia64/kernel/process.c2007-02-07 12:43:16.0 
+0900
@@ -41,6 +41,7 @@
 #include asm/uaccess.h
 #include asm/unwind.h
 #include asm/user.h
+#include asm/kexec.h
 
 #include entry.h
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)

[Horms]

On Fri, Feb 02, 2007 at 08:53:00PM +0900, Magnus Damm wrote:
> On 2/2/07, Magnus Damm <[EMAIL PROTECTED]> wrote:
> > On 2/2/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > Magnus Damm <[EMAIL PROTECTED]> wrote:
> > >
> > > > kexec: Fix CONFIG_SMP=n compilation (ia64)
> > > >
> > > > This patch makes it possible to compile kexec for ia64 without SMP 
> > > > support.
> > > > --- 0002/arch/ia64/kernel/machine_kexec.c
> > > > +++ work/arch/ia64/kernel/machine_kexec.c 2007-02-01 
> > > > 12:35:46.0 +0900
> > > > @@ -70,12 +70,14 @@ void machine_kexec_cleanup(struct kimage
> > > >
> > > >  void machine_shutdown(void)
> > > >  {
> > > > +#ifdef CONFIG_SMP
> > > >   int cpu;
> > > >
> > > >   for_each_online_cpu(cpu) {
> > > >   if (cpu != smp_processor_id())
> > > >   cpu_down(cpu);
> > > >   }
> > > > +#endif
> > > >   kexec_disable_iosapic();
> > > >  }
> > >
> > > hm.  I suspect this one should have been #ifndef CONFIG_HOTPLUG_CPU?
> 
> Re-reading this I assume you mean #ifdef CONFIG_HOTPLUG_CPU.
> 
> I would be happy to resend a new updated version of the patch, but I
> wonder if it may be better to fail miserably during the build than
> fail silently in the case of CONFIG_SMP=y but CONFIG_HOTPLUG_CPU=n.

There used to be alternate code for the CONFIG_SMP +
!CONFIG_HOTPLUG_CPU, but this was removed because it was determined to
be flakey and not maintainable (I can dig up the threads if you want).
I think that this means that if we have CONFIG_KEXEC and CONFIG_SMP then
CONFIG_HOTPLUG_CPU is required. I think this is expressable in Kconfig
somehow.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)

[Horms]

On Fri, Feb 02, 2007 at 08:53:00PM +0900, Magnus Damm wrote:
 On 2/2/07, Magnus Damm [EMAIL PROTECTED] wrote:
  On 2/2/07, Andrew Morton [EMAIL PROTECTED] wrote:
   Magnus Damm [EMAIL PROTECTED] wrote:
  
kexec: Fix CONFIG_SMP=n compilation (ia64)
   
This patch makes it possible to compile kexec for ia64 without SMP 
support.
--- 0002/arch/ia64/kernel/machine_kexec.c
+++ work/arch/ia64/kernel/machine_kexec.c 2007-02-01 
12:35:46.0 +0900
@@ -70,12 +70,14 @@ void machine_kexec_cleanup(struct kimage
   
 void machine_shutdown(void)
 {
+#ifdef CONFIG_SMP
  int cpu;
   
  for_each_online_cpu(cpu) {
  if (cpu != smp_processor_id())
  cpu_down(cpu);
  }
+#endif
  kexec_disable_iosapic();
 }
  
   hm.  I suspect this one should have been #ifndef CONFIG_HOTPLUG_CPU?
 
 Re-reading this I assume you mean #ifdef CONFIG_HOTPLUG_CPU.
 
 I would be happy to resend a new updated version of the patch, but I
 wonder if it may be better to fail miserably during the build than
 fail silently in the case of CONFIG_SMP=y but CONFIG_HOTPLUG_CPU=n.

There used to be alternate code for the CONFIG_SMP +
!CONFIG_HOTPLUG_CPU, but this was removed because it was determined to
be flakey and not maintainable (I can dig up the threads if you want).
I think that this means that if we have CONFIG_KEXEC and CONFIG_SMP then
CONFIG_HOTPLUG_CPU is required. I think this is expressable in Kconfig
somehow.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)

[Horms]

On Fri, Feb 02, 2007 at 11:01:21AM +0800, Zou, Nanhai wrote:
> > > >  void
> > > >  machine_crash_shutdown(struct pt_regs *pt)
> > > > @@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
> > > >   atomic_inc(_cpu_freezed);
> > > >   kdump_status[cpuid] = 1;
> > > >   mb();
> > > > - if (cpuid == 0) {
> > > > - for (;;)
> > > > - cpu_relax();
> > > > - } else
> > > > +#ifdef CONFIG_HOTPLUG_CPU
> > > > + if (cpuid != 0)
> > > >   ia64_jump_to_sal(_boot_rendez_state[cpuid]);
> > > > +#endif
> > > > + for (;;)
> > > > + cpu_relax();
> > > >  }
> > >
> > > I trust ia64_jump_to_sal doesn't return.
> > 
> > So do I. The main problem with the compilation seems to be that
> > ia64_jump_to_sal() only exists if CONFIG_HOTPLUG_CPU=y.
> > (include/asm-ia64/sal.h, arch/ia64/kernel/head.S)
> > 
>  This may cause problem on SN platform. 
> I remember SN requires cpu0 return to SAL rendez loop to do IRQ redirection.
> However this needs SGI people to confirm...

Does this mean that CONFIG_HOTPLUG_CPU may be required for kdump
on the SN platform?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)

[Horms]

On Fri, Feb 02, 2007 at 11:01:21AM +0800, Zou, Nanhai wrote:
 void
 machine_crash_shutdown(struct pt_regs *pt)
@@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
  atomic_inc(kdump_cpu_freezed);
  kdump_status[cpuid] = 1;
  mb();
- if (cpuid == 0) {
- for (;;)
- cpu_relax();
- } else
+#ifdef CONFIG_HOTPLUG_CPU
+ if (cpuid != 0)
  ia64_jump_to_sal(sal_boot_rendez_state[cpuid]);
+#endif
+ for (;;)
+ cpu_relax();
 }
  
   I trust ia64_jump_to_sal doesn't return.
  
  So do I. The main problem with the compilation seems to be that
  ia64_jump_to_sal() only exists if CONFIG_HOTPLUG_CPU=y.
  (include/asm-ia64/sal.h, arch/ia64/kernel/head.S)
  
  This may cause problem on SN platform. 
 I remember SN requires cpu0 return to SAL rendez loop to do IRQ redirection.
 However this needs SGI people to confirm...

Does this mean that CONFIG_HOTPLUG_CPU may be required for kdump
on the SN platform?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20: ia64 portion

[Horms]

Hi,

this patch fills in the portions for ia64 kexec.

I'm actually not sure what options are required for the dump-capture
kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.

This patch requires the documentation patch update that Vivek Goyal has
been circulating, and I believe is currently in mm. Feel free to fold it
into that change if it makes things easier for anyone.

Take II

Nanhai,

I have noted that vmlinux.gz may also be used. And added a note about the
kernel being able to automatically place the crashkernel region.
Furthermore, I added a note that if manually specified, the region should
be 64Mb aligned to avoid wastage. I notice that the auto placement code
uses 64Mb. But is this strictly neccessary for all page sizes?

Take III

Fixed some typos, thaniks to Andreas Schwab

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

Index: linux-2.6/Documentation/kdump/kdump.txt
===
--- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
17:45:19.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 17:59:42.0 
+0900
@@ -17,7 +17,7 @@
 memory image to a dump file on the local disk, or across the network to
 a remote system.
 
-Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
+Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
 architectures.
 
 When the system kernel boots, it reserves a small section of memory for
@@ -229,7 +229,23 @@
 
 Dump-capture kernel config options (Arch Dependent, ia64)
 --
-(To be filled)
+
+- No specific options are required to create a dump-capture kernel
+  for ia64, other than those specified in the arch idependent section
+  above. This means that it is possible to use the system kernel
+  as a dump-capture kernel if desired.
+  
+  The crashkernel region can be automatically placed by the system
+  kernel at run time. This is done by specifying the base address as 0,
+  or omitting it all together.
+
+  [EMAIL PROTECTED]
+  or
+  crashkernel=256M
+
+  If the start address is specified, note that the start address of the
+  kernel will be aligned to 64Mb, so if the start address is not then
+  any space below the alignment point will be wasted.
 
 
 Boot into System Kernel
@@ -248,6 +264,10 @@
 
On ppc64, use "[EMAIL PROTECTED]".
 
+   On ia64, [EMAIL PROTECTED] is a generous value that typically works.
+   The region may be automatically placed on ia64, see the
+   dump-capture kernel config option notes above.
+
 Load the Dump-capture Kernel
 
 
@@ -266,7 +286,8 @@
 For ppc64:
- Use vmlinux
 For ia64:
-   (To be filled)
+   - Use vmlinux or vmlinuz.gz
+
 
 If you are using a uncompressed vmlinux image then use following command
 to load dump-capture kernel.
@@ -282,18 +303,19 @@
--initrd= \
--append="root= "
 
+Please note, that --args-linux does not need to be specified for ia64.
+It is planned to make this a no-op on that architecture, but for now
+it should be omitted
+
 Following are the arch specific command line options to be used while
 loading dump-capture kernel.
 
-For i386 and x86_64:
+For i386, x86_64 and ia64:
"init 1 irqpoll maxcpus=1"
 
 For ppc64:
"init 1 maxcpus=1 noirqdistrib"
 
-For IA64
-   (To be filled)
-
 
 Notes on loading the dump-capture kernel:
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] Kdump documentation update for 2.6.20: ia64 portion

[Horms]

On Fri, Jan 12, 2007 at 11:46:39AM -0800, Jay Lan wrote:
> Horms wrote:
> > Hi,
> > 
> > this patch fills in the portions for ia64 kexec.
> > 
> > I'm actually not sure what options are required for the dump-capture
> > kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
> > Or more to the point, I'm not sure if irqpoll is needed or not.
> > 
> > This patch requires the documentation patch update that Vivek Goyal has
> > been circulating, and I believe is currently in mm. Feel free to fold it
> > into that change if it makes things easier for anyone.
> > 
> > Take II
> > 
> > Nanhai,
> > 
> > I have noted that vmlinux.gz may also be used. And added a note about the
> > kernel being able to automatically place the crashkernel region.
> > Furthermore, I added a note that if manually specified, the region should
> > be 64Mb aligned to avoid wastage. I notice that the auto placement code
> > uses 64Mb. But is this strictly neccessary for all page sizes?
> > 
> > Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
> > 
> > Index: linux-2.6/Documentation/kdump/kdump.txt
> > ===
> > --- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
> > 17:45:19.0 +0900
> > +++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 17:59:42.0 
> > +0900
> > @@ -17,7 +17,7 @@
> >  memory image to a dump file on the local disk, or across the network to
> >  a remote system.
> >  
> > -Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
> > +Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
> >  architectures.
> >  
> >  When the system kernel boots, it reserves a small section of memory for
> > @@ -229,7 +229,23 @@
> >  
> >  Dump-capture kernel config options (Arch Dependent, ia64)
> >  --
> > -(To be filled)
> > +
> > +- No specific options are required to create a dump-capture kernel
> > +  for ia64, other than those specified in the arch idependent section
> > +  above. This means that it is possible to use the system kernel
> > +  as a dump-capture kernel if desired.
> > +  
> > +  The crashkernel region can be automatically placed by the system
> > +  kernel at run time. This is done by specifying the base address as 0,
> > +  or omitting it all together.
> 
> In my testing, i found the base address was ignored. Whatever value
> specified was fine. Not necessary to be 0. But i guess it is fine to
> give people a guideline telling them to specify 0.

I submitted a patch to honour non-zero base addresses,
I'm pretty sure it is in there now.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20: ia64 portion

[Horms]

Hi,

this patch fills in the portions for ia64 kexec.

I'm actually not sure what options are required for the dump-capture
kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.

This patch requires the documentation patch update that Vivek Goyal has
been circulating, and I believe is currently in mm. Feel free to fold it
into that change if it makes things easier for anyone.

Take II

Nanhai,

I have noted that vmlinux.gz may also be used. And added a note about the
kernel being able to automatically place the crashkernel region.
Furthermore, I added a note that if manually specified, the region should
be 64Mb aligned to avoid wastage. I notice that the auto placement code
uses 64Mb. But is this strictly neccessary for all page sizes?

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

Index: linux-2.6/Documentation/kdump/kdump.txt
===
--- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
17:45:19.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 17:59:42.0 
+0900
@@ -17,7 +17,7 @@
 memory image to a dump file on the local disk, or across the network to
 a remote system.
 
-Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
+Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
 architectures.
 
 When the system kernel boots, it reserves a small section of memory for
@@ -229,7 +229,23 @@
 
 Dump-capture kernel config options (Arch Dependent, ia64)
 --
-(To be filled)
+
+- No specific options are required to create a dump-capture kernel
+  for ia64, other than those specified in the arch idependent section
+  above. This means that it is possible to use the system kernel
+  as a dump-capture kernel if desired.
+  
+  The crashkernel region can be automatically placed by the system
+  kernel at run time. This is done by specifying the base address as 0,
+  or omitting it all together.
+
+  [EMAIL PROTECTED]
+  or
+  crashkernel=256M
+
+  If the start address is specified, not that the start address of the
+  kernel will be alligned to 64Mb, so any if the start address is not then
+  any space below the alignment point will be wasted.
 
 
 Boot into System Kernel
@@ -248,6 +264,10 @@
 
On ppc64, use "[EMAIL PROTECTED]".
 
+   On ia64, [EMAIL PROTECTED] is a generous value that typically works.
+   The region may be automatically placed on ia64, see the
+   dump-capture kernel config option notes above.
+
 Load the Dump-capture Kernel
 
 
@@ -266,7 +286,8 @@
 For ppc64:
- Use vmlinux
 For ia64:
-   (To be filled)
+   - Use vmlinux or vmlinuz.gz
+
 
 If you are using a uncompressed vmlinux image then use following command
 to load dump-capture kernel.
@@ -282,18 +303,19 @@
--initrd= \
--append="root= "
 
+Please note, that --args-linux does not need to be specified for ia64.
+It is planned to make this a no-op on that architecture, but for now
+it should be omitted
+
 Following are the arch specific command line options to be used while
 loading dump-capture kernel.
 
-For i386 and x86_64:
+For i386, x86_64 and ia64:
"init 1 irqpoll maxcpus=1"
 
 For ppc64:
"init 1 maxcpus=1 noirqdistrib"
 
-For IA64
-   (To be filled)
-
 
 Notes on loading the dump-capture kernel:
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20: ia64 portion

[Horms]

Hi,

this patch fills in the portions for ia64 kexec.

I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.

This patch requires the documentation patch update that Vivek Goyal has
been circulating, and I believe is currently in mm. Feel free to fold it
into that change if it makes things easier for anyone.

Take II

Nanhai,

I have noted that vmlinux.gz may also be used. And added a note about the
kernel being able to automatically place the crashkernel region.
Furthermore, I added a note that if manually specified, the region should
be 64Mb aligned to avoid wastage. I notice that the auto placement code
uses 64Mb. But is this strictly neccessary for all page sizes?

Signed-off-by: Simon Horman [EMAIL PROTECTED]

Index: linux-2.6/Documentation/kdump/kdump.txt
===
--- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
17:45:19.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 17:59:42.0 
+0900
@@ -17,7 +17,7 @@
 memory image to a dump file on the local disk, or across the network to
 a remote system.
 
-Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
+Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
 architectures.
 
 When the system kernel boots, it reserves a small section of memory for
@@ -229,7 +229,23 @@
 
 Dump-capture kernel config options (Arch Dependent, ia64)
 --
-(To be filled)
+
+- No specific options are required to create a dump-capture kernel
+  for ia64, other than those specified in the arch idependent section
+  above. This means that it is possible to use the system kernel
+  as a dump-capture kernel if desired.
+  
+  The crashkernel region can be automatically placed by the system
+  kernel at run time. This is done by specifying the base address as 0,
+  or omitting it all together.
+
+  [EMAIL PROTECTED]
+  or
+  crashkernel=256M
+
+  If the start address is specified, not that the start address of the
+  kernel will be alligned to 64Mb, so any if the start address is not then
+  any space below the alignment point will be wasted.
 
 
 Boot into System Kernel
@@ -248,6 +264,10 @@
 
On ppc64, use [EMAIL PROTECTED].
 
+   On ia64, [EMAIL PROTECTED] is a generous value that typically works.
+   The region may be automatically placed on ia64, see the
+   dump-capture kernel config option notes above.
+
 Load the Dump-capture Kernel
 
 
@@ -266,7 +286,8 @@
 For ppc64:
- Use vmlinux
 For ia64:
-   (To be filled)
+   - Use vmlinux or vmlinuz.gz
+
 
 If you are using a uncompressed vmlinux image then use following command
 to load dump-capture kernel.
@@ -282,18 +303,19 @@
--initrd=initrd-for-dump-capture-kernel \
--append=root=root-dev arch-specific-options
 
+Please note, that --args-linux does not need to be specified for ia64.
+It is planned to make this a no-op on that architecture, but for now
+it should be omitted
+
 Following are the arch specific command line options to be used while
 loading dump-capture kernel.
 
-For i386 and x86_64:
+For i386, x86_64 and ia64:
init 1 irqpoll maxcpus=1
 
 For ppc64:
init 1 maxcpus=1 noirqdistrib
 
-For IA64
-   (To be filled)
-
 
 Notes on loading the dump-capture kernel:
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20: ia64 portion

[Horms]

Hi,

this patch fills in the portions for ia64 kexec.

I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.

This patch requires the documentation patch update that Vivek Goyal has
been circulating, and I believe is currently in mm. Feel free to fold it
into that change if it makes things easier for anyone.

Take II

Nanhai,

I have noted that vmlinux.gz may also be used. And added a note about the
kernel being able to automatically place the crashkernel region.
Furthermore, I added a note that if manually specified, the region should
be 64Mb aligned to avoid wastage. I notice that the auto placement code
uses 64Mb. But is this strictly neccessary for all page sizes?

Take III

Fixed some typos, thaniks to Andreas Schwab

Signed-off-by: Simon Horman [EMAIL PROTECTED]

Index: linux-2.6/Documentation/kdump/kdump.txt
===
--- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
17:45:19.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 17:59:42.0 
+0900
@@ -17,7 +17,7 @@
 memory image to a dump file on the local disk, or across the network to
 a remote system.
 
-Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
+Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
 architectures.
 
 When the system kernel boots, it reserves a small section of memory for
@@ -229,7 +229,23 @@
 
 Dump-capture kernel config options (Arch Dependent, ia64)
 --
-(To be filled)
+
+- No specific options are required to create a dump-capture kernel
+  for ia64, other than those specified in the arch idependent section
+  above. This means that it is possible to use the system kernel
+  as a dump-capture kernel if desired.
+  
+  The crashkernel region can be automatically placed by the system
+  kernel at run time. This is done by specifying the base address as 0,
+  or omitting it all together.
+
+  [EMAIL PROTECTED]
+  or
+  crashkernel=256M
+
+  If the start address is specified, note that the start address of the
+  kernel will be aligned to 64Mb, so if the start address is not then
+  any space below the alignment point will be wasted.
 
 
 Boot into System Kernel
@@ -248,6 +264,10 @@
 
On ppc64, use [EMAIL PROTECTED].
 
+   On ia64, [EMAIL PROTECTED] is a generous value that typically works.
+   The region may be automatically placed on ia64, see the
+   dump-capture kernel config option notes above.
+
 Load the Dump-capture Kernel
 
 
@@ -266,7 +286,8 @@
 For ppc64:
- Use vmlinux
 For ia64:
-   (To be filled)
+   - Use vmlinux or vmlinuz.gz
+
 
 If you are using a uncompressed vmlinux image then use following command
 to load dump-capture kernel.
@@ -282,18 +303,19 @@
--initrd=initrd-for-dump-capture-kernel \
--append=root=root-dev arch-specific-options
 
+Please note, that --args-linux does not need to be specified for ia64.
+It is planned to make this a no-op on that architecture, but for now
+it should be omitted
+
 Following are the arch specific command line options to be used while
 loading dump-capture kernel.
 
-For i386 and x86_64:
+For i386, x86_64 and ia64:
init 1 irqpoll maxcpus=1
 
 For ppc64:
init 1 maxcpus=1 noirqdistrib
 
-For IA64
-   (To be filled)
-
 
 Notes on loading the dump-capture kernel:
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] Kdump documentation update for 2.6.20: ia64 portion

[Horms]

On Fri, Jan 12, 2007 at 11:46:39AM -0800, Jay Lan wrote:
 Horms wrote:
  Hi,
  
  this patch fills in the portions for ia64 kexec.
  
  I'm actually not sure what options are required for the dump-capture
  kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
  Or more to the point, I'm not sure if irqpoll is needed or not.
  
  This patch requires the documentation patch update that Vivek Goyal has
  been circulating, and I believe is currently in mm. Feel free to fold it
  into that change if it makes things easier for anyone.
  
  Take II
  
  Nanhai,
  
  I have noted that vmlinux.gz may also be used. And added a note about the
  kernel being able to automatically place the crashkernel region.
  Furthermore, I added a note that if manually specified, the region should
  be 64Mb aligned to avoid wastage. I notice that the auto placement code
  uses 64Mb. But is this strictly neccessary for all page sizes?
  
  Signed-off-by: Simon Horman [EMAIL PROTECTED]
  
  Index: linux-2.6/Documentation/kdump/kdump.txt
  ===
  --- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
  17:45:19.0 +0900
  +++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 17:59:42.0 
  +0900
  @@ -17,7 +17,7 @@
   memory image to a dump file on the local disk, or across the network to
   a remote system.
   
  -Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
  +Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
   architectures.
   
   When the system kernel boots, it reserves a small section of memory for
  @@ -229,7 +229,23 @@
   
   Dump-capture kernel config options (Arch Dependent, ia64)
   --
  -(To be filled)
  +
  +- No specific options are required to create a dump-capture kernel
  +  for ia64, other than those specified in the arch idependent section
  +  above. This means that it is possible to use the system kernel
  +  as a dump-capture kernel if desired.
  +  
  +  The crashkernel region can be automatically placed by the system
  +  kernel at run time. This is done by specifying the base address as 0,
  +  or omitting it all together.
 
 In my testing, i found the base address was ignored. Whatever value
 specified was fine. Not necessary to be 0. But i guess it is fine to
 give people a guideline telling them to specify 0.

I submitted a patch to honour non-zero base addresses,
I'm pretty sure it is in there now.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Kdump documentation update for 2.6.20: ia64 portion

[Horms]

Hi,

this patch fills in the portions for ia64 kexec.

I'm actually not sure what options are required for the dump-capture
kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.

This patch requires the documentation patch update that Vivek Goyal has
been circulating, and I believe is currently in mm. Feel free to fold it
into that change if it makes things easier for anyone.

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

Index: linux-2.6/Documentation/kdump/kdump.txt
===
--- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
14:37:46.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 14:46:53.0 
+0900
@@ -17,7 +17,7 @@
 memory image to a dump file on the local disk, or across the network to
 a remote system.
 
-Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
+Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
 architectures.
 
 When the system kernel boots, it reserves a small section of memory for
@@ -227,7 +227,11 @@
 
 Dump-capture kernel config options (Arch Dependent, ia64)
 --
-(To be filled)
+
+- No specific options are required to create a dump-capture kernel
+  for ia64 other than those specified in the arch idependent section
+  above. This means that it is possible to use the system kernel
+  as a dump-capture kernel if desired.
 
 
 Boot into System Kernel
@@ -264,7 +268,8 @@
 For ppc64:
- Use vmlinux
 For ia64:
-   (To be filled)
+   - Use vmlinux
+
 
 If you are using a uncompressed vmlinux image then use following command
 to load dump-capture kernel.
@@ -280,18 +285,19 @@
--initrd= \
--append="root= "
 
+Please note, that --args-linux does not need to be specified for ia64.
+It is planned to make this a no-op on that architecture, but for now
+it should be omitted
+
 Following are the arch specific command line options to be used while
 loading dump-capture kernel.
 
-For i386 and x86_64:
+For i386, x86_64 and ia64:
"init 1 irqpoll maxcpus=1"
 
 For ppc64:
"init 1 maxcpus=1 noirqdistrib"
 
-For IA64
-   (To be filled)
-
 
 Notes on loading the dump-capture kernel:
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Kdump documentation update for 2.6.20: kexec-tools update

[Horms]

Hi,

Mohan Kumar suggested making kexec-tools-testing.tar.gz a link
to the latest version. I have done this and this patch updates the
documentation accordingly.

This patch requires the documentation patch update that Vivek Goyal has
been circulating, and I believe is currently in mm. Feel free to fold it
into that change if it makes things easier for anyone.

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

Index: linux-2.6/Documentation/kdump/kdump.txt
===
--- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
14:37:18.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 14:56:42.0 
+0900
@@ -61,7 +61,12 @@
 
 2) Download the kexec-tools user-space package from the following URL:
 
-http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar.gz
+http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing.tar.gz
+
+This is a symlink to the latest version, which at the time of writing is
+20061214, the only release of kexec-tools-testing so far. As other versions
+are made released, the older onese will remain available at
+http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/
 
 Note: Latest kexec-tools-testing git tree is available at
 
@@ -71,11 +76,11 @@
 
 3) Unpack the tarball with the tar command, as follows:
 
-   tar xvpzf kexec-tools-testing-20061214.tar.gz
+   tar xvpzf kexec-tools-testing.tar.gz
 
-4) Change to the kexec-tools-1.101 directory, as follows:
+4) Change to the kexec-tools directory, as follows:
 
-   cd kexec-tools-testing-20061214
+   cd kexec-tools-testing-VERSION
 
 5) Configure the package, as follows:
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20

[Horms]

On Wed, Jan 10, 2007 at 02:45:15PM +0530, Vivek Goyal wrote:
> On Wed, Jan 10, 2007 at 11:07:05AM +0530, Mohan Kumar M wrote:
> > On Tue, Jan 09, 2007 at 08:17:08PM +0530, Vivek Goyal wrote:
> > >
> > > Mohan, Can you please check the correctness of ppc64 specific details.
> > >
> > 
> > Vivek,
> > 
> > My inputs.
> > 
> 
> Thanks Mohan. I have updated the document as per your feedback.
> 
> Please find attached the latest patch.
> 
> Thanks
> Vivek
> 
> 
> o Kdump documentation update.
>   - Update details for using relocatable kernel.
>   - Start using kexec-tools-testing release as it is latest and old
> kexec-tools can't load relocatable bzImage file.
>   - Also add kdump on ia64 specific details.
> 
> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>

This seems like a great improvement on the existing document.
Lets get this in the tree and make any further changes from there.
I'll send a patch to add the ia64 details shortly.

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

> ---
> 
>  Documentation/kdump/kdump.txt |  224 
> --
>  1 file changed, 152 insertions(+), 72 deletions(-)
> 
> diff -puN Documentation/kdump/kdump.txt~kdump-documentation-update 
> Documentation/kdump/kdump.txt
> --- 
> linux-2.6.20-rc2-mm1-reloc/Documentation/kdump/kdump.txt~kdump-documentation-update
>2007-01-08 12:32:55.0 +0530
> +++ linux-2.6.20-rc2-mm1-reloc-root/Documentation/kdump/kdump.txt 
> 2007-01-10 14:38:58.0 +0530
> @@ -17,7 +17,7 @@ You can use common Linux commands, such 
>  memory image to a dump file on the local disk, or across the network to
>  a remote system.
>  
> -Kdump and kexec are currently supported on the x86, x86_64, and ppc64
> +Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
>  architectures.
>  
>  When the system kernel boots, it reserves a small section of memory for
> @@ -54,59 +54,64 @@ memory," in two ways:
>  Setup and Installation
>  ==
>  
> -Install kexec-tools and the Kdump patch
> 
> +Install kexec-tools
> +---
>  
>  1) Login as the root user.
>  
>  2) Download the kexec-tools user-space package from the following URL:
>  
> -   http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
> +http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar.gz
>  
> -3) Unpack the tarball with the tar command, as follows:
> -
> -   tar xvpzf kexec-tools-1.101.tar.gz
> -
> -4) Download the latest consolidated Kdump patch from the following URL:
> -
> -   http://lse.sourceforge.net/kdump/
> +Note: Latest kexec-tools-testing git tree is available at
>  
> -   (This location is being used until all the user-space Kdump patches
> -   are integrated with the kexec-tools package.)
> +git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git
> +or
> +http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary
>  
> -5) Change to the kexec-tools-1.101 directory, as follows:
> +3) Unpack the tarball with the tar command, as follows:
>  
> -   cd kexec-tools-1.101
> +   tar xvpzf kexec-tools-testing-20061214.tar.gz
>  
> -6) Apply the consolidated patch to the kexec-tools-1.101 source tree
> -   with the patch command, as follows. (Modify the path to the downloaded
> -   patch as necessary.)
> +4) Change to the kexec-tools-1.101 directory, as follows:
>  
> -   patch -p1 < /path-to-kdump-patch/kexec-tools-1.101-kdump.patch
> +   cd kexec-tools-testing-20061214
>  
> -7) Configure the package, as follows:
> +5) Configure the package, as follows:
>  
> ./configure
>  
> -8) Compile the package, as follows:
> +6) Compile the package, as follows:
>  
> make
>  
> -9) Install the package, as follows:
> +7) Install the package, as follows:
>  
> make install
>  
>  
> -Download and build the system and dump-capture kernels
> ---
> +Build the system and dump-capture kernels
> +-
> +There are two possible methods of using Kdump.
> +
> +1) Build a separate custom dump-capture kernel for capturing the
> +   kernel core dump.
> +
> +2) Or use the system kernel binary itself as dump-capture kernel and there is
> +   no need to build a separate dump-capture kernel. This is possible
> +   only with the architecutres which support a relocatable kernel. As
> +   of today i386 and ia64 architectures support reloc

Re: [PATCH] Kdump documentation update for 2.6.20

[Horms]

On Wed, Jan 10, 2007 at 02:45:15PM +0530, Vivek Goyal wrote:
 On Wed, Jan 10, 2007 at 11:07:05AM +0530, Mohan Kumar M wrote:
  On Tue, Jan 09, 2007 at 08:17:08PM +0530, Vivek Goyal wrote:
  
   Mohan, Can you please check the correctness of ppc64 specific details.
  
  
  Vivek,
  
  My inputs.
  
 
 Thanks Mohan. I have updated the document as per your feedback.
 
 Please find attached the latest patch.
 
 Thanks
 Vivek
 
 
 o Kdump documentation update.
   - Update details for using relocatable kernel.
   - Start using kexec-tools-testing release as it is latest and old
 kexec-tools can't load relocatable bzImage file.
   - Also add kdump on ia64 specific details.
 
 Signed-off-by: Vivek Goyal [EMAIL PROTECTED]

This seems like a great improvement on the existing document.
Lets get this in the tree and make any further changes from there.
I'll send a patch to add the ia64 details shortly.

Signed-off-by: Simon Horman [EMAIL PROTECTED]

 ---
 
  Documentation/kdump/kdump.txt |  224 
 --
  1 file changed, 152 insertions(+), 72 deletions(-)
 
 diff -puN Documentation/kdump/kdump.txt~kdump-documentation-update 
 Documentation/kdump/kdump.txt
 --- 
 linux-2.6.20-rc2-mm1-reloc/Documentation/kdump/kdump.txt~kdump-documentation-update
2007-01-08 12:32:55.0 +0530
 +++ linux-2.6.20-rc2-mm1-reloc-root/Documentation/kdump/kdump.txt 
 2007-01-10 14:38:58.0 +0530
 @@ -17,7 +17,7 @@ You can use common Linux commands, such 
  memory image to a dump file on the local disk, or across the network to
  a remote system.
  
 -Kdump and kexec are currently supported on the x86, x86_64, and ppc64
 +Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
  architectures.
  
  When the system kernel boots, it reserves a small section of memory for
 @@ -54,59 +54,64 @@ memory, in two ways:
  Setup and Installation
  ==
  
 -Install kexec-tools and the Kdump patch
 
 +Install kexec-tools
 +---
  
  1) Login as the root user.
  
  2) Download the kexec-tools user-space package from the following URL:
  
 -   http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
 +http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar.gz
  
 -3) Unpack the tarball with the tar command, as follows:
 -
 -   tar xvpzf kexec-tools-1.101.tar.gz
 -
 -4) Download the latest consolidated Kdump patch from the following URL:
 -
 -   http://lse.sourceforge.net/kdump/
 +Note: Latest kexec-tools-testing git tree is available at
  
 -   (This location is being used until all the user-space Kdump patches
 -   are integrated with the kexec-tools package.)
 +git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git
 +or
 +http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary
  
 -5) Change to the kexec-tools-1.101 directory, as follows:
 +3) Unpack the tarball with the tar command, as follows:
  
 -   cd kexec-tools-1.101
 +   tar xvpzf kexec-tools-testing-20061214.tar.gz
  
 -6) Apply the consolidated patch to the kexec-tools-1.101 source tree
 -   with the patch command, as follows. (Modify the path to the downloaded
 -   patch as necessary.)
 +4) Change to the kexec-tools-1.101 directory, as follows:
  
 -   patch -p1  /path-to-kdump-patch/kexec-tools-1.101-kdump.patch
 +   cd kexec-tools-testing-20061214
  
 -7) Configure the package, as follows:
 +5) Configure the package, as follows:
  
 ./configure
  
 -8) Compile the package, as follows:
 +6) Compile the package, as follows:
  
 make
  
 -9) Install the package, as follows:
 +7) Install the package, as follows:
  
 make install
  
  
 -Download and build the system and dump-capture kernels
 ---
 +Build the system and dump-capture kernels
 +-
 +There are two possible methods of using Kdump.
 +
 +1) Build a separate custom dump-capture kernel for capturing the
 +   kernel core dump.
 +
 +2) Or use the system kernel binary itself as dump-capture kernel and there is
 +   no need to build a separate dump-capture kernel. This is possible
 +   only with the architecutres which support a relocatable kernel. As
 +   of today i386 and ia64 architectures support relocatable kernel.
 +
 +Building a relocatable kernel is advantageous from the point of view that
 +one does not have to build a second kernel for capturing the dump. But
 +at the same time one might want to build a custom dump capture kernel
 +suitable to his needs.
  
 -Download the mainline (vanilla) kernel source code (2.6.13-rc1 or newer)
 -from http://www.kernel.org. Two kernels must be built: a system kernel
 -and a dump-capture kernel. Use the following steps to configure these
 -kernels with the necessary kexec and Kdump features:
 +Following

[PATCH] Kdump documentation update for 2.6.20: ia64 portion

[Horms]

Hi,

this patch fills in the portions for ia64 kexec.

I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.

This patch requires the documentation patch update that Vivek Goyal has
been circulating, and I believe is currently in mm. Feel free to fold it
into that change if it makes things easier for anyone.

Signed-off-by: Simon Horman [EMAIL PROTECTED]

Index: linux-2.6/Documentation/kdump/kdump.txt
===
--- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
14:37:46.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 14:46:53.0 
+0900
@@ -17,7 +17,7 @@
 memory image to a dump file on the local disk, or across the network to
 a remote system.
 
-Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
+Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
 architectures.
 
 When the system kernel boots, it reserves a small section of memory for
@@ -227,7 +227,11 @@
 
 Dump-capture kernel config options (Arch Dependent, ia64)
 --
-(To be filled)
+
+- No specific options are required to create a dump-capture kernel
+  for ia64 other than those specified in the arch idependent section
+  above. This means that it is possible to use the system kernel
+  as a dump-capture kernel if desired.
 
 
 Boot into System Kernel
@@ -264,7 +268,8 @@
 For ppc64:
- Use vmlinux
 For ia64:
-   (To be filled)
+   - Use vmlinux
+
 
 If you are using a uncompressed vmlinux image then use following command
 to load dump-capture kernel.
@@ -280,18 +285,19 @@
--initrd=initrd-for-dump-capture-kernel \
--append=root=root-dev arch-specific-options
 
+Please note, that --args-linux does not need to be specified for ia64.
+It is planned to make this a no-op on that architecture, but for now
+it should be omitted
+
 Following are the arch specific command line options to be used while
 loading dump-capture kernel.
 
-For i386 and x86_64:
+For i386, x86_64 and ia64:
init 1 irqpoll maxcpus=1
 
 For ppc64:
init 1 maxcpus=1 noirqdistrib
 
-For IA64
-   (To be filled)
-
 
 Notes on loading the dump-capture kernel:
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Kdump documentation update for 2.6.20: kexec-tools update

[Horms]

Hi,

Mohan Kumar suggested making kexec-tools-testing.tar.gz a link
to the latest version. I have done this and this patch updates the
documentation accordingly.

This patch requires the documentation patch update that Vivek Goyal has
been circulating, and I believe is currently in mm. Feel free to fold it
into that change if it makes things easier for anyone.

Signed-off-by: Simon Horman [EMAIL PROTECTED]

Index: linux-2.6/Documentation/kdump/kdump.txt
===
--- linux-2.6.orig/Documentation/kdump/kdump.txt2007-01-12 
14:37:18.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 14:56:42.0 
+0900
@@ -61,7 +61,12 @@
 
 2) Download the kexec-tools user-space package from the following URL:
 
-http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar.gz
+http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing.tar.gz
+
+This is a symlink to the latest version, which at the time of writing is
+20061214, the only release of kexec-tools-testing so far. As other versions
+are made released, the older onese will remain available at
+http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/
 
 Note: Latest kexec-tools-testing git tree is available at
 
@@ -71,11 +76,11 @@
 
 3) Unpack the tarball with the tar command, as follows:
 
-   tar xvpzf kexec-tools-testing-20061214.tar.gz
+   tar xvpzf kexec-tools-testing.tar.gz
 
-4) Change to the kexec-tools-1.101 directory, as follows:
+4) Change to the kexec-tools directory, as follows:
 
-   cd kexec-tools-testing-20061214
+   cd kexec-tools-testing-VERSION
 
 5) Configure the package, as follows:
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20

[Horms]

On Wed, Jan 10, 2007 at 09:34:12AM +0800, Zou, Nanhai wrote:
> > >
> > > I am hoping it --args-linux will be required while loading vmlinux on
> > > IA64? Because this is ELF file specific option. And this interface should
> > > be common across all the architectures.
> > >
> > > > Then again, I could be wrong, I'm not sure that I understand
> > > > --args-linux, I just know that I'm not using it :)
> > 
> > I will take a look into this.
> > 
>  args-linux is not support by IA64 kdump. 
> To have common interface, maybe we should support it by ignore this
> arg like ppc does.

That sounds reasonable to me. Vivek, what do you think?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20

[Horms]

On Tue, Jan 09, 2007 at 08:17:08PM +0530, Vivek Goyal wrote:
> On Tue, Jan 09, 2007 at 10:18:47AM +0900, Horms wrote:
> > >  Download and build the system and dump-capture kernels
> > >  --
> > > +There are two possible methods of using Kdump.
> > > +
> > > + 1) Build a separate custom dump-capture kernel for capturing the
> > > +kernel core dump.
> > > +
> > > + 2) Use system kernel itself as dump-capture kernel and there is
> > > +no need to build a separate dump-capture kernel. (Only for
> > > +i386 architecture kernel version 2.6.20 onwards)
> > > +
> > > +For i386, second method is recommended, as it takes away the need to 
> > > build
> > > +additional kernel.
> > 
> > I think that the above description is a little misleading, and quite
> > i386 centric. The question is not weather or not you are using the
> > system kernel, but rather, what options are needed for the crash kernel.
> > 
> Hi Horms,
> 
> Thanks for going through the update. Actually I never knew that kdump
> IA64 support is mainline now. I thought it is still in Tony's tree. And
> we never had IA64 specific documentation in kdump.txt file and that's another
> reason that discussion became more i386 centric when it came to relocatable
> kernels.

It wasn't that long ago it was merged, but its there now :)

> > In terms of a non-relocatable kernel, then the boot and crash kernels
> > need to be separate.
> > 
> > But in the case of a relocatable kernel, then the boot and crash kernels
> > may be the same, or they may be separate. Depending on just what
> > the end-user wants in each kernel.
> > 
> > On ia64 there is no CONFIG_RELOCATABLE option, but the kernel is always
> > relocatable anyway. That is, you can use the same kernel before and
> > after crash (though I am not sure that I have tested this).
> > 
> 
> I have tried to re-arrange the documentation based on some of your 
> recommendations. I have also left couple of sections empty which are
> ia64 specific. I don't have an IA64 machine and I don't know how exactly
> it is used on IA64. Can you please have a quick look at the patch and
> also fill IA64 specific details where appropriate.

Sure, will do.

> Hopefully, this time documentation is clearer.
> 
> 
> Mohan, Can you please check the correctness of ppc64 specific details.
> 
> > > +   --append="root= init 1 irqpoll maxcpus=1"
> > > +
> > > +If you are using a relocatable kernel (method 2), then use
> > > +following command.
> > >
> > > +   kexec -p  \
> > > +   --initrd= \
> > > +   --append="root= init 1 irqpoll maxcpus=1"
> > 
> > --args-linux is not needed on ia64, but its kernel is relocatable.
> > I think the important point is that if you are using a bzImage,
> > then you need --args-linux, and basically at this point that
> > means an i386 (or x86_64) relocatable bzImage.
> > 
> 
> I am hoping it --args-linux will be required while loading vmlinux on
> IA64? Because this is ELF file specific option. And this interface should
> be common across all the architectures.
> 
> > Then again, I could be wrong, I'm not sure that I understand
> > --args-linux, I just know that I'm not using it :)

I will take a look into this.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20

[Horms]

On Tue, Jan 09, 2007 at 08:17:08PM +0530, Vivek Goyal wrote:
 On Tue, Jan 09, 2007 at 10:18:47AM +0900, Horms wrote:
Download and build the system and dump-capture kernels
--
   +There are two possible methods of using Kdump.
   +
   + 1) Build a separate custom dump-capture kernel for capturing the
   +kernel core dump.
   +
   + 2) Use system kernel itself as dump-capture kernel and there is
   +no need to build a separate dump-capture kernel. (Only for
   +i386 architecture kernel version 2.6.20 onwards)
   +
   +For i386, second method is recommended, as it takes away the need to 
   build
   +additional kernel.
  
  I think that the above description is a little misleading, and quite
  i386 centric. The question is not weather or not you are using the
  system kernel, but rather, what options are needed for the crash kernel.
  
 Hi Horms,
 
 Thanks for going through the update. Actually I never knew that kdump
 IA64 support is mainline now. I thought it is still in Tony's tree. And
 we never had IA64 specific documentation in kdump.txt file and that's another
 reason that discussion became more i386 centric when it came to relocatable
 kernels.

It wasn't that long ago it was merged, but its there now :)

  In terms of a non-relocatable kernel, then the boot and crash kernels
  need to be separate.
  
  But in the case of a relocatable kernel, then the boot and crash kernels
  may be the same, or they may be separate. Depending on just what
  the end-user wants in each kernel.
  
  On ia64 there is no CONFIG_RELOCATABLE option, but the kernel is always
  relocatable anyway. That is, you can use the same kernel before and
  after crash (though I am not sure that I have tested this).
  
 
 I have tried to re-arrange the documentation based on some of your 
 recommendations. I have also left couple of sections empty which are
 ia64 specific. I don't have an IA64 machine and I don't know how exactly
 it is used on IA64. Can you please have a quick look at the patch and
 also fill IA64 specific details where appropriate.

Sure, will do.

 Hopefully, this time documentation is clearer.
 
 
 Mohan, Can you please check the correctness of ppc64 specific details.
 
   +   --append=root=root-dev init 1 irqpoll maxcpus=1
   +
   +If you are using a relocatable kernel (method 2), then use
   +following command.
  
   +   kexec -p bzImage-of-relocatable-kernel \
   +   --initrd=initrd-for-relocatable-kernel \
   +   --append=root=root-dev init 1 irqpoll maxcpus=1
  
  --args-linux is not needed on ia64, but its kernel is relocatable.
  I think the important point is that if you are using a bzImage,
  then you need --args-linux, and basically at this point that
  means an i386 (or x86_64) relocatable bzImage.
  
 
 I am hoping it --args-linux will be required while loading vmlinux on
 IA64? Because this is ELF file specific option. And this interface should
 be common across all the architectures.
 
  Then again, I could be wrong, I'm not sure that I understand
  --args-linux, I just know that I'm not using it :)

I will take a look into this.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20

[Horms]

On Wed, Jan 10, 2007 at 09:34:12AM +0800, Zou, Nanhai wrote:
  
   I am hoping it --args-linux will be required while loading vmlinux on
   IA64? Because this is ELF file specific option. And this interface should
   be common across all the architectures.
  
Then again, I could be wrong, I'm not sure that I understand
--args-linux, I just know that I'm not using it :)
  
  I will take a look into this.
  
  args-linux is not support by IA64 kdump. 
 To have common interface, maybe we should support it by ignore this
 arg like ppc does.

That sounds reasonable to me. Vivek, what do you think?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kdump documentation update for 2.6.20

[Horms]

On Mon, Jan 08, 2007 at 01:28:03PM +0530, Vivek Goyal wrote:
> 
> 
> 
> o Kdump documentation update.
>   - Update details for using relocatable kernel.
>   - Start using kexec-tools-testing release as it is latest and old
> kexec-tools can't load relocatable bzImage file.
> 
> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
> ---
> 
>  Documentation/kdump/kdump.txt |  160 
> ++
>  1 file changed, 130 insertions(+), 30 deletions(-)
> 
> diff -puN Documentation/kdump/kdump.txt~kdump-documentation-update 
> Documentation/kdump/kdump.txt
> --- 
> linux-2.6.20-rc2-mm1-reloc/Documentation/kdump/kdump.txt~kdump-documentation-update
>2007-01-08 10:01:50.0 +0530
> +++ linux-2.6.20-rc2-mm1-reloc-root/Documentation/kdump/kdump.txt 
> 2007-01-08 11:51:49.0 +0530
> @@ -54,56 +54,68 @@ memory," in two ways:
>  Setup and Installation
>  ==
>  
> -Install kexec-tools and the Kdump patch
> 
> +Install kexec-tools
> +---
>  
>  1) Login as the root user.
>  
>  2) Download the kexec-tools user-space package from the following URL:
>  
> -   http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
> +http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar.gz
>  
> -3) Unpack the tarball with the tar command, as follows:
> -
> -   tar xvpzf kexec-tools-1.101.tar.gz
> -
> -4) Download the latest consolidated Kdump patch from the following URL:
> -
> -   http://lse.sourceforge.net/kdump/
> +Note: Latest kexec-tools-testing git tree is available at
>  
> -   (This location is being used until all the user-space Kdump patches
> -   are integrated with the kexec-tools package.)
> +git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git
> +or
> +http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary
>  
> -5) Change to the kexec-tools-1.101 directory, as follows:
> +3) Unpack the tarball with the tar command, as follows:
>  
> -   cd kexec-tools-1.101
> +   tar xvpzf kexec-tools-testing-20061214.tar.gz
>  
> -6) Apply the consolidated patch to the kexec-tools-1.101 source tree
> -   with the patch command, as follows. (Modify the path to the downloaded
> -   patch as necessary.)
> +4) Change to the kexec-tools-1.101 directory, as follows:
>  
> -   patch -p1 < /path-to-kdump-patch/kexec-tools-1.101-kdump.patch
> +   cd kexec-tools-testing-20061214
>  
> -7) Configure the package, as follows:
> +5) Configure the package, as follows:
>  
> ./configure
>  
> -8) Compile the package, as follows:
> +6) Compile the package, as follows:
>  
> make
>  
> -9) Install the package, as follows:
> +7) Install the package, as follows:
>  
> make install
>  
>  
>  Download and build the system and dump-capture kernels
>  --
> +There are two possible methods of using Kdump.
> +
> + 1) Build a separate custom dump-capture kernel for capturing the
> +kernel core dump.
> +
> + 2) Use system kernel itself as dump-capture kernel and there is
> +no need to build a separate dump-capture kernel. (Only for
> +i386 architecture kernel version 2.6.20 onwards)
> +
> +For i386, second method is recommended, as it takes away the need to build
> +additional kernel.

I think that the above description is a little misleading, and quite
i386 centric. The question is not weather or not you are using the
system kernel, but rather, what options are needed for the crash kernel.

In terms of a non-relocatable kernel, then the boot and crash kernels
need to be separate.

But in the case of a relocatable kernel, then the boot and crash kernels
may be the same, or they may be separate. Depending on just what
the end-user wants in each kernel.

On ia64 there is no CONFIG_RELOCATABLE option, but the kernel is always
relocatable anyway. That is, you can use the same kernel before and
after crash (though I am not sure that I have tested this).

I'm not sure about ppc64.

I think that the description of how to build the kernels also needs to
be reworked a little to reflect this. Perhaps you could divide the
methods based on vmlinuz/bzImage, rather than
non-relocatable/relocatable (or custom kernel/system kernel?). It seems
that it is the former, rather than the later that has impact on how
things work.

> +
> +If you decide to use second option (Relocatable kernel), then directly jump 
> to
> +the section "Method 2".
> +
> +Method 1:
> +
>  
>  Download the mainline (vanilla) kern

Re: [PATCH] Kdump documentation update for 2.6.20

[Horms]

On Mon, Jan 08, 2007 at 01:28:03PM +0530, Vivek Goyal wrote:
 
 
 
 o Kdump documentation update.
   - Update details for using relocatable kernel.
   - Start using kexec-tools-testing release as it is latest and old
 kexec-tools can't load relocatable bzImage file.
 
 Signed-off-by: Vivek Goyal [EMAIL PROTECTED]
 ---
 
  Documentation/kdump/kdump.txt |  160 
 ++
  1 file changed, 130 insertions(+), 30 deletions(-)
 
 diff -puN Documentation/kdump/kdump.txt~kdump-documentation-update 
 Documentation/kdump/kdump.txt
 --- 
 linux-2.6.20-rc2-mm1-reloc/Documentation/kdump/kdump.txt~kdump-documentation-update
2007-01-08 10:01:50.0 +0530
 +++ linux-2.6.20-rc2-mm1-reloc-root/Documentation/kdump/kdump.txt 
 2007-01-08 11:51:49.0 +0530
 @@ -54,56 +54,68 @@ memory, in two ways:
  Setup and Installation
  ==
  
 -Install kexec-tools and the Kdump patch
 
 +Install kexec-tools
 +---
  
  1) Login as the root user.
  
  2) Download the kexec-tools user-space package from the following URL:
  
 -   http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
 +http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar.gz
  
 -3) Unpack the tarball with the tar command, as follows:
 -
 -   tar xvpzf kexec-tools-1.101.tar.gz
 -
 -4) Download the latest consolidated Kdump patch from the following URL:
 -
 -   http://lse.sourceforge.net/kdump/
 +Note: Latest kexec-tools-testing git tree is available at
  
 -   (This location is being used until all the user-space Kdump patches
 -   are integrated with the kexec-tools package.)
 +git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git
 +or
 +http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary
  
 -5) Change to the kexec-tools-1.101 directory, as follows:
 +3) Unpack the tarball with the tar command, as follows:
  
 -   cd kexec-tools-1.101
 +   tar xvpzf kexec-tools-testing-20061214.tar.gz
  
 -6) Apply the consolidated patch to the kexec-tools-1.101 source tree
 -   with the patch command, as follows. (Modify the path to the downloaded
 -   patch as necessary.)
 +4) Change to the kexec-tools-1.101 directory, as follows:
  
 -   patch -p1  /path-to-kdump-patch/kexec-tools-1.101-kdump.patch
 +   cd kexec-tools-testing-20061214
  
 -7) Configure the package, as follows:
 +5) Configure the package, as follows:
  
 ./configure
  
 -8) Compile the package, as follows:
 +6) Compile the package, as follows:
  
 make
  
 -9) Install the package, as follows:
 +7) Install the package, as follows:
  
 make install
  
  
  Download and build the system and dump-capture kernels
  --
 +There are two possible methods of using Kdump.
 +
 + 1) Build a separate custom dump-capture kernel for capturing the
 +kernel core dump.
 +
 + 2) Use system kernel itself as dump-capture kernel and there is
 +no need to build a separate dump-capture kernel. (Only for
 +i386 architecture kernel version 2.6.20 onwards)
 +
 +For i386, second method is recommended, as it takes away the need to build
 +additional kernel.

I think that the above description is a little misleading, and quite
i386 centric. The question is not weather or not you are using the
system kernel, but rather, what options are needed for the crash kernel.

In terms of a non-relocatable kernel, then the boot and crash kernels
need to be separate.

But in the case of a relocatable kernel, then the boot and crash kernels
may be the same, or they may be separate. Depending on just what
the end-user wants in each kernel.

On ia64 there is no CONFIG_RELOCATABLE option, but the kernel is always
relocatable anyway. That is, you can use the same kernel before and
after crash (though I am not sure that I have tested this).

I'm not sure about ppc64.

I think that the description of how to build the kernels also needs to
be reworked a little to reflect this. Perhaps you could divide the
methods based on vmlinuz/bzImage, rather than
non-relocatable/relocatable (or custom kernel/system kernel?). It seems
that it is the former, rather than the later that has impact on how
things work.

 +
 +If you decide to use second option (Relocatable kernel), then directly jump 
 to
 +the section Method 2.
 +
 +Method 1:
 +
  
  Download the mainline (vanilla) kernel source code (2.6.13-rc1 or newer)
 -from http://www.kernel.org. Two kernels must be built: a system kernel
 -and a dump-capture kernel. Use the following steps to configure these
 -kernels with the necessary kexec and Kdump features:
 +from http://www.kernel.org.
 +
 +Two kernels must be built: a system kernel and a dump-capture kernel.
 +Use the following steps to configure these kernels with the necessary kexec
 +and Kdump features

Re: [patch] linux/preempt.h needs linux/thread_info.h

[Horms]

On Wed, Dec 27, 2006 at 08:27:02AM +, Al Viro wrote:
> On Wed, Dec 27, 2006 at 05:17:02PM +0900, Horms wrote:
> > It seems that linux/preempt.h needs to include linux/thread_info.h
> > in order to access current_thread_info(), which is used in
> > preempt_count().
> > 
> > I guess that all callers of preempt_count() must include
> > both linux/thread_info.h and linux/preempt.h directly or indirectly,
> > as this does not cause a compile error. I noticed the problem while
> > working on an unrelated issue in xen-land.
> > 
> > Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
> > 
> > Index: linux-2.6/include/linux/preempt.h
> > ===
> > --- linux-2.6.orig/include/linux/preempt.h  2006-12-27 16:58:46.0 
> > +0900
> > +++ linux-2.6/include/linux/preempt.h   2006-12-27 17:13:12.0 
> > +0900
> > @@ -8,6 +8,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> 
> Huh?  It's just been included two lines above...

Sorry about that. I mucked around with this for a while
and ended up missing the obvious when doing the forward-port.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] linux/preempt.h needs linux/thread_info.h

[Horms]

It seems that linux/preempt.h needs to include linux/thread_info.h
in order to access current_thread_info(), which is used in
preempt_count().

I guess that all callers of preempt_count() must include
both linux/thread_info.h and linux/preempt.h directly or indirectly,
as this does not cause a compile error. I noticed the problem while
working on an unrelated issue in xen-land.

Signed-off-by: Simon Horman <[EMAIL PROTECTED]>

Index: linux-2.6/include/linux/preempt.h
===
--- linux-2.6.orig/include/linux/preempt.h  2006-12-27 16:58:46.0 
+0900
+++ linux-2.6/include/linux/preempt.h   2006-12-27 17:13:12.0 +0900
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_DEBUG_PREEMPT
   extern void fastcall add_preempt_count(int val);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] linux/preempt.h needs linux/thread_info.h

[Horms]

It seems that linux/preempt.h needs to include linux/thread_info.h
in order to access current_thread_info(), which is used in
preempt_count().

I guess that all callers of preempt_count() must include
both linux/thread_info.h and linux/preempt.h directly or indirectly,
as this does not cause a compile error. I noticed the problem while
working on an unrelated issue in xen-land.

Signed-off-by: Simon Horman [EMAIL PROTECTED]

Index: linux-2.6/include/linux/preempt.h
===
--- linux-2.6.orig/include/linux/preempt.h  2006-12-27 16:58:46.0 
+0900
+++ linux-2.6/include/linux/preempt.h   2006-12-27 17:13:12.0 +0900
@@ -8,6 +8,7 @@
 
 #include linux/thread_info.h
 #include linux/linkage.h
+#include linux/thread_info.h
 
 #ifdef CONFIG_DEBUG_PREEMPT
   extern void fastcall add_preempt_count(int val);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] linux/preempt.h needs linux/thread_info.h

[Horms]

On Wed, Dec 27, 2006 at 08:27:02AM +, Al Viro wrote:
 On Wed, Dec 27, 2006 at 05:17:02PM +0900, Horms wrote:
  It seems that linux/preempt.h needs to include linux/thread_info.h
  in order to access current_thread_info(), which is used in
  preempt_count().
  
  I guess that all callers of preempt_count() must include
  both linux/thread_info.h and linux/preempt.h directly or indirectly,
  as this does not cause a compile error. I noticed the problem while
  working on an unrelated issue in xen-land.
  
  Signed-off-by: Simon Horman [EMAIL PROTECTED]
  
  Index: linux-2.6/include/linux/preempt.h
  ===
  --- linux-2.6.orig/include/linux/preempt.h  2006-12-27 16:58:46.0 
  +0900
  +++ linux-2.6/include/linux/preempt.h   2006-12-27 17:13:12.0 
  +0900
  @@ -8,6 +8,7 @@
   
   #include linux/thread_info.h
   #include linux/linkage.h
  +#include linux/thread_info.h
 
 Huh?  It's just been included two lines above...

Sorry about that. I mucked around with this for a while
and ended up missing the obvious when doing the forward-port.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] free initrds boot option

[Horms]

On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
> > >Is there a kexec-tools patch too? How does second kernel know about
> > >the location of the first kernel's initrd to be reused?
> > >  
> > >
> > kexec-tools has to be modified to pass the first kernel initrd. On 
> > powerpc, initrd locations are exported using device-tree. At present, 
> > kexec-tool ignores the first kernel initrd property values and creates 
> > new initrd properties if the user passes '--initrd' option to the kexec 
> > command. So, will be an issue unless first kernel device-tree is passed 
> > as buffer.
> 
> We've been using the --devicetreeblob kexec-tools option available for
> POWERPC.  This enables you to setup the device tree (and hence, the
> initrd points) as you like.
> 
> I'm happy to put together a patch for kexec-tools. 

Please do. And please cc me on a copy that applies against kexec-tools-testing.

> Unfortunately this
> is arch specific.  A quick look through the x86, ia64, s390 and ppc64
> code shows the --initrd option for all these just reads the specified
> initrd file, pushes it out to memory and uses the base and size pointers
> to setup the next boot.  We'd obviously just skip to the last stage.
> 
> So what's the kexec-tools option called?  --initrd-location  ?

That sounds fine to me. I think its ok to make it arch specific for
starters and then move it out to generic code later. That said, if
you're feeling particularly entergetic, feel free to do the generic
stuff now and just add null stubs for the other architectures (does
that makes sense?).

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] free initrds boot option

[Horms]

On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
  Is there a kexec-tools patch too? How does second kernel know about
  the location of the first kernel's initrd to be reused?

  
  kexec-tools has to be modified to pass the first kernel initrd. On 
  powerpc, initrd locations are exported using device-tree. At present, 
  kexec-tool ignores the first kernel initrd property values and creates 
  new initrd properties if the user passes '--initrd' option to the kexec 
  command. So, will be an issue unless first kernel device-tree is passed 
  as buffer.
 
 We've been using the --devicetreeblob kexec-tools option available for
 POWERPC.  This enables you to setup the device tree (and hence, the
 initrd points) as you like.
 
 I'm happy to put together a patch for kexec-tools. 

Please do. And please cc me on a copy that applies against kexec-tools-testing.

 Unfortunately this
 is arch specific.  A quick look through the x86, ia64, s390 and ppc64
 code shows the --initrd option for all these just reads the specified
 initrd file, pushes it out to memory and uses the base and size pointers
 to setup the next boot.  We'd obviously just skip to the last stage.
 
 So what's the kexec-tools option called?  --initrd-location base size?

That sounds fine to me. I think its ok to make it arch specific for
starters and then move it out to generic code later. That said, if
you're feeling particularly entergetic, feel free to do the generic
stuff now and just add null stubs for the other architectures (does
that makes sense?).

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problems Building Bluetooth with K6 and CONFIG_REGPARM

[Horms]

On Thu, Sep 08, 2005 at 12:49:17PM -0400, Brian Gerst wrote:
> Horms wrote:
> >Hi Andy,
> >
> >that does indeed seem to be a problem. I have narrowed it down to
> >a combination of using K6 and CONFIG_REGPARM. Hunting around a bit
> >I found this http://my.execpc.com/~geezer/osd/gotchas/, which
> >suggests the problem is that the asm in question tries to add a register
> >to the clobber list which is not available. This makes sense,
> >I guess REGPARM is using edx, so inline assembly can't.
> >
> >I've CCed the bluetooth maintainers and lkml, hopefully someone there
> >will have some input on how to resolve this problem, as inline assembly
> >isn't my strong point and the problem seems to manifest in Linus' current
> >git tree. 
> >
> >The relevant code is the following call to BUILDIO(b,b,char) towards the
> >bottom of include/asm/io.h
> >
> >BUILDIO is as follows, and I am guessing it is the "Nd"(port) and
> >possibley "d"(port) portions that are problematic.
> 
> Sounds like a compiler bug, especially since changing the CPU type fixes 
> it.  What version of GCC?

I definately think it is compiler related, 
I was using Debian's GCC 4.0.1-6. I could try 
with 3.3 or soemthing like that if you like.

The problem was easily reproducable with
4.0.1 and a K6+CONFIG_REGPARM config.

-- 
Horms
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Problems Building Bluetooth with K6 and CONFIG_REGPARM

[Horms]

Hi Andy,

that does indeed seem to be a problem. I have narrowed it down to
a combination of using K6 and CONFIG_REGPARM. Hunting around a bit
I found this http://my.execpc.com/~geezer/osd/gotchas/, which
suggests the problem is that the asm in question tries to add a register
to the clobber list which is not available. This makes sense,
I guess REGPARM is using edx, so inline assembly can't.

I've CCed the bluetooth maintainers and lkml, hopefully someone there
will have some input on how to resolve this problem, as inline assembly
isn't my strong point and the problem seems to manifest in Linus' current
git tree. 

The relevant code is the following call to BUILDIO(b,b,char) towards the
bottom of include/asm/io.h

BUILDIO is as follows, and I am guessing it is the "Nd"(port) and
possibley "d"(port) portions that are problematic.

#define BUILDIO(bwl,bw,type) \
static inline void out##bwl##_local(unsigned type value, int port) { \
__asm__ __volatile__("out" #bwl " %" #bw "0, %w1" : : "a"(value), 
"Nd"(port)); \
} \
static inline unsigned type in##bwl##_local(int port) { \
unsigned type value; \
__asm__ __volatile__("in" #bwl " %w1, %" #bw "0" : "=a"(value) : 
"Nd"(port)); \
return value; \
} \
static inline void out##bwl##_local_p(unsigned type value, int port) { \
out##bwl##_local(value, port); \
slow_down_io(); \
} \
static inline unsigned type in##bwl##_local_p(int port) { \
unsigned type value = in##bwl##_local(port); \
slow_down_io(); \
return value; \
} \
__BUILDIO(bwl,bw,type) \
static inline void out##bwl##_p(unsigned type value, int port) { \
out##bwl(value, port); \
slow_down_io(); \
} \
static inline unsigned type in##bwl##_p(int port) { \
unsigned type value = in##bwl(port); \
slow_down_io(); \
return value; \
} \
static inline void outs##bwl(int port, const void *addr, unsigned long count) { 
\
__asm__ __volatile__("rep; outs" #bwl : "+S"(addr), "+c"(count) : 
"d"(port)); \
} \
static inline void ins##bwl(int port, void *addr, unsigned long count) { \
__asm__ __volatile__("rep; ins" #bwl : "+D"(addr), "+c"(count) : 
"d"(port)); \
}

-- 
Horms


On Sat, Sep 03, 2005 at 10:49:48AM -0700, [EMAIL PROTECTED] wrote:
> Package: linux-source-2.6.12
> Version: 2.6.12-5
> Severity: normal
> 
> # make-kpkg --initrd --append-to-version=-ahrairah --revision=ahrairah.1
> kernel-image modules-image
> 
>   CC [M]  drivers/bluetooth/bfusb.o
>   CC [M]  drivers/bluetooth/dtl1_cs.o
> drivers/bluetooth/dtl1_cs.c: In function 'dtl1_write':
> include/asm/io.h:377: error: can't find a register in class 'DREG' while
>   reloading 'asm'
> make[3]: *** [drivers/bluetooth/dtl1_cs.o] Error 1
> make[2]: *** [drivers/bluetooth] Error 2
> make[1]: *** [drivers] Error 2
> make[1]: Leaving directory `/usr/src/linux-source-2.6.12'
> make: *** [stamp-build] Error 2
> 
> Change CPU type to K7 and it builds successfully.
> 
> 
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers testing
>   APT policy: (500, 'testing'), (100, 'unstable'), (99, 'experimental')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.12.local
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> 
> Versions of packages linux-source-2.6.12 depends on:
> ii  binutils  2.16.1-2   The GNU assembler, linker and 
> bina
> ii  bzip2 1.0.2-8high-quality block-sorting file 
> co
> ii  coreutils [fileutils] 5.2.1-2ubuntu0 The GNU core utilities
> 
> Versions of packages linux-source-2.6.12 recommends:
> ii  gcc   4:4.0.1-3  The GNU C compiler
> ii  libc6-dev [libc-dev]  2.3.5-4GNU C Library: Development 
> Librari
> ii  make  3.80-9 The GNU version of the "make" 
> util
> 
> -- no debconf information

> #
> # Automatically generated make config: don't edit
> # Linux kernel version: 2.6.12-ahrairah
> # Sat Sep  3 09:11:09 2005
> #
> CONFIG_X86=y
> CONFIG_MMU=y
> CONFIG_UID16=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_IOMAP=y
> 
> #
> # Code maturity level options
> #
> CONFIG_EXPERIMENTAL=y
> CONFIG_CLEAN_COMPILE=y
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_LOCK_KERNEL=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> 
> #
> # General setup
> #
> CONFIG_LOCALVERSION=""
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_BSD_PROCESS_ACCT=y
> CONFIG_BSD_PROCESS_ACCT_V3=y
> CONFIG_SYSCTL=y
> CONFIG_AUDIT=y
> CONFIG_AU

Problems Building Bluetooth with K6 and CONFIG_REGPARM

[Horms]

Hi Andy,

that does indeed seem to be a problem. I have narrowed it down to
a combination of using K6 and CONFIG_REGPARM. Hunting around a bit
I found this http://my.execpc.com/~geezer/osd/gotchas/, which
suggests the problem is that the asm in question tries to add a register
to the clobber list which is not available. This makes sense,
I guess REGPARM is using edx, so inline assembly can't.

I've CCed the bluetooth maintainers and lkml, hopefully someone there
will have some input on how to resolve this problem, as inline assembly
isn't my strong point and the problem seems to manifest in Linus' current
git tree. 

The relevant code is the following call to BUILDIO(b,b,char) towards the
bottom of include/asm/io.h

BUILDIO is as follows, and I am guessing it is the Nd(port) and
possibley d(port) portions that are problematic.

#define BUILDIO(bwl,bw,type) \
static inline void out##bwl##_local(unsigned type value, int port) { \
__asm__ __volatile__(out #bwl  % #bw 0, %w1 : : a(value), 
Nd(port)); \
} \
static inline unsigned type in##bwl##_local(int port) { \
unsigned type value; \
__asm__ __volatile__(in #bwl  %w1, % #bw 0 : =a(value) : 
Nd(port)); \
return value; \
} \
static inline void out##bwl##_local_p(unsigned type value, int port) { \
out##bwl##_local(value, port); \
slow_down_io(); \
} \
static inline unsigned type in##bwl##_local_p(int port) { \
unsigned type value = in##bwl##_local(port); \
slow_down_io(); \
return value; \
} \
__BUILDIO(bwl,bw,type) \
static inline void out##bwl##_p(unsigned type value, int port) { \
out##bwl(value, port); \
slow_down_io(); \
} \
static inline unsigned type in##bwl##_p(int port) { \
unsigned type value = in##bwl(port); \
slow_down_io(); \
return value; \
} \
static inline void outs##bwl(int port, const void *addr, unsigned long count) { 
\
__asm__ __volatile__(rep; outs #bwl : +S(addr), +c(count) : 
d(port)); \
} \
static inline void ins##bwl(int port, void *addr, unsigned long count) { \
__asm__ __volatile__(rep; ins #bwl : +D(addr), +c(count) : 
d(port)); \
}

-- 
Horms


On Sat, Sep 03, 2005 at 10:49:48AM -0700, [EMAIL PROTECTED] wrote:
 Package: linux-source-2.6.12
 Version: 2.6.12-5
 Severity: normal
 
 # make-kpkg --initrd --append-to-version=-ahrairah --revision=ahrairah.1
 kernel-image modules-image
 
   CC [M]  drivers/bluetooth/bfusb.o
   CC [M]  drivers/bluetooth/dtl1_cs.o
 drivers/bluetooth/dtl1_cs.c: In function 'dtl1_write':
 include/asm/io.h:377: error: can't find a register in class 'DREG' while
   reloading 'asm'
 make[3]: *** [drivers/bluetooth/dtl1_cs.o] Error 1
 make[2]: *** [drivers/bluetooth] Error 2
 make[1]: *** [drivers] Error 2
 make[1]: Leaving directory `/usr/src/linux-source-2.6.12'
 make: *** [stamp-build] Error 2
 
 Change CPU type to K7 and it builds successfully.
 
 
 -- System Information:
 Debian Release: testing/unstable
   APT prefers testing
   APT policy: (500, 'testing'), (100, 'unstable'), (99, 'experimental')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.12.local
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 
 Versions of packages linux-source-2.6.12 depends on:
 ii  binutils  2.16.1-2   The GNU assembler, linker and 
 bina
 ii  bzip2 1.0.2-8high-quality block-sorting file 
 co
 ii  coreutils [fileutils] 5.2.1-2ubuntu0 The GNU core utilities
 
 Versions of packages linux-source-2.6.12 recommends:
 ii  gcc   4:4.0.1-3  The GNU C compiler
 ii  libc6-dev [libc-dev]  2.3.5-4GNU C Library: Development 
 Librari
 ii  make  3.80-9 The GNU version of the make 
 util
 
 -- no debconf information

 #
 # Automatically generated make config: don't edit
 # Linux kernel version: 2.6.12-ahrairah
 # Sat Sep  3 09:11:09 2005
 #
 CONFIG_X86=y
 CONFIG_MMU=y
 CONFIG_UID16=y
 CONFIG_GENERIC_ISA_DMA=y
 CONFIG_GENERIC_IOMAP=y
 
 #
 # Code maturity level options
 #
 CONFIG_EXPERIMENTAL=y
 CONFIG_CLEAN_COMPILE=y
 CONFIG_BROKEN_ON_SMP=y
 CONFIG_LOCK_KERNEL=y
 CONFIG_INIT_ENV_ARG_LIMIT=32
 
 #
 # General setup
 #
 CONFIG_LOCALVERSION=
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_BSD_PROCESS_ACCT_V3=y
 CONFIG_SYSCTL=y
 CONFIG_AUDIT=y
 CONFIG_AUDITSYSCALL=y
 CONFIG_HOTPLUG=y
 CONFIG_KOBJECT_UEVENT=y
 # CONFIG_IKCONFIG is not set
 CONFIG_EMBEDDED=y
 # CONFIG_KALLSYMS is not set
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_EPOLL=y
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
 CONFIG_SHMEM=y
 CONFIG_CC_ALIGN_FUNCTIONS=0
 CONFIG_CC_ALIGN_LABELS=0
 CONFIG_CC_ALIGN_LOOPS=0
 CONFIG_CC_ALIGN_JUMPS=0
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
 
 #
 # Loadable module support
 #
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_OBSOLETE_MODPARM=y

Re: Problems Building Bluetooth with K6 and CONFIG_REGPARM

[Horms]

On Thu, Sep 08, 2005 at 12:49:17PM -0400, Brian Gerst wrote:
 Horms wrote:
 Hi Andy,
 
 that does indeed seem to be a problem. I have narrowed it down to
 a combination of using K6 and CONFIG_REGPARM. Hunting around a bit
 I found this http://my.execpc.com/~geezer/osd/gotchas/, which
 suggests the problem is that the asm in question tries to add a register
 to the clobber list which is not available. This makes sense,
 I guess REGPARM is using edx, so inline assembly can't.
 
 I've CCed the bluetooth maintainers and lkml, hopefully someone there
 will have some input on how to resolve this problem, as inline assembly
 isn't my strong point and the problem seems to manifest in Linus' current
 git tree. 
 
 The relevant code is the following call to BUILDIO(b,b,char) towards the
 bottom of include/asm/io.h
 
 BUILDIO is as follows, and I am guessing it is the Nd(port) and
 possibley d(port) portions that are problematic.
 
 Sounds like a compiler bug, especially since changing the CPU type fixes 
 it.  What version of GCC?

I definately think it is compiler related, 
I was using Debian's GCC 4.0.1-6. I could try 
with 3.3 or soemthing like that if you like.

The problem was easily reproducable with
4.0.1 and a K6+CONFIG_REGPARM config.

-- 
Horms
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug#321442: kernel-source-2.6.8: fails to compile on powerpc (drivers/ide/ppc/pmac.c)

[Horms]

On Mon, Sep 05, 2005 at 02:42:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
> Should be fixed in 2.6.13.
> 
> On 8/16/05, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> > On Aug 13, 2005, at 18:54:30, LT-P wrote:
> > > Le lun 08 aoû 2005 17:57:04 CEST, Horms <[EMAIL PROTECTED]> a écrit:
> > >> Can you please enable BLK_DEV_IDEDMA_PCI and see if that resolves
> > >> your
> > >> problem. If it does, then the following patch should fix Kconfig
> > >> so that BLK_DEV_IDEDMA_PCI needs to be enabled for BLK_DEV_IDE_PMAC
> > >> to be enabled. It should patch cleanly against Debian's 2.6.8 and
> > >> Linus' current Git tree.
> > > It seems to solve the problem, thanks.
> > > Sometimes, I feel like I am the only person in the world to compile
> > > the kernel on
> > > powerpc... :)
> > 
> > Actually, I ran into this same bug a day or so ago when updating to
> > 2.6.13-rc6,
> > it's just I noticed the error, fixed my config, then recompiled and
> > forgot
> > about it completely until now :-D.  Thanks for the bug report, though!

thanks

-- 
Horms
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug#321442: kernel-source-2.6.8: fails to compile on powerpc (drivers/ide/ppc/pmac.c)

[Horms]

On Mon, Sep 05, 2005 at 02:42:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
 Should be fixed in 2.6.13.
 
 On 8/16/05, Kyle Moffett [EMAIL PROTECTED] wrote:
  On Aug 13, 2005, at 18:54:30, LT-P wrote:
   Le lun 08 aoû 2005 17:57:04 CEST, Horms [EMAIL PROTECTED] a écrit:
   Can you please enable BLK_DEV_IDEDMA_PCI and see if that resolves
   your
   problem. If it does, then the following patch should fix Kconfig
   so that BLK_DEV_IDEDMA_PCI needs to be enabled for BLK_DEV_IDE_PMAC
   to be enabled. It should patch cleanly against Debian's 2.6.8 and
   Linus' current Git tree.
   It seems to solve the problem, thanks.
   Sometimes, I feel like I am the only person in the world to compile
   the kernel on
   powerpc... :)
  
  Actually, I ran into this same bug a day or so ago when updating to
  2.6.13-rc6,
  it's just I noticed the error, fixed my config, then recompiled and
  forgot
  about it completely until now :-D.  Thanks for the bug report, though!

thanks

-- 
Horms
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel 2.4.27-10: isofs driver ignore some parameters with mount

[Horms]

Hi,

On Marcelo's request I have taken a closer look at this.
It seems that Alexander Pytlev's original (simple) patch was correct.

Without it the logic looks a bit like this.

while (...) {
if iocharset
...
else if map
...
if session
...
if sbsector
...
else if check
...
...
else
return 1;
}

Now, if iocharset, map or session are matched, then none of the if or
else if clauses under sbsector will match (that is none of these clauses
match iocharset, map or session), and thus the else clause will be hit,
and the function will return 1 without parsing any furhter options.

With Alexander's fix, the if session and if sbsector clauses
become else if, and its easy to see that the return 1 won't
be premeturely called.

I have tested that this patch works using the testcase options
iocharset=koi8-r,gid=100, and checking that gid is set correctly
with the patch, and incorrectly without.

Here is the patch and signoff again, just for the record.
I will send a second patch to clean up the *value = 0 code
that Marcelo cast concerns over - its bogus but harmless.

Signed-off-by: Horms <[EMAIL PROTECTED]>

--- a/fs/isofs/inode.c  2005-08-03 14:46:33.0 +0900
+++ b/fs/isofs/inode.c  2005-08-16 17:23:04.0 +0900
@@ -340,13 +337,13 @@
else if (!strcmp(value,"acorn")) popt->map = 'a';
else return 0;
}
-   if (!strcmp(this_char,"session") && value) {
+   else if (!strcmp(this_char,"session") && value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, , 0);
if(ivalue < 0 || ivalue >99) return 0;
popt->session=ivalue+1;
}
-   if (!strcmp(this_char,"sbsector") && value) {
+   else if (!strcmp(this_char,"sbsector") && value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, , 0);
if(ivalue < 0 || ivalue >660*512) return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Bogus code in parsing of iocharset in isofs

[Horms]

Hi, 

this is a followup for the patch I sent earlier (like about 2 minutes
ago) regarding isofs options parsing. In the course of debuging this
Marcelo pointed out the following code

#ifdef CONFIG_JOLIET
if (!strcmp(this_char,"iocharset") && value) {
popt->iocharset = value;
while (*value && *value != ',')
value++;
if (value == popt->iocharset)
return 0;
*value = 0;
} else 
#endif  

On inspection it turns out that because of use of strtok(),
*value is already NULL terminated, and thus the code snippet
above is largely bogus. The following patch should remove the
bogus code without changing functionality.

Signed-off-by: Horms <[EMAIL PROTECTED]>

--- ../build-386/fs/isofs/inode.c   2005-08-03 14:46:33.0 +0900
+++ fs/isofs/inode.c2005-08-16 17:23:04.0 +0900
@@ -324,12 +324,9 @@
 
 #ifdef CONFIG_JOLIET
if (!strcmp(this_char,"iocharset") && value) {
-   popt->iocharset = value;
-   while (*value && *value != ',')
-   value++;
-   if (value == popt->iocharset)
+   if (!value)
return 0;
-   *value = 0;
+   popt->iocharset = value;
} else
 #endif
if (!strcmp(this_char,"map") && value) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel 2.4.27-10: isofs driver ignore some parameters with mount

[Horms]

Hi,

On Marcelo's request I have taken a closer look at this.
It seems that Alexander Pytlev's original (simple) patch was correct.

Without it the logic looks a bit like this.

while (...) {
if iocharset
...
else if map
...
if session
...
if sbsector
...
else if check
...
...
else
return 1;
}

Now, if iocharset, map or session are matched, then none of the if or
else if clauses under sbsector will match (that is none of these clauses
match iocharset, map or session), and thus the else clause will be hit,
and the function will return 1 without parsing any furhter options.

With Alexander's fix, the if session and if sbsector clauses
become else if, and its easy to see that the return 1 won't
be premeturely called.

I have tested that this patch works using the testcase options
iocharset=koi8-r,gid=100, and checking that gid is set correctly
with the patch, and incorrectly without.

Here is the patch and signoff again, just for the record.
I will send a second patch to clean up the *value = 0 code
that Marcelo cast concerns over - its bogus but harmless.

Signed-off-by: Horms [EMAIL PROTECTED]

--- a/fs/isofs/inode.c  2005-08-03 14:46:33.0 +0900
+++ b/fs/isofs/inode.c  2005-08-16 17:23:04.0 +0900
@@ -340,13 +337,13 @@
else if (!strcmp(value,acorn)) popt-map = 'a';
else return 0;
}
-   if (!strcmp(this_char,session)  value) {
+   else if (!strcmp(this_char,session)  value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, vpnt, 0);
if(ivalue  0 || ivalue 99) return 0;
popt-session=ivalue+1;
}
-   if (!strcmp(this_char,sbsector)  value) {
+   else if (!strcmp(this_char,sbsector)  value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, vpnt, 0);
if(ivalue  0 || ivalue 660*512) return 0;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Bogus code in parsing of iocharset in isofs

[Horms]

Hi, 

this is a followup for the patch I sent earlier (like about 2 minutes
ago) regarding isofs options parsing. In the course of debuging this
Marcelo pointed out the following code

#ifdef CONFIG_JOLIET
if (!strcmp(this_char,iocharset)  value) {
popt-iocharset = value;
while (*value  *value != ',')
value++;
if (value == popt-iocharset)
return 0;
*value = 0;
} else 
#endif  

On inspection it turns out that because of use of strtok(),
*value is already NULL terminated, and thus the code snippet
above is largely bogus. The following patch should remove the
bogus code without changing functionality.

Signed-off-by: Horms [EMAIL PROTECTED]

--- ../build-386/fs/isofs/inode.c   2005-08-03 14:46:33.0 +0900
+++ fs/isofs/inode.c2005-08-16 17:23:04.0 +0900
@@ -324,12 +324,9 @@
 
 #ifdef CONFIG_JOLIET
if (!strcmp(this_char,iocharset)  value) {
-   popt-iocharset = value;
-   while (*value  *value != ',')
-   value++;
-   if (value == popt-iocharset)
+   if (!value)
return 0;
-   *value = 0;
+   popt-iocharset = value;
} else
 #endif
if (!strcmp(this_char,map)  value) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel 2.4.27-10: isofs driver ignore some parameters with mount

[Horms]

On Mon, Aug 15, 2005 at 10:11:21PM -0300, Marcelo Tosatti wrote:
> 
> Hi folks,
> 
> On Fri, Aug 12, 2005 at 05:29:36PM +0900, Horms wrote:
> > On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
> > > Hello Debian,
> > > 
> > > Kernel 2.4.27-10
> > > With mount isofs filesystem, any mount parameters after
> > > iocharset=,map=,session= are ignored.
> > > 
> > > Sample:
> > > 
> > > mount -t isofs -o uid=100,iocharset=koi8-r,gid=100 /dev/cdrom /media/cdrom
> > > 
> > > gid=100 - was ignored
> > > 
> > > I look in source and find that problem. I make two patch, simply and full
> > > (what addeded some functionality - ignore wrong mount parameters)
> > 
> > Thanks,
> > 
> > I will try and get the simple version of this patch into the next
> > Sarge update.
> > 
> > I have also CCed Marcelo and the LKML for their consideration,
> > as this problem still seems to be present in the lastest 2.4 tree.
> > 
> > -- 
> > Horms
> > 
> > simply patch:
> > ===
> > --- kernel-source-2.4.27/fs/isofs/inode.c   2005-05-19 
> > 13:29:39.0 +0300
> > +++ kernel-source/fs/isofs/inode.c  2005-08-11 11:55:12.0 +0300
> > @@ -340,13 +340,13 @@
> > else if (!strcmp(value,"acorn")) popt->map = 'a';
> > else return 0;
> > }
> > -   if (!strcmp(this_char,"session") && value) {
> > +   else if (!strcmp(this_char,"session") && value) {
> > char * vpnt = value;
> > unsigned int ivalue = simple_strtoul(vpnt, , 
> > 0);
> > if(ivalue < 0 || ivalue >99) return 0;
> > popt->session=ivalue+1;
> > }
> > -   if (!strcmp(this_char,"sbsector") && value) {
> > +   else if (!strcmp(this_char,"sbsector") && value) {
> > char * vpnt = value;
> > unsigned int ivalue = simple_strtoul(vpnt, , 
> > 0);
> > if(ivalue < 0 || ivalue >660*512) return 0;
> > ===
> 
> Neither "sbsector" or "session" parameters are part of the options string 
> used 
> in Alexander's example, so how come this patch can make any difference? 
> 
> Usage of "sbsector" or "session" parameters could explain the above patch
> making a difference because the buggy, always true "(unsigned long) ivalue < 
> 0"
> comparison invokes "return 0", but that is not the case.
> 
> The code after the "popt->iocharset = value;" does not make any sense.
> 
> It seems that the "*value = 0" assignment can screw up the rest of the
> string, isnt that the real issue?
> 
> #ifdef CONFIG_JOLIET
> if (!strcmp(this_char,"iocharset") && value) {
> popt->iocharset = value;
> while (*value && *value != ',')
> value++;
> if (value == popt->iocharset)
> return 0;
> *value = 0;
> } else
> #endif

Sorry about that, while the patch above does seem to be
a valid clean up, on further examination I agree that it
does not address the problem at hand, and that the problem seems
to lie in the *value assignment as you suggest. I wonder
if advancing this_char to the character aftter value, if
non-NULL would resolve this problem. I'll do some testing,
but in the mean time, here is what I have in mind:

--- a/fs/isofs/inode.c  2005-08-16 14:22:27.0 +0900
+++ b/fs/isofs/inode.c  2005-08-16 14:27:55.0 +0900
@@ -329,7 +329,10 @@
value++;
if (value == popt->iocharset)
return 0;
-   *value = 0;
+   if (*value) {
+   this_char = value + 1;
+   *value = 0;
+   }
} else
 #endif
if (!strcmp(this_char,"map") && value) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel 2.4.27-10: isofs driver ignore some parameters with mount

[Horms]

On Mon, Aug 15, 2005 at 10:11:21PM -0300, Marcelo Tosatti wrote:
 
 Hi folks,
 
 On Fri, Aug 12, 2005 at 05:29:36PM +0900, Horms wrote:
  On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
   Hello Debian,
   
   Kernel 2.4.27-10
   With mount isofs filesystem, any mount parameters after
   iocharset=,map=,session= are ignored.
   
   Sample:
   
   mount -t isofs -o uid=100,iocharset=koi8-r,gid=100 /dev/cdrom /media/cdrom
   
   gid=100 - was ignored
   
   I look in source and find that problem. I make two patch, simply and full
   (what addeded some functionality - ignore wrong mount parameters)
  
  Thanks,
  
  I will try and get the simple version of this patch into the next
  Sarge update.
  
  I have also CCed Marcelo and the LKML for their consideration,
  as this problem still seems to be present in the lastest 2.4 tree.
  
  -- 
  Horms
  
  simply patch:
  ===
  --- kernel-source-2.4.27/fs/isofs/inode.c   2005-05-19 
  13:29:39.0 +0300
  +++ kernel-source/fs/isofs/inode.c  2005-08-11 11:55:12.0 +0300
  @@ -340,13 +340,13 @@
  else if (!strcmp(value,acorn)) popt-map = 'a';
  else return 0;
  }
  -   if (!strcmp(this_char,session)  value) {
  +   else if (!strcmp(this_char,session)  value) {
  char * vpnt = value;
  unsigned int ivalue = simple_strtoul(vpnt, vpnt, 
  0);
  if(ivalue  0 || ivalue 99) return 0;
  popt-session=ivalue+1;
  }
  -   if (!strcmp(this_char,sbsector)  value) {
  +   else if (!strcmp(this_char,sbsector)  value) {
  char * vpnt = value;
  unsigned int ivalue = simple_strtoul(vpnt, vpnt, 
  0);
  if(ivalue  0 || ivalue 660*512) return 0;
  ===
 
 Neither sbsector or session parameters are part of the options string 
 used 
 in Alexander's example, so how come this patch can make any difference? 
 
 Usage of sbsector or session parameters could explain the above patch
 making a difference because the buggy, always true (unsigned long) ivalue  
 0
 comparison invokes return 0, but that is not the case.
 
 The code after the popt-iocharset = value; does not make any sense.
 
 It seems that the *value = 0 assignment can screw up the rest of the
 string, isnt that the real issue?
 
 #ifdef CONFIG_JOLIET
 if (!strcmp(this_char,iocharset)  value) {
 popt-iocharset = value;
 while (*value  *value != ',')
 value++;
 if (value == popt-iocharset)
 return 0;
 *value = 0;
 } else
 #endif

Sorry about that, while the patch above does seem to be
a valid clean up, on further examination I agree that it
does not address the problem at hand, and that the problem seems
to lie in the *value assignment as you suggest. I wonder
if advancing this_char to the character aftter value, if
non-NULL would resolve this problem. I'll do some testing,
but in the mean time, here is what I have in mind:

--- a/fs/isofs/inode.c  2005-08-16 14:22:27.0 +0900
+++ b/fs/isofs/inode.c  2005-08-16 14:27:55.0 +0900
@@ -329,7 +329,10 @@
value++;
if (value == popt-iocharset)
return 0;
-   *value = 0;
+   if (*value) {
+   this_char = value + 1;
+   *value = 0;
+   }
} else
 #endif
if (!strcmp(this_char,map)  value) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel 2.4.27-10: isofs driver ignore some parameters with mount

[Horms]

On Fri, Aug 12, 2005 at 05:29:36PM +0900, Horms wrote:
> On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
> > Hello Debian,
> > 
> > Kernel 2.4.27-10
> > With mount isofs filesystem, any mount parameters after
> > iocharset=,map=,session= are ignored.
> > 
> > Sample:
> > 
> > mount -t isofs -o uid=100,iocharset=koi8-r,gid=100 /dev/cdrom /media/cdrom
> > 
> > gid=100 - was ignored
> > 
> > I look in source and find that problem. I make two patch, simply and full
> > (what addeded some functionality - ignore wrong mount parameters)
> 
> Thanks,
> 
> I will try and get the simple version of this patch into the next
> Sarge update.
> 
> I have also CCed Marcelo and the LKML for their consideration,
> as this problem still seems to be present in the lastest 2.4 tree.
> 
> -- 
> Horms

Marcelo and LKML, here is a rediff of the simple version of the patch
from Alexander Pytlev that I forwarded previously. The whitespace in his
version had been munged.

I haven't tested it, but it looks like it should resolve the problem
Alexander reported that mount parameters after iocharset, map and
session are ignored.

This should apply against current 2.4 git.  I took a peek into 2.6, and
the code there has seems to have been completely restructured.

Signed-off-by: Horms <[EMAIL PROTECTED]>


--- fs/isofs/inode.c.orig   2005-08-12 17:33:31.0 +0900
+++ fs/isofs/inode.c2005-08-12 17:33:38.0 +0900
@@ -340,13 +340,13 @@
else if (!strcmp(value,"acorn")) popt->map = 'a';
else return 0;
}
-   if (!strcmp(this_char,"session") && value) {
+   else if (!strcmp(this_char,"session") && value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, , 0);
if(ivalue < 0 || ivalue >99) return 0;
popt->session=ivalue+1;
}
-   if (!strcmp(this_char,"sbsector") && value) {
+   else if (!strcmp(this_char,"sbsector") && value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, , 0);
if(ivalue < 0 || ivalue >660*512) return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel 2.4.27-10: isofs driver ignore some parameters with mount

[Horms]

On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
> Hello Debian,
> 
> Kernel 2.4.27-10
> With mount isofs filesystem, any mount parameters after
> iocharset=,map=,session= are ignored.
> 
> Sample:
> 
> mount -t isofs -o uid=100,iocharset=koi8-r,gid=100 /dev/cdrom /media/cdrom
> 
> gid=100 - was ignored
> 
> I look in source and find that problem. I make two patch, simply and full
> (what addeded some functionality - ignore wrong mount parameters)

Thanks,

I will try and get the simple version of this patch into the next
Sarge update.

I have also CCed Marcelo and the LKML for their consideration,
as this problem still seems to be present in the lastest 2.4 tree.

-- 
Horms

simply patch:
===
--- kernel-source-2.4.27/fs/isofs/inode.c   2005-05-19 13:29:39.0 
+0300
+++ kernel-source/fs/isofs/inode.c  2005-08-11 11:55:12.0 +0300
@@ -340,13 +340,13 @@
else if (!strcmp(value,"acorn")) popt->map = 'a';
else return 0;
}
-   if (!strcmp(this_char,"session") && value) {
+   else if (!strcmp(this_char,"session") && value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, , 0);
if(ivalue < 0 || ivalue >99) return 0;
popt->session=ivalue+1;
}
-   if (!strcmp(this_char,"sbsector") && value) {
+   else if (!strcmp(this_char,"sbsector") && value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, , 0);
if(ivalue < 0 || ivalue >660*512) return 0;
===

full patch:
===
--- kernel-source-2.4.27/fs/isofs/inode.c   2005-05-19 13:29:39.0 
+0300
+++ kernel-source/fs/isofs/inode.c  2005-08-11 11:50:56.0 +0300
@@ -327,10 +327,11 @@
popt->iocharset = value;
while (*value && *value != ',')
value++;
-   if (value == popt->iocharset)
-   return 0;
*value = 0;
-   } else
+   if (value == popt->iocharset){
+   printk("Invalid or missed 
parameter:%s=%s,\n",this_char,value);
+   }
+   }
 #endif
if (!strcmp(this_char,"map") && value) {
if (value[0] && !value[1] && strchr("ano",*value))
@@ -338,28 +339,30 @@
else if (!strcmp(value,"off")) popt->map = 'o';
else if (!strcmp(value,"normal")) popt->map = 'n';
else if (!strcmp(value,"acorn")) popt->map = 'a';
-   else return 0;
+   else printk("Invalid or missed 
parameter:%s=%s,\n",this_char,value);
}
if (!strcmp(this_char,"session") && value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, , 0);
-   if(ivalue < 0 || ivalue >99) return 0;
-   popt->session=ivalue+1;
+   if(ivalue < 0 || ivalue >99)
+   printk("Invalid or missed 
parameter:%s=%s,\n",this_char,value);
+   else popt->session=ivalue+1;
}
if (!strcmp(this_char,"sbsector") && value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, , 0);
-   if(ivalue < 0 || ivalue >660*512) return 0;
-   popt->sbsector=ivalue;
+   if(ivalue < 0 || ivalue >660*512)
+   printk("Invalid or missed 
parameter:%s=%s,\n",this_char,value);
+   else popt->sbsector=ivalue;
}
-   else if (!strcmp(this_char,"check") && value) {
+   if (!strcmp(this_char,"check") && value) {
if (value[0] && !value[1] && strchr("rs",*value))
popt->check = *value;
else if (!strcmp(value,"relaxed")) popt->check = 'r';
 

Re: kernel 2.4.27-10: isofs driver ignore some parameters with mount

[Horms]

On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
 Hello Debian,
 
 Kernel 2.4.27-10
 With mount isofs filesystem, any mount parameters after
 iocharset=,map=,session= are ignored.
 
 Sample:
 
 mount -t isofs -o uid=100,iocharset=koi8-r,gid=100 /dev/cdrom /media/cdrom
 
 gid=100 - was ignored
 
 I look in source and find that problem. I make two patch, simply and full
 (what addeded some functionality - ignore wrong mount parameters)

Thanks,

I will try and get the simple version of this patch into the next
Sarge update.

I have also CCed Marcelo and the LKML for their consideration,
as this problem still seems to be present in the lastest 2.4 tree.

-- 
Horms

simply patch:
===
--- kernel-source-2.4.27/fs/isofs/inode.c   2005-05-19 13:29:39.0 
+0300
+++ kernel-source/fs/isofs/inode.c  2005-08-11 11:55:12.0 +0300
@@ -340,13 +340,13 @@
else if (!strcmp(value,acorn)) popt-map = 'a';
else return 0;
}
-   if (!strcmp(this_char,session)  value) {
+   else if (!strcmp(this_char,session)  value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, vpnt, 0);
if(ivalue  0 || ivalue 99) return 0;
popt-session=ivalue+1;
}
-   if (!strcmp(this_char,sbsector)  value) {
+   else if (!strcmp(this_char,sbsector)  value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, vpnt, 0);
if(ivalue  0 || ivalue 660*512) return 0;
===

full patch:
===
--- kernel-source-2.4.27/fs/isofs/inode.c   2005-05-19 13:29:39.0 
+0300
+++ kernel-source/fs/isofs/inode.c  2005-08-11 11:50:56.0 +0300
@@ -327,10 +327,11 @@
popt-iocharset = value;
while (*value  *value != ',')
value++;
-   if (value == popt-iocharset)
-   return 0;
*value = 0;
-   } else
+   if (value == popt-iocharset){
+   printk(Invalid or missed 
parameter:%s=%s,\n,this_char,value);
+   }
+   }
 #endif
if (!strcmp(this_char,map)  value) {
if (value[0]  !value[1]  strchr(ano,*value))
@@ -338,28 +339,30 @@
else if (!strcmp(value,off)) popt-map = 'o';
else if (!strcmp(value,normal)) popt-map = 'n';
else if (!strcmp(value,acorn)) popt-map = 'a';
-   else return 0;
+   else printk(Invalid or missed 
parameter:%s=%s,\n,this_char,value);
}
if (!strcmp(this_char,session)  value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, vpnt, 0);
-   if(ivalue  0 || ivalue 99) return 0;
-   popt-session=ivalue+1;
+   if(ivalue  0 || ivalue 99)
+   printk(Invalid or missed 
parameter:%s=%s,\n,this_char,value);
+   else popt-session=ivalue+1;
}
if (!strcmp(this_char,sbsector)  value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, vpnt, 0);
-   if(ivalue  0 || ivalue 660*512) return 0;
-   popt-sbsector=ivalue;
+   if(ivalue  0 || ivalue 660*512)
+   printk(Invalid or missed 
parameter:%s=%s,\n,this_char,value);
+   else popt-sbsector=ivalue;
}
-   else if (!strcmp(this_char,check)  value) {
+   if (!strcmp(this_char,check)  value) {
if (value[0]  !value[1]  strchr(rs,*value))
popt-check = *value;
else if (!strcmp(value,relaxed)) popt-check = 'r';
else if (!strcmp(value,strict)) popt-check = 's';
-   else return 0;
+   else printk(Invalid or missed 
parameter:%s=%s,\n,this_char,value);
}
-   else if (!strcmp(this_char,conv)  value) {
+   if (!strcmp(this_char,conv)  value) {
/* no conversion is done anymore;
   we still accept the same mount options,
   but ignore them */
@@ -368,22 +371,24

Re: kernel 2.4.27-10: isofs driver ignore some parameters with mount

[Horms]

On Fri, Aug 12, 2005 at 05:29:36PM +0900, Horms wrote:
 On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
  Hello Debian,
  
  Kernel 2.4.27-10
  With mount isofs filesystem, any mount parameters after
  iocharset=,map=,session= are ignored.
  
  Sample:
  
  mount -t isofs -o uid=100,iocharset=koi8-r,gid=100 /dev/cdrom /media/cdrom
  
  gid=100 - was ignored
  
  I look in source and find that problem. I make two patch, simply and full
  (what addeded some functionality - ignore wrong mount parameters)
 
 Thanks,
 
 I will try and get the simple version of this patch into the next
 Sarge update.
 
 I have also CCed Marcelo and the LKML for their consideration,
 as this problem still seems to be present in the lastest 2.4 tree.
 
 -- 
 Horms

Marcelo and LKML, here is a rediff of the simple version of the patch
from Alexander Pytlev that I forwarded previously. The whitespace in his
version had been munged.

I haven't tested it, but it looks like it should resolve the problem
Alexander reported that mount parameters after iocharset, map and
session are ignored.

This should apply against current 2.4 git.  I took a peek into 2.6, and
the code there has seems to have been completely restructured.

Signed-off-by: Horms [EMAIL PROTECTED]


--- fs/isofs/inode.c.orig   2005-08-12 17:33:31.0 +0900
+++ fs/isofs/inode.c2005-08-12 17:33:38.0 +0900
@@ -340,13 +340,13 @@
else if (!strcmp(value,acorn)) popt-map = 'a';
else return 0;
}
-   if (!strcmp(this_char,session)  value) {
+   else if (!strcmp(this_char,session)  value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, vpnt, 0);
if(ivalue  0 || ivalue 99) return 0;
popt-session=ivalue+1;
}
-   if (!strcmp(this_char,sbsector)  value) {
+   else if (!strcmp(this_char,sbsector)  value) {
char * vpnt = value;
unsigned int ivalue = simple_strtoul(vpnt, vpnt, 0);
if(ivalue  0 || ivalue 660*512) return 0;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug#321442: kernel-source-2.6.8: fails to compile on powerpc (drivers/ide/ppc/pmac.c)

[Horms]

On Fri, Aug 05, 2005 at 05:15:57PM +0200, LT-P wrote:
> Package: kernel-source-2.6.8
> Version: 2.6.8-16
> Severity: normal
> 
> The kernel-source-2.6.8 sources fail to compile on powerpc (PowerMac 4400).
> 
> ___
> CC  drivers/ide/ide.o
> CC  drivers/ide/ide-default.o
> CC  drivers/ide/ide-io.o
> CC  drivers/ide/ide-iops.o
> CC  drivers/ide/ide-lib.o
> CC  drivers/ide/ide-probe.o
> CC  drivers/ide/ide-taskfile.o
> CC  drivers/ide/ide-dma.o
> CC  drivers/ide/ide-proc.o
> CC  drivers/ide/ppc/pmac.o
> drivers/ide/ppc/pmac.c: Dans la fonction ?? pmac_ide_dma_read ??:
> drivers/ide/ppc/pmac.c:1951: error: `ide_dma_intr' undeclared (first use in 
> this function)
> drivers/ide/ppc/pmac.c:1951: error: (Each undeclared identifier is reported 
> only once
> drivers/ide/ppc/pmac.c:1951: error: for each function it appears in.)
> drivers/ide/ppc/pmac.c: Dans la fonction ?? pmac_ide_dma_write ??:
> drivers/ide/ppc/pmac.c:1982: error: `ide_dma_intr' undeclared (first use in 
> this function)
> drivers/ide/ppc/pmac.c: Dans la fonction ?? pmac_ide_setup_dma ??:
> drivers/ide/ppc/pmac.c:2157: error: `__ide_dma_off_quietly' undeclared (first 
> use in this function)
> drivers/ide/ppc/pmac.c:2158: error: `__ide_dma_on' undeclared (first use in 
> this function)
> drivers/ide/ppc/pmac.c:2167: error: `__ide_dma_verbose' undeclared (first use 
> in this function)
> drivers/ide/ppc/pmac.c:2168: error: `__ide_dma_timeout' undeclared (first use 
> in this function)
> make[3]: *** [drivers/ide/ppc/pmac.o] Error 1
> make[2]: *** [drivers/ide] Error 2
> make[1]: *** [drivers] Error 2

Can you please enable BLK_DEV_IDEDMA_PCI and see if that resolves your
problem. If it does, then the following patch should fix Kconfig
so that BLK_DEV_IDEDMA_PCI needs to be enabled for BLK_DEV_IDE_PMAC
to be enabled. It should patch cleanly against Debian's 2.6.8 and
Linus' current Git tree.

-- 
Horms


BLK_DEV_IDEDMA_PCI seems to be needed for BLK_DEV_IDE_PMAC to compile

Signed-off-by: Horms <[EMAIL PROTECTED]>


--- a/drivers/ide/Kconfig.orig  2005-08-08 17:48:17.0 +0900
+++ b/drivers/ide/Kconfig   2005-08-08 17:48:48.0 +0900
@@ -749,8 +749,6 @@
  This allows the kernel to change PIO, DMA and UDMA speeds and to
  configure the chip to optimum performance.
 
-endif
-
 config BLK_DEV_IDE_PMAC
bool "Builtin PowerMac IDE support"
depends on PPC_PMAC && IDE=y
@@ -759,6 +757,8 @@
  most of the recent Apple Power Macintoshes and PowerBooks.
  If unsure, say Y.
 
+endif
+
 config BLK_DEV_IDE_PMAC_ATA100FIRST
bool "Probe internal ATA/100 (Kauai) first"
depends on BLK_DEV_IDE_PMAC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug#321442: kernel-source-2.6.8: fails to compile on powerpc (drivers/ide/ppc/pmac.c)

[Horms]

On Fri, Aug 05, 2005 at 05:15:57PM +0200, LT-P wrote:
 Package: kernel-source-2.6.8
 Version: 2.6.8-16
 Severity: normal
 
 The kernel-source-2.6.8 sources fail to compile on powerpc (PowerMac 4400).
 
 ___
 CC  drivers/ide/ide.o
 CC  drivers/ide/ide-default.o
 CC  drivers/ide/ide-io.o
 CC  drivers/ide/ide-iops.o
 CC  drivers/ide/ide-lib.o
 CC  drivers/ide/ide-probe.o
 CC  drivers/ide/ide-taskfile.o
 CC  drivers/ide/ide-dma.o
 CC  drivers/ide/ide-proc.o
 CC  drivers/ide/ppc/pmac.o
 drivers/ide/ppc/pmac.c: Dans la fonction ?? pmac_ide_dma_read ??:
 drivers/ide/ppc/pmac.c:1951: error: `ide_dma_intr' undeclared (first use in 
 this function)
 drivers/ide/ppc/pmac.c:1951: error: (Each undeclared identifier is reported 
 only once
 drivers/ide/ppc/pmac.c:1951: error: for each function it appears in.)
 drivers/ide/ppc/pmac.c: Dans la fonction ?? pmac_ide_dma_write ??:
 drivers/ide/ppc/pmac.c:1982: error: `ide_dma_intr' undeclared (first use in 
 this function)
 drivers/ide/ppc/pmac.c: Dans la fonction ?? pmac_ide_setup_dma ??:
 drivers/ide/ppc/pmac.c:2157: error: `__ide_dma_off_quietly' undeclared (first 
 use in this function)
 drivers/ide/ppc/pmac.c:2158: error: `__ide_dma_on' undeclared (first use in 
 this function)
 drivers/ide/ppc/pmac.c:2167: error: `__ide_dma_verbose' undeclared (first use 
 in this function)
 drivers/ide/ppc/pmac.c:2168: error: `__ide_dma_timeout' undeclared (first use 
 in this function)
 make[3]: *** [drivers/ide/ppc/pmac.o] Error 1
 make[2]: *** [drivers/ide] Error 2
 make[1]: *** [drivers] Error 2

Can you please enable BLK_DEV_IDEDMA_PCI and see if that resolves your
problem. If it does, then the following patch should fix Kconfig
so that BLK_DEV_IDEDMA_PCI needs to be enabled for BLK_DEV_IDE_PMAC
to be enabled. It should patch cleanly against Debian's 2.6.8 and
Linus' current Git tree.

-- 
Horms


BLK_DEV_IDEDMA_PCI seems to be needed for BLK_DEV_IDE_PMAC to compile

Signed-off-by: Horms [EMAIL PROTECTED]


--- a/drivers/ide/Kconfig.orig  2005-08-08 17:48:17.0 +0900
+++ b/drivers/ide/Kconfig   2005-08-08 17:48:48.0 +0900
@@ -749,8 +749,6 @@
  This allows the kernel to change PIO, DMA and UDMA speeds and to
  configure the chip to optimum performance.
 
-endif
-
 config BLK_DEV_IDE_PMAC
bool Builtin PowerMac IDE support
depends on PPC_PMAC  IDE=y
@@ -759,6 +757,8 @@
  most of the recent Apple Power Macintoshes and PowerBooks.
  If unsure, say Y.
 
+endif
+
 config BLK_DEV_IDE_PMAC_ATA100FIRST
bool Probe internal ATA/100 (Kauai) first
depends on BLK_DEV_IDE_PMAC
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug#320379: Errors during initrd loading when / is on LVM over RAID

[Horms]

On Fri, Jul 29, 2005 at 12:41:38AM +0200, Frans Pop wrote:
> Package: kernel
> Tags: patch
> 
> After switching from a 2.4.27 to 2.6.8 kernel for an old desktop Iuse as
> a server, I noticed the following messages on console and kern.log.
> Note: the errors are not harmful, just ugly; the system boots normally.
> 
> kernel: Inspecting /boot/System.map-2.6.8-2-686
> kernel: Loaded 27390 symbols from /boot/System.map-2.6.8-2-686.
> kernel: Symbols match kernel version 2.6.8.
> kernel: No module symbols loaded - kernel modules not enabled.
> kernel: ould not append to parent for /disc
> kernel: devfs_mk_dir: invalid argument.<4>devfs_mk_dev: could not append to 
> parent for /disc
> last message repeated 151 times
> 
> 
> Cleaned for a missing \n in a printk and with added debug printk's in
> fs/devfs/base.c, this looks like:
> kernel: devfs_mk_dir: invalid argument, buf: .
> kernel: _devfs_append_entry: -EEXIST for :disc
> kernel: devfs_mk_dev: could not append to parent for /disc
> (repeated)
> 
> The last error is a consequence of the error in devfs_mk_dir, so can
> be ignored. The basic problem is that buf is empty.
> 
> Tracing back I ended up in fs/partitions/check.c, which has the following code
> in function register_disk:
> 
>   /* No minors to use for partitions */
>   if (disk->minors == 1) {
>   if (disk->devfs_name[0] != '\0')
>   devfs_add_disk(disk);
>   return;
>   }
> 
>   /* always add handle for the whole disk */
>   devfs_add_partitioned(disk);
> 
> This looks unlogical: why does the first statement check for empty
> disk->devfs_name and is the second one called blindly?
> 
> Changing the last statement to:
>   if (disk->devfs_name[0] != '\0')
>   devfs_add_partitioned(disk);
>   else
>   printk(KERN_WARNING "%s: No devfs_name for %s.\n", 
> __FUNCTION__, disk->disk_name);
> resulted in the errors disappearing and the following log output:
> 
> kernel: register_disk: No devfs_name for md_d0.
> kernel: register_disk: No devfs_name for md_d64.
> kernel: register_disk: No devfs_name for md_d128.
> kernel: register_disk: No devfs_name for md_d192.
> kernel: register_disk: No devfs_name for md_d4.
> kernel: register_disk: No devfs_name for md_d68.
> kernel: register_disk: No devfs_name for md_d132.
> kernel: register_disk: No devfs_name for md_d196.
> (repeated to md_d255)
> 
> I've debugged using kernel version 2.6.8, but a check showed this code is
> unchanged in 2.6.11 and 2.6.12.
> 
> Please review my reasoning. If I'm correct, the attached patch may fix
> the errors (and fix the missing \n). If you think the patch is correct,
> I would appreciate advice how best to get it upstream.
> The other option would of course be that something is more fundamentally
> broken and that disk->devfs_name should be filled in these cases, but
> I doubt that.

Hi Frans,

The null devfs_name check seems fine to me,
I've CCed Richard Gooch for comment, hopefully
he can offer one despite devfs being debricated
upstream.

The \n fix is obviously ok, but again its going away upstream,
so I doubt they care, and I'm not excited about this kind
of fix for Sarge.

> 
> Cheers,
> FJP
> 

> --- fs/partitions/check.c.orig2005-05-19 12:52:23.0 +0200
> +++ fs/partitions/check.c 2005-07-29 00:36:04.523385998 +0200
> @@ -348,7 +348,8 @@
>   }
>  
>   /* always add handle for the whole disk */
> - devfs_add_partitioned(disk);
> + if (disk->devfs_name[0] != '\0')
> + devfs_add_partitioned(disk);
>  
>   /* No such device (e.g., media were just removed) */
>   if (!get_capacity(disk))
> --- fs/devfs/base.c.orig  2005-07-29 00:32:03.329992027 +0200
> +++ fs/devfs/base.c   2005-07-29 00:32:52.08934 +0200
> @@ -1644,7 +1644,7 @@
>   va_start(args, fmt);
>   n = vsnprintf(buf, 64, fmt, args);
>   if (n >= 64 || !buf[0]) {
> - printk(KERN_WARNING "%s: invalid argument.", __FUNCTION__);
> + printk(KERN_WARNING "%s: invalid argument.\n", __FUNCTION__);
>   return -EINVAL;
>   }
>  




-- 
Horms
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] v4l cx88 hue offset fix

[Horms]

On Tue, Aug 02, 2005 at 08:41:27AM -0400, Michael Krufky wrote:
> Horms wrote:
> 
> >Hi Marcelo, 
> >
> >Another fix from 2.6.12.3 that seems approprite for 2.4.
> >Should apply cleanly to your tree.
> > 
> >
> Horms-
> 
> Thank you for the effort of trying to get this into 2.4, but I don't 
> think there is any support at all for cx88 cards in kernel 2.4 v4l.  I 
> wasn't involved in v4l back then, but I took a look at Marcelo's 
> linux-2.4.git/tree , and /drivers/media/video/cx88* just doesn't exist.  
> There is no cx88-video.c file present for this patch to be applied to!
> 
> This one-line fix does make a very big difference, but unfortunately, it 
> looks like 2.4 doesn't have the cx88 driver for the fixing...
> 
> Good to see that debian has backported it to their 2.6.8 kernel, 
> though.  That really makes me smile.  :-)

Sorry about the noise. Dann Frazier and I ran through a bunch of patches
from 2.6.12-stable to see which onese were appropriate for Debian's
2.4.27 and 2.6.8. This patch did indeed get backported to 2.6.8.
And in the course of juggling all the patches I made a mistake and added
it our 2.4.27 patchset and subsequently sent it here.

cx88 indeed is not in 2.4 and the patch is completely invalid for that
tree. Please ignore :)

I do have few other patches from 2.6.12-stable that do seem appropriate
for 2.4, but after this mess up I am waiting for all the builds to
finish before forwarding stuff on.

-- 
Horms
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] v4l cx88 hue offset fix

[Horms]

On Tue, Aug 02, 2005 at 08:41:27AM -0400, Michael Krufky wrote:
 Horms wrote:
 
 Hi Marcelo, 
 
 Another fix from 2.6.12.3 that seems approprite for 2.4.
 Should apply cleanly to your tree.
  
 
 Horms-
 
 Thank you for the effort of trying to get this into 2.4, but I don't 
 think there is any support at all for cx88 cards in kernel 2.4 v4l.  I 
 wasn't involved in v4l back then, but I took a look at Marcelo's 
 linux-2.4.git/tree , and /drivers/media/video/cx88* just doesn't exist.  
 There is no cx88-video.c file present for this patch to be applied to!
 
 This one-line fix does make a very big difference, but unfortunately, it 
 looks like 2.4 doesn't have the cx88 driver for the fixing...
 
 Good to see that debian has backported it to their 2.6.8 kernel, 
 though.  That really makes me smile.  :-)

Sorry about the noise. Dann Frazier and I ran through a bunch of patches
from 2.6.12-stable to see which onese were appropriate for Debian's
2.4.27 and 2.6.8. This patch did indeed get backported to 2.6.8.
And in the course of juggling all the patches I made a mistake and added
it our 2.4.27 patchset and subsequently sent it here.

cx88 indeed is not in 2.4 and the patch is completely invalid for that
tree. Please ignore :)

I do have few other patches from 2.6.12-stable that do seem appropriate
for 2.4, but after this mess up I am waiting for all the builds to
finish before forwarding stuff on.

-- 
Horms
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug#320379: Errors during initrd loading when / is on LVM over RAID

[Horms]

On Fri, Jul 29, 2005 at 12:41:38AM +0200, Frans Pop wrote:
 Package: kernel
 Tags: patch
 
 After switching from a 2.4.27 to 2.6.8 kernel for an old desktop Iuse as
 a server, I noticed the following messages on console and kern.log.
 Note: the errors are not harmful, just ugly; the system boots normally.
 
 kernel: Inspecting /boot/System.map-2.6.8-2-686
 kernel: Loaded 27390 symbols from /boot/System.map-2.6.8-2-686.
 kernel: Symbols match kernel version 2.6.8.
 kernel: No module symbols loaded - kernel modules not enabled.
 kernel: ould not append to parent for /disc
 kernel: devfs_mk_dir: invalid argument.4devfs_mk_dev: could not append to 
 parent for /disc
 last message repeated 151 times
 
 
 Cleaned for a missing \n in a printk and with added debug printk's in
 fs/devfs/base.c, this looks like:
 kernel: devfs_mk_dir: invalid argument, buf: .
 kernel: _devfs_append_entry: -EEXIST for :disc
 kernel: devfs_mk_dev: could not append to parent for /disc
 (repeated)
 
 The last error is a consequence of the error in devfs_mk_dir, so can
 be ignored. The basic problem is that buf is empty.
 
 Tracing back I ended up in fs/partitions/check.c, which has the following code
 in function register_disk:
 
   /* No minors to use for partitions */
   if (disk-minors == 1) {
   if (disk-devfs_name[0] != '\0')
   devfs_add_disk(disk);
   return;
   }
 
   /* always add handle for the whole disk */
   devfs_add_partitioned(disk);
 
 This looks unlogical: why does the first statement check for empty
 disk-devfs_name and is the second one called blindly?
 
 Changing the last statement to:
   if (disk-devfs_name[0] != '\0')
   devfs_add_partitioned(disk);
   else
   printk(KERN_WARNING %s: No devfs_name for %s.\n, 
 __FUNCTION__, disk-disk_name);
 resulted in the errors disappearing and the following log output:
 
 kernel: register_disk: No devfs_name for md_d0.
 kernel: register_disk: No devfs_name for md_d64.
 kernel: register_disk: No devfs_name for md_d128.
 kernel: register_disk: No devfs_name for md_d192.
 kernel: register_disk: No devfs_name for md_d4.
 kernel: register_disk: No devfs_name for md_d68.
 kernel: register_disk: No devfs_name for md_d132.
 kernel: register_disk: No devfs_name for md_d196.
 (repeated to md_d255)
 
 I've debugged using kernel version 2.6.8, but a check showed this code is
 unchanged in 2.6.11 and 2.6.12.
 
 Please review my reasoning. If I'm correct, the attached patch may fix
 the errors (and fix the missing \n). If you think the patch is correct,
 I would appreciate advice how best to get it upstream.
 The other option would of course be that something is more fundamentally
 broken and that disk-devfs_name should be filled in these cases, but
 I doubt that.

Hi Frans,

The null devfs_name check seems fine to me,
I've CCed Richard Gooch for comment, hopefully
he can offer one despite devfs being debricated
upstream.

The \n fix is obviously ok, but again its going away upstream,
so I doubt they care, and I'm not excited about this kind
of fix for Sarge.

 
 Cheers,
 FJP
 

 --- fs/partitions/check.c.orig2005-05-19 12:52:23.0 +0200
 +++ fs/partitions/check.c 2005-07-29 00:36:04.523385998 +0200
 @@ -348,7 +348,8 @@
   }
  
   /* always add handle for the whole disk */
 - devfs_add_partitioned(disk);
 + if (disk-devfs_name[0] != '\0')
 + devfs_add_partitioned(disk);
  
   /* No such device (e.g., media were just removed) */
   if (!get_capacity(disk))
 --- fs/devfs/base.c.orig  2005-07-29 00:32:03.329992027 +0200
 +++ fs/devfs/base.c   2005-07-29 00:32:52.08934 +0200
 @@ -1644,7 +1644,7 @@
   va_start(args, fmt);
   n = vsnprintf(buf, 64, fmt, args);
   if (n = 64 || !buf[0]) {
 - printk(KERN_WARNING %s: invalid argument., __FUNCTION__);
 + printk(KERN_WARNING %s: invalid argument.\n, __FUNCTION__);
   return -EINVAL;
   }
  




-- 
Horms
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] v4l cx88 hue offset fix

[Horms]

On Tue, Aug 02, 2005 at 04:20:00PM +0900, Horms wrote:
> Hi Marcelo, 
> 
> Another fix from 2.6.12.3 that seems approprite for 2.4.
> Should apply cleanly to your tree.

Please ignore this. I sent the wrong patch.
I don't think thie cx88 driver is in 2.4 at all.

> Signed-off-by: Horms <[EMAIL PROTECTED]>
> 
> From: Michael Krufky <[EMAIL PROTECTED]>
> Date: Thu, 30 Jun 2005 20:06:41 + (-0400)
> Subject: [PATCH] v4l cx88 hue offset fix
> X-Git-Tag: v2.6.12.3
> X-Git-Url: 
> http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.12.y.git;a=commitdiff;h=aebaaf4060dd0db163694da8e4ab7ba86add57b9
> 
>   [PATCH] v4l cx88 hue offset fix
>   
>   Changed hue offset to 128 to correct behavior in cx88 cards.  Previously,
>   setting 0% or 100% hue was required to avoid blue/green people on screen.
>   Now, 50% Hue means no offset, just like bt878 stuff.
>   
>   Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
>   Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
>   Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
>   Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> ---
> 
> Backported to Debian's kernel-source-2.6.8 by dann frazier <[EMAIL PROTECTED]>
> 
> --- a/drivers/media/video/cx88/cx88-video.c
> +++ b/drivers/media/video/cx88/cx88-video.c
> @@ -261,7 +261,7 @@ static struct cx88_ctrl cx8800_ctls[] = 
>   .default_value = 0,
>   .type  = V4L2_CTRL_TYPE_INTEGER,
>   },
> - .off   = 0,
> + .off   = 128,
>   .reg   = MO_HUE,
>   .mask  = 0x00ff,
>   .shift = 0,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch] ppc32: stop misusing ntps time_offset value

[Horms]

Hi Marcelo,

is this appropriate for 2.4? It seems to apply cleanly to 
your current git tree.

Signed-off-by: Horms <[EMAIL PROTECTED]>

From: john stultz <[EMAIL PROTECTED]>
Date: Fri, 1 Jul 2005 05:08:54 + (+1000)
Subject: [PATCH] ppc32: stop misusing ntps time_offset value
X-Git-Tag: v2.6.12.3
X-Git-Url: 
http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.12.y.git;a=commitdiff;h=8f399a7448e0b58eae969426f61b7e81d55d2639

  [PATCH] ppc32: stop misusing ntps time_offset value
  
  As part of my timeofday rework, I've been looking at the NTP code and I
  noticed that the PPC architecture is apparently misusing the NTP's
  time_offset (it is a terrible name!) value as some form of timezone offset.
  
  This could cause problems when time_offset changed by the NTP code.  This
  patch changes the PPC code so it uses a more clear local variable:
  timezone_offset.
  
  Signed-off-by: John Stultz <[EMAIL PROTECTED]>
  Acked-by: Tom Rini <[EMAIL PROTECTED]>
  Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
  Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
  Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
  Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
Backported to Debian's 2.6.8 by dann frazier <[EMAIL PROTECTED]>
Backported to Debian's 2.4.27 by Horms <[EMAIL PROTECTED]>

--- a/arch/ppc/kernel/time.c2003-08-25 20:44:40.0 +0900
+++ b/arch/ppc/kernel/time.c2005-08-02 15:37:12.0 +0900
@@ -84,7 +84,7 @@
 
 extern unsigned long wall_jiffies;
 
-static long time_offset;
+static long timezone_offset;
 
 spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED;
 
@@ -187,7 +187,7 @@
 xtime.tv_sec - last_rtc_update >= 659 &&
 abs(xtime.tv_usec - (100-100/HZ)) < 50/HZ &&
 jiffies - wall_jiffies == 1) {
-   if (ppc_md.set_rtc_time(xtime.tv_sec+1 + time_offset) 
== 0)
+   if (ppc_md.set_rtc_time(xtime.tv_sec+1 + 
timezone_offset) == 0)
last_rtc_update = xtime.tv_sec+1;
else
/* Try again one minute later */
@@ -297,7 +297,7 @@
unsigned old_stamp, stamp, elapsed;
 
 if (ppc_md.time_init != NULL)
-time_offset = ppc_md.time_init();
+timezone_offset = ppc_md.time_init();
 
if (__USE_RTC()) {
/* 601 processor: dec counts down by 128 every 128ns */
@@ -344,9 +344,9 @@
/* If platform provided a timezone (pmac), we correct the time
 * using do_sys_settimeofday() which in turn calls warp_clock()
 */
-if (time_offset) {
+if (timezone_offset) {
struct timezone tz;
-   tz.tz_minuteswest = -time_offset / 60;
+   tz.tz_minuteswest = -timezone_offset / 60;
tz.tz_dsttime = 0;
do_sys_settimeofday(NULL, );
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch] v4l cx88 hue offset fix

[Horms]

Hi Marcelo, 

Another fix from 2.6.12.3 that seems approprite for 2.4.
Should apply cleanly to your tree.

Signed-off-by: Horms <[EMAIL PROTECTED]>

From: Michael Krufky <[EMAIL PROTECTED]>
Date: Thu, 30 Jun 2005 20:06:41 + (-0400)
Subject: [PATCH] v4l cx88 hue offset fix
X-Git-Tag: v2.6.12.3
X-Git-Url: 
http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.12.y.git;a=commitdiff;h=aebaaf4060dd0db163694da8e4ab7ba86add57b9

  [PATCH] v4l cx88 hue offset fix
  
  Changed hue offset to 128 to correct behavior in cx88 cards.  Previously,
  setting 0% or 100% hue was required to avoid blue/green people on screen.
  Now, 50% Hue means no offset, just like bt878 stuff.
  
  Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
  Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
  Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
  Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---

Backported to Debian's kernel-source-2.6.8 by dann frazier <[EMAIL PROTECTED]>

--- a/drivers/media/video/cx88/cx88-video.c
+++ b/drivers/media/video/cx88/cx88-video.c
@@ -261,7 +261,7 @@ static struct cx88_ctrl cx8800_ctls[] = 
.default_value = 0,
.type  = V4L2_CTRL_TYPE_INTEGER,
},
-   .off   = 0,
+   .off   = 128,
.reg   = MO_HUE,
.mask  = 0x00ff,
.shift = 0,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch] v4l cx88 hue offset fix

[Horms]

Hi Marcelo, 

Another fix from 2.6.12.3 that seems approprite for 2.4.
Should apply cleanly to your tree.

Signed-off-by: Horms [EMAIL PROTECTED]

From: Michael Krufky [EMAIL PROTECTED]
Date: Thu, 30 Jun 2005 20:06:41 + (-0400)
Subject: [PATCH] v4l cx88 hue offset fix
X-Git-Tag: v2.6.12.3
X-Git-Url: 
http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.12.y.git;a=commitdiff;h=aebaaf4060dd0db163694da8e4ab7ba86add57b9

  [PATCH] v4l cx88 hue offset fix
  
  Changed hue offset to 128 to correct behavior in cx88 cards.  Previously,
  setting 0% or 100% hue was required to avoid blue/green people on screen.
  Now, 50% Hue means no offset, just like bt878 stuff.
  
  Signed-off-by: Michael Krufky [EMAIL PROTECTED]
  Signed-off-by: Mauro Carvalho Chehab [EMAIL PROTECTED]
  Signed-off-by: Chris Wright [EMAIL PROTECTED]
  Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---

Backported to Debian's kernel-source-2.6.8 by dann frazier [EMAIL PROTECTED]

--- a/drivers/media/video/cx88/cx88-video.c
+++ b/drivers/media/video/cx88/cx88-video.c
@@ -261,7 +261,7 @@ static struct cx88_ctrl cx8800_ctls[] = 
.default_value = 0,
.type  = V4L2_CTRL_TYPE_INTEGER,
},
-   .off   = 0,
+   .off   = 128,
.reg   = MO_HUE,
.mask  = 0x00ff,
.shift = 0,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch] ppc32: stop misusing ntps time_offset value

[Horms]

Hi Marcelo,

is this appropriate for 2.4? It seems to apply cleanly to 
your current git tree.

Signed-off-by: Horms [EMAIL PROTECTED]

From: john stultz [EMAIL PROTECTED]
Date: Fri, 1 Jul 2005 05:08:54 + (+1000)
Subject: [PATCH] ppc32: stop misusing ntps time_offset value
X-Git-Tag: v2.6.12.3
X-Git-Url: 
http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.12.y.git;a=commitdiff;h=8f399a7448e0b58eae969426f61b7e81d55d2639

  [PATCH] ppc32: stop misusing ntps time_offset value
  
  As part of my timeofday rework, I've been looking at the NTP code and I
  noticed that the PPC architecture is apparently misusing the NTP's
  time_offset (it is a terrible name!) value as some form of timezone offset.
  
  This could cause problems when time_offset changed by the NTP code.  This
  patch changes the PPC code so it uses a more clear local variable:
  timezone_offset.
  
  Signed-off-by: John Stultz [EMAIL PROTECTED]
  Acked-by: Tom Rini [EMAIL PROTECTED]
  Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
  Signed-off-by: Andrew Morton [EMAIL PROTECTED]
  Signed-off-by: Chris Wright [EMAIL PROTECTED]
  Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
Backported to Debian's 2.6.8 by dann frazier [EMAIL PROTECTED]
Backported to Debian's 2.4.27 by Horms [EMAIL PROTECTED]

--- a/arch/ppc/kernel/time.c2003-08-25 20:44:40.0 +0900
+++ b/arch/ppc/kernel/time.c2005-08-02 15:37:12.0 +0900
@@ -84,7 +84,7 @@
 
 extern unsigned long wall_jiffies;
 
-static long time_offset;
+static long timezone_offset;
 
 spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED;
 
@@ -187,7 +187,7 @@
 xtime.tv_sec - last_rtc_update = 659 
 abs(xtime.tv_usec - (100-100/HZ))  50/HZ 
 jiffies - wall_jiffies == 1) {
-   if (ppc_md.set_rtc_time(xtime.tv_sec+1 + time_offset) 
== 0)
+   if (ppc_md.set_rtc_time(xtime.tv_sec+1 + 
timezone_offset) == 0)
last_rtc_update = xtime.tv_sec+1;
else
/* Try again one minute later */
@@ -297,7 +297,7 @@
unsigned old_stamp, stamp, elapsed;
 
 if (ppc_md.time_init != NULL)
-time_offset = ppc_md.time_init();
+timezone_offset = ppc_md.time_init();
 
if (__USE_RTC()) {
/* 601 processor: dec counts down by 128 every 128ns */
@@ -344,9 +344,9 @@
/* If platform provided a timezone (pmac), we correct the time
 * using do_sys_settimeofday() which in turn calls warp_clock()
 */
-if (time_offset) {
+if (timezone_offset) {
struct timezone tz;
-   tz.tz_minuteswest = -time_offset / 60;
+   tz.tz_minuteswest = -timezone_offset / 60;
tz.tz_dsttime = 0;
do_sys_settimeofday(NULL, tz);
 }
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] v4l cx88 hue offset fix

[Horms]

On Tue, Aug 02, 2005 at 04:20:00PM +0900, Horms wrote:
 Hi Marcelo, 
 
 Another fix from 2.6.12.3 that seems approprite for 2.4.
 Should apply cleanly to your tree.

Please ignore this. I sent the wrong patch.
I don't think thie cx88 driver is in 2.4 at all.

 Signed-off-by: Horms [EMAIL PROTECTED]
 
 From: Michael Krufky [EMAIL PROTECTED]
 Date: Thu, 30 Jun 2005 20:06:41 + (-0400)
 Subject: [PATCH] v4l cx88 hue offset fix
 X-Git-Tag: v2.6.12.3
 X-Git-Url: 
 http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.12.y.git;a=commitdiff;h=aebaaf4060dd0db163694da8e4ab7ba86add57b9
 
   [PATCH] v4l cx88 hue offset fix
   
   Changed hue offset to 128 to correct behavior in cx88 cards.  Previously,
   setting 0% or 100% hue was required to avoid blue/green people on screen.
   Now, 50% Hue means no offset, just like bt878 stuff.
   
   Signed-off-by: Michael Krufky [EMAIL PROTECTED]
   Signed-off-by: Mauro Carvalho Chehab [EMAIL PROTECTED]
   Signed-off-by: Chris Wright [EMAIL PROTECTED]
   Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
 ---
 
 Backported to Debian's kernel-source-2.6.8 by dann frazier [EMAIL PROTECTED]
 
 --- a/drivers/media/video/cx88/cx88-video.c
 +++ b/drivers/media/video/cx88/cx88-video.c
 @@ -261,7 +261,7 @@ static struct cx88_ctrl cx8800_ctls[] = 
   .default_value = 0,
   .type  = V4L2_CTRL_TYPE_INTEGER,
   },
 - .off   = 0,
 + .off   = 128,
   .reg   = MO_HUE,
   .mask  = 0x00ff,
   .shift = 0,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Maintainers list update: linux-net -> netdev

[Horms]

On Tue, Apr 12, 2005 at 12:14:56PM -0700, George Anzinger wrote:
> Horms wrote:
> >
> >Use netdev as the mailing list contact instead of the mostly dead
> >linux-net list.
> >
> ~
> > PHRAM MTD DRIVER
> >@@ -1795,7 +1795,7 @@
> > POSIX CLOCKS and TIMERS
> > P:  George Anzinger
> > M:  george@mvista.com
> >-L:  linux-net@vger.kernel.org
> >+L:  netdev@oss.sgi.com
> > S:  Supported
> > 
> I don't really know about the rest of them, but I think this should be:
> L: linux-kernel@vger.kernel.org
> 
> Least wise that is where I look...

Yes, I was wondering about that one. Here is a patch that
adds to my previous patch. Trivial to say the least. 
I can re-diff the whole thing if that is more convenient.

-- 
Horms

POSIX CLOCKS and TIMERS disscussion is more appropriate
on linux-kernel than linux-net. As suggested by the maintainer,
George Anzinger.

Signed-off-by: Horms <[EMAIL PROTECTED]>

--- a/MAINTAINERS   2005-04-13 11:06:39.0 +0900
+++ b/MAINTAINERS   2005-04-13 11:07:04.0 +0900
@@ -1795,7 +1795,7 @@
 POSIX CLOCKS and TIMERS
 P: George Anzinger
 M: george@mvista.com
-L: linux-net@vger.kernel.org
+L: linux-kernel@vger.kernel.org
 S: Supported
 
 PNP SUPPORT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Maintainers list update: linux-net -> netdev

[Horms]

On Sat, Apr 09, 2005 at 03:52:05PM +0200, Jörn Engel wrote:
> On Fri, 8 April 2005 22:16:07 +0200, Pavel Machek wrote:
> > 
> > More importantly, it is still listed as "the list" for network
> > drivers...
> > 
> > NETWORK DEVICE DRIVERS
> > P:  Andrew Morton
> > M:  [EMAIL PROTECTED]
> > P:  Jeff Garzik
> > M:  [EMAIL PROTECTED]
> > L:  linux-net@vger.kernel.org
> > S:  Maintained
> 
> Maybe one of the two maintainers might want to change that? ;)

Use netdev as the mailing list contact instead of the mostly dead
linux-net list.

Signed-off-by: Horms <[EMAIL PROTECTED]>

= MAINTAINERS 1.295 vs edited =
--- 1.295/MAINTAINERS   2005-04-04 06:20:11 +09:00
+++ edited/MAINTAINERS  2005-04-12 15:11:38 +09:00
@@ -73,7 +73,7 @@
 3C359 NETWORK DRIVER
 P: Mike Phillips
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 L: [EMAIL PROTECTED]
 W: http://www.linuxtr.net
 S: Maintained
@@ -81,13 +81,13 @@
 3C505 NETWORK DRIVER
 P: Philip Blundell
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 3CR990 NETWORK DRIVER
 P: David Dillow
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 3W- ATA-RAID CONTROLLER DRIVER
@@ -143,7 +143,7 @@
 8390 NETWORK DRIVERS [WD80x3/SMC-ELITE, SMC-ULTRA, NE2000, 3C503, etc.]
 P: Paul Gortmaker
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 A2232 SERIAL BOARD DRIVER
@@ -334,7 +334,7 @@
 
 ARPD SUPPORT
 P: Jonathan Layes
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 ASUS ACPI EXTRAS DRIVER
@@ -708,7 +708,7 @@
 
 DIGI RIGHTSWITCH NETWORK DRIVER
 P: Rick Richardson
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 W: http://www.digi.com
 S: Orphaned
 
@@ -814,7 +814,7 @@
 ETHEREXPRESS-16 NETWORK DRIVER
 P: Philip Blundell
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 ETHERNET BRIDGE
@@ -877,7 +877,7 @@
 FRAME RELAY DLCI/FRAD (Sangoma drivers too)
 P: Mike McLagan
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 FREEVXFS FILESYSTEM
@@ -1217,7 +1217,7 @@
 IPX NETWORK LAYER
 P: Arnaldo Carvalho de Melo
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 IRDA SUBSYSTEM
@@ -1594,13 +1594,13 @@
 M: [EMAIL PROTECTED]
 P: Jeff Garzik
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 NETWORKING [GENERAL]
 P: Networking Team
 M: netdev@oss.sgi.com
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 NETWORKING [IPv4/IPv6]
@@ -1636,7 +1636,7 @@
 P: Jan-Pascal van Best and Andreas Mohr
 M: Jan-Pascal van Best <[EMAIL PROTECTED]>
 M: Andreas Mohr <[EMAIL PROTECTED]>
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 NINJA SCSI-3 / NINJA SCSI-32Bi (16bit/CardBus) PCMCIA SCSI HOST ADAPTER DRIVER
@@ -1678,7 +1678,7 @@
 M: [EMAIL PROTECTED]
 P: Mike Phillips
 M: [EMAIL PROTECTED] 
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 L: [EMAIL PROTECTED]
 W: http://www.linuxtr.net
 S: Maintained
@@ -1783,7 +1783,7 @@
 PCNET32 NETWORK DRIVER
 P: Thomas Bogendörfer
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 PHRAM MTD DRIVER
@@ -1795,7 +1795,7 @@
 POSIX CLOCKS and TIMERS
 P: George Anzinger
 M: george@mvista.com
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Supported
 
 PNP SUPPORT
@@ -2042,7 +2042,7 @@
 P: Daniele Venzano
 M: [EMAIL PROTECTED]
 W: http://www.brownhat.org/sis900.html
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 SIS FRAMEBUFFER DRIVER
@@ -2101,7 +2101,7 @@
 SONIC NETWORK DRIVER
 P: Thomas Bogendoerfer
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 SONY VAIO CONTROL DEVICE DRIVER
@@ -2151,7 +2151,7 @@
 SPX NETWORK LAYER
 P: Jay Schulist
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Supported
 
 SRM (Alpha) environment access
@@ -2230,7 +2230,7 @@
 TOKEN-RING NETWORK DRIVER
 P: Mike Phillips
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 L: [EMAIL PROTECTED]
 W: http://www.linuxtr.net
 S: Maintained
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/