I recently got a new laptop with a 500GB Seagate ST9500420AS, 7200rpm 16mb. I am not sure there is a problem with the drive, but at least something concerning the drive seems faulty. The problem is as follows; when the HDD is idling and not doing any hard work it will freeze up 2-3 times every minute for a 1-2 seconds. This affects all programs but it does not freeze the whole computer as I am able to move the cursor around as normal. The HDD-activity light turns on during these freezes so there seems to be something concerning the HDD as it is active.

I have run several diagnostic programs like HDD Regenerator and tests, benchmarks and such from SeaTools and HD Tune. Every one of these programs says that the HDD is at good health and no problems are discovered with the drive. In the windows event list I had errors showing "bad/faulty controller on disc 1", then I installed the latest chipset drivers and that has not appeared anymore. There is however another error saying "bad block", but the source for that is labeled cdrom. Might this be the problem?

Here's a recording of the problem. http://youtu.be/_ntdJZh3yDg

I saw the pauses on the YouTube video, but didn't hear any unusual noises - I'm not sure if that is due to the microphone position, or whether there really are no unusual noises.


Understood - that is a worry.


As I just said in another thread, a diagnostic "pass" does not mean that no fault exists. Also, because you haven't supplied any data from those tests (especially the raw SMART attribute values and read benchmark graph), then you're not allowing readers here to review that data.

I suggest that those 2 sets of data that I mentioned, would be the first things for you to provide here.


I don't see how that is related, because of the source that you mentioned. You should check to see if those messages are logged immediately after seeing the HDD activity light being lit unexpectedly. If you see none of those messages logged at the relevant time, then that also suggests no link.

In addition to supplying the data I suggested (raw SMART values and read benchmark graph), have you tried a different OS (e.g. booting a Linux Live CD) to see if the same HDD activity light behaviour occurs? This forum isn't a Windows support forum, so it would be helpful to eliminate Windows as the trigger e.g. is a background program (e.g. virus-scanner) causing those disk accesses? An intermediate step would be to boot Windows Safe Mode and seeing if the same periods of HDD activity light being lit still occur or not.

Hope those comments are useful.

Thanks for the reply, Vulcan! I'm a bit in a hurry so I'll have to come back later with some screenshots from the different programs. I did however try Ubuntu linux, not for very long, but the problem did not seem to be the same in linux. The HDD-activity light was off when the HDD was idling and I did not experience the stutter/lag that I do in windows. I'm back in windows now and the HDD-activity light is constantly blinking on and off just to mention the difference.

I think that Vulcan has hit the nail on the head in his last paragraph...

_________________
East Anglian Data Recovery Services
http://www.eadr.co.uk

"If it's your only copy - then it's not a backup!"

@Touchclarity: Hopefully we'll get somewhere

@gecco:


So that suggests some possibilities to me, including:

(a) Perhaps the unexpected disk I/O is from something running under Windows (e.g.. virus scanner etc.). IMHO this is quite likely. On a new laptop, there can be pre-installed rubbish/unnecessary software, which you don't know about because you didn't install it. You could investigate the Autoruns utility, to see what software is being started automatically by Windows.

or

(b) Perhaps the lack of the same behaviour under Linux is due to Linux not accessing the disk in exactly the same way (e.g. if there is a marginal sector which is read often by Windows, it may not be read when using Linux, so Linux may not trigger a problem which is provoked when using Windows). IMHO this is less likely, but we can't yet say this is definitely a Windows-related issue, although it might be...

As I said before, Windows support is off-topic here, but you can use utilities like Filemon to see if you can identify whether an application is causing lots of I/Os at the times of the pauses. Also using Windows Performance Monitor may give you useful info. FYI I have seen significant pauses with network-related Windows issues/mis-configuration in the distant past, but I'm not going to remotely diagnose a Windows-related problem now.

Another tool for investigating disk drive health, which may be useful in this situation due to that Linux test result, is MHDD from this website, since it can be run from a bootable CD (it runs under DOS). You would need to change your SATA HDD controller into IDE/compatibility mode, before booting MHDD, if that is not its current setting.

You could then perform a read scan (F4 key) to check for slow or unreadable sectors, without Windows being involved at all (this will be different conditions than using HD Tune, which you've done already, although those HD Tune results will still be interesting, when you can supply them).

There is one type of test which hasn't been mentioned so far, and that is a write benchmark. Very rarely I've seen disks which are slow to write. I doubt that this problem is involved here, and of course, it needs a full (and verified) backup to be taken first - but I just wanted to mention it.

It is impossible to eliminate something (e.g. the disk) as the cause of a problem, if all tests show "good" results - those tests might not be accessing the disk in the way which is needed to provoke a genuine problem. However in your case, you might need to go and get some Windows help, if you can only provoke the problem under Windows - even without being able to prove that the disk is perfect.

One other test you could perform (although this is some effort for you), is to clone your current disk onto a different (but similar) disk, install that different disk in your laptop, and see if the same behaviour is seen when booting from that different disk. If the same behaviour is seen with a diifferent disk, then except for one rare possibility, that usually means that the disks are not the cause of the problem.

I look forward to seeing that data from your earlier tests

The laptop is a self-configured one, so it's a clean windows 7 x64 install on it without any bloatware or antivirus so that bit should be covered. But I am more and more leaning towards the fact that there might be a problem either with windows or with a driver since the linux testing made the HDD behave in such a different way. Will try more linux tomorrow and look into MHDD and try that. Big thanks so far!

Here are some screenshots from the tests/info/benchmarks:













Info from sisoft sandra:
http://pastebin.com/gZkDEm5t

The SMART Load/Unload Cycle count is extremely high.

I calculate that, on average, there is one Load/Unload Cycle every 1.83 minutes.

http://www.google.com/search?q=0xf4e+x+ ... in+decimal

At this rate the drive will hit the SMART threshold of 200,000 cycles in a very short time.

There is a Dell firmware update that addresses this problem. It updates your 0002SDM1 retail firmware to 0005SDM1.

There is a long thread at Seagate's forums that explains how to forcibly update your firmware if the update utility rejects your drive. The procedure is completely safe.

http://forums.seagate.com/t5/Momentus-X ... td-p/30598

Your drive's temperatures are also on the high side (50C), but there is probably not much you can about this in a laptop environment.

_________________
A backup a day keeps DR away.

@gecco:

Thanks for that info. From that SMART data (and f/w version) I see that fzabkar has already pointed you at that relevant thread on the Seagate forum. I'll just mention a couple of other brief points:

- I didn't see a normal read benchmark graph in those images (file benchmark and random I/O - yes, but not from the tab just labeled "Benchmark"). From the other data, I don't expect there to be any problem seen in the result of that test, however as far as I can see, none of the other tests show the timing for reading all of the surface.

- SMART attribute 188 (0xBC) [Command Timeout] is non-zero. As you can see in the raw hex data, this proprietary encoding appears to show 3 different 16-bit values, for which I've not seen a full explanation. It's probably that 9 timeouts (i.e. the low 16-bits of the full 48-bits) have occurred. That's a low number compared to other drives I've seen, but may be worth investigating further if it starts to rise.

- If you used something like smartmontools to report the drive's internal SMART Error Log, then that would give extra confirmation that the drive had detected no problems.

However, from the data supplied, I don't see evidence of a disk hardware problem. I suggest to investigate that f/w update, in order to eliminate that known issue which seems to fit with your symptoms. Good luck

Hi guys! I've been really busy the last days so I'm sorry that I haven't had the time to check in.

I just updated the firmware and so far I can say that I'm in heaven! Looks like that did the trick!

Thank you all so much for the time you have made to help me out on this problem

@gecco: Glad to hear that news. Kudos to fzabkar for linking to the thread about the f/w.