forums.ps2dev.org Forum Index forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Strange semaphore behaviour

 
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development
View previous topic :: View next topic  
Author Message
Fanjita



Joined: 28 Sep 2005
Posts: 217

PostPosted: Sat Nov 05, 2005 12:03 pm    Post subject: Strange semaphore behaviour Reply with quote

Quick question : has anyone ever seen anything like this before:

I create a semaphore using

Code:
lrc = sceKernelCreateSema("name", 0, 0, 10, 0)


(actually directly via the syscall, rather than via the SDK)
expecting to create a simple semaphore with 10 max count, 0 initial.

lrc seems to return a sensible number - generally around the 0x04600000 range, a different number each time, so it looks like a plausible SceUID.

But any time I attempt to do anything with that semaphore (signal, wait, referStatus) the operation fails - waits just complete immediately, referStatus doesn't change the sceKernelSemaphoreInfo structure at all - but still returns a successful return code (where applicable).

I can't understand what's going wrong - any advice?
_________________
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
Back to top
View user's profile Send private message
Fanjita



Joined: 28 Sep 2005
Posts: 217

PostPosted: Sun Nov 06, 2005 7:06 am    Post subject: Reply with quote

Curiouser and curiouser.

It seems that this thread (which I think is the VSH_GRAPHICS_THREAD) doesn't respond to many requests to stall itself.

When I attempt sceKernelSleepThread(), I get the error code SCE_KERNEL_ERROR_ILLEGAL_CONTEXT.

Is there a class of thread (perhaps via thread attributes) that is enforced as non-blocking? Or perhaps a context such as interrupt handler in which blocking is not allowed?

I need to be able to stall this thread somehow, in a recoverable way, as I'm trying to enable clean return from the EBOOT loader to the VSH, using Abu's HELLO2 ideas - and if I don't stall this thread, it keeps messing with the display.
_________________
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
Back to top
View user's profile Send private message
mrbrown



Joined: 17 Jan 2004
Posts: 1536

PostPosted: Sun Nov 06, 2005 8:46 am    Post subject: Reply with quote

My guess would be that only threads in the same class (user, VSH, or USB/WLAN) can manipulate other threads in that class. If that's not the case then it's possible that VSH threads take precedence over user threads.
Back to top
View user's profile Send private message
Fanjita



Joined: 28 Sep 2005
Posts: 217

PostPosted: Sun Nov 06, 2005 8:49 am    Post subject: Reply with quote

I don't think that can apply, since all my threads are actually VSH (as they hijacked the VSH's TIFF display thread in the first place, and I preserved those attributes during thread creation).

It definitely seems that the thread is defined as non-blocking in some way.
_________________
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
Back to top
View user's profile Send private message
mrbrown



Joined: 17 Jan 2004
Posts: 1536

PostPosted: Sun Nov 06, 2005 9:11 am    Post subject: Reply with quote

Ah... I see what you mean. Sorry, no ideas here that wouldn't require digging into the kernel :).
Back to top
View user's profile Send private message
Vampire



Joined: 12 Apr 2005
Posts: 138

PostPosted: Sun Nov 06, 2005 10:06 am    Post subject: clean return from the EBOOT loader to the VSH Reply with quote

Fanjita wrote:
... as I'm trying to enable clean return from the EBOOT loader to the VSH...

have you tried sceKernelExitGame (or sceKernelExitGameWithStatus)
or maybe you can use vshKernelExitVSH or vshKernelExitVSHVSH
Back to top
View user's profile Send private message
Fanjita



Joined: 28 Sep 2005
Posts: 217

PostPosted: Sun Nov 06, 2005 10:30 am    Post subject: Re: clean return from the EBOOT loader to the VSH Reply with quote

Vampire wrote:
Fanjita wrote:
... as I'm trying to enable clean return from the EBOOT loader to the VSH...

have you tried sceKernelExitGame (or sceKernelExitGameWithStatus)
or maybe you can use vshKernelExitVSH or vshKernelExitVSHVSH


The problem is that the loader is running within the scePafJob thread, rather than within a standard EBOOT environment. So I don't believe that ExitGame() will work (though I haven't tried it).

Any idea what ExitVSH actually does? If it provides a way to restart VSH, then that would be perfect.

At the moment, I'm trying to hang the VSH threads while the loader runs in a new thread, then restart them once I'm done. Otherwise, they interfere with the display while the loader is trying to run.

All this is based on Abu's HELLO2 source, which allows you to use the TIFF exploit to launch a new thread, then repair the stack and return the VSH threads as if nothing happened.
_________________
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
Back to top
View user's profile Send private message
Fanjita



Joined: 28 Sep 2005
Posts: 217

PostPosted: Sun Nov 06, 2005 1:53 pm    Post subject: Reply with quote

Well, I managed to get a nasty hack working - freezing the VSH, running a simple app with full control of the screen + input, then returning to VSH as if nothing had happened at the end.

It's all a little ugly, and now I think I'll abandon it in favour of the far simpler solution using sceExitGame().

But if anyone is interested in the source, let me know and I'll post it. It was an interesting exercise, if nothing else.

P.S. I never got to the bottom of the semaphore issue. I suspect it may have been a dispatch thread, although I can't find much info about them. In the end, I found a solution that avoiding having to freeze the particular thread that was behaving oddly (SceWaveMain, I believe).
_________________
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
Back to top
View user's profile Send private message
Zigo



Joined: 07 Nov 2005
Posts: 1

PostPosted: Tue Nov 08, 2005 8:23 pm    Post subject: Strange semaphore behaviour Reply with quote

Are you using timeouts in sceKernelWaitSema? I am using 0 or NULL for the last parameter and the semaphores seem to be working perfectly (signal and wait). I have not tried out sceKernelReferSemaStatus though.
Back to top
View user's profile Send private message
Fanjita



Joined: 28 Sep 2005
Posts: 217

PostPosted: Tue Nov 08, 2005 8:44 pm    Post subject: Reply with quote

I was using zero (infinite) timeouts.

Both WaitSema and WaitSemaCB were failing.
_________________
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group