Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Bodo Eggert]

Clemens Koller <clemens.koller@anagramm.de> wrote:

> Well, sure, it's not a notebook HDD, but maybe it's possible
> to give headpark a more generic way to get the heads parked?

I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
which the park command would seek. Maybe you could do something similar
and park the head on the last cylinder if the other options fail.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: IBM HDAPS things are looking up

[Alejandro Bonilla]

Bodo Eggert wrote:

>Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>  
>
>>Well, sure, it's not a notebook HDD, but maybe it's possible
>>to give headpark a more generic way to get the heads parked?
>>    
>>
>
>I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
>which the park command would seek. Maybe you could do something similar
>and park the head on the last cylinder if the other options fail.
>  
>
This makes me wonder... If you replace the internal HD with a non IBM or 
IBM supported Hard Drive, will it still park the head and will it 
support all the stuff?

.Alejandro

Re: IBM HDAPS things are looking up

[Jens Axboe]

On Thu, Jul 07 2005, Alejandro Bonilla wrote:
> Bodo Eggert wrote:
> 
> >Clemens Koller <clemens.koller@anagramm.de> wrote:
> >
> > 
> >
> >>Well, sure, it's not a notebook HDD, but maybe it's possible
> >>to give headpark a more generic way to get the heads parked?
> >>   
> >>
> >
> >I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
> >which the park command would seek. Maybe you could do something similar
> >and park the head on the last cylinder if the other options fail.
> > 
> >
> This makes me wonder... If you replace the internal HD with a non IBM or 
> IBM supported Hard Drive, will it still park the head and will it 
> support all the stuff?

Depends, the drive must support the IDLE_IMMEDIATE unload subfeature, as
described in ata7.

-- 
Jens Axboe

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jens Axboe]

On Fri, Jul 08 2005, Bodo Eggert wrote:
> Clemens Koller <clemens.koller@anagramm.de> wrote:
> 
> > Well, sure, it's not a notebook HDD, but maybe it's possible
> > to give headpark a more generic way to get the heads parked?
> 
> I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
> which the park command would seek. Maybe you could do something similar
> and park the head on the last cylinder if the other options fail.

Yeah, in ancient times you would simply issue a SEEK to the landing zone
and the drive would park. Those days are long gone.

The SEEK is just a hint anyways, with the sophisticated caching that
drives do today I wouldn't rely on it doing anything reliable.

-- 
Jens Axboe

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Vojtech Pavlik]

On Fri, Jul 08, 2005 at 02:56:08AM +0200, Bodo Eggert wrote:

> Clemens Koller <clemens.koller@anagramm.de> wrote:
> 
> > Well, sure, it's not a notebook HDD, but maybe it's possible
> > to give headpark a more generic way to get the heads parked?
> 
> I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
> which the park command would seek. Maybe you could do something similar
> and park the head on the last cylinder if the other options fail.
 
This is not really a good idea. It worked for the old drives, because
you weren't supposed to move them around.

The shock when the machine hits the ground will cause the head to move
anyway and bounce across the whole surface.

Real parking makes a click because the head is moved outside the surface
and locked in that position.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jesper Juhl]

On 7/3/05, Alejandro Bonilla <abonilla@linuxwireless.org> wrote:
> 
> BTW, we are on irc.freenode.org in #hdaps If anyone is interested.
> 
> .Alejandro
> 
I just had a nice chat with the guys there and we got some
improvements made by them and us merged up. And I /think/ we agreed
that I'll maintain the driver, merge fixes/features etc and eventually
try to get it merged.

Currently the driver loads, initializes the accelerometer and we can
read data from it.
I'll be working on adding sysfs stuff to it tomorrow so it's generally
useful (at least for monitoring things - not yet for parking disk
heads).
Once I've got the sysfs stuff sorted I'll publish a new version.

The most recent version of the driver is currently at
http://lemonshop.dk/ibm_hpaps/ (note: this is most likely not going to
be the permanent home of this driver, but it's where it lives for
now).

Patches are welcome at jesper.juhl@gmail.com


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Lenz Grimmer]

[-- Attachment #1: Type: text/plain, Size: 3615 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jesper,

Jesper Juhl wrote:

> I just had a nice chat with the guys there and we got some
> improvements made by them and us merged up. And I /think/ we agreed
> that I'll maintain the driver, merge fixes/features etc and eventually
> try to get it merged.

Thanks a ton! I am really excited to see that you guys made so much
progress over the past few days! Of course, I immediately had to give it
a try :)

> Currently the driver loads, initializes the accelerometer and we can
> read data from it.

And here is a first support request - the kernel module does not load
for me :(

I have a Thinkpad T42, running SUSE Linux 9.3 (Kernel 2.6.11 with SUSE
patches). The APS works on Windows, so I know the accelerometer is there.

I have downloaded the sources from your site mentioned below, ran "make"
and "make install". Then I created the /dev/hdaps0 device node by
running "mknod hdaps0 c 228 0". (I picked this out of another message in
the discussion)

However, running "modprobe ibm_hdaps" only yields an error:

FATAL: Error inserting ibm_hdaps
(/lib/modules/2.6.11.4-21.7-default/kernel/drivers/misc/ibm_hdaps.ko):
No such device or address

In /var/log/messages, I only see:

Jul  4 07:17:20 metis kernel: ibm_hdaps: unsupported module, tainting
kernel.
Jul  4 07:17:20 metis kernel: init 1 50239260

(The last number differs every time I load the module)
Passing "debug=1" did not really reveal any more info. How could I
provide you with more detail?

I also tried to load Henrik's module, but it also spits out an error
"failed to allocate I/O", then a long number of "latch_check" lines and
"initialize() ret: -5".

Maybe the accelerometer on the T42 uses a different port range? Or could
it be that some other kernel module is blocking this I/O range? I have
no clue...

> I'll be working on adding sysfs stuff to it tomorrow so it's generally
> useful (at least for monitoring things - not yet for parking disk
> heads).

Maybe there is some kind of all-purpose ATA command that instructs the
disk drive to park the heads? Jens, could you give us a hint on how a
userspace application would do that?

> Once I've got the sysfs stuff sorted I'll publish a new version.
> 
> The most recent version of the driver is currently at
> http://lemonshop.dk/ibm_hpaps/ (note: this is most likely not going to
> be the permanent home of this driver, but it's where it lives for
> now).

Should we try to move the sources over to the hdaps.sf.net CVS tree?
Even though I am more a Subversion fan, having at least some kind of
version control would make it easier for others to participate and make
sure we can send patches against the latest version.

> Patches are welcome at jesper.juhl@gmail.com

Attached please find a diff against ibm_hdaps.c I found on the URL above
- - I moved some stuff to a separate header file (attached) and added
printing out the driver name and copyright during module initialization
(taken from Henrik's files). I also added an "uninstall" target to the
Makefile.

I hope you find it useful!

Bye,
	LenZ
- --
- ------------------------------------------------------------------
 Lenz Grimmer <lenz@grimmer.com>                             -o)
 [ICQ: 160767607 | Jabber: LenZGr@jabber.org]                /\\
 http://www.lenzg.org/                                       V_V
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCyNBpSVDhKrJykfIRAmLjAJwI1xaQEeW98M4yLVema2u+b9gX9wCfSufx
BuNm1Kcfk48FAn1e3pMa27M=
=yy24
-----END PGP SIGNATURE-----

[-- Attachment #2: ibm_hdaps.diff --]
[-- Type: text/x-patch, Size: 2133 bytes --]

--- ibm_hdaps.c.org	2005-07-04 07:33:17.000000000 +0200
+++ ibm_hdaps.c	2005-07-04 07:42:58.000000000 +0200
@@ -34,31 +34,18 @@
 #include <linux/delay.h>
 #include <asm/io.h>
 #include <asm/uaccess.h>
+#include "ibm_hdaps.h"
 
 
+#define DRV_NAME        "ibm_hdaps"
+#define DRV_DESCRIPTION	"IBM ThinkPad Accelerometer driver"
+#define DRV_COPYRIGHT  	"Copyright (c) 2005 Jesper Juhl <jesper.juhl@gmail.com>"
+#define DRV_VERSION     "0.2"
 
-#define HDAPS_LOW_PORT	0x1600	/* first port used by accelerometer */
-#define HDAPS_NR_PORTS	0x30	/* nr of ports total - 0x1600 through 0x162f */
-
-#define STATE_STALE	0x00	/* accelerometer data is stale */
-#define STATE_FRESH	0x50	/* accelerometer data fresh fresh */
-
-#define REFRESH_ASYNC	0x00	/* do asynchronous refresh */
-#define REFRESH_SYNC	0x01	/* do synchronous refresh */
-
-/* 
- * where to find the various accelerometer data
- * these map to the members of struct hdaps_accel_data
- */
-#define HDAPS_PORT_STATE	0x1611
-#define	HDAPS_PORT_XACCEL	0x1612
-#define HDAPS_PORT_YACCEL	0x1614
-#define HDAPS_PORT_TEMP		0x1616
-#define HDAPS_PORT_XVAR		0x1617
-#define HDAPS_PORT_YVAR		0x1619
-#define HDAPS_PORT_TEMP2	0x161b
-#define HDAPS_PORT_UNKNOWN	0x161c
-#define HDAPS_PORT_KMACCT	0x161d
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR(DRV_COPYRIGHT);
+MODULE_DESCRIPTION(DRV_DESCRIPTION);
+MODULE_VERSION(DRV_VERSION);
 
 static short debug = 0;
  
@@ -345,6 +332,9 @@
 	int retval;
 	struct hdaps_accel_data data;
 
+	printk(KERN_INFO DRV_NAME ": " DRV_DESCRIPTION ", " DRV_VERSION "\n");
+	printk(KERN_INFO DRV_NAME ": " DRV_COPYRIGHT "\n");
+
 	printk(KERN_WARNING "init 1 %08ld\n", jiffies);
 	if (!request_region(HDAPS_LOW_PORT, HDAPS_NR_PORTS, "ibm_hdaps"))
 		return -ENXIO;
@@ -367,7 +357,6 @@
 	}
 	
 	if (0) for (i = 0; i < 50; i++) {
-		int j;
 		unsigned long tmp;
 		accelerometer_read(&data);
 		printk(KERN_WARNING "state = %d\n", data.state);
@@ -405,8 +394,3 @@
 module_init(ibm_hdaps_init);
 module_exit(ibm_hdaps_exit);
 
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Jesper Juhl");
-
-MODULE_DESCRIPTION("IBM ThinkPad Accelerometer driver");
-MODULE_VERSION("0.2");

[-- Attachment #3: ibm_hdaps.h --]
[-- Type: text/plain, Size: 1832 bytes --]

/*
 * Driver for IBM HDAPS (HardDisk Active Protection system)
 *
 * Based on the document by Mark A. Smith available at
 * http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html
 *
 * Copyright (c) 2005  Jesper Juhl <jesper.juhl@gmail.com>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 */

#ifndef __IBM_HDAPS_H__
#define __IBM_HDAPS_H__

#define HDAPS_LOW_PORT	0x1600	/* first port used by accelerometer */
#define HDAPS_NR_PORTS	0x30	/* nr of ports total - 0x1600 through 0x162f */

#define STATE_STALE	0x00	/* accelerometer data is stale */
#define STATE_FRESH	0x50	/* accelerometer data fresh fresh */

#define REFRESH_ASYNC	0x00	/* do asynchronous refresh */
#define REFRESH_SYNC	0x01	/* do synchronous refresh */

/* 
 * where to find the various accelerometer data
 * these map to the members of struct hdaps_accel_data
 */
#define HDAPS_PORT_STATE	0x1611
#define	HDAPS_PORT_XACCEL	0x1612
#define HDAPS_PORT_YACCEL	0x1614
#define HDAPS_PORT_TEMP		0x1616
#define HDAPS_PORT_XVAR		0x1617
#define HDAPS_PORT_YVAR		0x1619
#define HDAPS_PORT_TEMP2	0x161b
#define HDAPS_PORT_UNKNOWN	0x161c
#define HDAPS_PORT_KMACCT	0x161d

#endif /*  __IBM_HDAPS_H__  */

[-- Attachment #4: Makefile.diff --]
[-- Type: text/x-patch, Size: 292 bytes --]

--- Makefile.org	2005-07-04 07:58:53.000000000 +0200
+++ Makefile	2005-07-04 07:57:50.000000000 +0200
@@ -26,3 +26,7 @@
 	install -d $(KMISC)
 	install -m 644 -c $(addsuffix .ko,$(list-m)) $(KMISC)
 	/sbin/depmod -a
+
+uninstall:
+	rm -f $(KMISC)/$(addsuffix .ko,$(list-m))
+	/sbin/depmod -a

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jens Axboe]

On Mon, Jul 04 2005, Lenz Grimmer wrote:
> > I'll be working on adding sysfs stuff to it tomorrow so it's generally
> > useful (at least for monitoring things - not yet for parking disk
> > heads).
> 
> Maybe there is some kind of all-purpose ATA command that instructs the
> disk drive to park the heads? Jens, could you give us a hint on how a
> userspace application would do that?

Dunno if there's something that explicitly only parks the head, the best
option is probably to issue a STANDBY_NOW command. You can test this
with hdparm -y.

Generel observation on this driver - why isn't it just contained in user
space? You need to do the monitoring and sending of ide commands from
there anyways, I don't see the point of putting it in the kernel.

-- 
Jens Axboe

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Alejandro Bonilla]

Jens Axboe wrote:

>On Mon, Jul 04 2005, Lenz Grimmer wrote:
>  
>
>>>I'll be working on adding sysfs stuff to it tomorrow so it's generally
>>>useful (at least for monitoring things - not yet for parking disk
>>>heads).
>>>      
>>>
>>Maybe there is some kind of all-purpose ATA command that instructs the
>>disk drive to park the heads? Jens, could you give us a hint on how a
>>userspace application would do that?
>>    
>>
>
>Dunno if there's something that explicitly only parks the head, the best
>option is probably to issue a STANDBY_NOW command. You can test this
>with hdparm -y.
>  
>
This is exactly what I said. Use hdparm to make the HD park 
inmediatelly. I did send the email to the HDPARM developer, but he never 
replied. I asked him what would be the best way to make the HD park with 
no exception and then let it come back 5 or 10 seconds later.

Never heard back. ;-(

.Alejandro

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jens Axboe]

On Mon, Jul 04 2005, Alejandro Bonilla wrote:
> Jens Axboe wrote:
> 
> >On Mon, Jul 04 2005, Lenz Grimmer wrote:
> > 
> >
> >>>I'll be working on adding sysfs stuff to it tomorrow so it's generally
> >>>useful (at least for monitoring things - not yet for parking disk
> >>>heads).
> >>>     
> >>>
> >>Maybe there is some kind of all-purpose ATA command that instructs the
> >>disk drive to park the heads? Jens, could you give us a hint on how a
> >>userspace application would do that?
> >>   
> >>
> >
> >Dunno if there's something that explicitly only parks the head, the best
> >option is probably to issue a STANDBY_NOW command. You can test this
> >with hdparm -y.
> > 
> >
> This is exactly what I said. Use hdparm to make the HD park 
> inmediatelly. I did send the email to the HDPARM developer, but he never 
> replied. I asked him what would be the best way to make the HD park with 
> no exception and then let it come back 5 or 10 seconds later.

IIRC, you don't have to do anything to wake up the drive after a
STANDBYNOW command, if you want to be on the safe side you just issue an
IDLEIMMEDIATE. So your code will look something like:

int drive_standby(int fd)
{
        char foo[4] = { 0xe0, 0, 0, 0 };

        return ioctl(fd, HDIO_DRIVE_CMD, &foo);
}

int drive_wakeup(int fd)
{
        char foo[4] = { 0xe1, 0, 0, 0 };

        return ioctl(fd, HDIO_DRIVE_CMD, &foo);
}

-- 
Jens Axboe

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Arjan van de Ven]

> > This is exactly what I said. Use hdparm to make the HD park 
> > inmediatelly. I did send the email to the HDPARM developer, but he never 
> > replied. I asked him what would be the best way to make the HD park with 
> > no exception and then let it come back 5 or 10 seconds later.
> 
> IIRC, you don't have to do anything to wake up the drive after a
> STANDBYNOW command, if you want to be on the safe side you just issue an
> IDLEIMMEDIATE. So your code will look something like:

the problem for this will be that this app will also want to prevent ANY
io going to the disk for a few seconds.

I mean, what use is parking the head if you notice the laptop falling,
when the kernel submits IO to it and wakes it up again before it hits
the ground :)

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jens Axboe]

On Mon, Jul 04 2005, Arjan van de Ven wrote:
> 
> > > This is exactly what I said. Use hdparm to make the HD park 
> > > inmediatelly. I did send the email to the HDPARM developer, but he never 
> > > replied. I asked him what would be the best way to make the HD park with 
> > > no exception and then let it come back 5 or 10 seconds later.
> > 
> > IIRC, you don't have to do anything to wake up the drive after a
> > STANDBYNOW command, if you want to be on the safe side you just issue an
> > IDLEIMMEDIATE. So your code will look something like:
> 
> the problem for this will be that this app will also want to prevent ANY
> io going to the disk for a few seconds.
> 
> I mean, what use is parking the head if you notice the laptop falling,
> when the kernel submits IO to it and wakes it up again before it hits
> the ground :)

Yeah, that likely needs a little help from the ide driver. If you force
a spindown, you will effectively have parked the head for as long as the
spindown + spinup takes. That could turn out to be enough, it will take
more than 1-2 seconds anyways.

-- 
Jens Axboe

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Arjan van de Ven]

> 
> Yeah, that likely needs a little help from the ide driver. If you force
> a spindown, you will effectively have parked the head for as long as the
> spindown + spinup takes. That could turn out to be enough, it will take
> more than 1-2 seconds anyways.

I doubt it; laptop disks seem to be optimized for spinning up/down fast
(for powersaving reasons) so while for normal disks I'd agree with you,
for laptop disks I'm far less sure.

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jens Axboe]

On Mon, Jul 04 2005, Arjan van de Ven wrote:
> 
> > 
> > Yeah, that likely needs a little help from the ide driver. If you force
> > a spindown, you will effectively have parked the head for as long as the
> > spindown + spinup takes. That could turn out to be enough, it will take
> > more than 1-2 seconds anyways.
> 
> I doubt it; laptop disks seem to be optimized for spinning up/down fast
> (for powersaving reasons) so while for normal disks I'd agree with you,
> for laptop disks I'm far less sure.

It isn't too pretty to rely on such unreliable timing anyways. I'm not
too crazy about spinning the disk down either, it's useless wear
compared to just parking the head.

-- 
Jens Axboe

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Lenz Grimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Jens Axboe wrote:

> It isn't too pretty to rely on such unreliable timing anyways. I'm 
> not too crazy about spinning the disk down either, it's useless wear 
> compared to just parking the head.

Fully agreed, and that's the approach the IBM Windows driver seems to
take - you just hear the disk park its head when the sensor kicks in
(you can hear it) - the disk does not spin down when this happens.

Could this be some reserved ATA command that only works with certain#
drives?

Bye,
	LenZ
- --
- ------------------------------------------------------------------
 Lenz Grimmer <lenz@grimmer.com>                             -o)
 [ICQ: 160767607 | Jabber: LenZGr@jabber.org]                /\\
 http://www.lenzg.org/                                       V_V
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCyRBySVDhKrJykfIRAkM+AJ9UDbO8JU48UcEgVE2Kf35X1f4PjgCfaNPx
xEHnSU5BagtmC02nwGx66F4=
=BDfq
-----END PGP SIGNATURE-----

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jens Axboe]

On Mon, Jul 04 2005, Lenz Grimmer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Jens Axboe wrote:
> 
> > It isn't too pretty to rely on such unreliable timing anyways. I'm 
> > not too crazy about spinning the disk down either, it's useless wear 
> > compared to just parking the head.
> 
> Fully agreed, and that's the approach the IBM Windows driver seems to
> take - you just hear the disk park its head when the sensor kicks in
> (you can hear it) - the disk does not spin down when this happens.
> 
> Could this be some reserved ATA command that only works with certain#
> drives?

Perhaps the IDLE or IDLEIMMEDIATE commands imply a head parking, that
would make sense. As you say, you can hear a drive parking its head.
Here's a test case, it doesn't sound like it's parking the hard here.

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/hdreg.h>

int main(int argc, char *argv[])
{
	char cmd[4] = { 0xe1, 0, 0, 0 };
	int fd;

	if (argc < 2) {
		printf("%s <dev>\n", argv[0]);
		return 1;
	}

	fd = open(argv[1], O_RDONLY);
	if (fd == -1) {
		perror("open");
		return 1;
	}

	if (ioctl(fd, HDIO_DRIVE_CMD, cmd))
		perror("ioctl");

	close(fd);
	return 0;
}

-- 
Jens Axboe

Re: IBM HDAPS things are looking up

[Lenz Grimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jens!

Thanks for the sample code. I've trimmed the recipient list a bit...

Jens Axboe wrote:

> Perhaps the IDLE or IDLEIMMEDIATE commands imply a head parking, that
> would make sense. As you say, you can hear a drive parking its head.
> Here's a test case, it doesn't sound like it's parking the hard here.

Not here either, but let me check, if I understand this correctly:

> #include <stdio.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <sys/ioctl.h>
> #include <linux/hdreg.h>
> 
> int main(int argc, char *argv[])
> {
> 	char cmd[4] = { 0xe1, 0, 0, 0 };

The "0xe1" in here is what is defined as "WIN_IDLEIMMEDIATE" in hdreg.h,
correct?

> 	int fd;
> 
> 	if (argc < 2) {
> 		printf("%s <dev>\n", argv[0]);
> 		return 1;
> 	}
> 
> 	fd = open(argv[1], O_RDONLY);

Hmm, don't I need to actually have *write* access for sending an ioctl?

> 	if (fd == -1) {
> 		perror("open");
> 		return 1;
> 	}
> 
> 	if (ioctl(fd, HDIO_DRIVE_CMD, cmd))
> 		perror("ioctl");
> 
> 	close(fd);
> 	return 0;
> }

I will give it another try, after clarifying the above questions - maybe
there is a command that will perform the desired task. If not, I guess
we're back at snooping what the Windows driver does here...

Bye,
	LenZ
- --
- ------------------------------------------------------------------
 Lenz Grimmer <lenz@grimmer.com>                             -o)
 [ICQ: 160767607 | Jabber: LenZGr@jabber.org]                /\\
 http://www.lenzg.org/                                       V_V
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCyTcySVDhKrJykfIRAqAEAJ93Fx7EpdtAfoR7ab61D9CDgIFX1ACfekHD
9Dxg1MDYwph+8tQfHicWii8=
=YM7P
-----END PGP SIGNATURE-----

Re: IBM HDAPS things are looking up

[Jens Axboe]

On Mon, Jul 04 2005, Lenz Grimmer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Jens!
> 
> Thanks for the sample code. I've trimmed the recipient list a bit...
> 
> Jens Axboe wrote:
> 
> > Perhaps the IDLE or IDLEIMMEDIATE commands imply a head parking, that
> > would make sense. As you say, you can hear a drive parking its head.
> > Here's a test case, it doesn't sound like it's parking the hard here.
> 
> Not here either, but let me check, if I understand this correctly:
> 
> > #include <stdio.h>
> > #include <unistd.h>
> > #include <fcntl.h>
> > #include <sys/ioctl.h>
> > #include <linux/hdreg.h>
> > 
> > int main(int argc, char *argv[])
> > {
> > 	char cmd[4] = { 0xe1, 0, 0, 0 };
> 
> The "0xe1" in here is what is defined as "WIN_IDLEIMMEDIATE" in hdreg.h,
> correct?

Correct.

> > 	int fd;
> > 
> > 	if (argc < 2) {
> > 		printf("%s <dev>\n", argv[0]);
> > 		return 1;
> > 	}
> > 
> > 	fd = open(argv[1], O_RDONLY);
> 
> Hmm, don't I need to actually have *write* access for sending an ioctl?

No, but you need CAP_SYS_RAWIO capability. So run it as root.

> > 	if (fd == -1) {
> > 		perror("open");
> > 		return 1;
> > 	}
> > 
> > 	if (ioctl(fd, HDIO_DRIVE_CMD, cmd))
> > 		perror("ioctl");
> > 
> > 	close(fd);
> > 	return 0;
> > }
> 
> I will give it another try, after clarifying the above questions - maybe
> there is a command that will perform the desired task. If not, I guess
> we're back at snooping what the Windows driver does here...

I'm not aware of a generally specificed command, it's likely that the
ibm drive has a vendor specific one. Or that one of the idle commands
can be configured to park the drive. Or... I'm not sure you'll find
anything interesting in the windows driver, I would imagine that the
user app is the one issuing the ide command (like the linux equiv would
as well).

-- 
Jens Axboe

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Pavel Machek]

Hi!

> > > > This is exactly what I said. Use hdparm to make the HD park 
> > > > inmediatelly. I did send the email to the HDPARM developer, but he never 
> > > > replied. I asked him what would be the best way to make the HD park with 
> > > > no exception and then let it come back 5 or 10 seconds later.
> > > 
> > > IIRC, you don't have to do anything to wake up the drive after a
> > > STANDBYNOW command, if you want to be on the safe side you just issue an
> > > IDLEIMMEDIATE. So your code will look something like:
> > 
> > the problem for this will be that this app will also want to prevent ANY
> > io going to the disk for a few seconds.
> > 
> > I mean, what use is parking the head if you notice the laptop falling,
> > when the kernel submits IO to it and wakes it up again before it hits
> > the ground :)
> 
> Yeah, that likely needs a little help from the ide driver. If you force
> a spindown, you will effectively have parked the head for as long as the
> spindown + spinup takes. That could turn out to be enough, it will take
> more than 1-2 seconds anyways.

Actually, "spin disk down and keep it down" would be nice for other
reasons. Taking computer for a jog playing mp3s from ramdisk is
something I'd like to do...
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: IBM HDAPS things are looking up

[Lenz Grimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Pavel Machek wrote:

> Actually, "spin disk down and keep it down" would be nice for other
> reasons. Taking computer for a jog playing mp3s from ramdisk is
> something I'd like to do...

Isn't that called "laptop-mode" and available already? I remember that
Jens wrote something like that :)

Bye,
	LenZ
- --
- ------------------------------------------------------------------
 Lenz Grimmer <lenz@grimmer.com>                             -o)
 [ICQ: 160767607 | Jabber: LenZGr@jabber.org]                /\\
 http://www.lenzg.org/                                       V_V
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCyZxvSVDhKrJykfIRAkH/AJ9lMUvtxgNdZ6eRHAWGjuTxx5GyqACggF/O
p4V0PprkPpDWX/uFgp8Plgs=
=ffpU
-----END PGP SIGNATURE-----

Re: IBM HDAPS things are looking up

[Pavel Machek]

Hi!

> > Actually, "spin disk down and keep it down" would be nice for other
> > reasons. Taking computer for a jog playing mp3s from ramdisk is
> > something I'd like to do...
> 
> Isn't that called "laptop-mode" and available already? I remember that
> Jens wrote something like that :)

Laptop-mode is "keep hdd spinned down as much as possible" -- to save
battery power. What this project and jogging mp3s need is "keep hdd
spinned down!" -- to prevent hdd damage.
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Shawn Starr]

We could put it in userspace, but if the system is
swapping like mad, can we still get a critical
response if this remains in userspace fully?

Someone mentioned we should use a kernel thread(s) to
handle stopping all I/O so we can safely park heads.

Shawn.

--- Jens Axboe <axboe@suse.de> wrote:

> On Mon, Jul 04 2005, Lenz Grimmer wrote:
> > > I'll be working on adding sysfs stuff to it
> tomorrow so it's generally
> > > useful (at least for monitoring things - not yet
> for parking disk
> > > heads).
> > 
> > Maybe there is some kind of all-purpose ATA
> command that instructs the
> > disk drive to park the heads? Jens, could you give
> us a hint on how a
> > userspace application would do that?
> 
> Dunno if there's something that explicitly only
> parks the head, the best
> option is probably to issue a STANDBY_NOW command.
> You can test this
> with hdparm -y.
> 
> Generel observation on this driver - why isn't it
> just contained in user
> space? You need to do the monitoring and sending of
> ide commands from
> there anyways, I don't see the point of putting it
> in the kernel.
> 
> -- 
> Jens Axboe
> 
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> informative Webcasts and more! Get everything you
> need to get up to
> speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Hdaps-devel mailing list
> Hdaps-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/hdaps-devel
> 

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jens Axboe]

(don't top post!)

On Mon, Jul 04 2005, Shawn Starr wrote:
> 
> We could put it in userspace, but if the system is
> swapping like mad, can we still get a critical
> response if this remains in userspace fully?

Just make sure the program isn't swapped out.

> Someone mentioned we should use a kernel thread(s) to
> handle stopping all I/O so we can safely park heads.

That's madness, we can't add a kernel thread for every single little
silly thing. You don't need to stop any io, you just want to make sure
that your park request gets issued right after the current io has
finished.


-- 
Jens Axboe

Re: IBM HDAPS things are looking up

[Alejandro Bonilla]

Jens Axboe wrote:

>
>That's madness, we can't add a kernel thread for every single little
>silly thing. You don't need to stop any io, you just want to make sure
>that your park request gets issued right after the current io has
>finished.
>  
>
HI,

    For me, the heads have to park so fast. That I would be afraid of a 
kernel panil or something that could happen if you park the head so fast 
that it won't even tell the kernel it did, or because ext3 couldn't 
update or any crazy reason.

    I use a lot a project called laptop_mode, which suspend the hd until 
you do a request to the kernel or the HD and it spins up the HD. I think 
somehow, the kernel is not fast enough to do what we want, I mean, I 
don't see it.

    Imagine you are in starbucks, your laptop is over a 1.2 M table, 
Linus just said that a new kernel is out. So you simply download it, and 
now you are compiling it. But, you invited your kid to Starbucks. And 
while your CPU is at 100% and full throttle HD usage. Then your kid 
trips on the cable or simply pushes the PC out.

    Do you think that the kernel will STOP, HOLD and park the head in 
less than a second? OR on the time we need?

    I would say is a dammed good kernel if it would. (could RTOS, make 
things faster)

Simply send the flames my way if you think I'm totally wrong. Which I 
might be. I really don't know...

.Alejandro

Re: IBM HDAPS things are looking up

[dean gaudet]

On Mon, 4 Jul 2005, Alejandro Bonilla wrote:

>    Do you think that the kernel will STOP, HOLD and park the head in less than
> a second? OR on the time we need?

this is why the windows driver uses heuristics to decide when the laptop 
is possibly unstable and *may* fall soon... because it takes something 
like 700ms to actually park.  (a url floated by with the whitepaper-level 
details at some point.)

btw -- my usual box is a t42p running winxp, and i disable the parking 
code... whatever my normal usage is tends to trigger the parking 
heuristics too readily.  it's a cool idea, but i'm skeptical of its 
real-world value.

as for other details it's trivial to lock the daemon in memory and run it 
at nice -4 to get a head start on parking even when at 100% cpu and under 
memory load.

-dean

Re: IBM HDAPS things are looking up

[Lee Revell]

On Mon, 2005-07-04 at 11:36 -0700, dean gaudet wrote:
> as for other details it's trivial to lock the daemon in memory and run
> it at nice -4 to get a head start on parking even when at 100% cpu and
> under memory load.
> 

Negative nice values are not the correct solution when dealing with RT
constraints like this, you need SCHED_FIFO.  You can't afford the chance
that the scheduler could decide to run another task due to some internal
heuristic.

Lee

Re: IBM HDAPS things are looking up

[Jens Axboe]

On Mon, Jul 04 2005, Alejandro Bonilla wrote:
> Jens Axboe wrote:
> 
> >
> >That's madness, we can't add a kernel thread for every single little
> >silly thing. You don't need to stop any io, you just want to make sure
> >that your park request gets issued right after the current io has
> >finished.
> > 
> >
> HI,
> 
>    For me, the heads have to park so fast. That I would be afraid of a 
> kernel panil or something that could happen if you park the head so fast 
> that it won't even tell the kernel it did, or because ext3 couldn't 
> update or any crazy reason.
> 
>    I use a lot a project called laptop_mode, which suspend the hd until 
> you do a request to the kernel or the HD and it spins up the HD. I think 
> somehow, the kernel is not fast enough to do what we want, I mean, I 
> don't see it.
> 
>    Imagine you are in starbucks, your laptop is over a 1.2 M table, 
> Linus just said that a new kernel is out. So you simply download it, and 
> now you are compiling it. But, you invited your kid to Starbucks. And 
> while your CPU is at 100% and full throttle HD usage. Then your kid 
> trips on the cable or simply pushes the PC out.
> 
>    Do you think that the kernel will STOP, HOLD and park the head in 
> less than a second? OR on the time we need?
> 
>    I would say is a dammed good kernel if it would. (could RTOS, make 
> things faster)
> 
> Simply send the flames my way if you think I'm totally wrong. Which I 
> might be. I really don't know...

You have to wait for the current command to finish, that is the fastest
approach. Aborting it would likely take longer. So what I describe
above, is really as fast as you can issue that command. If you are busy
doing io (writes, from the sound of the above), a single command doesn't
take very long as it goes to cache. Lets just say 10ms as a nice
pessimistic number. On average, that means you have 5ms until that
command finishes and you can issue the park. Submitting the park command
doesn't take long, the time is dominated by the actual park time. Which
is hardware bound, there's not much we can improve there in software.

The actualy accel daemon would run at an appropriate scheduling
priority/class, to ensure good response there.

-- 
Jens Axboe