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:<David.Olien@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	6C678488C5CEE74F813A4D1948FD2DC7B7B92FBB@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 24 Mar 2010 13:59:01 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Olien, David" <David.Olien@lsi.com>
Subject: Re: Tuxtor work
Message-ID: <20100324135901.7678159e@ripper.onstor.net>
In-Reply-To: <6C678488C5CEE74F813A4D1948FD2DC7B7B92FBB@cosmail02.lsi.com>
References: <6C678488C5CEE74F813A4D1948FD2DC7B7B92FBB@cosmail02.lsi.com>
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

Yes, I believe that Max is misquoting me on this.  I believe that we
have some core dump support, but as he said, it has to write the core
out through the scsi code, which isn't finished yet.  When that code is
ready, then the task would be to wire up the core dump support to the
scsi code and get it all working.

As he said, perhaps the kgdb support for the ESM threads is the first
place to start.  Does that clear things up at all?

Cheers,

a


On Wed, 24 Mar 2010 14:52:00 -0600 "Olien, David" <David.Olien@lsi.com>
wrote:

> Hi Andy,
> 
> I'm forwarding this to you to get clarification on some of the work
> I'm signed up for.
> 
> What is the state of core dump support in the tuxrx kernel?  It there
> something I can pick up doing here?
> 
> dave
> 
> -----Original Message-----
> From: Kozlovsky, Maxim 
> Sent: Wednesday, March 24, 2010 1:46 PM
> To: Olien, David
> Cc: Thomas, Craig
> Subject: RE: Tuxtor work
> 
> Hi,
> 
> The scsi code is not working yet. You can try to write the code, but
> you will not be able to test it. 
> 
> About the only thing you might be able to test right away is KGDB
> support for ESM threads, after I check in some fixes that are being
> reviewed now.
> 
> Andy was telling me a day ago that the kernel we are using does not
> actually have core dump support (?!). So the first step may be to
> apply some patches that provide that support to our kernel. Andy
> should be able to give more details on that.
> 
> Max
> 
> -----Original Message-----
> From: Olien, David 
> Sent: Wednesday, March 24, 2010 1:38 PM
> To: Kozlovsky, Maxim
> Cc: Thomas, Craig
> Subject: RE: Tuxtor work
> 
> Hi Max,
> 
> Just an update on approach to these work items.
> 
> Sam of course is taking item number 1, the memory sizing issue.
> 
> I'm thinking I'll do item 3 first... the, "Core dump support".  I've
> written a few Linux block drivers, and worked with some scsi
> drivers.  So I think I can do this quickly and easily. Maybe get this
> done by early next week. 
> 
> Doing step 3 first, I think, will make it easier to do step 2 (ESM
> core dump support).  I'll almost certainly do this step in user
> mode.  Best to keep things out of the kernel when possible.
> 
> I'll think about the others steps a little more over the next week,
> as I'm working on the others.
> 
> Sound OK?
> 
> dave
> 
> -----Original Message-----
> From: Kozlovsky, Maxim 
> Sent: Wednesday, March 17, 2010 5:09 PM
> To: Olien, David
> Subject: RE: Tuxtor work
> 
> 
> 
> -----Original Message-----
> From: Olien, David 
> Sent: Wednesday, March 17, 2010 4:48 PM
> To: Kozlovsky, Maxim
> Subject: RE: Tuxtor work
> 
> Hi Max,
> 
> Here's my first dumb question :-)
> 
> I'll direct this at just you, since I doubt Andy really wants to be
> involved at this level.
> 
> In your task summary, you mention a "new GDB".  I see that the gdb64
> that I have on my client machine is version 5.5.1.  The native gdb is
> version 6.8.  So I'm guessing that I need a newer gdb64 version for
> this project. [MK] This was my assumption as well. gdb 5.5.1 will not
> work with gcc version 4.1.2 that is used for the kernel.
> 
> Do you know where I can get this? Do you have a summary of what the
> differences are, at least regarding core dump format, or is there gdb
> source I could look at? [MK] To get gdb source - "apt-get source gdb"
> if you are using debian. I don't know what the difference in the core
> dump format are, likely there will be something in the way the
> threads are handled. We had a simplified core dump format for EEE and
> modified gdb source to force it to understand that.
> 
> Can I install the new gdb6 while preserving my existing gd64?
> [MK] Yes, just use different name or directory for it. There is
> pre-built cross gdb 6.8 for mips in /n/build-trees/gdb/gdb64-tux.
> 
> Dave
> 
> -----Original Message-----
> From: Kozlovsky, Maxim 
> Sent: Wednesday, March 17, 2010 10:29 AM
> To: Olien, David; Sharp, Andy
> Cc: Thomas, Craig
> Subject: RE: Tuxtor work
> 
> Hello,
> 
> Here is some explanation of the tasks:
> 
> 1) Update memory sizing algorithms:
> 
> Current implementation has partitioned memory space, there are 3
> types of preallocated buffers and "malloc" space, FP and TXRX memory
> is split. The FP and TXRX memory sizing algorithms calculate the
> sizes of various caches based on the available buffers, or based on
> the size of the malloc space. On linux FP and TXRX will run from the
> same kernel, and there will not be any preallocated buffers. The
> cache sizing algorithms need to be updated to account for this
> change. 
> 
> 2) ESM core dump support
> 
> Linux core dump code need to be updated to include our ESM threads
> information. This can be either done in the kernel, or a user space
> program can be created which will peek into the standard linux core
> dump in the right places, extract the ESM threads information and
> rewrite the core dump to include the ESM threads. The second variant
> may be preferable as it allows us to ship the kernel without any
> modifications, which helps with the licensing issues.
> 
> 3) Core dump support
> 
> Cougar linux port will have the original EEE scsi/ispfc code. Linux
> core dump code needs to be modified to be able to use our core volume
> LUN as core dump target. Perhaps the way to do it is to create some
> pseudo block device which will use our scsi code to write the data
> and tell linux kernel to use that as a core dump device. The existing
> EEE core dump support is in code/sm-coredump/coredump.c.
> 
> 4) KGDB support 
> 
> KGDB supporting code needs to be modified to be aware about ESM
> threads. GDB has a way of interrogating the kernel about the
> currently running threads and their current register state, this code
> needs to be updated to include the ESM threads. We had that support
> in EEE in code/sm-except/debug.c. While I have never seen the kernel
> gdb supporting code, I am assuming it will have something similar. I
> know this can be done but the exact way needs to be researched. It is
> ok to modify the kernel for this feature, we don't need to ship it,
> the feature will be used internally for development.
> 
> 5) Volume exception dump
> 
> There is user space program that rewrites the volume exception dump
> into core dump format. This code might need to be updated for new GDB
> version. There will be subsequent task to support x86 core dumps. The
> code is in code/sm-fs/rewritedump.c.
> 
> 6) Writestacks support
> 
> There is code in the file system, see fs_writeStacksThread(), which
> saves a mini-coredump on the management volume containing the stacks
> of all ESM threads. This code needs to be updated for new GDB
> version. There will be subsequent task to support x86 core dumps.
> 
> Max
> 
> -----Original Message-----
> From: Olien, David 
> Sent: Tuesday, March 16, 2010 2:12 PM
> To: Sharp, Andy; Kozlovsky, Maxim
> Cc: Thomas, Craig
> Subject: RE: Tuxtor work
> 
> Thanks, Max!
> 
> I'll wait to hear from you.  Whatever isn't clear from the email,
> I'll ask more questions.
> 
> dave
> 
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> Sent: Tuesday, March 16, 2010 2:08 PM
> To: Kozlovsky, Maxim
> Cc: Olien, David; Thomas, Craig
> Subject: Fw: Tuxtor work
> 
> Hi Max,
> 
> Connecting you into this email thread about the tuxstor tasks for
> David Olien.
> 
> David, Max told me that he thinks he can explain things pretty well
> via email, and if that isn't sufficient then we can do a conf. call.
> 
> Thanks everyone!
> 
> a
> 
> 
> Begin forwarded message:
> 
> Date: Tue, 16 Mar 2010 11:22:33 -0700
> From: Andrew Sharp <andy.sharp@lsi.com>
> To: "Olien, David" <David.Olien@lsi.com>
> Cc: "Thomas, Craig" <Craig.Thomas@lsi.com>
> Subject: Re: Tuxtor work
> 
> 
> On Mon, 15 Mar 2010 18:25:19 -0600 "Olien, David"
> <David.Olien@lsi.com> wrote:
> 
> > Hi Andy,
> > 
> > I've been told that I'll be helping out with some  tuxtor
> > development.   I'll be glad to do whatever I can.
> 
> How'd you draw the short straw?  I thought Sam was [slightly] keen on
> doing some of this cruft?
> 
> > I've seen your tuxtor schedule chart.  I see 5 items listed for
> > people here in Beaverton.  Initially at least, I'll try to take all
> > of these tasks.  I also understand you have some sort of May 18
> > deadline for all of the work on this schedule to be completed.
> > 
> > I'm going to list the work items, along with what I think these
> > mean.  Can you fill in whatever details you can,  I'll then try to
> > give an estimate, with the May 18 deadline in mind.  I'm looking at
> > the  wiki page for the tuxstor threads port.  My linux desktop is
> > hung right now, and I'm waiting for someone to reboot it.  So these
> > my are guesses without looking at what's already written.
> > 
> > Here's the work items and what I THINK they mean.
> 
> I think maybe the best thing to do is set up a conference call with
> Max because he's the person who actually understands these tasks at
> the lowest level.  I'll set that up and let you know.
> 
> 
> > 1.       Update FP and TXRX memory handling algorithms (chart
> > estimate 16 hr (2 days)) I'm guessing that most of this code is
> > already there, or can be adapted from the existing cougar source
> > code.  The basic requirement is the non-blocking, non-failing
> > semantics. These are the interfaces implemented in eee-mem.h,
> > eee-mem.c?
> 
> Nah, ask Sam what he did recently for EEE.  It will be similar.  I
> hope.  I think we just have some stuff that assumes 32 bits will be
> enough to hold an address.
> 
> 
> > 2.       ESM thread core dump support (chart estimate 40h (1 week))
> > 
> > This is support for dumping out the contents of memory for the fp
> > and txrx "cores" (i.e. the Linux kernel threads that provide the
> > execution context for the eee threads) , along with information
> > about eee threads that are running on those "cores", ESM being the
> > lower-level implementation  that supports the
> > thread_create()/thread_exit()/thread_yield().   Also include the
> > "per-core" private memory.
> > 
> > 
> > 
> > 3.       Core dump support (chart estimate 40h (1 week))
> > 
> > I'm not sure where number 2 ends and number 3 begins
> 
> One is all the memory in the entire world (kernel core dump, which,
> BTW, might be there already, but would need some testing and possibly
> tweaking), and the other is just a core dump of an ESM thread itself.
> 
> 
> > 4.       Implement FS writestacks support (chart estimate 24 hr (3
> > days))
> > 
> > Looks like this has to do with displaying validthread stacks via the
> > fscmd writestacks command.
> > 
> > 
> > 
> > 5.       Kgdb support for ESM threads (chart estimate 80 hr (two
> > weeks))
> > 
> > I'm guessing this refers to the .gdbinit file used when debugging?
> > 
> > Am I at least on the right track?
> 
> Anything's possible.
> 
> I'll set up a chat with Max, that should be quite educational.
> 
> Cheers,
> 
> a
