| Registered User
Join Date: Mar 2003 Location: Australia
Posts: 24
| Stability of the Eruware 1.2 driver I'm interested to know what others have found with the 1.2 release (public beta or gold - apparently there hasn't been any change between them).
Personally, on my NZ90 with a Mittoni 1GB card, I have found a number of problems, and some that lead to corruption of the files on it. I haven't posted here about this until now, but have reported to Eruware earlier in the public beta cycle...
To be fair, I wouldn't be surprised if this has something to do with my card, but then the Sony drivers do not exhibit any of the problems I describe below.
What follows is a summary of my reports to Eruware. Anyone else had similar problems? If so, what have you been able to do to fix them?
Eruware suggested turning slow mode on, but this causes my screen to 'crackle' every time the CF accesses (they must be turning off interrupts for long enough to muck around with screen refreshes).
Any comments appreciated... sorry for the long post, but I wanted to be complete ...
=======Support Call 1.======
My config is as follows:
Clie NZ90
CF Driver version 1.2.0
Running with MSPro patches (even though I only have a 128Meg standard stick)
128Meg Memory Stick
1Gig CF Card, from Mittoni
I have successfully installed the current (?) driver version, and the following problems are evident with my configuration:
=======================
1. Dual MS Mode ON, Cache ON, Primary card set to the CF card, MoviePlayer failure
I run movieplayer, and attempt to play an Mpeg movie (approx 12Meg size). It pauses for a second, greying the buttons, then returns for a split second after sending the Play button green (I'm assuming its starting to play the movie after successfully initialising), finally a warning dialog appears titled "Internal Error" with the message "Internal error occured.(8012)". I click OK (the only option), and MoviePlayer drops back to the movie selection list.
This does not occur with cache off, and appears to be new with 1.2.0
=======================
2. Any configuration with CF active, CF Driver failure(?)
I run audioplayer, start playing with background active. Then, drop out to the launcher and use any util that accesses the CF card (I've tried McFlash, and Avantgo). The driver munges the concurrent data stream from the background AudioPlayer process, and the foreground process. Listening to the audio, I hear a "glitch" in the audio stream from AudioPlayer (if I am, for example copying an mp3, I actually hear a 'snip' of sound from the file I am copying! Otherwise I hear white noise as audioplayer picks up the other data stream...).
Then, within a second, the Clie freezes up and its soft boot time.
This problem is far more apparent (quicker freeze time, more obvious 'garble' of streams) whne writing to the card, but also occurs when reading. On tiny files, it is less apparent or masked. I copied mpgs as samples, and it always goes strange during the first ~4-5meg of data.
When I return after the soft reset, if I was copying files, the first is a few hundred bytes written to the output destination. I have tried copy files within the confines of the CF, and between CF and MS (to ensure read only from the CF) as well as to the CF from the stick. All exhibit the problem, although when copying *to* the CF card, the unit doesn't freeze, but picks up after the copy completes.
=======================
3. Dual MS Mode ON, Cache ON, Primary card set to MS, Copying files from CF to MS. CF Driver failure(?)
If I have cache on, and copy a file from the CF to the MS (I used a couple of prc's to the Launcher directory as samples), the destination files are corrupted. An attempt to execute the prcs (after moving to main memory) produces a "Emul68K Main.c Line:456, line 1111" fatal alert. The 'Reset' button is responsive, and I then can soft boot the Clie.
Did the same thing with a 53K file and it copied ok...
Tried copying a ~600K file from Launcher on the CF to the root of the CF, then back, and it too crashed the Palm after copying/executing from RAM (this time no fatal, just total hang when the Palm got to 'Please Wait' message. This one really fubar'd the system. On soft reboot via the pin, my Palm remained cactus, wouldn't go past the "Palm Powered" screen. Used the "warm boot + up arrow" to get to the launcher, then deleted the executable which failed to copy to RAM from the CF card earlier using Clie Files. Rebooted again, and the Clie is ok. So the prc that was in RAM was being sent startup events, and it must have been corrupted and froze the system.... the prc had written out a config file to RAM before crashing (it wasn't there before) so it must have begun executing before getting to corrupted code and crapping itself ... )
Soooo.. summary is.... cache is stuffed on my config. I tested the above scenarios without cache, and all was fine...
Note: I also tested with dual mode off, cache on, and cloaked on. Same corruption.
I tested this stuff with McFile, and also with Clie Files (older version - without the zip capability).
=======================
Generally, my config also exhibits the MoviePlayer play problem described in various threads on ClieSource, and in your "Known Issues" list. Any idea when you might (if ever - I realise the limitations) have a solution to this?
=======Support Call 2======
Last night I had some bad stuff happen with the CF driver; I had significant corruption over multiple files (MPG's in MSAUDIO, and MQV's in that directory whose name I can't remember...). I honestly don't know at this time what caused it; I'm looking for patterns that do it over the weekend...
The only potentials I can think of relate to my previous bug report, where I deliberately caused the driver to malfunction in the tests of concurrent writes, and also I used ClieFiles (old version) to copy files around.
When I ran scandisk under win2K this morning from my reader, I had massive numbers of lost blocks written out to the temp directories that scandisk creates.
Internally, various (but not all) files showed up prior to scandisk as corrupt in AudioPlayer, and some (not all) could not be read any more (causing a 'general read' failure dialog from McFile).
Post scandisk, after copying all the data from the card, reformmatting and copying back, one of the MPG's states corrupt, the others seem ok, but I won't know until I play them. Nothing important lost, and (frankly) I can't be sure it was your driver specifically because I froze up and had to soft reset during read/writes in testing for the last report and so it could be a corrupted FAT due to that ...
=====Support call 3 (after suggestion from Eruware for SLOW mode)
Ok,
A followup. I repeated the tests described in the attached bug-report mail, and wanted you to know the corruption related to copying files from the CF card to another location (with a destination on or off the card) still occurs if I have slow + cache.
There's an additional symptom I hadn't noticed when slow mode is enabled too... the Clie LCD "crackles" - reminds me of electrical interference - during any copy to or from the CF card (using McFile), cache or no cache. Doesn't corrupt when cache is off, but the crackle is annoying.... As follows:
CF to/from Stick = Crackle
CF to CF = Crackle
CF to Main Memory = Crackle, but less evident
Main Memory to CF = Crackle
Interestingly, when the same prc is placed into the CF Card Launcher directory and launched, it does not 'crackle' as it copies to main memory. Let me know if this is a known problem; I am tempted to do some more testing to narrow down what is going on... but it feels like an interrupt problem with the driver - what's it doing in slow mode - turning some interrupts off longer than 'non-slow', and thus interfering with screen refresh?
===END.
Note: Eruware confirmed the 'crackle' is because of interrupt issues. Actually, probably more to do with the Palm than the driver (apparently OS5 does not handle interrupts preemptively, so there is a much greater chance of an application holding up an important interrupt for long enough to cause system problems. An example of this would appear to be Eruware's driver holding up screen refresh ... ). |