Recently I have repartitioned the microdrive of my Zaurus: I've cut down the size of the FAT partition, /dev/hda3, to 1GB and created another partion, /dev/hda4/, which I formatted with an ext3 filesystem. I mount is as /usr/local, to have lots of space to play with when custom compiling applications.
Unfortunately, ever since then, I have a problem with a suspend mode. Every time I suspend the Zaurus, with about a 50% probability a following thing will happen: firstly, the hard disc LED will turn on green and stay like that while the Zaurus remains in the suspend mode. Secondly, when I bring it out of the suspend mode, it freezes for much longer than usual. It remains complete unresponsive - to the stylus or to the keyboard - for close to a minute. Then everything returns to normal.
My guess is that it is happening because the Zaurus thinks /dev/hda4 is a CF card (I can see it as a CF card under the File tab) and does something stupid to it. Like runs some filesystem check or something. I have tried my best to read the hotplug scripts, but I can not locate the point where that happens. As far as I can figure out, on suspend it calls first "usbd" with "suspend", which unloads one bunch of modules (what are all these *_fd modules like storage_fd?), then calls "usbdstorage" with "inactive", which erases the /var/run/usbdstorage.pid, then calls "usbh" with "suspend", which essentially umounts any /dev/sda and/or /dev/sca devices (which I dont have) and then removes "usbcore". When coming out of the suspend the process is reversed: first "usbh" is called to load usb_ohci_pxa27x and to mount usbdevfs. Then "usbdstorage" is called to update /var/run/usbdstorage.pid with new PID. Then "usbd" loads the rest of modules.
So what gives? Is the hard-disk suspend purely kernel-based? I REALLY do not want to try and read THAT source code. And I am fed up with waiting for ages for the Zaurus to come back after a suspend mode. Help?
