SATA Shutdown issue confuses (sda)

SATA Shutdown issue confuses (sda)

[Dark Sylinc]

Hi,
I have compiled my own 2.6.23 kernel for a friend, and
worried to find out that his SATA disk reports the
shutdown warning: http://linux-ata.org/shutdown.html

I've digged into Debian's sysvinit 2.86.1 src and I
got confused:

1) Like Scott James Remnant, Ubuntu's Development
Manager
(http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06595.html)
said, in Debian (actually he referred to Ubuntu, but
looking at the code they make the same thing) shutdown
iterates through all /dev/hd* files and shuts them
down. So, if I'm right, sda (the node file for my
friend's PC) is leaved untouch. Why is the warning
appearing then? It is supposed that SATA drives not
using the /dev/hd* convention shouldn't be stopped by
shutdown.

2) The kernel Flushes cache and puts in stand-by-now
since 2.6.22 This can cause (if it was already
stopped) the disk to spin up and then down. So....
anyway the disk should spun down propperly before
power down, it might be done twice, but none of them
would be an emergency shut down. I think I'm missing
something... or otherwise there is no problem at all

3) What's the proposed solution after all??? Shutdown
should flush cache AND stop the SATA? or shutdown
shouldn't do anything?
You seem to be in favor of "not doing anything" but
I'm also concerned that Kernel's prior to 2.6.22 would
be negative affected by this solution.

4) What everyone in forums is asking... are they SATA
drives being forced from long time ago, and they have
just found out by using the new kernel? That remains
unclear.

5) At least on my friend's SATA, the "clack" sounds
like 2 or 3 seconds before power downs, but it sounds
slightly (and really slightly) different to the
Window's shutdown "clack". Does this means that his
drive is safe? Or is it possible for software to power
down just the HDD without stopping the heads???

5b)I've compiled the kernel without the "Asynchronous
SCSI scanning" flag (SCSI_SCAN_ASYNC). Does it have
something to do that the kernel seems to be waiting
for the SCSI to stop before powering down?

6) If I'm not mistaken, in hdddown.c (debian's
sysvinit code
http://packages.debian.org/etch/sysvinit) in line 67
we should change
static int do_standby_idedisk(char *device)
{
#ifndef WIN_STANDBYNOW1
#define WIN_STANDBYNOW1 0xE0
#endif
#ifndef WIN_STANDBYNOW2
#define WIN_STANDBYNOW2 0x94
#endif
	unsigned char args1[4] = {WIN_STANDBYNOW1,0,0,0};
	unsigned char args2[4] = {WIN_STANDBYNOW2,0,0,0};
	int fd;

	if ((fd = open(device, O_RDWR)) < 0)
		return -1;

	if (ioctl(fd, HDIO_DRIVE_CMD, &args1) &&
	    ioctl(fd, HDIO_DRIVE_CMD, &args2))
		return -1;

	return 0;
}

By:

static int do_standby_idedisk(char *device)
{
#ifndef WIN_STANDBYNOW1
#define WIN_STANDBYNOW1 0xE0
#endif
#ifndef WIN_STANDBYNOW2
#define WIN_STANDBYNOW2 0x94
#endif
#ifndef WIN_FLUSHCACHE
#define WIN_FLUSHCACHE 0xE7
#endif
	unsigned char args0[4] = {WIN_FLUSHCACHE,0,0,0};
	unsigned char args1[4] = {WIN_STANDBYNOW1,0,0,0};
	unsigned char args2[4] = {WIN_STANDBYNOW2,0,0,0};
	int fd;

	if ((fd = open(device, O_RDWR)) < 0)
		return -1;

	if (ioctl(fd, HDIO_DRIVE_CMD, &args0) &&
	    ioctl(fd, HDIO_DRIVE_CMD, &args1) &&
	    ioctl(fd, HDIO_DRIVE_CMD, &args2))
		return -1;

	return 0;
}

Right?
Am I missing something?

This email is long but I take HDD potential issues
very seriously.

Thanks
Dark Sylinc

PS: I'm not a distro mantainer. But I'm concerned
about my friend's SATA, and if we can get to a
solution, I would be glad to report the patch to the
Debian Community


      Los referentes más importantes en compra/ venta de autos se juntaron:
Demotores y Yahoo!
Ahora comprar o vender tu auto es más fácil. Vistá ar.autos.yahoo.com/

Re: SATA Shutdown issue confuses (sda)

[Tejun Heo]

[cc'ing Henrique.]

Hello,

Dark Sylinc wrote:
> 1) Like Scott James Remnant, Ubuntu's Development
> Manager
> (http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06595.html)
> said, in Debian (actually he referred to Ubuntu, but
> looking at the code they make the same thing) shutdown
> iterates through all /dev/hd* files and shuts them
> down. So, if I'm right, sda (the node file for my
> friend's PC) is leaved untouch. Why is the warning
> appearing then? It is supposed that SATA drives not
> using the /dev/hd* convention shouldn't be stopped by
> shutdown.

Don't have any debian around but apparently it's issuing spin down for
/dev/sdX's too.

> 2) The kernel Flushes cache and puts in stand-by-now
> since 2.6.22 This can cause (if it was already
> stopped) the disk to spin up and then down. So....
> anyway the disk should spun down propperly before
> power down, it might be done twice, but none of them
> would be an emergency shut down. I think I'm missing
> something... or otherwise there is no problem at all

Well, double spin-down doesn't sound too good and as introducing double
spin down would be a kernel regression kernel doesn't issue spin-down if
it's already spun down.  This is usually okay but some rare drives spin
up on FLUSH_CACHE even if the cache is empty which leads to emergency
spin down.  The warning message is for such cases.

> 3) What's the proposed solution after all??? Shutdown
> should flush cache AND stop the SATA? or shutdown
> shouldn't do anything?
> You seem to be in favor of "not doing anything" but
> I'm also concerned that Kernel's prior to 2.6.22 would
> be negative affected by this solution.

Shutdown doesn't need to do anything for later kernels.  For older ones,
it should continue to issue FLUSH_CACHE and STANDBYNOW1.  The presence
of manage_start_stop sysfs node can be used to tell which action to take.

> 4) What everyone in forums is asking... are they SATA
> drives being forced from long time ago, and they have
> just found out by using the new kernel? That remains
> unclear.

I don't really get the question here.  Can you please elaborate?

> 5) At least on my friend's SATA, the "clack" sounds
> like 2 or 3 seconds before power downs, but it sounds
> slightly (and really slightly) different to the
> Window's shutdown "clack". Does this means that his
> drive is safe? Or is it possible for software to power
> down just the HDD without stopping the heads???

Sure way to tell is to look at emergency unload count int the output of
'smartctl -a'.  Basically, it should identical to 'hdparm -y'.

> 5b)I've compiled the kernel without the "Asynchronous
> SCSI scanning" flag (SCSI_SCAN_ASYNC). Does it have
> something to do that the kernel seems to be waiting
> for the SCSI to stop before powering down?

Nope.

> 6) If I'm not mistaken, in hdddown.c (debian's
> sysvinit code
> http://packages.debian.org/etch/sysvinit) in line 67
> we should change
> static int do_standby_idedisk(char *device)
> {
> #ifndef WIN_STANDBYNOW1
> #define WIN_STANDBYNOW1 0xE0
> #endif
> #ifndef WIN_STANDBYNOW2
> #define WIN_STANDBYNOW2 0x94
> #endif
> 	unsigned char args1[4] = {WIN_STANDBYNOW1,0,0,0};
> 	unsigned char args2[4] = {WIN_STANDBYNOW2,0,0,0};
> 	int fd;
> 
> 	if ((fd = open(device, O_RDWR)) < 0)
> 		return -1;
> 
> 	if (ioctl(fd, HDIO_DRIVE_CMD, &args1) &&
> 	    ioctl(fd, HDIO_DRIVE_CMD, &args2))
> 		return -1;
> 
> 	return 0;
> }
> 
> By:
> 
> static int do_standby_idedisk(char *device)
> {
> #ifndef WIN_STANDBYNOW1
> #define WIN_STANDBYNOW1 0xE0
> #endif
> #ifndef WIN_STANDBYNOW2
> #define WIN_STANDBYNOW2 0x94
> #endif
> #ifndef WIN_FLUSHCACHE
> #define WIN_FLUSHCACHE 0xE7
> #endif
> 	unsigned char args0[4] = {WIN_FLUSHCACHE,0,0,0};
> 	unsigned char args1[4] = {WIN_STANDBYNOW1,0,0,0};
> 	unsigned char args2[4] = {WIN_STANDBYNOW2,0,0,0};
> 	int fd;
> 
> 	if ((fd = open(device, O_RDWR)) < 0)
> 		return -1;
> 
> 	if (ioctl(fd, HDIO_DRIVE_CMD, &args0) &&
> 	    ioctl(fd, HDIO_DRIVE_CMD, &args1) &&
> 	    ioctl(fd, HDIO_DRIVE_CMD, &args2))
> 		return -1;
> 
> 	return 0;
> }

Opcode 0x94 is retired now and it's probably not too good a idea to
issue it to modern disks.  0xE0 should be good enough and yes you
definitely need to issue FLUSH before spinning down the disk.

The code needs to be a tad bit more complex.  It needs to check
manage_start_stop presence and skip any action if it's there.

> PS: I'm not a distro mantainer. But I'm concerned
> about my friend's SATA, and if we can get to a
> solution, I would be glad to report the patch to the
> Debian Community

ISTR this was resolved somehow and somebody was about to write how to
deal with this for debian.  Henrique, do you recall anything?  Did I
drop the ball again?

Thanks.

-- 
tejun

Re: SATA Shutdown issue confuses (sda)

[Dark Sylinc]

Thanks for the quick reply
Actually I managed to fix the issue by using the
patches here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436703
After using that patch, no more "clack"

> Don't have any debian around but apparently it's
> issuing spin down for
> /dev/sdX's too.

The patch still doesn't solve the missing flush-cache,
however after seeing the code, seems that the origin
of the problem was that shutdown was NOT issuing spin
down at all (for sdX).

> > 4) What everyone in forums is asking... are they
> SATA
> > drives being forced from long time ago, and they
> have
> > just found out by using the new kernel? That
> remains
> > unclear.
> 
> I don't really get the question here.  Can you
> please elaborate?

Some people around the net is concerned about their
SATA drives. They're wondering if before kernel 2.6.22
their SATA HDDs were making emergency shutdowns and
didn't realize that they weren't normal shutdowns. And
they may have been using Linux in their SATAs from a
long time ago, just to realize now (thanks to the new
K2.6.22 warning) that they were damaging their HDDs
since years.
In summary: the emergency shutdowns issue appeared in
K2.6.22, and using previous kernels fixes it, or the
emergenct shutdown happens in any kernel version??
I can't answer that question by myself, because I've
just installed Linux in this HDD and upgraded
immediately.

> Sure way to tell is to look at emergency unload
> count int the output of
> 'smartctl -a'.  Basically, it should identical to
> 'hdparm -y'.

Thanks, but the idea that software can do such thing
gives me the creeps.


> Opcode 0x94 is retired now and it's probably not too
> good a idea to
> issue it to modern disks.  0xE0 should be good
> enough

Don't blame me, it's in Debian's src. I'm not an HDD
expert. :D

> and yes you
> definitely need to issue FLUSH before spinning down
> the disk.

Seems missing both in the official src and in the
patch provided...
May be I can submit a patch...
However the patch I'm using doesn't trigger FLUSH but
the problem is solved anyway.

Thanks again
Dark Sylinc


      Compartí video en la ventana de tus mensajes (y también tus fotos de Flickr). 
Usá el nuevo Yahoo! Messenger versión Beta. http://ar.beta.messenger.yahoo.com/

Re: SATA Shutdown issue confuses (sda)

[Tejun Heo]

Dark Sylinc wrote:
> Some people around the net is concerned about their
> SATA drives. They're wondering if before kernel 2.6.22
> their SATA HDDs were making emergency shutdowns and
> didn't realize that they weren't normal shutdowns. And
> they may have been using Linux in their SATAs from a
> long time ago, just to realize now (thanks to the new
> K2.6.22 warning) that they were damaging their HDDs
> since years.
> In summary: the emergency shutdowns issue appeared in
> K2.6.22, and using previous kernels fixes it, or the
> emergenct shutdown happens in any kernel version??
> I can't answer that question by myself, because I've
> just installed Linux in this HDD and upgraded
> immediately.

It depends on your distro.  If the distro issues spin down on shutdown,
things should have been fine beofre 2.6.22 but it it doesn't, disks
attached via libata would do emergency unload on power off.  Also small
fraction of disks which spin up to do FLUSH_CACHE issued by kernel would
do double spin down where the last one is emergency if the distro
shutdown issues spin down.

2.6.22 fixes the problem completely for distros which don't issue spin
down.  For distros which do issue spin down, the situation isn't worse,
the kernel behaves the same way as before 2.6.22.  It just issues
FLUSH_CACHE.  The warning message is for small fraction of disks
mentioned above which do double spin down and to accelerate transition
to kernel-driven spin down.

>> Sure way to tell is to look at emergency unload
>> count int the output of
>> 'smartctl -a'.  Basically, it should identical to
>> 'hdparm -y'.
> 
> Thanks, but the idea that software can do such thing
> gives me the creeps.

Oh well, it can, apparently.  :-)

>> and yes you
>> definitely need to issue FLUSH before spinning down
>> the disk.
> 
> Seems missing both in the official src and in the
> patch provided...
> May be I can submit a patch...
> However the patch I'm using doesn't trigger FLUSH but
> the problem is solved anyway.

So, the patch isn't in the package yet?

-- 
tejun

Re: SATA Shutdown issue confuses (sda)

[Dark Sylinc]

Hi,

> 2.6.22 fixes the problem completely for distros
> which don't issue spin
> down.  For distros which do issue spin down, the
> situation isn't worse,
> the kernel behaves the same way as before 2.6.22. 
> It just issues
> FLUSH_CACHE.  The warning message is for small
> fraction of disks
> mentioned above which do double spin down and to
> accelerate transition
> to kernel-driven spin down.

What you're telling me contradicts my experience.
I'm using Debian Etch with my custom kernel 2.6.23
After seeing debian's code, shutdown does NOT issue
spin down in my friend's pc. The clack sounds, and the
warning appears.
Using patched code, I don't have any more clacks and
warnings. After seeing the altered code, shutdown now
IS spinning down the sda.
However none of them is flushing the cache as you
suggests.

So you're saying:
1) Don't spin down to avoid the problem
2) Flush cache solves the problem

I'm seeing:
1) The hdd is not spun down by shutdown and the
problem persists
2) By spinning down /dev/sdX in shutdown(8) the
problem disappears. Flush cache doesn't seem to
influence the emergency shutdown problem.

That's why I'm confused.
May be I've missed something in the code.

> So, the patch isn't in the package yet?

I checked yesterday both Debian's unstable and
testing, and the patch wasn't there.

Dark Sylinc


      Compartí video en la ventana de tus mensajes (y también tus fotos de Flickr). 
Usá el nuevo Yahoo! Messenger versión Beta. http://ar.beta.messenger.yahoo.com/

Re: SATA Shutdown issue confuses (sda)

[Tejun Heo]

Dark Sylinc wrote:
> So you're saying:
> 1) Don't spin down to avoid the problem

Yes.

> 2) Flush cache solves the problem

No.

> I'm seeing:
> 1) The hdd is not spun down by shutdown and the
> problem persists
> 2) By spinning down /dev/sdX in shutdown(8) the
> problem disappears. Flush cache doesn't seem to
> influence the emergency shutdown problem.
> 
> That's why I'm confused.
> May be I've missed something in the code.

If I and you are looking at the same patch, you're misreading the
patch.  From the patch description...

 I'm attaching a patch that fixes it. It basically follows
 http://linux-ata.org/shutdown.html and *SKIPS* the drive shutdown when
 the respective /sys/block/sdX/device/scsi_disk:*/manage_start_stop
 exists (leaving it for the kernel to do).

>> So, the patch isn't in the package yet?
> 
> I checked yesterday both Debian's unstable and
> testing, and the patch wasn't there.

Eeeeekk....

-- 
tejun

Re: SATA Shutdown issue confuses (sda)

[Dark Sylinc]

>  I'm attaching a patch that fixes it. It basically
> follows
>  http://linux-ata.org/shutdown.html and *SKIPS* the
> drive shutdown when
>  the respective
> /sys/block/sdX/device/scsi_disk:*/manage_start_stop
>  exists (leaving it for the kernel to do).
> 

eeeehhh, I'm ashamed :$ . Now everything makes sense.
Thanks

> >> So, the patch isn't in the package yet?
> > 
> > I checked yesterday both Debian's unstable and
> > testing, and the patch wasn't there.
> 
> Eeeeekk....

Dark Sylinc


      Los referentes más importantes en compra/ venta de autos se juntaron:
Demotores y Yahoo!
Ahora comprar o vender tu auto es más fácil. Vistá ar.autos.yahoo.com/