Chronic 100 percent disk and CPU usage on older hardware

gregrocker said:

Very confusing results. I boot from Linux Partition Wizard disk and drive is detected with files intact. Passed surface test and Rebuilt MBR. Was then able to boot into it, at least until I unplugged the other drive and installed the problem drive. It wouldn't start again. Why it required the other drive attached to even be seen I don't know. Tried different cables and SATA ports. The other drive is IDE.

Now it's playing weird games showing up in BIOS storage and boot listings as a blank under whatever port I plug it into.

I'm going to try Seatools and Data Lifeguards on CD now.

Because the drive is set not to spin on power up but to wait for a spin command to spin up you need to set the drive to spin on power up.

If it's the only drive plugged in then wouldn't it spin by default? How would you do this?

I've wiped with Data Lifeguard Quick wipe to see if that helps clear something in the partition table or boot sector - possibly a "dirty bit?" Then I'll try installing TP. If it takes it then I'll put the Macrium Image on here.

Other suggestions?

Hi all,
I've pinpointed the issue which is related to this function of HDDs Power-up in standby - Wikipedia, the free encyclopedia

Your motherboard doesn't support PM2 and neither does mine.
You should get your old HDD back as it is OK. Windows haven't broke the hardware.
Guys in your shop are lame, sorry.

That's the explanation of what's happening:
HDD gets power (electric current) but stays still instead of spinning (it waits for ATA signal).
If your BIOS doesn't support it (you probably get something like "SATA1 0MB") bootloader can't start so Windows won't work.
On the other hand, Linux supports direct communication with SATA drives so here comes our saviour.


SOLUTION!

a) One time
You can fix it for one time by booting Linux LiveCD/LiveUSB and rebooting - Linux communicates with SATA drives and spins them - after reboot BIOS will detect your WD drive and so will Windows.


b) Permanent
(that is until Windows 10 overwrites the setting again )

Follow the instruction and avoid Sleep on 9879.
After you boot your LiveUSB/CD:
1. Open Terminal (Ctrl+Alt+T or Ctrl+Alt+F1 or just click the icon)
2. Execute:
sudo hdparm -iI /dev/sd?
sudo hdparm -s0 /dev/sd?


hdparm is a Linux tool for configuring HDDs.
First command displays some info (look for Power-up in Standby on the list - Shift+PgUp to scroll the output).
Second commands sends disable command to that feature.
'?' in commands should work as a wildcard but if it doesn't use 'ls /dev/sd*' to find the letter of the HDD (it usually is either /dev/sda or /dev/sdb - but sometimes can even happen to be /dev/hda)

Credits go to T61T9300 - I couldn't find that command


Here comes the explanation of what happens in there from the author of HDAT2 HDAT2 FAQ


I'm happy to make your 'bricked' HDDs working fine again.

Cheers,
Michael

Link

Thanks.
:)

Is he saying the Permanent solution works unless Sleep is used?. If Sleep can stay then I'll run that fix and reinstall.

gregrocker said:

Thanks. Is he saying the Permanent solution works unless Sleep is used?. If Sleep can stay then I'll run that fix and reinstall.



Otherwise maybe I should wait until the next build for this HD.

You need to run the command so you can install later and yes he is saying disable drive sleep in W10.

Michal -


I have have used your permanent solution to this puis issue. It worked!! so now i have my bricked drives back.. i used the iso version of hdat2. it uses version 5.0 of the hdat2 program.

until of course the next time windows 10 overwrites the setting again!!! which it promptly did and does at every shutdown/ sleep power cycle. right now my win 10 machine is not allowed to sleep either.

drive I am using is an hgst 7k1000 in a thinkpad T400. bios is set to ahci mode.

I have checked driver status for both the controller and hdd in device manager and all drivers appears to have been updated around nov 3.

i am going to report this thru the feedback app as has been suggested.

thanks for your effort on this issue!!!!!

Yeah I thought I should put my roommates off another few months but they were chomping at the bit to try 10, and were enthusiastic 7 beta testers so want to get in early. Each still has 7 in a Dual Boot but I doubt they'll go back unless there's disaster - for which there's plenty of backup images, drives and machines. Right now I'm finishing Macrium images of both of their finished Dual Boots to backup machines which will sit on the shelf.

I'm leaving Tues to travel for a month each at my other home and Hawaii so don't want to leave anything possibly unstable. I think I'll put this scuzzy drive aside until I get back so I don't get behind.

I notice the drive is labeled SCSI but has SATA connectors. I wonder if this is related.

gregrocker said:

I notice the drive is labeled SCSI but has SATA connectors. I wonder if this is related.

Yep that feature is mandatory for SCSI arrays so as not to overload the power supply on power up..

Want to read more about it when I get a chance to find out how this happens besides the drive not spinning up until called. What intervenes that bricks the drive? Something to do with Fast Boot and "dirty bit" I've been hearing about?

gregrocker said:

Want to read more about it when I get a chance to find out how this happens besides the drive not spinning up until called. What intervenes that bricks the drive? Something to do with Fast Boot and "dirty bit" I've been hearing about?

Nope it is a hard ware setting on the drive used to be a jumper. The drive cannot read anything on the disk until it spins up. If the MB does not tell the drive to spin up then no OS is available.