Sorry I was travelling last week, and couldn't respond earlier.
I can see that you've already thought through most of the
the same issues that have been troubling me, on this subject :-)
>> Hello,
>>
>> Looking at the vmdump code, here is something that puzzles me.
>> I'm not sure if I'm missing something obvious here.
>>
>> Since right now dump involves wait_kio calls, which involves a context
>> switch to another runnable process, isn't there a chance of the memory
>> state changing whilst the dump is going on. Couldn't the dump become
>> inconsistent, or not correctly reflect the state of the system when the
>> incident that triggered the dump happened ? (Since interrupts aren't
turned
>> off, even that could affect the state ... but to a lesser extent, I
guess)
>
>Yes -- the whole point behind adding smp_send_stop() into the panic()
>and die_if_kernel() mechanism was to avoid having other processes run
>while the dump was taking place. I didn't see a good hook in the
>scheduler to say, "Okay, hold off, don't run any other jobs except
>mine", and putting smp_send_stop() into place messes up both x86 and
>ia64 systems, due to the local APIC being disabled (meaning, if your
>system crashes on a CPU other than 0, you're toast).
>
In your response to Simon Falvey's question, you mentioned a patch that
you had sent that addresses this problem of stopping all scheduling at the
time of a dump. That sounds interesting. Could I take a look at it too ?
(Have you already posted it somewhere ?)
>This leads to the second problem -- even if you do stop all other
>system processes and are able to disable interrupts to most devices,
>you can't write out to disk in a "raw" fashion. Kiobufs are a hack
>at best as far as raw I/O is concerned. It's just a page grouping
>mechanism for good s/g stuff, IMHO. Linux is immature as far as
>raw device output is concerned.
>
>> I had actually started with looking into the smp_send_stop issue and the
>> more generic issue of getting a consistent system snapshot (as
accurately
>> reflecting the state at the time of the system crash as possible), when
>> this question came to mind. BTW, is there some work going on in this
area ?
>> Or have the issues been sorted out already ?
>
>There are two ways to do this:
>
>1) Stop all system activity, shut down interrupts as much as possible,
> and dump all of memory to disk.
>
>2) Stop the system immediately, reset the system, and on the way back
> up, early in the boot process, dump the memory to disk either at
> bios or in the setup of the kernel.
>
>Both mechanisms have their problems in Linux. I don't like the second
>solution, because not every system (most, in fact) preserve memory state
>between system resets. The first solution is as close as I can get at
>this point to saving the memory dump accurately, and even with that,
>we can have problems in some circumstances.
>
>For example, what if you crash in a disk interrupt handler?
>
Yes,the situation of a crash in an interrupt handler was the first problem
that came to mind -- made me look in further and come up with the question
in the first place. Its a tricky thing to handle.
>> Matt you had mentioned that you were working on a specialized IDE driver
>> for dump, to avoid having to go through the normal kio/raw i/o path in
the
>> kernel. Is that still in the plan ?
>
>Yes, although I sent it off to Andre Hedrick, and he sent me a
>single line response saying (basically), "Why would you ever want
>to do that?"
:-)
>
>Needless to say, it wasn't very encouraging. I have it, it's written,
>and it works on my disk here in the office, but I haven't tried it on
>multiple IDE disks, or different IDE controllers, etc. It's basically
>untested outside my office. :)
>
>The best solution (IMHO) is to create:
>
> raw device table
> raw device handles (open(), read(), write(), etc.)
> disk device driver handles (ide_rw_open(), etc.)
>
>Right now, ide-disk.c interfacing to ide.c is horrific. Putting in
>my raw disk mechanism is again, doing things in a non-elegant way,
>but it does get the job done.
>
>Anyway, I have something, you're more than welcome to look it over
>and tell me what you think. I was hoping to get Andre's impression
>on things, but given the way the kernel development has been going
>on lately, I'm never sure what's going to get in.
>
Thanks.
Yes, I'd like to take a look at what you have. Not that I know much
about IDE drivers (I have been looking at the generic block layer code and
raw i/o for a while, but not specific drivers so far), but it'll help me
understand the approach that you've taken a little better. Ideally it would
be nice to arrive at some kind of solution that isn't very device specific
...
(oh yes, I realize its not all that easy ) so we know it'll just work on
all
kinds of h/w rightaway, so to say . Or worst case, something
very minimalist for each kind of dump device(sort of like AIX does now).
What you have may be a good start.
Do let me know how I can access it.
>
>--Matt
Suparna Bhattacharya
IBM Software Lab, India
E-mail : bsuparna@xxxxxxxxxx
Phone : 91-80-5267117, Extn : 2525
|