On Mon, 2007-03-05 at 02:02 +0100, Arnd Bergmann wrote: > On Friday 02 March 2007, Michael Ellerman wrote: > > There's also the error case for spu_run_init() which skips the master > > stop. I guess that's ok because we've only set the master control in the > > backing store, and the only way that will ever get propagated to an > > actual spu is by coming back thorough spufs_run_spu(). > > Hmm, the correct way would be to switch off the master control in there, > afaics. Fixing it only in spu_run_init would mean that we also handle > the case of spu_reacquire_runnable along with it. > > > What originally caught my eye on this was the output from xmon. When we > > drop into xmon with no spu programs running and stop the spus, it > > reports that they _all_ have the master run enabled, > > That looks right, there is no problem to have master control enabled, > as long as user space can't access the spu through a context that is > bound to it. > > > and some of them > > have the runcntl enabled (those that have had spu programs run on them > > since boot it seems). > > While this sounds wrong. Maybe the runcntl is active on those that have > _not_ run since boot, which would make more sense. We should investigate > this.
No I'm pretty sure it's enabled on the ones that _have_ run since boot. I'm booting up fresh, running two spu programs, and then I see two spus with master and runcntl set. 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
signature.asc
Description: This is a digitally signed message part