AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090114123040.6928d601@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:exch1.onstor.net
NSV:
SSH:
R:<maxim.kozlovsky@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	2779531E7C760D4491C96305019FEEB51763B781F9@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 14 Jan 2009 12:30:48 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Maxim Kozlovsky <maxim.kozlovsky@onstor.com>
Subject: Re: TuxRx Functional Spec
Message-ID: <20090114123048.18d65cd4@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB51763B781F9@exch1.onstor.net>
References: <20090106152711.76b59d5d@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB5176334C548@exch1.onstor.net>
	<20090113201411.4080c3aa@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781A5@exch1.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781AE@exch1.onstor.net>
	<20090114111145.760306eb@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781BE@exch1.onstor.net>
	<20090114112048.229b2444@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781C6@exch1.onstor.net>
	<20090114112812.4642a19a@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781CD@exch1.onstor.net>
	<20090114114719.53b87b16@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781E9@exch1.onstor.net>
	<20090114120046.72117789@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781F9@exch1.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 14 Jan 2009 12:09:57 -0800 Maxim Kozlovsky
<maxim.kozlovsky@onstor.com> wrote:

> 
> 
> >-----Original Message-----
> >From: Andy Sharp
> >Sent: Wednesday, January 14, 2009 12:01 PM
> >To: Maxim Kozlovsky
> >Subject: Re: TuxRx Functional Spec
> >
> >On Wed, 14 Jan 2009 11:53:13 -0800 Maxim Kozlovsky
> ><maxim.kozlovsky@onstor.com> wrote:
> >
> >> >
> >> >Congratulations.  It's worthless though, unless you're willing to
> >> >explain it to me.
> >> [MK]
> >>
> >> We currently support attaching debugger to the kernel after it
> >> crashes, and executing console commands, the same features have to
> >> be supported with linux kernel.
> >
> >I don't see why.  If anything, we will have more features than we
> >currently have; they might manifest themselves in different ways.
> [MK] 
> 
> As an example, to debug the ECC problem Brian had to execute the
> console commands after the kernel crashed. There are cases when the
> kernel debugger support after the crash is absolutely necessary, for
> example when the core dump fails. It is much more convenient in the
> development to have interactive debugging after the crash instead of
> waiting for 16GB core to dump and then debugging that.

Hmm, OK.  I will think about that.  Keep in mind though that this ECC
problem would have been obvious from the start with Linux because the
kernel would have reported it as an ECC or bus error with correct
address.  But I hear you.

BTW I'm still a bit fuzzy on how this works on eee.  As I understand
it, eee is just running bare on the processor.  So how is it able to do
anything after it crashes?  Is the console I/O interrupt driven, and
the command shell connected to the interrupt handler?  Or does this
scheme rely on the exeception handler being invoked?



