Linux SATA S.M.A.R.T. and SLEEP?

Linux SATA S.M.A.R.T. and SLEEP?

[Justin Piszcz]

Under 2.6.13.2,

Is there any utility that I can use to put a SATA HDD to sleep?
Secondly, I notice I cannot access any of the HDD's S.M.A.R.T. functions 
on SATA drives?

Justin.

Re: Linux SATA S.M.A.R.T. and SLEEP?

[jmerkey]

Someone needs to fix SATA drive ordering in the kernel so it matches 
GRUBs ordering, or perhaps GRUB needs fixing. I have run into
several situation where hd0,hd1 are in reverse order from what is 
reported when the Intel PII drivers load from the kernel, making in
necessary to swap the two values in the grub config.

Jeff

Justin Piszcz wrote:

> I will have to give this a shot, any idea when it will be merged into 
> mainline?
>
> Thanks,
>
> Justin.
>
> On Thu, 29 Sep 2005, Nuno Silva wrote:
>
>> Justin Piszcz wrote:
>>
>>> Under 2.6.13.2,
>>>
>>> Is there any utility that I can use to put a SATA HDD to sleep?
>>> Secondly, I notice I cannot access any of the HDD's S.M.A.R.T. 
>>> functions on SATA drives?
>>
>>
>> Search for Jeff's patch 2.6.12-git4-passthru1.patch
>> I think this will be included RSN. This solves your two issues.
>>
>> Regards,
>> Nuno Silva
>>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

Re: Linux SATA S.M.A.R.T. and SLEEP?

[jmerkey]

Grant Coady wrote:

>On Thu, 29 Sep 2005 11:53:21 -0600, jmerkey <jmerkey@utah-nac.org> wrote:
>
>  
>
>>Someone needs to fix SATA drive ordering in the kernel so it matches 
>>GRUBs ordering, or perhaps GRUB needs fixing. I have run into
>>    
>>
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^
>User-space issue?  Four of the last five drives I buy are SATA, I 
>don't see this problem 'cos I use lilo :o)
>
>Cheers
>
>  
>
Seems to show up on FC2/3/4 installs on Piix motherboards. The drive 
parameters reported for /dev/sda, /dev/sdb are inverted based on the 
BIOS ordering of the SATA devices. It's more a BIOS issues I think. I 
have noted that IDE doesn't change the ordering, but the current Linux 
drivers do.

Jeff

Re: Linux SATA S.M.A.R.T. and SLEEP?

[Nuno Silva]

Justin Piszcz wrote:
> Under 2.6.13.2,
> 
> Is there any utility that I can use to put a SATA HDD to sleep?
> Secondly, I notice I cannot access any of the HDD's S.M.A.R.T. functions 
> on SATA drives?

Search for Jeff's patch 2.6.12-git4-passthru1.patch
I think this will be included RSN. This solves your two issues.

Regards,
Nuno Silva

Re: Linux SATA S.M.A.R.T. and SLEEP?

[Justin Piszcz]

I will have to give this a shot, any idea when it will be merged into 
mainline?

Thanks,

Justin.

On Thu, 29 Sep 2005, Nuno Silva wrote:

> Justin Piszcz wrote:
>> Under 2.6.13.2,
>> 
>> Is there any utility that I can use to put a SATA HDD to sleep?
>> Secondly, I notice I cannot access any of the HDD's S.M.A.R.T. functions on 
>> SATA drives?
>
> Search for Jeff's patch 2.6.12-git4-passthru1.patch
> I think this will be included RSN. This solves your two issues.
>
> Regards,
> Nuno Silva
>

Re: Linux SATA S.M.A.R.T. and SLEEP? -- was [PATCH libata-dev-2.6:passthru] passthru fixes

[John W. Linville]

Nuno Silva <nuno.silva@vgertech.com> wrote:
> Justin Piszcz wrote:
> >Under 2.6.13.2,
> >
> >Is there any utility that I can use to put a SATA HDD to sleep?
> >Secondly, I notice I cannot access any of the HDD's S.M.A.R.T. functions
> >on SATA drives?
> 
> Search for Jeff's patch 2.6.12-git4-passthru1.patch
> I think this will be included RSN. This solves your two issues.

You probably want this patch as well, at least the first hunk.
It fixes a potential memory leak that could cause lock-ups when using
hdparm or smartctl/smartd.

John
---
Fix a few problems seen with the passthru branch:

- leaked scsi_request on buffer allocate failure
- passthru sense routines were refering to tf->command
  which is not read in tf_read, instead use drv_stat for
  status register.
- passthru sense passed back to user on ata_task_ioctl

Patch is against the current libata-dev passthru branch.

Signed-off-by: Jeff Raubitschek <jhr@google.com>

diff --git a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c
--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -116,8 +116,10 @@ int ata_cmd_ioctl(struct scsi_device *sc
 	if (args[3]) {
 		argsize = SECTOR_SIZE * args[3];
 		argbuf = kmalloc(argsize, GFP_KERNEL);
-		if (argbuf == NULL)
-			return -ENOMEM;
+		if (argbuf == NULL) {
+			rc = -ENOMEM;
+			goto error;
+		}
 
 		scsi_cmd[1]  = (4 << 1); /* PIO Data-in */
 		scsi_cmd[2]  = 0x0e;     /* no off.line or cc, read from dev,
@@ -182,6 +184,7 @@ int ata_task_ioctl(struct scsi_device *s
 	u8 scsi_cmd[MAX_COMMAND_SIZE];
 	u8 args[7];
 	struct scsi_request *sreq;
+	unsigned char *sb;
 
 	if (NULL == (void *)arg)
 		return -EINVAL;
@@ -192,7 +195,7 @@ int ata_task_ioctl(struct scsi_device *s
 	memset(scsi_cmd, 0, sizeof(scsi_cmd));
 	scsi_cmd[0]  = ATA_16;
 	scsi_cmd[1]  = (3 << 1); /* Non-data */
-	/* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
+	scsi_cmd[2]  = 0x20; /* Always ask for sense data */
 	scsi_cmd[4]  = args[1];
 	scsi_cmd[6]  = args[2];
 	scsi_cmd[8]  = args[3];
@@ -211,15 +214,29 @@ int ata_task_ioctl(struct scsi_device *s
 	   from scsi_ioctl_send_command() for default case... */
 	scsi_wait_req(sreq, scsi_cmd, NULL, 0, (10*HZ), 5);
 
-	if (sreq->sr_result) {
+	sb = sreq->sr_sense_buffer;
+
+	/* Retrieve data from check condition */
+	if((sb[1] == NO_SENSE) && (sb[2] == 0) && (sb[3] == 0x1D)) {
+		unsigned char *desc= sb + 8;
+
+		args[0]=desc[13];
+		args[1]=desc[3];
+		args[2]=desc[5];
+		args[3]=desc[7];
+		args[4]=desc[9];
+		args[5]=desc[11];
+	} else if (sreq->sr_result) {
 		rc = -EIO;
 		goto error;
 	}
 
-	/* Need code to retrieve data from check condition? */
-
 error:
 	scsi_release_request(sreq);
+
+	if (rc == 0 && copy_to_user(arg, args, sizeof(args)))
+		return -EFAULT;
+
 	return rc;
 }
 
@@ -323,6 +340,7 @@ struct ata_queued_cmd *ata_scsi_qc_new(s
  *	ata_dump_status - user friendly display of error info
  *	@id: id of the port in question
  *	@tf: ptr to filled out taskfile
+ *	@stat: ATA command/status register
  *
  *	Decode and dump the ATA error/status registers for the user so
  *	that they have some idea what really happened at the non
@@ -331,9 +349,9 @@ struct ata_queued_cmd *ata_scsi_qc_new(s
  *	LOCKING:
  *	inherited from caller
  */
-void ata_dump_status(unsigned id, struct ata_taskfile *tf)
+void ata_dump_status(unsigned id, struct ata_taskfile *tf, u8 stat)
 {
-	u8 stat = tf->command, err = tf->feature;
+	u8 err = tf->feature;
 
 	printk(KERN_WARNING "ata%u: status=0x%02x { ", id, stat);
 	if (stat & ATA_BUSY) {
@@ -479,6 +497,7 @@ void ata_to_sense_error(unsigned id, u8 
 /*
  *	ata_gen_ata_desc_sense - Generate check condition sense block.
  *	@qc: Command that completed.
+ *	@stat: ATA status register
  *
  *	This function is specific to the ATA descriptor format sense
  *	block specified for the ATA pass through commands.  Regardless
@@ -489,7 +508,7 @@ void ata_to_sense_error(unsigned id, u8 
  *	LOCKING:
  *	spin_lock_irqsave(host_set lock)
  */
-void ata_gen_ata_desc_sense(struct ata_queued_cmd *qc)
+void ata_gen_ata_desc_sense(struct ata_queued_cmd *qc, u8 stat)
 {
 	struct scsi_cmnd *cmd = qc->scsicmd;
 	struct ata_taskfile *tf = &qc->tf;
@@ -510,10 +529,15 @@ void ata_gen_ata_desc_sense(struct ata_q
 	 * Use ata_to_sense_error() to map status register bits
 	 * onto sense key, asc & ascq.
 	 */
-	if (unlikely(tf->command & (ATA_BUSY | ATA_DF | ATA_ERR | ATA_DRQ))) {
+	if (unlikely(stat & (ATA_BUSY | ATA_DF | ATA_ERR | ATA_DRQ))) {
 		ata_to_sense_error(qc->ap->id, tf->command, tf->feature,
 				   &sb[1], &sb[2], &sb[3]);
 		sb[1] &= 0x0f;
+	} else {
+		/* ATA PASS THROUGH INFORMATION AVAILABLE */
+		sb[1] = NO_SENSE;
+		sb[2] = 0;
+		sb[3] = 0x1D;
 	}
 
 	/*
@@ -540,7 +564,7 @@ void ata_gen_ata_desc_sense(struct ata_q
 	desc[9] = tf->lbam;
 	desc[11] = tf->lbah;
 	desc[12] = tf->device;
-	desc[13] = tf->command; /* == status reg */
+	desc[13] = stat;
 
 	/*
 	 * Fill in Extend bit, and the high order bytes
@@ -558,6 +582,7 @@ void ata_gen_ata_desc_sense(struct ata_q
 /**
  *	ata_gen_fixed_sense - generate a SCSI fixed sense block
  *	@qc: Command that we are erroring out
+ *	@stat: ATA status register
  *
  *	Leverage ata_to_sense_error() to give us the codes.  Fit our
  *	LBA in here if there's room.
@@ -565,7 +590,7 @@ void ata_gen_ata_desc_sense(struct ata_q
  *	LOCKING:
  *	inherited from caller
  */
-void ata_gen_fixed_sense(struct ata_queued_cmd *qc)
+void ata_gen_fixed_sense(struct ata_queued_cmd *qc, u8 stat)
 {
 	struct scsi_cmnd *cmd = qc->scsicmd;
 	struct ata_taskfile *tf = &qc->tf;
@@ -585,7 +610,7 @@ void ata_gen_fixed_sense(struct ata_queu
 	 * Use ata_to_sense_error() to map status register bits
 	 * onto sense key, asc & ascq.
 	 */
-	if (unlikely(tf->command & (ATA_BUSY | ATA_DF | ATA_ERR | ATA_DRQ))) {
+	if (unlikely(stat & (ATA_BUSY | ATA_DF | ATA_ERR | ATA_DRQ))) {
 		ata_to_sense_error(qc->ap->id, tf->command, tf->feature,
 				   &sb[2], &sb[12], &sb[13]);
 		sb[2] &= 0x0f;
@@ -998,7 +1023,7 @@ static int ata_scsi_qc_complete(struct a
 	 */
 	if (((cmd->cmnd[0] == ATA_16) || (cmd->cmnd[0] == ATA_12)) &&
  	    ((cmd->cmnd[2] & 0x20) || need_sense)) {
- 		ata_gen_ata_desc_sense(qc);
+ 		ata_gen_ata_desc_sense(qc, drv_stat);
 	} else {
 		if (!need_sense) {
 			cmd->result = SAM_STAT_GOOD;
@@ -1009,13 +1034,13 @@ static int ata_scsi_qc_complete(struct a
 			 * good for smaller LBA (and maybe CHS?)
 			 * devices.
 			 */
-			ata_gen_fixed_sense(qc);
+			ata_gen_fixed_sense(qc, drv_stat);
 		}
 	}
 
 	if (need_sense) {
 		/* The ata_gen_..._sense routines fill in tf */
-		ata_dump_status(qc->ap->id, &qc->tf);
+		ata_dump_status(qc->ap->id, &qc->tf, drv_stat);
 	}
 
 	qc->scsidone(cmd);
-- 
John W. Linville
linville@tuxdriver.com

Re: Linux SATA S.M.A.R.T. and SLEEP?

[Bill Davidsen]

Nuno Silva wrote:
> Justin Piszcz wrote:
> 
>> Under 2.6.13.2,
>>
>> Is there any utility that I can use to put a SATA HDD to sleep?
>> Secondly, I notice I cannot access any of the HDD's S.M.A.R.T. 
>> functions on SATA drives?
> 
> 
> Search for Jeff's patch 2.6.12-git4-passthru1.patch
> I think this will be included RSN. This solves your two issues.

Thank you for mentioning this, it makes using SATA drives in production 
look more appealing. I like to be proactive on drive health and check it 
regularly.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux SATA S.M.A.R.T. and SLEEP?

[Grant Coady]

On Thu, 29 Sep 2005 11:53:21 -0600, jmerkey <jmerkey@utah-nac.org> wrote:

>
>Someone needs to fix SATA drive ordering in the kernel so it matches 
>GRUBs ordering, or perhaps GRUB needs fixing. I have run into
                    ^^^^^^^^^^^^^^^^^^^^^^^^^
User-space issue?  Four of the last five drives I buy are SATA, I 
don't see this problem 'cos I use lilo :o)

Cheers

Re: Linux SATA S.M.A.R.T. and SLEEP? -- was [PATCH libata-dev-2.6:passthru] passthru fixes

[Mark Lord]

John W. Linville wrote:
> You probably want this patch as well, at least the first hunk.
> It fixes a potential memory leak that could cause lock-ups when using
> hdparm or smartctl/smartd.
> 
> John
> ---
> Fix a few problems seen with the passthru branch:
> 
> - leaked scsi_request on buffer allocate failure
> - passthru sense routines were refering to tf->command
>   which is not read in tf_read, instead use drv_stat for
>   status register.
> - passthru sense passed back to user on ata_task_ioctl
> 
> Patch is against the current libata-dev passthru branch.
> 
> Signed-off-by: Jeff Raubitschek <jhr@google.com>
...

When I tried that patch recently, smartctl stopped working.
Reverted.  Works again.

??

Re: Linux SATA S.M.A.R.T. and SLEEP? -- was [PATCH libata-dev-2.6:passthru] passthru fixes

[John W. Linville]

On Thu, Sep 29, 2005 at 05:53:37PM -0400, Mark Lord wrote:
> John W. Linville wrote:
> >You probably want this patch as well, at least the first hunk.
> >It fixes a potential memory leak that could cause lock-ups when using
> >hdparm or smartctl/smartd.
> >
> >John
> >---
> >Fix a few problems seen with the passthru branch:
> >
> >- leaked scsi_request on buffer allocate failure
> >- passthru sense routines were refering to tf->command
> >  which is not read in tf_read, instead use drv_stat for
> >  status register.
> >- passthru sense passed back to user on ata_task_ioctl
> >
> >Patch is against the current libata-dev passthru branch.
> >
> >Signed-off-by: Jeff Raubitschek <jhr@google.com>
> ...
> 
> When I tried that patch recently, smartctl stopped working.
> Reverted.  Works again.
> 
> ??

Interesting...well, take the first hunk and ignore the rest...

Hey, I didn' write it... :-)

John
-- 
John W. Linville
linville@tuxdriver.com

Re: Linux SATA S.M.A.R.T. and SLEEP?

[Alistair John Strachan]

On Thursday 29 September 2005 19:19, jmerkey wrote:
> Grant Coady wrote:
> >On Thu, 29 Sep 2005 11:53:21 -0600, jmerkey <jmerkey@utah-nac.org> wrote:
> >>Someone needs to fix SATA drive ordering in the kernel so it matches
> >>GRUBs ordering, or perhaps GRUB needs fixing. I have run into
> >
> >                    ^^^^^^^^^^^^^^^^^^^^^^^^^
> >User-space issue?  Four of the last five drives I buy are SATA, I
> >don't see this problem 'cos I use lilo :o)
> >
> >Cheers
>
> Seems to show up on FC2/3/4 installs on Piix motherboards. The drive
> parameters reported for /dev/sda, /dev/sdb are inverted based on the
> BIOS ordering of the SATA devices. It's more a BIOS issues I think. I
> have noted that IDE doesn't change the ordering, but the current Linux
> drivers do.

It's a BIOS issue. I had problems on my MSI nForce3 mainboard because when you 
select the "bootable SATA harddrive", it swaps round the ports so that the 
one you selected is hd0, and the others follow. I couldn't fix it, so in the 
end I just installed grub on both HDs separately, then use the BIOS toggle to 
switch between them.

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Linux SATA S.M.A.R.T. and SLEEP?

[Etienne Lorrain]

Grant Coady wrote:
> jmerkey wrote:
> >Someone needs to fix SATA drive ordering in the kernel so it matches 
> >GRUBs ordering, or perhaps GRUB needs fixing. I have run into
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^
> User-space issue?  Four of the last five drives I buy are SATA, I 
> don't see this problem 'cos I use lilo :o)

  Lilo is not the only bootloader which do not make random assumptions
 on the order of the drives - you should also try Gujin...
http://gujin.org

  Etienne.


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: Linux SATA S.M.A.R.T. and SLEEP?

[Bill Davidsen]

jmerkey wrote:
> 
> Someone needs to fix SATA drive ordering in the kernel so it matches 
> GRUBs ordering, or perhaps GRUB needs fixing. I have run into
> several situation where hd0,hd1 are in reverse order from what is 
> reported when the Intel PII drivers load from the kernel, making in
> necessary to swap the two values in the grub config.

There's more to it than that. With PATA drives I see issues with order 
as well, and they date back to the Redhat 7.x days, where the install 
chose one order for the scsi drivers and the boot chose another. With 
IDE the order in which drivers are loaded affects the drive naming.

It would be great to have some way to match drives with names, but there 
doesn't seem to be a single solution for PATA, SATA, SCSI and hotplug. 
Something like mounts using UUID of the filesystem, but for the drives.

I do use pluggable drives for backup, load modules for various 
controllers on demand, etc, so I'm aware that the most reliable 
solutions seem to involve either reduced flexibility, human intervention 
at boot, or both.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux SATA S.M.A.R.T. and SLEEP?

[Mark Lord]

Bill Davidsen wrote:
>
> It would be great to have some way to match drives with names, but there 
> doesn't seem to be a single solution for PATA, SATA, SCSI and hotplug. 
> Something like mounts using UUID of the filesystem, but for the drives.

I believe it would be pretty easy for userspace hotplug scripts
(udev and pals) to assign drives names by matching model/serialno,
if that's what you had in mind.

cheers

Re: Linux SATA S.M.A.R.T. and SLEEP?

[Bill Davidsen]

Mark Lord wrote:
> Bill Davidsen wrote:
> 
>>
>> It would be great to have some way to match drives with names, but 
>> there doesn't seem to be a single solution for PATA, SATA, SCSI and 
>> hotplug. Something like mounts using UUID of the filesystem, but for 
>> the drives.
> 
> 
> I believe it would be pretty easy for userspace hotplug scripts
> (udev and pals) to assign drives names by matching model/serialno,
> if that's what you had in mind.

That's the functionality I have in mind, the problem is finding the 
model and serial number info for all the various types. In some "really 
works" plug and play world there would be software to generate something 
like the UUID, and a nice table of what to call it. That doesn't quite 
seem to be the case yet, and it makes life a bit dificult if you need 
raw partitions on plugable devices.

Not impossible, but PITA right now. Anyone looking for a topic for their 
thesis? ;-)
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux SATA S.M.A.R.T. and SLEEP?

[jmerkey]

Bill Davidsen wrote:

> jmerkey wrote:
>
>>
>> Someone needs to fix SATA drive ordering in the kernel so it matches 
>> GRUBs ordering, or perhaps GRUB needs fixing. I have run into
>> several situation where hd0,hd1 are in reverse order from what is 
>> reported when the Intel PII drivers load from the kernel, making in
>> necessary to swap the two values in the grub config.
>
>
> There's more to it than that. With PATA drives I see issues with order 
> as well, and they date back to the Redhat 7.x days, where the install 
> chose one order for the scsi drivers and the boot chose another. With 
> IDE the order in which drivers are loaded affects the drive naming.
>
> It would be great to have some way to match drives with names, but 
> there doesn't seem to be a single solution for PATA, SATA, SCSI and 
> hotplug. Something like mounts using UUID of the filesystem, but for 
> the drives.
>
> I do use pluggable drives for backup, load modules for various 
> controllers on demand, etc, so I'm aware that the most reliable 
> solutions seem to involve either reduced flexibility, human 
> intervention at boot, or both.

Have the IDE and SATA driver layer check the BIOS ordering and preserve 
it during registration of the IDE and SATA devices for boot.

Jeff