Forums › Forums › GLD Forums › Archived GLD Discussions › ****WARNING**** SERIOUS GLD80 CRASH › 2619
Hi All
Some more information on Martin’s crash.
There are 2 separate bugs here which are unrelated but cause the same point of failure:
1) An O/S indexing service generating large temporary files
2) USB Key hot unplug generating excessive event log entries
Both eventually cause the on board storage to fill up and the desk will fail to boot.
Martin’s failure was type 1, but type 2 is more common.
V1.12 maintenance release contains 2 changes to address these issues:
1) We’ve disabled the indexing service, to prevent it creating temporary files.
2) We check the log file size on the next boot, and clear them up if they are preventing the system from booting correctly.
The thing to note here is the log files ( for type 2 ) are created because the system was busy writing to a USB key, and the key was removed before the write was completed.
Our modification in V1.12 will therefore get a console broken in this way working again AFTER a reboot, but doesn’t prevent it from happening in the first place. Further after the disk has filled up, and before the console has been rebooted, the console will be unable to store shows / libraries to the disk – its full!
To prevent this situation you need to wait for the write to USB Key to completely finish. There’s usually a light which flashes on the device, but often the write activity happens in bursts with gaps in between. This can cause the user to think its finished, when actually its just gearing up for another write!
The USB Key manufacturer has a slight bearing because some are faster than others. You are less likely to hot unplug a fast key, because its more likely to be finished! Also some manufactures use large caches to improve write performance, and haven’t actually completed the write, but tell the console they have!
In addition to the fixes in V1.12 we’re looking into suppressing the event log entries altogether for a future firmware update which would stop the event log from overflowing.
But …
The user will still run the risk of loosing data if the key was removed before the write completes.
The best advice is therefore to give the USB key writes a bit of breathing space. Count to 10 before pulling the key out after a write!
V1.12 should go live on the website later today.
Hope this helps.
Andy
A&H
