| View previous topic :: View next topic |
| Author |
Message |
Herben
Joined: 25 Jan 2004
Posts: 107
|
 Posted: Tue Jan 30, 2007 7:32 pm Post subject: seriously bad bug in padman rpc |
 |
|
I've been noticing some weird behavior for a while but haven't been able to track it down until now. Something was overwriting 0x80000000-0x800000FF on EE with what seemed to be garbage. After eliminating causes I finally tracked it down to the padman rpc in ps2sdk, mainly the "padx" version. not only was the arg not being passed to the init function, it is also not a mode! it is actually an EE-side address that something(I don't know what yet, don't know if I care to bother reversing the rest) is DMA'd to. This is done regardless of if you do padopen/etc. Sooo, long story short the RPC server on IOP was being passed "0"(usually) which resulted in a DMA being transfered and trashing the first part of EE RAM. My fix was to add a 256-byte buffer to the rpc client and pass the address of that.
FYI, the first 256 bytes of EE RAM are 2 exception vectors... |
|
| Back to top |
|
 |
Lukasz
Joined: 19 Jan 2004
Posts: 248
Location: Denmark
|
| Posted: Tue Jan 30, 2007 9:27 pm Post subject: |
|
|
Nasty bug!
Would this also explain why padx did not work for some people (myself included) ?
_________________
Lukasz.dk |
|
| Back to top |
|
|
Herben
Joined: 25 Jan 2004
Posts: 107
|
| Posted: Tue Jan 30, 2007 9:49 pm Post subject: |
|
|
| padx works for me, though I suspect it's still a bit fucked. I don't think the "init" RPC call it makes is really init, for one. I don't know what the data area it sets up is for but I suspect this is more of an "open" call... maybe if I get bored one day I'll finish sorting it, but for now at least it won't trash the TLB Refill and Perf Counter exception vectors anymore. |
|
| Back to top |
|
|
dlanor
Joined: 28 Oct 2004
Posts: 269
Location: Stockholm, Sweden
|
| Posted: Wed Jan 31, 2007 12:05 am Post subject: |
|
|
| Herben wrote: | padx works for me, though I suspect it's still a bit fucked. I don't think the "init" RPC call it makes is really init, for one. I don't know what the data area it sets up is for but I suspect this is more of an "open" call... maybe if I get bored one day I'll finish sorting it, but for now at least it won't trash the TLB Refill and Perf Counter exception vectors anymore.
|
This bug reminds me of a problem we've seen in uLE, where the gamepad initialization also seemed to ignore some arguments (and I guess it really did, from what you say). Instead the result would be dependent of whether or not any disc was in the CDVD tray, and on whether that disc was a CD or a DVD. Quite insane of course, since there should be no connection between those things, but with one disc type we got analog init and with the other disc type we got digital init.
Note that this particular error only affected Dev1 booting, so it had nothing to do with the real content of those discs, as they were not involved in the booting at all... When relaunching the same copy of uLE another time, using uLE itself to do it, then that problem would not occur at all.
I don't really understand what happened there, but it might somehow be related to the argument handling you fixed.
Btw: Is that fix also in the current SVN updates ?
Best regards: dlanor |
|
| Back to top |
|
|
Herben
Joined: 25 Jan 2004
Posts: 107
|
| Posted: Wed Jan 31, 2007 12:26 am Post subject: |
|
|
it could be that your problem was related to that, try and find out then let me know. ;)
yes, I've committed my changes to SVN. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
