Seagate update

Seagate got their act together and released new firmware for their drives. They even replied to my email. I applied it to both my 500GB drives. Both went OK but the original fault in one of my drives remains – bad blocks, chattering sounds even when its idle.

I ran SpinRite on level 5 (reclaim lost sectors) over it for a few hours. Then I restarted SpinRite to test how it had gone… the bad sectors were still there. So the drive is toast and worse still, its S.M.A.R.T reports the drive is imminent to fail.

I don’t know if I’ll bother returning it. I dont really want another Seagate! As for the other drive, I’m going to be testing it regularly and watching it very carefully.

[EDIT April 2009].

I’ve been following the Seagate forum discussion on my ST500320AS drives. One of mine is still working and the other is useless with bad sectors. Kind of given up on it being resolved by newer firmware but I might get around to returning the drive, hopefully at a time in the future when they’ll find it easier to replace it with an SSD 🙂 (wishful thinking).

Seagate Drive update crash followup

I guess I was lucky the 500GB Seagate drive update crashed… had it worked it might have bricked the drive

“This will be firmware to fix the firmware (SD1A) that was issued to fix the firmware (SD15) that caused some 1TB Barracuda 7200.11 drives and others to stop working. The SD1A firmware caused 500GB Barracuda 7200.11s to stop working.”

Woah, exactly the version of my 2 drives..

Seagate 500GB drive troubles and crashing flash utility

Well, looks like the 2 500GB drives I bought for my new PC have both got lemon firmware on them. I’d already removed one of them from my system and put it into a spare Dell server I have here to diagnose silly “seek” sounds it would make with nothing accessing it.

So I was interested when I read about Seagate’s firmware fixes.

Unfortunately, the flash utility barfs trying to update either of my drives on 2 different systems.

The firmware update I got from Seagate called itself:

MooseDT-32MB-SD1A.ISO The CD it made boots OK and the flash updater loads. I can use the “S” key to scan my drives and I get:

Model ST3500320AS
S/N   5QM331TJ
F/W   SD15
Ctrl  Intel IHC7

However when I press “D” to perform the update, I get a fault:

Exiting due to signal SIGSEGV
Page fault at ieip=00006683, error=0004
… register dump …

followed by the text:

Error specific model not found. ST3500320AS expected

Doh!

I emailed Seagate about it and will be surprised if they actually answer.

Latest on the Linux GL824 driver

Its been a year since I started working with a small group on getting a Linux driver going for the GadgetLabs GL824 8 channel sound card We’ve got card syncing going so you can have 2 or 3 cards synced for 16/24 channels playback.

During the break I messed with it a bit more as Mike, the project leader, is working on getting a WFS system going – using a speaker array to project sound into free space.

32 channels is a minimum so we’ve been pushing the envelope and working on a system with FOUR GL cards. Up until recently we’ve had no luck getting the 4th card working but we’ve now achieved playback on 32 channels at 44.1k.

The initial blockers included a few driver issues and apparent PCI slot sensitivty but the main one appears to have been that the sync-clock signal (passed from card to card with link cables) degrades from card to card.

The sync signal is generated by the first card in the chain, the master. Its around 16MHz for 44.1K and 18MHz for 48K. Each card filters and buffers the signal before outputting it again, so its not a level problem.

I’m currently working on the theory that each card in the chain introduces jitter to the signal. So by the last card theres enough to upset the DACs on it which causes a continuous static.

After some messing about we’ve stumbled upon a combination of cards and sync cable order where at 44.1K its workable. I’m thinking we need to build a small clock buffer board  (eg with a 74Ls14) and then distribute the clock in parallel to the 3 slave cards.

Mike is already imagining syncing 5 cards in one system, or multiple PCs …

This is all for playback. For recording, we’ve found the GL has a very poor transfer rate for samples from the card to the host – 4 times a slow as transferring samples to the card. This makes the maximum practical number of inputs 16 (2 cards).

Also we’re finding that later Linux distros like Fedora Core10 (x64), Ubuntu 8.10 (x64) have made a bit of a dogs breakfast of the ALSA tools, for example ‘arecord’ just doesn’t work properly but the graphical apps are OK.

I’ve gone back to FC8 and get good realtime performance from both the oldish CCRMA realtime kernel 2.6.24.7-1rt3.2 and the lastest FC8 update 2.6.26.8-57. With these and using qjackctl (with its realtime option selected), my system is pretty free of XRUNs.