Strange I/O errors [solved]

[methos3]

Hi,
I've noticed some weird errors on a program that I am developing, such as:
*fioDOpen freezes ONLY when I pass "mc0:/" or "mc1:/" as argument
*fileXioOpen() opens sucesfully a file on a pendrive location choosen by the user, but an irx freezes when tries to open a file of the very same name/location using open() (from iomanX), and the function that does that is called right before I do fileXioClose() on the EE.

what an I doing:
*when the program starts, I reset the IOP and all the stuff, then load rom0:XSIO2MAN, rom0:XMCMAN, rom0:XPADMAN, buffers: usbd, usb_mass, iomanX, fileXio, init fileXio, then open up the file browser.
if the user selects "mc0:/", the screen wil freeze, choosing a dir from mass:/ will go ok, but...

*the I reset the IOP again, reload all these modules, use fileXioOpen to test if the pendrive is acessible, and, in fact, it is, only then I fileXioClose the new file, then load my version of "mcdump_irx". It loads up ok, I acess the rpc ok from the EE (mcdumpInit() ), I use the function to call my irx's dumping function, and when it freezes! (if I remove the pendrive, it won't freze, the open() function will only return an error, like it is supposed to be...)

So... why is fioDOpen() freezing when I open the "mc0:/", and why is open() from iomanX freezing when called from the own IOP, but not when called by fileXioOpen, from the EE?

Any help would be appreciated : )

ps.:I've created another topic talking about fileXioOpen, but that one isn't explaining on the better way, and it's not talking about the mcx:/ problem so I've created this one, so... this is NOT a spam!

ps2.:I am using the latest ps2sdk version...

[ragnarok2040]

You haven't listed rom0:XMCSERV as a module that's been loaded. It sets up the RPC server for accessing the memory card from EE which should fix the freezes on accessing "mc0:/" and "mc1:/". It should be loaded right after rom0:XMCMAN.

As for the second problem, from your description, it sounds like you're trying to open the same file twice, the first open with fileXioOpen, which works, then the second with open() from the IOP, which doesn't work and should return a error but instead freezes unless you pull out the pendrive.

I've looked at the usb_mass code and iomanX's code, usb_mass does check to see if the file is opened for write previously and returns an error if it is. So iomanX should get that and return an error unless you're opening the file as read-only using fileXioOpen() which would make the second open() call return another file descriptor. I'm not sure why it's freezing on you.

I haven't done any ps2-related development in a few months because my Arch install broke so I'm probably missing something :D.

[methos3]

Mmm...
rom0:XMCSERV is needed only when we want to use the libmc.h functions, but not for fioDOpen("mc0:/"), for example.
So... it was only my debugging skills that failed this time :/
As for the fileXioOpen() and open(), I was testing that way: opened the file with fileXioOpen, then closed it, and only then called the irx.
I've noticed that the real problem is the irx itself, because it opens up 2 files, right after opening the first one I wrote some info in it , then close() it. The files appear on the pendrive with the data that I've written, only on another part of the irx that the program freezes, the problem is not with the open() part...

And for the "mc0:/", the problem was because I was allocating 1 byte less than the necessary to store the filename on my routine :/ .

Code: Select all

char* entryn = (char*)malloc(strlen(entry.name)+1);
sprintf(entryn, "/%s", entry.name);

when it should be
char* entryn = (char*)malloc(strlen(entry.name)+2); because of the '/'

I must have changed the +2 for +1 whihout noticing :)


Thanks for the help!

[ragnarok2040]

Ahh, I didn't know that. I thought XMCSERV had setup the "mc" device with iomanX, for some reason. Thanks for clarifying that for me :D.

[methos3]

Oh, no problem : )
Now my problem is... that I used my ultimate debugging method, and I realized that the program actually freezes on the open() call, but only if I try to open a location on the pendrive.
See:

Code: Select all

void dbg_msg(char* msg)
{
    int fd = open("mc1:/debug.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666);
    write(fd, msg, strlen(msg));
    close(fd);

}

//putting that in the whole code, with a different number:
dbg_msg("1008");
 

 blocks = cardsize / blocksize;
 erasebyte = (cardflags & 0x10) ? 0x0 : 0xFF;

 /* allocating memory for I/O buffer */
 mcbuffer = (char*)SysAlloc((pagesize + 0xFF) & ~(u_int)0xFF);



 /* creating a card information file */

 register CardInfo *mcih;

 switch (cardtype)
 {
  case sceMcTypePS2:
   r = PS2_CARDINFO_SIGN;
   break;
  default:
   r = 0;
   break;
 }

 mcih = (CardInfo*)mcbuffer;

 mcih->sign = r;
 mcih->spec.PageSize = pagesize;
 mcih->spec.BlockSize = blocksize;
 mcih->spec.CardSize = cardsize;
 mcih->flag = cardflags;
dbg_msg("just before fd = open()");
 fd = open(info_file, O_WRONLY|O_CREAT|O_TRUNC, 0666);
 if &#40;fd < 0&#41;
 &#123;
  SysFree&#40;mcbuffer&#41;;
  if &#40;verbose&#41; printf&#40;"mcdump&#58; Unable to create file '%s'.\n", info_file&#41;;
  if &#40;verbose&#41; printf&#40;"mcdump&#58; I/O error&#58; %d\n", fd&#41;;
  error = 1010;
  goto end;
 &#125;

The last number that I see in mc1:/debug.txt is "just before fd = open()"; and dbg_msg("just before fd = open()"); is just before the open() call, and if I try to create mass:/debug.txt instead of mc1:/debug.txt, the file won't appear and the program will freeze :/
And what bothers me even more is that if I use fileXioOpen() on the EE just before, any file will be opened!! IOP programs doesn't need need any linking, need?

[methos3]

Ok, I "fixed" it.
See:
I have: one elf with one thread running from the EE, and my program for the IOP have a function, that is called via rpc, and it starts a new thread (a second thread, not the one from the rpc server), to do all the job (including create the files). For some reason, the PS2 will freeze if the EE thread is not blocked and I try to open() a file on mass:/ (opening on mc0:/ and mc1:/ will work, for example), but... If my irx opens up the file directly from the thread of the RPC server (and the EE thread is blocked), the file will be opened sucessfully, and any operations with it on the another thread will work with it, including close() the file. And then... the program will work.

So... if my second thread can open files on mc0:/ and mc1:/, but not on mass:/ (freezing the PS2 instead), there must be some kind of bug on the usbhdfsd, right?

in another words:

Code: Select all

int Mc_Dump(void *Data) //called directly from the rpm server thread (block mode, EE's only thread will be blocked while executing.
{
 iop_thread_t param;
 int	thid, ret;

 progress = -1;
 char vmc_file[1024], info_file[1024];
 int *Pointer = Data;
 Rpc_Packet_Send_Dump *Packet = (Rpc_Packet_Send_Dump *)Pointer;
 sprintf(info_file, "%s.mci", Packet->file);
 sprintf(vmc_file, "%s.bin", Packet->file);
 fd1 = open(info_file, O_WRONLY|O_CREAT|O_TRUNC, 0666); //this way it works


 printf("mcdump: Starting Dump process.\n");

 param.attr      = TH_C;
 param.thread    = Mc_DumpNow;
 param.priority  = 0x4f;
 param.stacksize = 0xF00;
 param.option    = 0;
 thid = CreateThread(&param);
 ret = StartThread(thid, Data);
 if &#40;ret < 0&#41;
 &#123;
  printf&#40;"mcdump&#58; Failed Starting dump thread\n"&#41;;
  DeleteThread&#40;thid&#41;;
  return -1;
 &#125;

 printf&#40;"mcdump&#58; Dump thread started.\n"&#41;;

 while &#40;!&#40;progress >= 0&#41;&#41;
 &#123;
  DelayThread&#40;100*1000&#41;;
 &#125;

 return 1;
&#125;

void Mc_DumpNow&#40;void* Data&#41;//Ok, the another thread... if I try to open a file in mass&#58;/ from here, the program will freeze.
&#123;
...
fd1 = open&#40;info_file, O_WRONLY|O_CREAT|O_TRUNC, 0666&#41;; //if called from here, it won't work
...
&#125;

[methos3]

Ok, the problem was as this line:

Code: Select all

param.stacksize = 0xF00; 

I just put

Code: Select all

param.stacksize = 0x4000; 

as the stacksize and it worked!

Cya!