[Cbe-oss-dev] [PATCH] spufs: fix missing stop-and-signal
Noguchi, Masato
Masato.Noguchi at jp.sony.com
Fri Nov 17 12:35:41 EST 2006
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, November 17, 2006 1:27 AM
>
> On Thursday 16 November 2006 06:51, Masato Noguchi wrote:
> > This patch fixes missing stop-and-signal problem.
> >
> > When there is pending signals, current spufs_run_spu() always
returns
> > -ERESTERTSYS and it is called again automatically.
> > But, if spe already stopped by stop-and-signal or halt instruction,
> > returning -ERESTARTSYS makes stop-and-signal/halt lost and
> > spu run over the end-point.
> >
> > For your convenience, I attached a sample code to restage this bug.
> > If there is no bug, printed NPC will be 0x4000.
> >
> > Signed-off-by: Masato Noguchi <Masato.Noguchi at jp.sony.com>
>
> Ok, thanks for hunting this down. I'll forward it for
> inclusion soon. Do you see this in real-life programs, so
> that we should fix it in 2.6.19? If not, I'll queue the fix
> up together with the other 2.6.20 patches that I want to
> still submit.
I heard this problem happened in following conditions:
(1) ppe process attached to gdb.
(2) program creates many spe thread(In other words, ppe uses many
pthread).
(3) spe prints many debug print by spe-side printf().
GDB sends signals when new pthread created. And spe's printf implemented
by stop-and-signal. If these conflict, next instruction of
stop-and-signal
is executed (unfortunately, it is a data, not instruction).
But, I think it's a rare case. Usually spe do not stop so often and
signals are not used so positively except gdb.
About 2.6.19, Use your judgment.
Regards,
M.Noguchi
More information about the cbe-oss-dev
mailing list