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

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))

[Alejandro Bonilla]

Jesper Juhl wrote:

>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.
>
>  
>
Jesper,

    Deal. Since the beggining, when you look at the thread I created, I 
was always looking for someone interested. You all are, and you all will 
maintain the driver and we all will help with it. Thanks again Jesper.

    Thanks to Brix as well for the kickstart and for helping on part of 
the initial code.

    I will put up hdaps.sf.net. I have someone that will/might make a 
nice site and will put us up. We also need a Laptop matrix that will 
tell the users if their laptops have HDAPS and so on.

    I will also look on to give access to hdaps.sf.net to whomever 
maintains the tarball, which is in other words, Jesper.

    Again, I want to thanks everyone for helping further on this. ANY 
help is appreciated.

    Unfortunately, I'm not good at coding, but I can help with 
Documentation, installation tips and improved user help. Also, to help 
make things easier.

The IRC channel is there. Whoever sticks around and give nice support (I 
will) gets their access, here is the mailing list, if someone wants to 
be added as a List admin, please let me know.

Thanks again all for everything. It's incredible on how fast this 
process is going. I can't imagine how soon we will make it into 
mainline, even more with kernel people.

If anyone needs access to anything, or wants to be copied to anything, 
please let me know.

It is a holiday for me tomorrow, so I can listed to every need that we 
will have, to make a TODO and bla bla...

Anyway... Let's have a chat tomorrow at irc and see what we have to do.

(It still doesn't work for me.) ;-(

.Alejandro

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))

[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))

[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))

[Andrey Panin]

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

On 185, 07 04, 2005 at 08:00:12AM +0200, Lenz Grimmer wrote:
> -----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

Looks like io port region is already busy.

> (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?

Run cat /proc/ioports
 
> 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-----

> --- 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");

> /*
>  * 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__  */

> --- 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


-- 
Andrey Panin		| Linux and UNIX system administrator
pazke@donpac.ru		| PGP key: wwwkeys.pgp.net

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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,

thanks for your quick reply!

Jens Axboe wrote:

> 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.

Thanks for the hint! As others already mentioned, STANDBY_NOW may not be
the best option in this case - we shall investigate what the IBM Windows
driver is using here.

> 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.

Sorry, my comments may have been misleading - I agree that this should
be better done in userspace.

The kernel module just reads out the accelerometer, a user space app
could then interpret the values and take appropriate action (e.g.
parking the hdd head). This allows other apps to make use of these
acceleratometer values as well (think SDL for games).

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

iD8DBQFCyQ9XSVDhKrJykfIRAktdAJ9eltvz0sjTfKT7oVgqikGFEYJwHQCfdr7n
b7M02yR0n2UrUFLL03xA804=
=MHtj
-----END PGP SIGNATURE-----

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))

[Pekka Enberg]

Hi Jesper,

On 7/4/05, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> static int
> ibm_hdaps_open(struct inode *inode, struct file *filp)
> {
> 	printk("%s() start\n", __func__);
> 	if (!atomic_dec_and_test(&ibm_hdaps_available)) {
> 		printk("%s() busy\n", __func__);
> 		atomic_inc(&ibm_hdaps_available);
> 		return -EBUSY;
> 	}
> 	printk("%s() good\n", __func__);
> 
> 	filp->private_data = kmalloc(sizeof(struct hdaps_accel_data), GFP_KERNEL);

You seem to be leaking private_data.

                                    Pekka

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

[Jesper Juhl]

On 7/4/05, Pekka Enberg <penberg@gmail.com> wrote:
> Hi Jesper,
> 
> On 7/4/05, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > static int
> > ibm_hdaps_open(struct inode *inode, struct file *filp)
> > {
> >       printk("%s() start\n", __func__);
> >       if (!atomic_dec_and_test(&ibm_hdaps_available)) {
> >               printk("%s() busy\n", __func__);
> >               atomic_inc(&ibm_hdaps_available);
> >               return -EBUSY;
> >       }
> >       printk("%s() good\n", __func__);
> >
> >       filp->private_data = kmalloc(sizeof(struct hdaps_accel_data), GFP_KERNEL);
> 
> You seem to be leaking private_data.
> 
Thanks. It still needs a lot of work (as can also be seen from all the
nice feedback in this thread).
I just woke up and I'll start looking at the mails people have posted
in a few hours.


-- 
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))

[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 (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Pavel Machek]

Hi!

> > 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

Actually you should probably implement it as an input device; no need to
mess with sysfs. drivers/input/accell ?

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

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 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))

[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: [Hdaps-devel] Re: IBM HDAPS things are looking up

[Shawn Starr]

>From what I'm told its not specific to hard disk, you
can put any laptop HD and it will work the same (?).

Shawn.

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

> 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
> 
> 
> 
>
-------------------------------------------------------
> 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

[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

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

[Aaron Cohen]

On 7/4/05, Jens Axboe <axboe@suse.de> wrote:
> 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.
> 

Can't the accelerometer be used as an input device in addition to just
being a "about to fall detector?"

I seem to remember games where the the input method involved tilting
the device in the direction you want a marble to roll or something
like that.

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,

Aaron Cohen wrote:

> Can't the accelerometer be used as an input device in addition to just
> being a "about to fall detector?"

Yes, it can - the kernel driver just prints the data taken from the
accelerometer. It's up to another application to make sense out of this.
One purpose would be the mentioned "fall detector" that would then
instruct the disk drive to part its head.

> I seem to remember games where the the input method involved tilting
> the device in the direction you want a marble to roll or something
> like that.

Correct, that would be one option. Mark Smith (they IBM guy who wrote up
the information required to write the kernel module) actually mentioned
he had patched SDL to support the accelerometer as an input device.

Playing "Neverball" by tilting your Laptop sounds like fun :)

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

iD8DBQFCyY20SVDhKrJykfIRAjo/AJ0dyN0GXE7U5H3+updjuMKALoHlXQCdExrA
FwgCv2ELKCc9cC0M47E5B+w=
=pigJ
-----END PGP SIGNATURE-----

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 (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Alejandro Bonilla]

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...
>				Pavel
>  
>
This is exactly what I wanted to do. hdparm suspend which would send 
things to cache or buffer and then copy or get files only when needed. I 
just hope is fast enough, but we could trigger this with tilting or 
vibration and then something heavier when we find a free fall.

This driver does not exactly has to behave like Windows. It can be 
better. We always make things better.

.Alejandro

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

[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 (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jens Axboe]

On Mon, Jul 04 2005, Alejandro Bonilla wrote:
> 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...
> >				Pavel
> > 
> >
> This is exactly what I wanted to do. hdparm suspend which would send 
> things to cache or buffer and then copy or get files only when needed. I 
> just hope is fast enough, but we could trigger this with tilting or 
> vibration and then something heavier when we find a free fall.
> 
> This driver does not exactly has to behave like Windows. It can be 
> better. We always make things better.

As Lenz already suggested, you both pretty much seem to be describing
laptop mode. See the documentation.

-- 
Jens Axboe

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

[Alejandro Bonilla]

>
> As Lenz already suggested, you both pretty much seem to be describing
> laptop mode. See the documentation.
>
> --
> Jens Axboe
>
Jens,

	Yes, I know about laptop_mode, I always use it, but HD APS does not
automatically starts laptop_mode currently. That's why I was spitting out
that it could be a good idea to kick something like laptop_mode or
laptop_mode if normall vibration is detected, and then if higher vibration
or tilting numbers are detected, then park the head.

	If you check the IBM software in Windows, it shows 2 things. First, when it
pauses the HD and when it stops the HD. It all depends on how hard you hit
the PC. In one we suspend the drive and in the other we park the drive.

.Alejandro
(removing some people so they don't get triplicated emails)

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

[Sander]

Alejandro Bonilla wrote (ao):
> 	If you check the IBM software in Windows, it shows 2 things.
> 	First, when it pauses the HD and when it stops the HD. It all
> 	depends on how hard you hit the PC. In one we suspend the drive
> 	and in the other we park the drive.

This is not true. The software only parks the head, it does not spin
down the disk. That would take too much time to protect against a fall
anyway.

        Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

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

[Lee Revell]

On Tue, 2005-07-05 at 06:29 -0600, Alejandro Bonilla wrote:
> .Alejandro
> (removing some people so they don't get triplicated emails)

Please don't trim cc: lists!  We *want* the duplicate emails, so that
one goes in the Inbox and one in the LKML folder.

See the list archives for more reasons why it'd bad to trim cc: lists.

Lee

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

[Alejandro Bonilla]

> Alejandro Bonilla wrote (ao):
> > 	If you check the IBM software in Windows, it shows 2 things.
> > 	First, when it pauses the HD and when it stops the HD. It all
> > 	depends on how hard you hit the PC. In one we suspend the drive
> > 	and in the other we park the drive.
>
> This is not true. The software only parks the head, it does not spin
> down the disk. That would take too much time to protect against a fall
> anyway.
>
>         Sander

Sander,

	Sorry for not making myself clear "In one we suspend the drive and in the
other we park the drive" means that it would be nice to do that in Linux. We
don't have to do things like Windows does them. We can improve them to our
needs.

	In windows, there are 2 Simbols. 1. When the drive detects vibration and
then pauses the HD(yellow II sign in the taskbar) 2. When the HD is stop
when a free fall is detected. (Red simbol in the Taskbar)

	Please check it out in windows so you can see what I'm talking about.

.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, Jens Axboe wrote:
> 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.

ATA7 defines a park maneuvre, I don't know how well supported it is yet
though. You can test with this little app, if it says 'head parked' it
works. If not, it has just idled the drive.


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

int main(int argc, char *argv[])
{
	unsigned char buf[8];
	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;
	}

	memset(buf, 0, sizeof(buf));
	buf[0] = 0xe1;
	buf[1] = 0x44;
	buf[3] = 0x4c;
	buf[4] = 0x4e;
	buf[5] = 0x55;

	if (ioctl(fd, HDIO_DRIVE_TASK, buf)) {
		perror("ioctl");
		return 1;
	}

	if (buf[3] == 0xc4)
		printf("head parked\n");
	else
		printf("head not parked %x\n", buf[3]);

	close(fd);
	return 0;
}

-- 
Jens Axboe

Re: Head parking (was: IBM HDAPS things are looking up)

[Lenz Grimmer]

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

Hi,

Jens Axboe wrote:

> ATA7 defines a park maneuvre, I don't know how well supported it is 
> yet though. You can test with this little app, if it says 'head 
> parked' it works. If not, it has just idled the drive.

Great! Thanks for digging this up - it works on my T42, using a Fujitsu
MHT2080AH drive:

  lenz@metis:~/work/ibm_hdaps> sudo ./headpark /dev/hda
  head parked

Judging from the sound the drive makes, this is the same operation that
the windows tool performs.

However, the head does not remain parked for a very long time,
especially if there is a lot of disk activity going on (I tested it by
running a "find /" in parallel). The head parks, but leaves the park
position immediately afterwards again. I guess now we need to find a way
to "nail" the head into the parking position for some time - otherwise
it may already be on its way back to the platter before the laptop hits
the ground...

Thanks again - this is another helpful bit in getting all the pieces
together.

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

iD8DBQFCzOqlSVDhKrJykfIRAlm0AJ9WvadtsxAdLdTCe40N/KDbvSLf5wCdEWWA
OsiXzwFjziNuKvK5HKSMjb4=
=qXXH
-----END PGP SIGNATURE-----

Re: Head parking (was: IBM HDAPS things are looking up)

[Jens Axboe]

On Thu, Jul 07 2005, Lenz Grimmer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Jens Axboe wrote:
> 
> > ATA7 defines a park maneuvre, I don't know how well supported it is 
> > yet though. You can test with this little app, if it says 'head 
> > parked' it works. If not, it has just idled the drive.
> 
> Great! Thanks for digging this up - it works on my T42, using a Fujitsu
> MHT2080AH drive:
> 
>   lenz@metis:~/work/ibm_hdaps> sudo ./headpark /dev/hda
>   head parked
>
> Judging from the sound the drive makes, this is the same operation that
> the windows tool performs.

Very cool, I wasn't sure if this was a 'new' feature waiting to be
implemented in drives or if ata7 just documented existing use in some
drives.

How long did the park take? Spec states it can take up to 500ms.

> However, the head does not remain parked for a very long time,
> especially if there is a lot of disk activity going on (I tested it by
> running a "find /" in parallel). The head parks, but leaves the park
> position immediately afterwards again. I guess now we need to find a way
> to "nail" the head into the parking position for some time - otherwise
> it may already be on its way back to the platter before the laptop hits
> the ground...

The head just remains parked until the next command is issued. This
needs to be combined with some ide help, to freeze the queue. Perhaps
some sysfs file so you could do

# echo park > /sys/block/hda/device/head_state

Or whatever, at least just exposing this possibility so that the drive
internally can block future io until a 'resume' command is issued.

-- 
Jens Axboe

Re: Head parking (was: IBM HDAPS things are looking up)

[Pekka Enberg]

Jens Axboe wrote:
> > ATA7 defines a park maneuvre, I don't know how well supported it is
> > yet though. You can test with this little app, if it says 'head
> > parked' it works. If not, it has just idled the drive.

On 7/7/05, Lenz Grimmer <lenz@grimmer.com> wrote:
> Great! Thanks for digging this up - it works on my T42, using a Fujitsu
> MHT2080AH drive:

Works on my T42p which uses a Hitachi HTS726060M9AT00 drive. I don't
hear any sound, though.

                              Pekka

Re: [Hdaps-devel] Re: Head parking (was: IBM HDAPS things are looking up)

[Lenz Grimmer]

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

Hi,

Jens Axboe wrote:

> Very cool, I wasn't sure if this was a 'new' feature waiting to be 
> implemented in drives or if ata7 just documented existing use in some
>  drives.
> 
> How long did the park take? Spec states it can take up to 500ms.

Hard to measure (I don't have the C skills to add timing to your sample
snippet...), but almost instantly after issuing the command. "time"
states the command takes around 0.733 seconds in total (until the
command returns), the head park happens almost instantly after the
program started, probably after ~300ms).

> The head just remains parked until the next command is issued.

Right, which usually happens right away on a busy system, especially
when it's using swap (think KDE desktops :) )

> This needs to be combined with some ide help, to freeze the queue.
> Perhaps some sysfs file so you could do
> 
> # echo park > /sys/block/hda/device/head_state
> 
> Or whatever, at least just exposing this possibility so that the
> drive internally can block future io until a 'resume' command is
> issued.

Or for a given timeout, whatever happens first. Sounds good to me!
So would this feature require modifications to the IDE layer?

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

iD8DBQFCzQE+SVDhKrJykfIRAtN9AJ9207U5cJIw1i5a0t+PsrkbbkW6/ACfZk0M
D0l/YVWoiq+Jo0zw+mqFV9g=
=Eda0
-----END PGP SIGNATURE-----

Re: Head parking (was: IBM HDAPS things are looking up)

[Jens Axboe]

On Thu, Jul 07 2005, Pekka Enberg wrote:
> Jens Axboe wrote:
> > > ATA7 defines a park maneuvre, I don't know how well supported it is
> > > yet though. You can test with this little app, if it says 'head
> > > parked' it works. If not, it has just idled the drive.
> 
> On 7/7/05, Lenz Grimmer <lenz@grimmer.com> wrote:
> > Great! Thanks for digging this up - it works on my T42, using a Fujitsu
> > MHT2080AH drive:
> 
> Works on my T42p which uses a Hitachi HTS726060M9AT00 drive. I don't
> hear any sound, though.

Did it say 'head parked'? If the drive is idle, you wont hear anything.
Laptop drives auto-park really quickly themselves. A time ./park
/dev/hda should tell you whether it needed to park or not, if it
executes faster than a few hundred ms it was already parked.

-- 
Jens Axboe

Re: Head parking (was: IBM HDAPS things are looking up)

[Pekka Enberg]

On 7/7/05, Jens Axboe <axboe@suse.de> wrote:
> Did it say 'head parked'? If the drive is idle, you wont hear anything.
> Laptop drives auto-park really quickly themselves. A time ./park
> /dev/hda should tell you whether it needed to park or not, if it
> executes faster than a few hundred ms it was already parked.

Aah, you're right.

haji tmp # time ./a.out /dev/hda
head parked

real    0m0.421s
user    0m0.000s
sys     0m0.001s

Immediately after that:

haji tmp # time ./a.out /dev/hda
head parked

real    0m0.001s
user    0m0.000s
sys     0m0.001s

And then I do bit of disk reads and I get this again:

haji tmp # time ./a.out /dev/hda
head parked

real    0m0.429s
user    0m0.001s
sys     0m0.001s

So looks like it works for me too.

                                Pekka

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

[Shawn Starr]

Model: HTS548080M9AT00 (Hitachi)
Laptop: T42.

segfault:/home/spstarr# ./a /dev/hda
head parked

Seems to park, heard it click :)

Shawn.

On July 7, 2005 04:03, Jens Axboe wrote:
> On Mon, Jul 04 2005, Jens Axboe wrote:
> > 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.
>
> ATA7 defines a park maneuvre, I don't know how well supported it is yet
> though. You can test with this little app, if it says 'head parked' it
> works. If not, it has just idled the drive.
>
>
> #include <stdio.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <string.h>
> #include <sys/ioctl.h>
> #include <linux/hdreg.h>
>
> int main(int argc, char *argv[])
> {
> 	unsigned char buf[8];
> 	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;
> 	}
>
> 	memset(buf, 0, sizeof(buf));
> 	buf[0] = 0xe1;
> 	buf[1] = 0x44;
> 	buf[3] = 0x4c;
> 	buf[4] = 0x4e;
> 	buf[5] = 0x55;
>
> 	if (ioctl(fd, HDIO_DRIVE_TASK, buf)) {
> 		perror("ioctl");
> 		return 1;
> 	}
>
> 	if (buf[3] == 0xc4)
> 		printf("head parked\n");
> 	else
> 		printf("head not parked %x\n", buf[3]);
>
> 	close(fd);
> 	return 0;
> }

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

[Alejandro Bonilla]

Jens,

	Thanks for this util. :-) It will make things easier for us and do part of
the Job we are looking for. I will post this  script in the hdaps.sf.net for
people if it's ok with you.

Thanks again,

.Alejandro

> > #include <stdio.h>
> > #include <unistd.h>
> > #include <fcntl.h>
> > #include <string.h>
> > #include <sys/ioctl.h>
> > #include <linux/hdreg.h>
> >
> > int main(int argc, char *argv[])
> > {
> > 	unsigned char buf[8];
> > 	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;
> > 	}
> >
> > 	memset(buf, 0, sizeof(buf));
> > 	buf[0] = 0xe1;
> > 	buf[1] = 0x44;
> > 	buf[3] = 0x4c;
> > 	buf[4] = 0x4e;
> > 	buf[5] = 0x55;
> >
> > 	if (ioctl(fd, HDIO_DRIVE_TASK, buf)) {
> > 		perror("ioctl");
> > 		return 1;
> > 	}
> >
> > 	if (buf[3] == 0xc4)
> > 		printf("head parked\n");
> > 	else
> > 		printf("head not parked %x\n", buf[3]);
> >
> > 	close(fd);
> > 	return 0;
> > }

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

[Shawn Starr]

Model: HTS548080M9AT00 (Hitachi)
Laptop: T42.

segfault:/home/spstarr# ./a /dev/hda
head parked

Seems to park, heard it click :)

Shawn.

On July 7, 2005 04:03, Jens Axboe wrote:
> On Mon, Jul 04 2005, Jens Axboe wrote:
> > 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.
>
> ATA7 defines a park maneuvre, I don't know how well supported it is yet
> though. You can test with this little app, if it says 'head parked' it
> works. If not, it has just idled the drive.
>
>
> #include <stdio.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <string.h>
> #include <sys/ioctl.h>
> #include <linux/hdreg.h>
>
> int main(int argc, char *argv[])
> {
> 	unsigned char buf[8];
> 	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;
> 	}
>
> 	memset(buf, 0, sizeof(buf));
> 	buf[0] = 0xe1;
> 	buf[1] = 0x44;
> 	buf[3] = 0x4c;
> 	buf[4] = 0x4e;
> 	buf[5] = 0x55;
>
> 	if (ioctl(fd, HDIO_DRIVE_TASK, buf)) {
> 		perror("ioctl");
> 		return 1;
> 	}
>
> 	if (buf[3] == 0xc4)
> 		printf("head parked\n");
> 	else
> 		printf("head not parked %x\n", buf[3]);
>
> 	close(fd);
> 	return 0;
> }

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

[Jens Axboe]

On Thu, Jul 07 2005, Shawn Starr wrote:
> 
> Model: HTS548080M9AT00 (Hitachi)
> Laptop: T42.
> 
> segfault:/home/spstarr# ./a /dev/hda
> head parked
> 
> Seems to park, heard it click :)

Note on that - if the util says it parked, you can be very sure that it
actually did as the drive actually returns that status outside of just
completing the command.

Just FYI for the people that are going to work on the surrounding
support.

-- 
Jens Axboe

Re: [Hdaps-devel] Re: Head parking (was: IBM HDAPS things are looking up)

[Shawn Starr]

Model: HTS548080M9AT00 (Hitachi)
Laptop: T42.

segfault:/home/spstarr# ./a /dev/hda
head parked

Seems to park, heard it click :)

Shawn.

On July 7, 2005 04:48, Jens Axboe wrote:
> On Thu, Jul 07 2005, Lenz Grimmer wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > Jens Axboe wrote:
> > > ATA7 defines a park maneuvre, I don't know how well supported it is
> > > yet though. You can test with this little app, if it says 'head
> > > parked' it works. If not, it has just idled the drive.
> >
> > Great! Thanks for digging this up - it works on my T42, using a Fujitsu
> > MHT2080AH drive:
> >
> >   lenz@metis:~/work/ibm_hdaps> sudo ./headpark /dev/hda
> >   head parked
> >
> > Judging from the sound the drive makes, this is the same operation that
> > the windows tool performs.
>
> Very cool, I wasn't sure if this was a 'new' feature waiting to be
> implemented in drives or if ata7 just documented existing use in some
> drives.
>
> How long did the park take? Spec states it can take up to 500ms.
>
> > However, the head does not remain parked for a very long time,
> > especially if there is a lot of disk activity going on (I tested it by
> > running a "find /" in parallel). The head parks, but leaves the park
> > position immediately afterwards again. I guess now we need to find a way
> > to "nail" the head into the parking position for some time - otherwise
> > it may already be on its way back to the platter before the laptop hits
> > the ground...
>
> The head just remains parked until the next command is issued. This
> needs to be combined with some ide help, to freeze the queue. Perhaps
> some sysfs file so you could do
>
> # echo park > /sys/block/hda/device/head_state
>
> Or whatever, at least just exposing this possibility so that the drive
> internally can block future io until a 'resume' command is issued.

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

[Jens Axboe]

On Thu, Jul 07 2005, Alejandro Bonilla wrote:
> Jens,
> 
> 	Thanks for this util. :-) It will make things easier for us and do part of
> the Job we are looking for. I will post this  script in the hdaps.sf.net for
> people if it's ok with you.

Knock yourself out, I have no interest in this myself as I don't have
the hardware in question. This is all Lenz's fault!

-- 
Jens Axboe

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

[Clemens Koller]

Hello,

Just for the records....
-----
root@ecam:~$ ./headpark /dev/hda
head not parked 4c
-----

HDD is a desktop Maxtor Diamond MaxPlus 9 120GB
on a Promise Ultra133 TX2 IDE Controller.

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?

Are the commands different per HDD model / manufacturer?
Then we might need some information to send the proper
commands to the different types?!
And if there is no headpark command, might it be valuable to send
the HDD a shutdown instead?

PS:
I'm working on an embedded PowerPC (MPC8540) system which
will be turned into a high-resolution portable camera in
the future (with acceleration sensors for the right image
orientation). Therefore it will likely be another candidate
for a Drop'n'Park or Drop'n'Stop (tm) feature as are planning
to put a 2.5" notebook HDD into the cam, too.

Greets,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

Jens Axboe wrote:
> On Mon, Jul 04 2005, Jens Axboe wrote:
> 
>>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.
> 
> 
> ATA7 defines a park maneuvre, I don't know how well supported it is yet
> though. You can test with this little app, if it says 'head parked' it
> works. If not, it has just idled the drive.
> 
> 
> #include <stdio.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <string.h>
> #include <sys/ioctl.h>
> #include <linux/hdreg.h>
> 
> int main(int argc, char *argv[])
> {
> 	unsigned char buf[8];
> 	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;
> 	}
> 
> 	memset(buf, 0, sizeof(buf));
> 	buf[0] = 0xe1;
> 	buf[1] = 0x44;
> 	buf[3] = 0x4c;
> 	buf[4] = 0x4e;
> 	buf[5] = 0x55;
> 
> 	if (ioctl(fd, HDIO_DRIVE_TASK, buf)) {
> 		perror("ioctl");
> 		return 1;
> 	}
> 
> 	if (buf[3] == 0xc4)
> 		printf("head parked\n");
> 	else
> 		printf("head not parked %x\n", buf[3]);
> 
> 	close(fd);
> 	return 0;
> }
> 

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

[Alejandro Bonilla]

> Hello,
>
> Just for the records....
> -----
> root@ecam:~$ ./headpark /dev/hda
> head not parked 4c
> -----
>
> HDD is a desktop Maxtor Diamond MaxPlus 9 120GB
> on a Promise Ultra133 TX2 IDE Controller.
>
> 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?
>
> Are the commands different per HDD model / manufacturer?
> Then we might need some information to send the proper
> commands to the different types?!
> And if there is no headpark command, might it be valuable to send
> the HDD a shutdown instead?
>
> PS:
> I'm working on an embedded PowerPC (MPC8540) system which
> will be turned into a high-resolution portable camera in
> the future (with acceleration sensors for the right image
> orientation). Therefore it will likely be another candidate
> for a Drop'n'Park or Drop'n'Stop (tm) feature as are planning
> to put a 2.5" notebook HDD into the cam, too.
>
> Greets,
>
> Clemens Koller

Clemens,

	Thanks for bringing this up. We were actually in a conversation about this
subject in IRC a couple of minutes ago, and this actually came up. It would
be a good idea to kick this little script into the kernel so that people
that develop new accelerometers will be able to just make the call from the
script already in the kernel.

	How do we go by making this script maybe more broad, or simple so that it
can be implemented on more devices?

We could either leave this for only some hard drives, like camera's and
notebooks and use hdparm for other systems, or then use this script for all
HD's.

What could we do?

.Alejandro

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

[Jens Axboe]

On Thu, Jul 07 2005, Clemens Koller wrote:
> Hello,
> 
> Just for the records....
> -----
> root@ecam:~$ ./headpark /dev/hda
> head not parked 4c
> -----
> 
> HDD is a desktop Maxtor Diamond MaxPlus 9 120GB
> on a Promise Ultra133 TX2 IDE Controller.
> 
> 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?

This _is_ the generic way, if your drive doesn't support it you are out
of luck.

> Are the commands different per HDD model / manufacturer?
> Then we might need some information to send the proper
> commands to the different types?!

Each drive may have a vendor unique way of parking the head. But for
non-laptop drives, I would highly doubt it.

> And if there is no headpark command, might it be valuable to send
> the HDD a shutdown instead?

That would be the solution.

> PS:
> I'm working on an embedded PowerPC (MPC8540) system which
> will be turned into a high-resolution portable camera in
> the future (with acceleration sensors for the right image
> orientation). Therefore it will likely be another candidate
> for a Drop'n'Park or Drop'n'Stop (tm) feature as are planning
> to put a 2.5" notebook HDD into the cam, too.

Just make sure to choose a suitable laptop drive, then.

-- 
Jens Axboe

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

[Jens Axboe]

On Thu, Jul 07 2005, Alejandro Bonilla wrote:
> 
> > Hello,
> >
> > Just for the records....
> > -----
> > root@ecam:~$ ./headpark /dev/hda
> > head not parked 4c
> > -----
> >
> > HDD is a desktop Maxtor Diamond MaxPlus 9 120GB
> > on a Promise Ultra133 TX2 IDE Controller.
> >
> > 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?
> >
> > Are the commands different per HDD model / manufacturer?
> > Then we might need some information to send the proper
> > commands to the different types?!
> > And if there is no headpark command, might it be valuable to send
> > the HDD a shutdown instead?
> >
> > PS:
> > I'm working on an embedded PowerPC (MPC8540) system which
> > will be turned into a high-resolution portable camera in
> > the future (with acceleration sensors for the right image
> > orientation). Therefore it will likely be another candidate
> > for a Drop'n'Park or Drop'n'Stop (tm) feature as are planning
> > to put a 2.5" notebook HDD into the cam, too.
> >
> > Greets,
> >
> > Clemens Koller
> 
> Clemens,
> 
> Thanks for bringing this up. We were actually in a conversation about
> this subject in IRC a couple of minutes ago, and this actually came
> up. It would be a good idea to kick this little script into the kernel
> so that people that develop new accelerometers will be able to just
> make the call from the script already in the kernel.

What is needed is to flesh out what the kernel interface should looke
like. I suggested a sysfs file for suspending and resuming access to the
device, if people have other ideas they should voice them.

> How do we go by making this script maybe more broad, or simple so that
> it can be implemented on more devices?

It's a test utility, I just wrote it so people could test. The actual
command used woule be used in the internal implementation. The file
itself holds no other value than for testing purposes.

-- 
Jens Axboe

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

[Dave Hansen]

On Thu, 2005-07-07 at 19:27 +0200, Jens Axboe wrote:
> On Thu, Jul 07 2005, Clemens Koller 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?
> 
> This _is_ the generic way, if your drive doesn't support it you are out
> of luck.

I do wonder what is done in Windows, though...

They had to have had a method to park the drive there, or they probably
wouldn't have even included the HDAPS driver in the first place.
Anybody wanna strace the Windows app?

-- Dave

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

[Matthew Garrett]

Jens Axboe <axboe@suse.de> wrote:

> What is needed is to flesh out what the kernel interface should looke
> like. I suggested a sysfs file for suspending and resuming access to the
> device, if people have other ideas they should voice them.

That sounds quite reasonable. Does it need to do anything other than
park the head and suspend the command queue for that device?

(On an only slightly related note, for full ACPI support of PATA, we're
supposed to use the _GTF interface. This returns a set of taskfile
commands that are then supposed to be executed by the host. However, at
the point where we want to do this, the IDE queues haven't been
restarted. Is the best solution here just to add a trivial and stupid
IDE driver for managing the disks when we don't want userspace doing
anything with them?)

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

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

[Lee Revell]

On Thu, 2005-07-07 at 10:38 -0700, Dave Hansen wrote:
> On Thu, 2005-07-07 at 19:27 +0200, Jens Axboe wrote:
> > On Thu, Jul 07 2005, Clemens Koller 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?
> > 
> > This _is_ the generic way, if your drive doesn't support it you are out
> > of luck.
> 
> I do wonder what is done in Windows, though...
> 

My guess would be that it silently upgrades the firmware if it detects
that head parking isn't supported.

Lee

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

[Dave Hansen]

On Thu, 2005-07-07 at 14:01 -0400, Lee Revell wrote:
> On Thu, 2005-07-07 at 10:38 -0700, Dave Hansen wrote:
> > On Thu, 2005-07-07 at 19:27 +0200, Jens Axboe wrote:
> > > This _is_ the generic way, if your drive doesn't support it you are out
> > > of luck.
> > 
> > I do wonder what is done in Windows, though...
> 
> My guess would be that it silently upgrades the firmware if it detects
> that head parking isn't supported.

More likely that the things were shipped with firmware that only knows
some proprietary method of doing that we don't know about.

-- Dave

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

[Jens Axboe]

On Thu, Jul 07 2005, Dave Hansen wrote:
> On Thu, 2005-07-07 at 19:27 +0200, Jens Axboe wrote:
> > On Thu, Jul 07 2005, Clemens Koller 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?
> > 
> > This _is_ the generic way, if your drive doesn't support it you are out
> > of luck.
> 
> I do wonder what is done in Windows, though...
> 
> They had to have had a method to park the drive there, or they probably
> wouldn't have even included the HDAPS driver in the first place.
> Anybody wanna strace the Windows app?

It's not unlikely that the drives that IBM shipped in that notebook used
a "secret" command or subfeature to park the head. It's a little strange
though, as they supposedly shipped various makes and models of drives
with the hdaps included. If they did use a vendor unique command for
parking the head, I bet it would be different for each make.

-- 
Jens Axboe

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

[Jens Axboe]

On Thu, Jul 07 2005, Matthew Garrett wrote:
> Jens Axboe <axboe@suse.de> wrote:
> 
> > What is needed is to flesh out what the kernel interface should looke
> > like. I suggested a sysfs file for suspending and resuming access to the
> > device, if people have other ideas they should voice them.
> 
> That sounds quite reasonable. Does it need to do anything other than
> park the head and suspend the command queue for that device?

Not really, no. Someone mentioned a timeout for this as well, but I
think that should just be done in user space.

> (On an only slightly related note, for full ACPI support of PATA, we're
> supposed to use the _GTF interface. This returns a set of taskfile
> commands that are then supposed to be executed by the host. However, at
> the point where we want to do this, the IDE queues haven't been
> restarted. Is the best solution here just to add a trivial and stupid
> IDE driver for managing the disks when we don't want userspace doing
> anything with them?)

Either that, or always allow non-fs commands to go through a frozen
queue. Or flag those commands as ok for a frozen queue. The advantage of
either of those approaches, is that we probably don't have to add any
kernel support then and the generic block device freezing/unfreezing can
be used.

-- 
Jens Axboe

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

[Folkert van Heusden]

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

Doesn't park here:

ehm:/home/folkert# ./park /dev/hda
head not parked 4c

ehm:/home/folkert# hdparm -i /dev/hda

/dev/hda:

 Model=IC25N060ATMR04-0, FwRev=MO3OAD5A, SerialNo=MRG357K3KKN0XH
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7884kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=117210240
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:

 * signifies the current active mode

[   38.772050] hda: max request size: 1024KiB
[   38.792458] hda: 117210240 sectors (60011 MB) w/7884KiB Cache, CHS=16383/255/63, UDMA(100)

> > > #include <stdio.h>
> > > #include <unistd.h>
> > > #include <fcntl.h>
> > > #include <string.h>
> > > #include <sys/ioctl.h>
> > > #include <linux/hdreg.h>
> > >
> > > int main(int argc, char *argv[])
> > > {
> > > 	unsigned char buf[8];
> > > 	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;
> > > 	}
> > >
> > > 	memset(buf, 0, sizeof(buf));
> > > 	buf[0] = 0xe1;
> > > 	buf[1] = 0x44;
> > > 	buf[3] = 0x4c;
> > > 	buf[4] = 0x4e;
> > > 	buf[5] = 0x55;
> > >
> > > 	if (ioctl(fd, HDIO_DRIVE_TASK, buf)) {
> > > 		perror("ioctl");
> > > 		return 1;
> > > 	}
> > >
> > > 	if (buf[3] == 0xc4)
> > > 		printf("head parked\n");
> > > 	else
> > > 		printf("head not parked %x\n", buf[3]);
> > >
> > > 	close(fd);
> > > 	return 0;
> > > }


Folkert van Heusden

-- 
Auto te koop, zie: http://www.vanheusden.com/daihatsu.php
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden.
--------------------------------------------------------------------
 UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) 
 a try, it brings monitoring logfiles to a different level! See     
 http://vanheusden.com/multitail/features.html for a feature-list.  
--------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 282 bytes --]

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

[Jon Escombe]

Jens Axboe wrote:

>On Thu, Jul 07 2005, Shawn Starr wrote:
>  
>
>>Model: HTS548080M9AT00 (Hitachi)
>>Laptop: T42.
>>
>>segfault:/home/spstarr# ./a /dev/hda
>>head parked
>>
>>Seems to park, heard it click :)
>>    
>>
>
>Note on that - if the util says it parked, you can be very sure that it
>actually did as the drive actually returns that status outside of just
>completing the command.
>  
>
It's worth noting that you'll need the libata passthrough patch to make 
this work on a T43..

However, with this patch I'm getting the "head not parked 4c" message, 
but I can hear the click from the drive.. It takes around 350-400ms for 
the command to execute, but when repeated, it drops to around 5ms for a 
short while (with no audible clicking), before reverting to original 
behaviour after a few seconds.

The clicking and the variation in execution time lead me to think it is 
parking, but not being reported correctly?

Regards,
Jon,


______________________________________________________________
Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk)

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

[Alejandro Bonilla]

Jon Escombe wrote:

> Jens Axboe wrote:
>
>> Note on that - if the util says it parked, you can be very sure that it
>> actually did as the drive actually returns that status outside of just
>> completing the command.
>>  
>>
> It's worth noting that you'll need the libata passthrough patch to 
> make this work on a T43..
>
> However, with this patch I'm getting the "head not parked 4c" message, 
> but I can hear the click from the drive.. It takes around 350-400ms 
> for the command to execute, but when repeated, it drops to around 5ms 
> for a short while (with no audible clicking), before reverting to 
> original behaviour after a few seconds.
>
> The clicking and the variation in execution time lead me to think it 
> is parking, but not being reported correctly?
>
> Regards,
> Jon,

Jon,

    Most likely it might be doing it but returning inmediately. If you 
are in a quiet place, you should be able to notice the change.

    You can test this by having 2 consoles. With one you run the command 
and with the other one, try going deep into the filesystem, you should 
notice that it takes awhile to find the files and folders.

If it is fast, then is not parking.

.Alejandro

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 (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))

[Jens Axboe]

On Fri, Jul 08 2005, Jon Escombe wrote:
> Jens Axboe wrote:
> 
> >On Thu, Jul 07 2005, Shawn Starr wrote:
> > 
> >
> >>Model: HTS548080M9AT00 (Hitachi)
> >>Laptop: T42.
> >>
> >>segfault:/home/spstarr# ./a /dev/hda
> >>head parked
> >>
> >>Seems to park, heard it click :)
> >>   
> >>
> >
> >Note on that - if the util says it parked, you can be very sure that it
> >actually did as the drive actually returns that status outside of just
> >completing the command.
> > 
> >
> It's worth noting that you'll need the libata passthrough patch to make 
> this work on a T43..
> 
> However, with this patch I'm getting the "head not parked 4c" message, 
> but I can hear the click from the drive.. It takes around 350-400ms for 
> the command to execute, but when repeated, it drops to around 5ms for a 
> short while (with no audible clicking), before reverting to original 
> behaviour after a few seconds.
> 
> The clicking and the variation in execution time lead me to think it is 
> parking, but not being reported correctly?

Sounds like a pass through bug, it should pass the register output back
out again for a non-data command.

Checking code... Yeah it does not. Since the 'we parked successfully' is
stored in the lbal register, we need the full register set copied back
into the buffer. That goes for all three HDIO_* commands, there's still
some work to be done for the libata passthrough to be compliant with the
ide one.

-- 
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

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

[Shawn Starr]

It should be noted im using linux-2.6.git. 

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

> On Fri, Jul 08 2005, Jon Escombe wrote:
> > Jens Axboe wrote:
> > 
> > >On Thu, Jul 07 2005, Shawn Starr wrote:
> > > 
> > >
> > >>Model: HTS548080M9AT00 (Hitachi)
> > >>Laptop: T42.
> > >>
> > >>segfault:/home/spstarr# ./a /dev/hda
> > >>head parked
> > >>
> > >>Seems to park, heard it click :)
> > >>   
> > >>
> > >
> > >Note on that - if the util says it parked, you
> can be very sure that it
> > >actually did as the drive actually returns that
> status outside of just
> > >completing the command.
> > > 
> > >
> > It's worth noting that you'll need the libata
> passthrough patch to make 
> > this work on a T43..
> > 
> > However, with this patch I'm getting the "head not
> parked 4c" message, 
> > but I can hear the click from the drive.. It takes
> around 350-400ms for 
> > the command to execute, but when repeated, it
> drops to around 5ms for a 
> > short while (with no audible clicking), before
> reverting to original 
> > behaviour after a few seconds.
> > 
> > The clicking and the variation in execution time
> lead me to think it is 
> > parking, but not being reported correctly?
> 
> Sounds like a pass through bug, it should pass the
> register output back
> out again for a non-data command.
> 
> Checking code... Yeah it does not. Since the 'we
> parked successfully' is
> stored in the lbal register, we need the full
> register set copied back
> into the buffer. That goes for all three HDIO_*
> commands, there's still
> some work to be done for the libata passthrough to
> be compliant with the
> ide one.
> 
> -- 
> Jens Axboe
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With
> Dual!' webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to
> explore the latest in dual
> core and dual graphics technology at this free one
> hour event hosted by HP,
> AMD, and NVIDIA.  To register visit
> http://www.hp.com/go/dualwebinar
> _______________________________________________
> Hdaps-devel mailing list
> Hdaps-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/hdaps-devel
>