| View previous topic :: View next topic |
| Author |
Message |
Fanjita
Joined: 28 Sep 2005 Posts: 217
|
Posted: Sat Nov 05, 2005 12:03 pm Post subject: Strange semaphore behaviour |
|
|
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 |
|
 |
Fanjita
Joined: 28 Sep 2005 Posts: 217
|
Posted: Sun Nov 06, 2005 7:06 am Post subject: |
|
|
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 |
|
 |
mrbrown
Joined: 17 Jan 2004 Posts: 1536
|
Posted: Sun Nov 06, 2005 8:46 am Post subject: |
|
|
| 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 |
|
 |
Fanjita
Joined: 28 Sep 2005 Posts: 217
|
Posted: Sun Nov 06, 2005 8:49 am Post subject: |
|
|
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 |
|
 |
mrbrown
Joined: 17 Jan 2004 Posts: 1536
|
Posted: Sun Nov 06, 2005 9:11 am Post subject: |
|
|
| Ah... I see what you mean. Sorry, no ideas here that wouldn't require digging into the kernel :). |
|
| Back to top |
|
 |
Vampire
Joined: 12 Apr 2005 Posts: 138
|
Posted: Sun Nov 06, 2005 10:06 am Post subject: clean return from the EBOOT loader to the VSH |
|
|
| 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 |
|
 |
Fanjita
Joined: 28 Sep 2005 Posts: 217
|
Posted: Sun Nov 06, 2005 10:30 am Post subject: Re: clean return from the EBOOT loader to the VSH |
|
|
| 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 |
|
 |
Fanjita
Joined: 28 Sep 2005 Posts: 217
|
Posted: Sun Nov 06, 2005 1:53 pm Post subject: |
|
|
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 |
|
 |
Zigo
Joined: 07 Nov 2005 Posts: 1
|
Posted: Tue Nov 08, 2005 8:23 pm Post subject: Strange semaphore behaviour |
|
|
| 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 |
|
 |
Fanjita
Joined: 28 Sep 2005 Posts: 217
|
Posted: Tue Nov 08, 2005 8:44 pm Post subject: |
|
|
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 |
|
 |
|