Re: [PATCH 1/2] Add support for stopping spus from xmon

[Michael Ellerman <michael@ellerman.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

On Thu, 2006-10-12 at 20:10 -0700, Haren Myneni wrote:
> Michael Ellerman wrote:
> 
> >This patch adds support for stopping, and restarting, spus
> >from xmon. We use the spu master runcntl bit to stop execution,
> >this is apparently the "right" way to control spu execution and
> >spufs will be changed in the future to use this bit.
> >
> >Testing has shown that to restart execution we have to turn the
> >master runcntl bit on and also rewrite the spu runcntl bit, even
> >if it is already set to 1 (running).
> >
> >Stopping spus is triggered by the xmon command 'ss' - "spus stop"
> >perhaps. Restarting them is triggered via 'sr'. Restart doesn't
> >start execution on spus unless they were running prior to being
> >stopped by xmon.
> >
> >Walking the spu->full_list in xmon after a panic, would mean
> >corruption of any spu struct would make all the others
> >inaccessible. To avoid this, and also to make the next patch
> >easier, we cache pointers to all spus during boot.
> >
> >We attempt to catch and recover from errors while stopping and
> >restarting the spus, but as with most xmon functionality there are
> >no guarantees that performing these operations won't crash xmon
> >itself.
> >
> >  
> >
> I think, kdump also need stop_spus() functionality when the dump support 
> is included on cell. If so, how about both stop_spus() and start_spus() 
> in platforms/cell/.

Good point. We haven't got that far with kdump on cell so I hadn't
thought of it. We won't need start_spus(), but we will need something to
stop spus for kdump. I'll leave it for now, but keep it in mind for when
we get kdump going on cell.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]