DCEmulation

dreamcast development • homebrew software • hardware hacking • indie games • emulators • and more!
Back to main site
It is currently Thu Feb 26, 2015 3:56 pm

All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 19 posts ] 
Author Message
PostPosted: Tue Feb 03, 2015 9:02 pm 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sat Jan 31, 2004 1:34 pm
Posts: 183
Location: Russia/Novosibirsk
Hello everyone!
Approximately after commit http://sourceforge.net/p/cadcdev/kallis ... ded37e9e1/ (I tested all CD-ROM changes from http://sourceforge.net/p/cadcdev/kallis ... a4ba0ca76/) G1-ATA driver works unstable.
Seems the recursive mutex is locked and freezes all code after several readings from HDD/CF.
If I use this revision http://sourceforge.net/p/cadcdev/kallis ... db411efe2/ the G1-ATA driver works fine.

_________________
Image


Top
 Profile  
 
PostPosted: Thu Feb 05, 2015 5:54 pm 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 4431
I'm pretty sure that Quzar doesn't have a G1 ATA device, so I'll take a look at it.

That said, what exactly is happening? It sounds like (from what you've described) it works fine for several read operations and then just locks up later waiting on the mutex? Is this all from the same thread, or separate threads?


Top
 Profile  
 
PostPosted: Sun Feb 08, 2015 9:38 pm 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sat Jan 31, 2004 1:34 pm
Posts: 183
Location: Russia/Novosibirsk
BlueCrab wrote:
...it works fine for several read operations and then just locks up later waiting on the mutex? Is this all from the same thread, or separate threads?


Yep. From the same thread.

_________________
Image


Top
 Profile  
 
PostPosted: Sun Feb 08, 2015 10:46 pm 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 4431
Are you doing any operations to the GD-ROM drive in the mean time, or just to the ATA device?


Top
 Profile  
 
PostPosted: Mon Feb 09, 2015 3:35 am 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sat Jan 31, 2004 1:34 pm
Posts: 183
Location: Russia/Novosibirsk
Nope, just ATA...

Update: I call cdrom_spin_down

_________________
Image


Top
 Profile  
 
PostPosted: Tue Feb 10, 2015 8:16 am 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 4431
If you could provide me with a minimal piece of code that demonstrates the way to freeze things up, it'd help me immensely in debugging. If you can do it with just the g1_ata_* and cdrom_* functions (ie, no filesystem-related stuff), that'd be best.

My suspicion (which I can't back up at all, at the moment) is that it is something going screwy between the mutex being locked in the fs_iso9660 code during vblank interrupts and whatever you're doing in the foreground with the ATA device...

EDIT: Actually, let's see if my suspicion is correct before you try to write an example to show the bug. I've attached a patch that might fix any potential issues with interrupts and recursive mutexes... Try applying that patch ("patch -p1 < mutex.diff" from the $KOS_BASE directory, assuming you put the file attached there too), and see if it fixes the issue. I'd also suggest a full "make clean && make" on both KOS and whatever you're using to test with, just in case there are other funny things that have been changed in the meantime...


Attachments:
mutex.diff [2.64 KiB]
Downloaded 7 times
Top
 Profile  
 
PostPosted: Wed Feb 11, 2015 5:07 am 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sat Jan 31, 2004 1:34 pm
Posts: 183
Location: Russia/Novosibirsk
Ok I'll try it.

_________________
Image


Top
 Profile  
 
PostPosted: Wed Feb 11, 2015 9:07 pm 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sat Jan 31, 2004 1:34 pm
Posts: 183
Location: Russia/Novosibirsk
Hmm my application now crashes at new place:

Code:
*** ASSERTION FAILURE ***
Assertion "0" failed at pvr_prim.c:98 in `pvr_poly_compile': Invalid texture U size


Video rendering I have in separate thread. And it's uses normal mutex.

_________________
Image


Top
 Profile  
 
PostPosted: Thu Feb 12, 2015 6:12 am 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 4431
That message is entirely unrelated to the g1ata stuff, quite obviously. That error means that you've put in an invalid size for the width of a texture somewhere...

Other than that, it could, of course, be caused by memory corruption elsewhere (outside of your rendering code). :?


Top
 Profile  
 
PostPosted: Thu Feb 12, 2015 6:33 am 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sun Apr 20, 2014 7:45 am
Posts: 122
I saw that kind of error message before on these forums when somebody only partially recompiled KOS

_________________
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with some small fixes): https://bitbucket.org/bogglez/lxdream


Top
 Profile  
 
PostPosted: Thu Feb 12, 2015 6:55 am 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 4431
bogglez wrote:
I saw that kind of error message before on these forums when somebody only partially recompiled KOS
That's also entirely possible (and that's also why I suggested doing a full "make clean && make" pass).

@SWAT: Did you do a full "make clean && make" pass on both KOS and your program? Do you use anything from kos-ports (or other external libraries)? If so, you should probably do a "make clean && make" on those too. Basically, clean and remake everything in this order: KOS, any external libraries (in order of any dependencies they have on each other, of course), and then your program that is failing.


Top
 Profile  
 
PostPosted: Thu Feb 12, 2015 8:29 am 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sun Apr 20, 2014 7:45 am
Posts: 122
Bluecrab: Out of curiosity, do you know why this error message always occurs in the PVR code? Is it because there was an ABI change in that code recently or something? Funny error that one.

_________________
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with some small fixes): https://bitbucket.org/bogglez/lxdream


Top
 Profile  
 
PostPosted: Thu Feb 12, 2015 9:50 am 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 4431
bogglez wrote:
Bluecrab: Out of curiosity, do you know why this error message always occurs in the PVR code? Is it because there was an ABI change in that code recently or something? Funny error that one.
Relatively recently, the pvr_poly_cxt_t was changed, which is what causes it. So, yes, that would be an ABI change.

Since KOS is statically linked, we've never worried about ABI changes. It has always been recommended practice to do a full clean/rebuild pass every time you update. I'll try to be more explicit about it in the commit messages in the future when things like that happen, but yeah, please do a full clean/rebuild pass every time you update. :wink:


Top
 Profile  
 
PostPosted: Thu Feb 12, 2015 9:45 pm 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sat Jan 31, 2004 1:34 pm
Posts: 183
Location: Russia/Novosibirsk
Sorry I forget rebuild parallax library, now it's ok. Soon I'll check your patch on HDD.

Update: Your patch did not help :( Still freezing at ATA access. Now even slightly worse, freezes earlier than before the patch.

_________________
Image


Top
 Profile  
 
PostPosted: Sat Feb 14, 2015 6:14 pm 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 4431
I doubt that the patch itself made matters worse (I'd guess it's something random happening, at this point).

I'm going to need some sort of example code that demonstrates the issue, since I don't seem to be having this problem... :?


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 1:15 am 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sat Jan 31, 2004 1:34 pm
Posts: 183
Location: Russia/Novosibirsk
It's not easy to make example with this problem. I really don't know why this happen, but if I use cdrom driver before this changes, it's works fine...
Ok, I'll try get more info about this at free time.

_________________
Image


Top
 Profile  
 
PostPosted: Thu Feb 19, 2015 9:26 pm 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 4431
So, the only thing you have to revert is the cdrom changes? No other code has to be changed in order to make your code work -- that is to say, if you save the cdrom.[ch] files from when it works and otherwise update everything else to the current version, does it work?


Top
 Profile  
 
PostPosted: Fri Feb 20, 2015 8:15 pm 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 4431
Also, when you say it's difficult to make an example, does that imply that you don't run into the same issue outside of whatever you're normally using to test it? That actually makes it sound like the problem is elsewhere in your code (or in some other unrelated part of KOS to the g1ata code).

Remember, KOS doesn't give you any memory protection or kernel/userspace separation, so a simple buffer overflow pretty much anywhere can break things in very strange ways. :?


Top
 Profile  
 
PostPosted: Tue Feb 24, 2015 4:51 am 
Offline
Insane DCEmu
Insane DCEmu
User avatar

Joined: Sat Jan 31, 2004 1:34 pm
Posts: 183
Location: Russia/Novosibirsk
Not easy because need time :) I have not time for any code example :(
But I have some testers, they are help me with debugging.
So, I can say yes for:

BlueCrab wrote:
So, the only thing you have to revert is the cdrom changes? No other code has to be changed in order to make your code work -- that is to say, if you save the cdrom.[ch] files from when it works and otherwise update everything else to the current version, does it work?


I just replace cdrom.c and cdrom.h in current KOS rev to 2014-05-01 and it's works.

BlueCrab wrote:
Also, when you say it's difficult to make an example, does that imply that you don't run into the same issue outside of whatever you're normally using to test it? That actually makes it sound like the problem is elsewhere in your code (or in some other unrelated part of KOS to the g1ata code).
Remember, KOS doesn't give you any memory protection or kernel/userspace separation, so a simple buffer overflow pretty much anywhere can break things in very strange ways. :?


Not sure what it is my case. I did not touch the code before have this problem, everything worked well with old cdrom driver.

_________________
Image


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ] 

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group