AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Rendell.Fong@lsi.com>,<David.Olien@lsi.com>,<Richard.Hardiman@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	1269912269.26360.264.camel@rendellf
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 30 Mar 2010 09:39:48 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: Rendell Fong <Rendell.Fong@lsi.com>
Cc: "Olien, David" <David.Olien@lsi.com>, "Hardiman, Richard"
 <Richard.Hardiman@lsi.com>
Subject: Re: kgdb io device
Message-ID: <20100330093948.1406fa97@ripper.onstor.net>
In-Reply-To: <1269912269.26360.264.camel@rendellf>
References: <6C678488C5CEE74F813A4D1948FD2DC7B7BF8896@cosmail02.lsi.com>
	<20100329165919.3a0cc28b@ripper.onstor.net>
	<1269910318.26360.259.camel@rendellf>
	<6C678488C5CEE74F813A4D1948FD2DC7B7BF88CB@cosmail02.lsi.com>
	<1269912269.26360.264.camel@rendellf>
Organization: LSI
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 Mon, 29 Mar 2010 19:24:29 -0600 Rendell Fong <Rendell.Fong@lsi.com>
wrote:

> On Mon, 2010-03-29 at 19:16 -0600, Olien, David wrote:
> > OK.
> > 
> > Is Richard Hardman the person to talk with about this?
> > 
> It's either him or Brian Stark.

It's Richard.

Kgdb can be used today.  The wiki is here:

http://wiki.onstor.net/wiki/TuxStor:Howto_kgdb_to_TXRX/FP

Which links off of

http://wiki.onstor.net/wiki/TuxStor

> > 
> > dave
> > 
> > -----Original Message-----
> > From: Rendell Fong [mailto:Rendell.Fong@lsi.com] 
> > Sent: Monday, March 29, 2010 5:52 PM
> > To: Sharp, Andy
> > Cc: Olien, David
> > Subject: Re: kgdb io device
> > 
> > On Mon, 2010-03-29 at 17:59 -0600, Andrew Sharp wrote:
> > > On Mon, 29 Mar 2010 17:24:43 -0600 "Olien, David"
> > > <David.Olien@lsi.com> wrote:
> > > 
> > > > Hi Andy
> > > > 
> > > > Another question.
> > > > 
> > > > We re-arranged my task list to do the kgdb support first.  I
> > > > see that kdgb support is configured into the tuxrx  debug
> > > > kernel.  What are you using for the kdgb io device?  Are you
> > > > using serial console?  The only other possibility might be
> > > > Ethernet.
> > > > 
> > > > The  wiki page
> > > > 
> > > > http://wiki.onstor.net/wiki/TuxStor:Howto_kgdb_to_TXRX/FP
> > > > 
> > > > talks about using rcon to run kdgb.  But rcon is not yet
> > > > supported, and you probably never will support it.
> > > 
> > > Actually, and sadly, rcon is supported, and this was the way that
> > > certain people insisted it be implemented.  But it is a pain.
> > > I'll cc Rendell on this because he was the one that got it all
> > > working way back when. Possibly using the second serial port as
> > > the IO device is also possible.
> > > 
> > 
> > If you can get the second serial port connected, then it is the way
> > to go.  A lot of filers don't even have one serial port connected.
> > kgdb currently relies on using the rcon data queues to relay cmds
> > and data between the gdb client and a tuxstor core via SSC.   Once
> > connected with gdb, I don't think rcon can be used.  rcon is not of
> > much use anyway since the cmd set has been stripped down and is
> > very limited.
> > 
> > Note: the mapping rcon port numbers (61230-61237) to cpu cores was
> > never done.
> > 
> > 
> > > > For the jaguar release (which if I remember will be before
> > > > ORION, and will NOT use virtual machines to separate ssc
> > > > functionality from fp and txrx?) the only things that make
> > > > sense would be serial console or Ethernet?
> > > 
> > > That's all that ever made sense to me, but I was alone in the
> > > forest. One of those people is coming around to recognizing that
> > > there is going to be a large paradigmn change from EEE days, so
> > > possibly we can abandon the rcon thing.  Or use the mgmtbus
> > > network device, which might not be time/resource possible.
> > > 
> > > > For ORION, where we have virtual machines that are separating
> > > > some of these functionalities, if the ssc is in it's own VM,
> > > > then something LIKE rcon might be useful again?  Probably won't
> > > > go with the rcon per processor.  Instead, just have some
> > > > network-like port that can talk from ssc virtual machine to the
> > > > others, and could support debugging operations.  But this is
> > > > still a while from now?
> > > > 
> > > > dave
> > > > 
> > > > 
> > 
> 
