[Cbe-oss-dev] [PATCH] spufs: avoid using backing operation for wbox write

[Arnd Bergmann]

On Monday 06 August 2007, Andre Detsch wrote:
> On Sunday 05 August 2007 16:18:07 Arnd Bergmann wrote:
> > But the SPU_WrEventAck word _is_ written at the context restore time,
> > so we must have a way to give it a specific value. AFAICS, all that
> > needs to be done is to change the save channel data in
> > spu_state->chnldata[2] to restore the new correct value to
> > SPU_WrEventAck through the channel access facility.
> 
> Channel 2 is not saved/restored. Not in the code, not in the documentation.
> Section 12.5 of CBE_Handbook_v1.1_24APR2007_pub.pdf details the context switch 
> process, and it does not mention channel 2. For example, item 39 refers the 
> events channels, but does not include channel SPU_WrEventAck (channel 2)
> 
> "39. For the following channels:
> • SPU_RdEventStat (channel index 0)
> • SPU_WrEventMask (channel index 1)
> • SPU_RdSigNotify1 (channel index 3)
> • SPU_RdSigNotify2 (channel index 4)
> • MFC_RdTagStat (channel index 24)
> • MFC_RdListStallStat (channel index 25)
> • MFC_RdAtomicStat (channel index 27)"
> 
> Latter, like on item 45, additional channels are referenced, but nothing about 
> channel 2.
> 
> However, saving/restoring channel 2 was my first try (hoping that the 
> documentation could be incomplete). Attached is a patch with such a try. The 
> results are the same for the simulator and blade, but on simulator, we can 
> observe the channel values more easily. The test case I have hangs after the 
> following messages from the kernel:
> 
> Saving Channel 2 0x4D0 (spu=7)
> Saving Channel 2 0x4D0 (spu=6)
> Setting Channel 2 to 0x4C0 (spu=7)
> Setting Channel 2 to 0x4C0 (spu=6)
> 
> Looking at the channels debug window, both SPU 6 and 7 still have Channel 2 == 
> 0x4D0 (although I'm explicitly trying to write 0x4C0, which correspond to the 
> same mask, only without the MB event bit unset). I've also tried a different 
> write order (writting channel 2 at the end of the function, after the other 
> channels), and also, forcing SPU_WrEventMask (channel 1) to have a non-zero 
> value, but nothing has helped.
> 
> PS: like channel 1, channel 2 does not have an associated count. Simulator 
> even complains if one tries to write on channel 2 count (e.g., "WARNING: 
> 92790504834: SPE7: Attempt to write channel count for CH 2 with no associated 
> count is ignored"). 

Well, channel 0 and 2 both reflect the internal 'pending event register' in an
indirect way when looking at them from the SPU, while the PPU sees the real
pending event register at index 0 in the channel access facility. Consequently,
we must set the bit in the saved channel-0 state, which the code already does.

However, we recently had a bug in that area (fixed in 2.6.23-rc1), where Linux
accidentally saves and restores the channel 0 twice, which can lead to broken
events. Noguchi-san originally found that problem and the fix that went into
the kernel is archived at
http://patchwork.ozlabs.org/cbe-oss-dev/patch?id=12483

Could the new problem be fixed by this patch as well? What was the symptom
that this patch was supposed to fix?

	Arnd <><