A regression in IA64 kexec/kdump patch for 2.6.18?

A regression in IA64 kexec/kdump patch for 2.6.18?

[Jay Lan]

I ran into a problem not seen in kexec/dkump 2.6.17rc5 ia64 patch.
The system on test was an Altix.

The system was booted up fine; however, after loading 'kexec -p'
and "echo c >/proc/sysrq-triggeŕ", the crashdump kernel would try
to boot up and restarted the system near the end of init().

The extraodinary message observed on the console was
    Warning: unable to open an initial console

but the actual reboot seems to be invoked in running /sbin/init:
    run_init_process("/sbin/init");

The problem is 100% reproducible. I have disabled all cpus except
cpu0 in my testing.

Is this a known problem? Anyone else runs into this?

Thanks,
 - jay
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A regression in IA64 kexec/kdump patch for 2.6.18?

[Jay Lan]

Jay Lan wrote:
> I ran into a problem not seen in kexec/dkump 2.6.17rc5 ia64 patch.
> The system on test was an Altix.
> 
> The system was booted up fine; however, after loading 'kexec -p'
> and "echo c >/proc/sysrq-triggeŕ", the crashdump kernel would try
> to boot up and restarted the system near the end of init().
> 
> The extraodinary message observed on the console was
>     Warning: unable to open an initial console

It failed in do_filp_open(AT_FDCWD, "/dev/console", O_RDWR, 0)
with error -2.

However, it was fine booting up as the 1st kernel.

- jay


> 
> but the actual reboot seems to be invoked in running /sbin/init:
>     run_init_process("/sbin/init");
> 
> The problem is 100% reproducible. I have disabled all cpus except
> cpu0 in my testing.
> 
> Is this a known problem? Anyone else runs into this?
> 
> Thanks,
>  - jay

Re: A regression in IA64 kexec/kdump patch for 2.6.18?

[Zou Nan hai]

On Tue, 2006-10-17 at 04:59, Jay Lan wrote:
> I ran into a problem not seen in kexec/dkump 2.6.17rc5 ia64 patch.
> The system on test was an Altix.
> 
  You mean 2.6.18rc5 patch?
> The system was booted up fine; however, after loading 'kexec -p'
> and "echo c >/proc/sysrq-triggeŕ", the crashdump kernel would try
> to boot up and restarted the system near the end of init().
> 
> The extraodinary message observed on the console was
>     Warning: unable to open an initial console
> 
> but the actual reboot seems to be invoked in running /sbin/init:
>     run_init_process("/sbin/init");
> 
> The problem is 100% reproducible. I have disabled all cpus except
> cpu0 in my testing.
> 
> Is this a known problem? Anyone else runs into this?
> 
  It seems to be an incorrect initrd problem

  Zou Nan hai
> Thanks,
>  - jay

Re: A regression in IA64 kexec/kdump patch for 2.6.18?

[Jay Lan]

Zou Nan hai wrote:
> On Tue, 2006-10-17 at 04:59, Jay Lan wrote:
>> I ran into a problem not seen in kexec/dkump 2.6.17rc5 ia64 patch.
>> The system on test was an Altix.
>>
>   You mean 2.6.18rc5 patch?

Oops, yes, i meant 2.6.18rc5... although i found the kernel patch
was not the cause. See below.

>> The system was booted up fine; however, after loading 'kexec -p'
>> and "echo c >/proc/sysrq-triggeŕ", the crashdump kernel would try
>> to boot up and restarted the system near the end of init().
>>
>> The extraodinary message observed on the console was
>>     Warning: unable to open an initial console
>>
>> but the actual reboot seems to be invoked in running /sbin/init:
>>     run_init_process("/sbin/init");
>>
>> The problem is 100% reproducible. I have disabled all cpus except
>> cpu0 in my testing.
>>
>> Is this a known problem? Anyone else runs into this?
>>
>   It seems to be an incorrect initrd problem

No, i used the correct initrd. I would not be able to boot the
kernel/initrd pair as the 1st kernel (sytstem kernel) if the
initrd was incorrect.

Well, i built 2.6.18 kernel and 2.6.18rc5 kernels.
I also built 2 kexec-tools based on kdump10 patch. I have been
associating the kexec-tools tree that i built at the rc5 time with
the rc5 kernel and the newer kexec-tools tree with the 2.6.18
kernel.

I just ran a few tests with different combination of kexec-tools
and kernels. Well, it showed that the rc5 version of kexec-tools
worked correctly with both kernels, but the newer version of
kexec-tools displayed the system restart problem with both kernels.

So, it was the kexec-tools that caused the problem. Not the kernel
side. I will diff the patches i applied to both trees...

Later,
 - jay



> 
>   Zou Nan hai
>> Thanks,
>>  - jay
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A regression in IA64 kexec/kdump patch for 2.6.18?

[Jay Lan]

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

Jay Lan wrote:
<snip>
> 
> Well, i built 2.6.18 kernel and 2.6.18rc5 kernels.
> I also built 2 kexec-tools based on kdump10 patch. I have been
> associating the kexec-tools tree that i built at the rc5 time with
> the rc5 kernel and the newer kexec-tools tree with the 2.6.18
> kernel.
> 
> I just ran a few tests with different combination of kexec-tools
> and kernels. Well, it showed that the rc5 version of kexec-tools
> worked correctly with both kernels, but the newer version of
> kexec-tools displayed the system restart problem with both kernels.
> 
> So, it was the kexec-tools that caused the problem. Not the kernel
> side. I will diff the patches i applied to both trees...

Nan-hai,

OK, the '-noio' option patch you posted on 9/20 was the cause of
my system restart.
http://lists.osdl.org/pipermail/fastboot/2006-September/004062.html

If instead, if i make every inline functions in
purgatory/arch/ia64/io.h null functions, it would then work.
I will attach the patch i used (based on your suggestion) here for
your reference. It was in rough form.


Thanks,
 - jay


> 
> Later,
>  - jay
> 
> 
> 
>>   Zou Nan hai
>>> Thanks,
>>>  - jay
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: kexec-ia64-reset-vga --]
[-- Type: text/plain, Size: 1676 bytes --]

Index: kexec-tools-1.101/purgatory/arch/ia64/io.h
===================================================================
--- kexec-tools-1.101.orig/purgatory/arch/ia64/io.h	2006-10-16 18:19:07.346416494 -0700
+++ kexec-tools-1.101/purgatory/arch/ia64/io.h	2006-10-16 18:47:14.742913628 -0700
@@ -4,6 +4,7 @@
 #define MF()	asm volatile ("mf.a" ::: "memory")
 #define IO_SPACE_ENCODING(p)     ((((p) >> 2) << 12) | (p & 0xfff))
 
+#ifdef DO_VGA_IO
 static inline void *io_addr (unsigned long port)
 {
         unsigned long offset;
@@ -91,4 +92,46 @@ static inline void writel(unsigned int b
 {
         *(volatile unsigned int *) addr = b;
 }
+#else
+static inline void *io_addr (unsigned long port)
+{ return (void*)0; }
+
+static inline unsigned int inb (unsigned long port)
+{ return 0; }
+
+static inline unsigned int inw (unsigned long port)
+{ return 0; }
+
+static inline unsigned int ia64_inl (unsigned long port)
+{ return 0; }
+
+static inline void outb (unsigned char val, unsigned long port)
+{ return; }
+
+static inline void outw (unsigned short val, unsigned long port)
+{ return; }
+
+static inline void outl (unsigned int val, unsigned long port)
+{ return; }
+
+
+static inline unsigned char readb(const volatile void  *addr)
+{ return 0; }
+
+static inline unsigned short readw(const volatile void  *addr)
+{ return 0; }
+
+static inline unsigned int readl(const volatile void  *addr)
+{ return 0; }
+
+static inline void writeb(unsigned char b, volatile void  *addr)
+{ return; }
+
+static inline void writew(unsigned short b, volatile void  *addr)
+{ return; }
+
+static inline void writel(unsigned int b, volatile void  *addr)
+{ return; }
+
+#endif
 #endif

Re: A regression in IA64 kexec/kdump patch for 2.6.18?

[Zou Nan hai]

On Tue, 2006-10-17 at 09:51, Jay Lan wrote:
> Jay Lan wrote:
> <snip>
> > 
> > Well, i built 2.6.18 kernel and 2.6.18rc5 kernels.
> > I also built 2 kexec-tools based on kdump10 patch. I have been
> > associating the kexec-tools tree that i built at the rc5 time with
> > the rc5 kernel and the newer kexec-tools tree with the 2.6.18
> > kernel.
> > 
> > I just ran a few tests with different combination of kexec-tools
> > and kernels. Well, it showed that the rc5 version of kexec-tools
> > worked correctly with both kernels, but the newer version of
> > kexec-tools displayed the system restart problem with both kernels.
> > 
> > So, it was the kexec-tools that caused the problem. Not the kernel
> > side. I will diff the patches i applied to both trees...
> 
> Nan-hai,
> 
> OK, the '-noio' option patch you posted on 9/20 was the cause of
> my system restart.
> http://lists.osdl.org/pipermail/fastboot/2006-September/004062.html
> 
> If instead, if i make every inline functions in
> purgatory/arch/ia64/io.h null functions, it would then work.
> I will attach the patch i used (based on your suggestion) here for
> your reference. It was in rough form.
> 
> 
> Thanks,
>  - jay
> 
  Hi, did you run kexec -p with --noio option?

Zou Nan hai
> 
> > 
> > Later,
> >  - jay
> > 
> > 
> > 
> >>   Zou Nan hai
> >>> Thanks,
> >>>  - jay
> >> -
> >> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> ______________________________________________________________________
> 
> Index: kexec-tools-1.101/purgatory/arch/ia64/io.h
> =================================> --- kexec-tools-1.101.orig/purgatory/arch/ia64/io.h	2006-10-16 18:19:07.346416494 -0700
> +++ kexec-tools-1.101/purgatory/arch/ia64/io.h	2006-10-16 18:47:14.742913628 -0700
> @@ -4,6 +4,7 @@
>  #define MF()	asm volatile ("mf.a" ::: "memory")
>  #define IO_SPACE_ENCODING(p)     ((((p) >> 2) << 12) | (p & 0xfff))
>  
> +#ifdef DO_VGA_IO
>  static inline void *io_addr (unsigned long port)
>  {
>          unsigned long offset;
> @@ -91,4 +92,46 @@ static inline void writel(unsigned int b
>  {
>          *(volatile unsigned int *) addr = b;
>  }
> +#else
> +static inline void *io_addr (unsigned long port)
> +{ return (void*)0; }
> +
> +static inline unsigned int inb (unsigned long port)
> +{ return 0; }
> +
> +static inline unsigned int inw (unsigned long port)
> +{ return 0; }
> +
> +static inline unsigned int ia64_inl (unsigned long port)
> +{ return 0; }
> +
> +static inline void outb (unsigned char val, unsigned long port)
> +{ return; }
> +
> +static inline void outw (unsigned short val, unsigned long port)
> +{ return; }
> +
> +static inline void outl (unsigned int val, unsigned long port)
> +{ return; }
> +
> +
> +static inline unsigned char readb(const volatile void  *addr)
> +{ return 0; }
> +
> +static inline unsigned short readw(const volatile void  *addr)
> +{ return 0; }
> +
> +static inline unsigned int readl(const volatile void  *addr)
> +{ return 0; }
> +
> +static inline void writeb(unsigned char b, volatile void  *addr)
> +{ return; }
> +
> +static inline void writew(unsigned short b, volatile void  *addr)
> +{ return; }
> +
> +static inline void writel(unsigned int b, volatile void  *addr)
> +{ return; }
> +
> +#endif
>  #endif

Re: A regression in IA64 kexec/kdump patch for 2.6.18?

[Jay Lan]

Zou Nan hai wrote:
> On Tue, 2006-10-17 at 09:51, Jay Lan wrote:
>> Jay Lan wrote:
>> <snip>
>>> Well, i built 2.6.18 kernel and 2.6.18rc5 kernels.
>>> I also built 2 kexec-tools based on kdump10 patch. I have been
>>> associating the kexec-tools tree that i built at the rc5 time with
>>> the rc5 kernel and the newer kexec-tools tree with the 2.6.18
>>> kernel.
>>>
>>> I just ran a few tests with different combination of kexec-tools
>>> and kernels. Well, it showed that the rc5 version of kexec-tools
>>> worked correctly with both kernels, but the newer version of
>>> kexec-tools displayed the system restart problem with both kernels.
>>>
>>> So, it was the kexec-tools that caused the problem. Not the kernel
>>> side. I will diff the patches i applied to both trees...
>> Nan-hai,
>>
>> OK, the '-noio' option patch you posted on 9/20 was the cause of
>> my system restart.
>> http://lists.osdl.org/pipermail/fastboot/2006-September/004062.html
>>
>> If instead, if i make every inline functions in
>> purgatory/arch/ia64/io.h null functions, it would then work.
>> I will attach the patch i used (based on your suggestion) here for
>> your reference. It was in rough form.
>>
>>
>> Thanks,
>>  - jay
>>
>   Hi, did you run kexec -p with --noio option?

Yes, i did. Without specifying the option the crashkernel
would not even have started.

Here is the command line i used:
# kexec -p /boot/efi/efi/redhat/vmlinuz-2.6.18-kdump --noio
--initrd=/boot/efi/efi/redhat/initrd-2.6.18-kdump
--append="root=/dev/sdb6 irqpoll maxcpus=1 ro console=ttySG0"


Thanks,
 - jay

> 
> Zou Nan hai
>>> Later,
>>>  - jay
>>>
>>>
>>>
>>>>   Zou Nan hai
>>>>> Thanks,
>>>>>  - jay
>>>> -
>>>> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> -
>>> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> ______________________________________________________________________
>>
>> Index: kexec-tools-1.101/purgatory/arch/ia64/io.h
>> =================================>> --- kexec-tools-1.101.orig/purgatory/arch/ia64/io.h	2006-10-16 18:19:07.346416494 -0700
>> +++ kexec-tools-1.101/purgatory/arch/ia64/io.h	2006-10-16 18:47:14.742913628 -0700
>> @@ -4,6 +4,7 @@
>>  #define MF()	asm volatile ("mf.a" ::: "memory")
>>  #define IO_SPACE_ENCODING(p)     ((((p) >> 2) << 12) | (p & 0xfff))
>>  
>> +#ifdef DO_VGA_IO
>>  static inline void *io_addr (unsigned long port)
>>  {
>>          unsigned long offset;
>> @@ -91,4 +92,46 @@ static inline void writel(unsigned int b
>>  {
>>          *(volatile unsigned int *) addr = b;
>>  }
>> +#else
>> +static inline void *io_addr (unsigned long port)
>> +{ return (void*)0; }
>> +
>> +static inline unsigned int inb (unsigned long port)
>> +{ return 0; }
>> +
>> +static inline unsigned int inw (unsigned long port)
>> +{ return 0; }
>> +
>> +static inline unsigned int ia64_inl (unsigned long port)
>> +{ return 0; }
>> +
>> +static inline void outb (unsigned char val, unsigned long port)
>> +{ return; }
>> +
>> +static inline void outw (unsigned short val, unsigned long port)
>> +{ return; }
>> +
>> +static inline void outl (unsigned int val, unsigned long port)
>> +{ return; }
>> +
>> +
>> +static inline unsigned char readb(const volatile void  *addr)
>> +{ return 0; }
>> +
>> +static inline unsigned short readw(const volatile void  *addr)
>> +{ return 0; }
>> +
>> +static inline unsigned int readl(const volatile void  *addr)
>> +{ return 0; }
>> +
>> +static inline void writeb(unsigned char b, volatile void  *addr)
>> +{ return; }
>> +
>> +static inline void writew(unsigned short b, volatile void  *addr)
>> +{ return; }
>> +
>> +static inline void writel(unsigned int b, volatile void  *addr)
>> +{ return; }
>> +
>> +#endif
>>  #endif