Re: [lkdump-develop] Re: [ANNOUNCE 0/7] Diskdump 1.0 Release

Re: [lkdump-develop] Re: [ANNOUNCE 0/7] Diskdump 1.0 Release

[Itsuro Oda]

Hi,

I am a developer of an yet another crash dump (mkdump). 
I'd like to know conditions which cause taking dump fail.
It is helpful to share those informations for dump developers.

I have three major concerns about taking dump.
* interrupt disable
  taking dump should be run under interrput disable.
  diskdump is aware of that. How about kexec based dump ?
* avoid deadlock
  taking dump should not get any locks to avoid deadlock. (?)
  I think there are many posibility of deadlock in the kexec
  based dump (from crash occur to initiate the new kernel).
  (mkdump does not meet neither yet. :-p)
* be sure to get the other CPUs' register value
  How are the other CPUs' regsiter value get and how are the 
  other CPUs stoped ?
(of course the goal of mkdump is to solve these points 
 although not implemented yet :-)

Any other points to be consider ?
Comments and suggestions are welcome.

Thank you.
-- 
Itsuro ODA <oda@valinux.co.jp>

Re: [lkdump-develop] Re: [ANNOUNCE 0/7] Diskdump 1.0 Release

[Vivek Goyal]

Hi,

On Tue, 2004-11-30 at 06:01, Itsuro Oda wrote:
> Hi,
> 
> I am a developer of an yet another crash dump (mkdump). 
> I'd like to know conditions which cause taking dump fail.
> It is helpful to share those informations for dump developers.
> 
> I have three major concerns about taking dump.
> * interrupt disable
>   taking dump should be run under interrput disable.
>   diskdump is aware of that. How about kexec based dump ?
> * avoid deadlock
>   taking dump should not get any locks to avoid deadlock. (?)
>   I think there are many posibility of deadlock in the kexec
>   based dump (from crash occur to initiate the new kernel).
>   (mkdump does not meet neither yet. :-p)

Now kexec based dump is in -mm tree. Could you please have a look at the
code and point out if any problems you see.

> * be sure to get the other CPUs' register value
>   How are the other CPUs' regsiter value get and how are the 
>   other CPUs stoped ?

Kexec based dump does capture the other CPU's register values.

> (of course the goal of mkdump is to solve these points 
>  although not implemented yet :-)
> 
> Any other points to be consider ?
> Comments and suggestions are welcome.
> 
> Thank you.

Thanks
Vivek

Re: [lkdump-develop] Re: [ANNOUNCE 0/7] Diskdump 1.0 Release

[Itsuro Oda]

Hi,

On 30 Nov 2004 15:56:45 +0530
Vivek Goyal <vgoyal@in.ibm.com> wrote:

> 
> Now kexec based dump is in -mm tree. Could you please have a look at the
> code and point out if any problems you see.

(I looked 2.6.10-rc1-mm3.)

At first crash_machine_kexec() should be called before bust_spinlock(0)
in the panic() function :-)

In disable_IO_APIC() (this is called from crash_dump_stop_cpus())
spin_lock_irqsave(&ioapic_lock, flags) is required. It may be cause
a deadlock. (The other CPU may be stoped with this lock hold.)

It seems no lock required except the point mentioned above from
crash_machine_kexec called to jumping the new kernel. I feel it is
fine.

(BTW. The disconnect_bsp_APIC() in the crash_dump_stop_cpus() 
 is called twice if both CONFIG_X86_IO_APIC and CONFIG_X86_LOCAL_APIC
 are set. The code is beter as follows.
#if defined(CONFIG_X86_IO_APIC)
        disable_IO_APIC();
#elif defined(CONFIG_X86_LOCAL_APIC)
        disconnect_bsp_APIC();
#endif
)

Thank you.
-- 
Itsuro ODA <oda@valinux.co.jp>

Re: [lkdump-develop] Re: [ANNOUNCE 0/7] Diskdump 1.0 Release

[Arjan van de Ven]

On Tue, 2004-11-30 at 10:15 +0900, Takao Indoh wrote:
> On Mon, 29 Nov 2004 13:45:13 +0100, Arjan van de Ven wrote:
> 
> >>
> >> I think kexec-dump is not stable yet.
> >
> >Do you have any facts to back this up? Is your project more stable ?
> >What is the success rate of dumps of diskdump ? How does that compare to
> >kexec-dump under the same circumstances ?
> 
> Sorry, a word "stable" was not appropriate. I meant that kexec-dump was
> under development yet. 

well diskdump seems to be quite under development as well; only a subset
of drivers is supported and your latest release just added initial
support for several architectures.

> kexec-dump works well on i386/x86_64, but it is
> in the development stage on other architectures.

not too different from diskdump then...

> 
> >> I heard that kexec-dump of
> >> some architecture (ex. ia64) had some problems and not worked.
> >
> >wouldn't it be better to then help finish that rather than making an
> >alternative ? 
> 
> It is, if diskdump project just started now. But the basic code of
> diskdump is almost completed. I think it is more efficient to enhance 
> quality of diskdump than help kexec-dump.

You are obviously free to spend your time wherever you want to, even though I do not agree with your reasoning.

Re: [lkdump-develop] Re: [ANNOUNCE 0/7] Diskdump 1.0 Release

[Takao Indoh]

On Mon, 29 Nov 2004 13:45:13 +0100, Arjan van de Ven wrote:

>>
>> I think kexec-dump is not stable yet.
>
>Do you have any facts to back this up? Is your project more stable ?
>What is the success rate of dumps of diskdump ? How does that compare to
>kexec-dump under the same circumstances ?

Sorry, a word "stable" was not appropriate. I meant that kexec-dump was
under development yet. kexec-dump works well on i386/x86_64, but it is
in the development stage on other architectures.

>> I heard that kexec-dump of
>> some architecture (ex. ia64) had some problems and not worked.
>
>wouldn't it be better to then help finish that rather than making an
>alternative ? 

It is, if diskdump project just started now. But the basic code of
diskdump is almost completed. I think it is more efficient to enhance 
quality of diskdump than help kexec-dump.

Best Regards,
Takao Indoh

Re: [lkdump-develop] Re: [ANNOUNCE 0/7] Diskdump 1.0 Release

[Arjan van de Ven]

On Mon, 2004-11-29 at 21:34 +0900, Takao Indoh wrote:
> The problem of kexec-dump is that initialization of devices depends
> on the quality of device driver when kexec reboots system. Sometimes the
> device drivers tacitly rely on the firmware to initialize them.

thankfully linux has very very few of those nowadays...

> 
> Anyway, most important point is that kexec-dump is not available enough
> now. 

How is that ?
>
> I think kexec-dump is not stable yet. 

Do you have any facts to back this up? Is your project more stable ?
What is the success rate of dumps of diskdump ? How does that compare to
kexec-dump under the same circumstances ?

> I heard that kexec-dump of
> some architecture (ex. ia64) had some problems and not worked.

wouldn't it be better to then help finish that rather than making an
alternative ? 

Re: [lkdump-develop] Re: [ANNOUNCE 0/7] Diskdump 1.0 Release

[Takao Indoh]

On Mon, 29 Nov 2004 12:19:52 +0100, Arjan van de Ven wrote:

>On Mon, 2004-11-29 at 19:35 +0900, Takao Indoh wrote:
>> Hi, all!
>> I release diskdump 1.0 for kernel 2.6.9. It can be downloaded from
>> the following site. Please feel free to use it!
>>    http://sourceforge.net/projects/lkdump
>> 
>> Diskdump project is a joint development of RedHat and Fujitsu, and I'd 
>
>I think the company name is spelled Red Hat ;)

Sorry.


>> like to express my gratitude to a RedHat developers for many comments
>> and advices.
>
>Can you explain to me why anyone would want to use this invasive patch 
>(it requires all drivers to change) instead of the kexec-dump approach? The
>kexec-dump approach appears on first sight to be far cleaner and far more 
>powerful,
>so there must be a reason this work was done regardless of that.. I'm 
>curious 
>what those reasons are, eg what's the advantage ???

The problem of kexec-dump is that initialization of devices depends
on the quality of device driver when kexec reboots system. Sometimes the
device drivers tacitly rely on the firmware to initialize them.

Anyway, most important point is that kexec-dump is not available enough
now. I think kexec-dump is not stable yet. I heard that kexec-dump of
some architecture (ex. ia64) had some problems and not worked.

Best Regards,
Takao Indoh