Strange PSP behaviour when connected via USB under Ubuntu

[Barts_706]

I have finally managed to install newest pspsdk under Dapper Drake Ubuntu. I have configured the paths, compiled a few examples from the gu part of sdk. So far so good.

The problem starts when I connect my PSP to my laptop (old Dell Latitude) via USB 1.1 (I said it is old).

It is detected, automounted, but when I copy anything to memory stick from my PC, the files are not copied instantly (as under Windows XP on the same machine). Instead, they show in file browser (console, mc, nautilus) as if they were copied on the memory stick, but if I disconnect the PSP - they are not there. If, on the other hand, I wait 5-10 minutes, they eventually get copied at some (more or less random) point. It is not very slow transfer, rather as if the data was cached somewhere and then flushed to USB when my Ubuntu thinks the time is right.

I quite frankly do not know why it happens so. It is not like that under Windows XP. I have googled, but not found anything similar. I have searched this forums, neither. So I post a description of a problem here, maybe someone will have an idea what to do about it.

[Drakonite]

You have to unmount the drive.... ffs people, you are supposed to do the same thing in windows too, but since windows uses sync writes instead of the faster async batch writes, chances are as long as the light isn't flashing the file has been written, but the drive still isn't in a clean state to be removed..

[jimparis]

If you really really want the slower synchronous writes so you can pull the PSP at any time, you should be able to add a rule to /etc/hal/fdi/policy/preferences.fdi to add the "sync" option; this is untested but it's something like

Code: Select all

  <device>
    <match key="block.is_volume" bool="true">
        <match key="@block.storage_device&#58;storage.removable" bool="true">
          <merge key="volume.policy.mount_option.sync" type="bool">true</merge>
        </match>
    </match>
  </device>

[zilt]

Or just type 'sync' after you do the copy. It flushes the file system buffers

[Drakonite]

...and it still leaves the filesystem in a dirty state. Seriously, just unmount the stuff, otherwise you are begging for filesystem corruption.

[zilt]

...and it still leaves the filesystem in a dirty state.

Then you must have a broken 'sync' command. I use it all the time without issue. From the 'info sync':

The kernel keeps data in memory to avoid doing (relatively slow) disk
reads and writes. This improves performance, but if the computer
crashes, data may be lost or the file system corrupted as a result.
The `sync' command ensures everything in memory is written to disk.

A umount ends up calling the same sync system call to flush the buffers to disk. However, if you want to disconnect the PSP, you _should_ be calling umount anyways, so the sync command is unneeded.

[Drakonite]

...and it still leaves the filesystem in a dirty state.

Then you must have a broken 'sync' command. I use it all the time without issue. From the 'info sync':

It has nothing to do with the sync command. Until a filesystem is unmounted it's marked as dirty, regardless of how many times you call 'sync' it doesn't guarentee the filesystem is clean when you pull it, as anything could access the drive at any time; not to mention any filesystem with a global dirty flag is still marked dirty.

Pulling a drive with a syncronous (or just sync'd) filesystem _tends_ to work, as the data tends to be there, and then when the filesystem driver sees the filesystem is dirty and checks it, it typically shows up as okay or the only inconsistencies are quietly fixed. But it's not guarenteed to be so. Pulling a drive without unmounting is playing russian roulette.

And besides, it's as you say.. if you are running anything, you should be running umount, not just running sync. Running a sync command instead of unmounting is idiotic at best... And in the case of mounting with the sync option, the possibility of catching it in a corrupt state is even larger.

[groepaz]

depending on your setup (kernel/udev/hotplug/etc) actually funny things may occur if you dont unmount before running something...because the kernel doesnt know the device was unmounted, it may see another device the next time the psp initializes its drivers. i even managed to get some kernel-ooops (in the usb driver) when playing with pspinside too much :=)

[Barts_706]

Thank you for your quick replies. I haven't replied earlier, because I went to sleep (well, you just need to sometimes).

But how come the automount connects my PSP in asynchronous mode?

Well, never mind, I'll play with that. At least I have a bunch of new google keywords to search for (this sometimes is the main problem - I can describe the problem, but don't know what keywords to type...).

Still, do I understand it well that /etc/hal/fdi/policy/preferences.fdi contains the rules concerning additional mounting options (this whole sync thing)?

[groepaz]

i'd disable automount completely for developing, it only causes weird problems :)

[Barts_706]

I have been thinking about it (purely theoretically for the time being, as I am at work now and could not check it here) and more questions arose :

- does umount _always_ call the sync?
Even if there is a lot waiting to be copied (like a file of, say, 950Mb, umm, a hypothetical file of a kind that we do not talk about in this forums)? If I call umount in such a situation, will it go for a looong copy (USB 1.1, mind you) and then unmount system?

- if I draw proper conclusions, is it okay to :
a) copy eboots to PSP;
b) then use 'sync' command;
c) then use 'umount'?

Sorry for the trouble, but you seem to have a good knowledge of the subject, so maybe I can learn something from you.

[zilt]

Yes - umount always does a sync. If I copy a video file over to the psp, the cp generally returns immediately, then I do a umount and it can take a minute of two till the umount command ends while it flushes the buffer (by umount calling the sync system call ). There's no feedback from the umount call - it'll just sit there for a while till it's done. Do not unplug your cable till it returns.

[Drakonite]

- does umount _always_ call the sync?

The entire purpose of umount is to commit everything, prepare a filesystem for removal, and then remove it.... so yes, it always syncs the buffer to the filesystem.

[Brunni]

It seems that the PSP manages this by itself anyway. If you press circle to stop the USB connection, even when writing a file, it won't corrupt the stick (IIRC).

[Arwin]

It seems that the PSP manages this by itself anyway. If you press circle to stop the USB connection, even when writing a file, it won't corrupt the stick (IIRC).

Not necessarily true, in my experience. I've had a few times that the file I copied ended up corrupt - doesn't happen a lot, but it can be really annoying. Like Drakonite says, it's just a really bad idea anyway and you're just waiting for your memorystick to end up corrupt.

So I always properly unmount my USB device from windows (XP) as well. It's not like it's that much work, clicking it twice ...

[ooPo]

In ubuntu, right-click on the icon on your desktop and select 'unmount'.

[groepaz]

just add a little script thingy to your makefile that does mount/copy/unmount. easiest for me anyways :)

[Brunni]

It seems that the PSP manages this by itself anyway. If you press circle to stop the USB connection, even when writing a file, it won't corrupt the stick (IIRC).

Not necessarily true, in my experience. I've had a few times that the file I copied ended up corrupt - doesn't happen a lot, but it can be really annoying. Like Drakonite says, it's just a really bad idea anyway and you're just waiting for your memorystick to end up corrupt.

So I always properly unmount my USB device from windows (XP) as well. It's not like it's that much work, clicking it twice ...

What do you mean by memory stick corruption? Are there cases where the entire stick becomed unaccessable because of corruption, or is it just for one file?