Failure of brand new drive... possibly due to staggered spinup?

On Jun 1, 1:43 pm, "Folkert Rienstra" wrote:
of a drive controller issue. I tried holding the drive in my hand as
it powered up, and I could not feel the characteristic hum of the motor!

And why should you? You set it up to "power-on in standby mode".
So it does.

Indeed. However, I would expect it to come out of standby mode when
addressed by the host :-) For example, under Linux I can put a drive
temporarily into standby with "hdparm -y /dev/sda". However, the
Linux IDE/SATA drivers will bring it out of standby as soon as I try
to access it.

In my experience, drives in standby mode are still capable of communicating
with the host,

And it probably does.
Problem is likely that host doesn't understand why it is in standby mode,
so it fails it.

Okay. I would believe this if it was only the laptop BIOS that didn't
know what to do. But not only the laptop BIOS can't initialize it,
also the BIOS on my desktop can't initialize it, and the Linux kernel
can't initialize it when booting from an external disk.

I certainly think a recent Linux 2.6.20 kernel must know how to deal
with this situation... I've never met another hard drive feature that
the Linux kernel couldn't handle with ease.

Of course, now that I dig around a little more, I find this patch on
the linux-ide mailing list: http://www.mail-archive.com/linux-id.../msg04323.html
Maybe with this patch my kernel will figure out what to do? I'll try
it tonight...

Anyone have any advice/anecdotes/explanation?

Most likely your host isn't compatible with power-on in standby mode.
Set the drive back to normal. That may be easier said then done, apparently.

Indeed. Is there any utility to do this??

Dan Lenski

"Dan Lenski" wrote in message ups.com
On Jun 1, 1:43 pm, "Folkert Rienstra" wrote:
of a drive controller issue. I tried holding the drive in my hand as
it powered up, and I could not feel the characteristic hum of the motor!

And why should you? You set it up to "power-on in standby mode".
So it does.

Indeed. However, I would expect it to come out of standby mode when
addressed by the host :-)

Nope.
It wants/needs to be specifically told. Else any access would wake it up.

For example, under Linux I can put a drive
temporarily into standby with "hdparm -y /dev/sda". However, the
Linux IDE/SATA drivers will bring it out of standby as soon as I try
to access it.

Power-on in standby mode is an altogether different feature.
It's similar to the start unit command of SCSI that is required
if a SCSI drive has been jumpered for autospin disabled.
The difference here is that the jumper has been executed in software
so you have a jumper command and a spinup command.
Svend has mentioned them both already.


In my experience, drives in standby mode are still capable of communicating
with the host,

And it probably does.
Problem is likely that host doesn't understand why it is in standby mode,
so it fails it.

Okay. I would believe this if it was only the laptop BIOS that didn't
know what to do. But not only the laptop BIOS can't initialize it,
also the BIOS on my desktop can't initialize it, and the Linux kernel
can't initialize it when booting from an external disk.

That's not so surprising at all. Even IBM/Hitachi who are normally well
equiped (either their Drive Fitness Test or Feature Tool) don't have it in
their toolkits.


I certainly think a recent Linux 2.6.20 kernel must know how to deal
with this situation... I've never met another hard drive feature that
the Linux kernel couldn't handle with ease.

Of course, now that I dig around a little more, I find this patch on
the linux-ide mailing list: http://www.mail-archive.com/linux-id.../msg04323.html
Maybe with this patch my kernel will figure out what to do? I'll try
it tonight...

Anyone have any advice/anecdotes/explanation?

Most likely your host isn't compatible with power-on in standby mode.
Set the drive back to normal. That may be easier said then done, apparently.

Indeed. Is there any utility to do this??

Now that you mention it, Svend was experimenting with it.
http://www.partitionsupport.com/advancednotes.htm


Dan Lenski

On Jun 1, 5:12 pm, (Svend Olaf Mikkelsen)
wrote:
This is as expected. You need to send a

Power-Up In Standby feature set device spin-up.

command to spinup the disk, or a

Disable Power-Up In Standby feature set.

to disable the feature.
--
Svend Olaf

Wow. Just wow. I can hardly believe it, but that worked. Thanks
Svend and Folkert for helping me figure out that the drive wasn't
actually dead.

Issuing those commands to the drive wasn't so easy: I had to apply
Mark Lord's patch (http://www.mail-archive.com/linux-
) to the 2.6.20 kernel. But lo and
behold, when I booted with that patch, the SETFEATURE_SPINUP command
was sent to the drive, and it began to operate again.

The whole thing is kind of amazing: toggling the "power up in standby"
feature caused the BIOS of *three* desktop computers to pronounce the
drive dead, and to freeze when booting. In order to get past the
BIOS, I had to hotplug the drive at the GRUB boot menu. And the
default 2.6.20 Linux kernel of Ubuntu failed to spin the drive up as
well. Probably the Linux kernel doesn't support this since it expects
the BIOS to have spun the drive up already.

So I still have some questions...
* does anyone know of a BIOS that actually *does* know how to spin up
drives that boot in standby?
* why isn't this feature marked as DANGEROUS in the hdparm
manual :-) ?
* is there a way to issue raw commands to a drive from Linux (maybe
via /sys) without recompiling the kernel?

I'd like to make a standalone boot disk to help out other folks who've
bricked their drive in a similar fashion. It'd be great to figure out
a way to do it without a custom kernel.

Wow. This is definitely the strangest hardware/firmware quirk I've
ever encountered... and one of the most time-consuming.

Dan

The whole thing is kind of amazing: toggling the "power up in standby"
feature caused the BIOS of *three* desktop computers to pronounce the
drive dead, and to freeze when booting.

A clear sign of bad industry support of this (S)ATA feature, especially for
laptop drives.

For SCSI drives, their SCSI BIOSes can send START STOP UNIT (the similar SCSI
command) at boot for very long times, and the drive can be mechanically
jumpered to "no spin at powerup".

This is because spinning up a SCSI drive imposes significant load to the PSU,
so, it is a good idea to delay its spinup until after the BIOS self-tests,
while the (S)ATA drives will be spinned up and power up. This reduces the PSU
power load.

But this is relevant for "heavy" SCSI drives only, not relevant for a laptop
drive. That's why - IMHO - the industry support for a feature is bad on (S)ATA.

* why isn't this feature marked as DANGEROUS in the hdparm
manual :-) ?

Hey, it's open source, mark yourself and tell the maintainer :-)

* is there a way to issue raw commands to a drive from Linux (maybe
via /sys) without recompiling the kernel?

Try FreeBSD and "camcontrol".

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com

Maxim S. Shatskih wrote:
The whole thing is kind of amazing: toggling the "power up in standby"
feature caused the BIOS of *three* desktop computers to pronounce the
drive dead, and to freeze when booting.

A clear sign of bad industry support of this (S)ATA feature, especially for
laptop drives.

For SCSI drives, their SCSI BIOSes can send START STOP UNIT (the similar SCSI
command) at boot for very long times, and the drive can be mechanically
jumpered to "no spin at powerup".

This is because spinning up a SCSI drive imposes significant load to the PSU,
so, it is a good idea to delay its spinup until after the BIOS self-tests,
while the (S)ATA drives will be spinned up and power up. This reduces the PSU
power load.

But this is relevant for "heavy" SCSI drives only, not relevant for a laptop
drive. That's why - IMHO - the industry support for a feature is bad on (S)ATA.

I don't agree on that. Don't forget that SATA drives are also used in
big (and very expensive) storage arrays for low performance high
capacity disk storage.


* why isn't this feature marked as DANGEROUS in the hdparm
manual :-) ?

Hey, it's open source, mark yourself and tell the maintainer :-)

* is there a way to issue raw commands to a drive from Linux (maybe
via /sys) without recompiling the kernel?

Try FreeBSD and "camcontrol".

On Jun 2, 4:02 am, "Maxim S. Shatskih" wrote:
The whole thing is kind of amazing: toggling the "power up in standby"
feature caused the BIOS of *three* desktop computers to pronounce the
drive dead, and to freeze when booting.

A clear sign of bad industry support of this (S)ATA feature, especially for
laptop drives.

Right. It's about a 3-line addition to the BIOS code, as can be seen
from Mark Lord's libata patch which I linked to. In my opinion, it
*is* a feature which would benefit desktop computers and embedded
systems, since you could save significant load on the PSU by not
spinning up the HD at boot time. For example, my friend has built an
automotive PC and he had problems with it crashing at boot, due to
excessive drain on the car's 12V supply.

Also, I don't think the distinction between 2.5" and 3.5" drives is
relevant here, since they all use the same (S)ATA command set.

* why isn't this feature marked as DANGEROUS in the hdparm
manual :-) ?

Hey, it's open source, mark yourself and tell the maintainer :-)

Oh, believe me, I plan to :-) In my opinion, it is MUCH more
dangerous than the other features marked dangerous. Most of them can
simply crash the OS or lock up the drive until the next reboot.

This one can make the drive appear dead *and* freeze the BIOS.

* is there a way to issue raw commands to a drive from Linux (maybe
via /sys) without recompiling the kernel?

Try FreeBSD and "camcontrol".

Cool. That's a neat utility. I feel like it outta be possible to
send some commands via /sys/bus/scsi/devices or something like that...
but it's just a hunch. I'm going to email Mark Lord about his patch
and maybe he'll have a suggestion for that!

I'd also like to poke the freakin' BIOS vendors with a clue stick and
tell them to support this feature... but that's probably a lost cause,
right?

Dan

On Jun 2, 4:22 am, Dirk Munk wrote:
I don't agree on that. Don't forget that SATA drives are also used in
big (and very expensive) storage arrays for low performance high
capacity disk storage.

Right. I assume that's why this drive has the feature. I have heard
that some data centers use arrays of 2.5" disks since they consume
significantly less power, and I'm assuming that's why this feature is
implemented for SATA disks.

Dan

Try FreeBSD and "camcontrol".

Cool. That's a neat utility. I feel like it outta be possible to
send some commands via /sys/bus/scsi/devices or something like that...
but it's just a hunch.

"camcontrol" IIRC can do this.

But, to send SCSI commands to (S)ATA drive in FreeBSD, you need a properly
built kernel - no direct ATA disk driver, but the SCSI-to-ATA bridge driver.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com

In comp.sys.ibm.pc.hardware.storage Dan Lenski wrote:
On Jun 2, 4:22 am, Dirk Munk wrote:
I don't agree on that. Don't forget that SATA drives are also used in
big (and very expensive) storage arrays for low performance high
capacity disk storage.

Right. I assume that's why this drive has the feature. I have heard
that some data centers use arrays of 2.5" disks since they consume
significantly less power, and I'm assuming that's why this feature is
implemented for SATA disks.

Actually 2.5" SATA drives are used as local disks in blade servers,
were space and power are at a premium. There are also high performance
2.5" disks that are unsuitable for laptops, but AFAIK they are
not available to ordinary customers, just to OEMs.

And yes, I believe you are correct that this is the reason
the feature is present. An other one is that 2.5" disks are
far better at starting fast than 3.5" disks, since on laptops this
is a typical way to save power.

Still, basically the BIOS manufacurers or customizers messed
up badly here.

Arno

In comp.sys.ibm.pc.hardware.storage Dan Lenski wrote:
[...]
I'd also like to poke the freakin' BIOS vendors with a clue stick and
tell them to support this feature... but that's probably a lost cause,
right?

Very likely. These people believe they know what they are doing, which
is the worst kind of incompetence.

Arno