HDAPS, Need to park the head for real

HDAPS, Need to park the head for real

[Alejandro Bonilla Beeche]

Hi,

	We are currently almost there with hdaps. We are thinking how we should
make things and have made most of the decesions. We still need help from
anyone that might know about this. Please, if you can think of anything,
let us know.

The head_park script given by Jens Axboe was good for us, but we need to
park the head of the hard drive for a certain amount of time, please
call it 5 seconds or 10 seconds. I/We do not know how to make this
script to *park* the head for the selected amount of time.

Can anyone give us a clue?

Here is the current head_park
http://hdaps.sourceforge.net/head_park

Cheers,

.Alejandro

Re: HDAPS, Need to park the head for real

[Lee Revell]

On Tue, 2005-08-16 at 09:25 -0600, Alejandro Bonilla Beeche wrote:
> 	We are currently almost there with hdaps. We are thinking how we should
> make things and have made most of the decesions. We still need help from
> anyone that might know about this. Please, if you can think of anything,
> let us know.
> 

Please don't start a new thread for every little HDAPS issue.  It will
make it impossible to follow the development for archive users.  This
should have been a followup to the previous thread.

Lee

Re: HDAPS, Need to park the head for real

[Alejandro Bonilla Beeche]

On Tue, 2005-08-16 at 11:34 -0400, Lee Revell wrote:
> On Tue, 2005-08-16 at 09:25 -0600, Alejandro Bonilla Beeche wrote:
> > 	We are currently almost there with hdaps. We are thinking how we should
> > make things and have made most of the decesions. We still need help from
> > anyone that might know about this. Please, if you can think of anything,
> > let us know.
> > 
> 
> Please don't start a new thread for every little HDAPS issue.  It will
> make it impossible to follow the development for archive users.  This
> should have been a followup to the previous thread.
> 
> Lee

Lee,

	Sorry, the problem is that this IS the main *issue*, if we can figure
this out, we can go from there and get this working.

Previous threads were related to the fact that we needed a developer or
if we should either use sysfs or not.

This one is hopefully the last thread about this subject regarding
driver making.

Hopefully we can get an answer? ;-)

.Alejandro

Re: HDAPS, Need to park the head for real

[Jens Axboe]

On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote:
> Hi,
> 
> 	We are currently almost there with hdaps. We are thinking how we should
> make things and have made most of the decesions. We still need help from
> anyone that might know about this. Please, if you can think of anything,
> let us know.
> 
> The head_park script given by Jens Axboe was good for us, but we need to
> park the head of the hard drive for a certain amount of time, please
> call it 5 seconds or 10 seconds. I/We do not know how to make this
> script to *park* the head for the selected amount of time.

Ok, I'll give you some hints to get you started... What you really want
to do, is:

- Insert a park request at the front of the queue
- On completion callback on that request, freeze the block queue and
  schedule it for unfreeze after a given time

I would suggest some sysfs file for doing this. The best approach would
be to incorporate my generic command types (patch posted some months
ago), since that would allow you to add this sysfs file as just a
generic helper and let the drivers actually do what they need. That
would be the Right Approach, but to involved for your project I'm sure.

If I were in your position, I would just implement this for ide (pata,
not sata) right now, since that is what you need to support (or do some
of these notebooks come with sata?). So it follows that you add an ide
sysfs attribute for this and we integrate a proper solution once the
request type stuff is finalized. As the user api, I would suggest just
echoing a timeout in seconds to the file. So:

# echo 5 > /sys/block/hda/device/freeze

would park the head, freeze queue, and unfreeze in 5 seconds.

The sysfs write function for that file would allocate a request, fill in
the request as a REQ_DRIVE_TASKFILE with the command I listed in the
original program. The request->end_io function will inspect success of
the park command, and if successful freeze the queue. The freeze act
would probably just abuse queue->unplug_work to register a different
unplug worker that will restart the queue.

static void blk_unfreeze_work(void *data)
{
        request_queue_t *q = work;

        INIT_WORK(&q->unplug_work, blk_unplug_work, q);

        blk_start_queue(q);
}

static void blk_unfreeze_timeout(unsigned long data)
{
        request_queue_t *q = (request_queue_t *) data;

        INIT_WORK(&q->unplug_work, blk_unfreeze_work, q);
        q->unplug_timer.function = blk_unplug_timeout;
}

void blk_freeze_queue(request_queue_t *q, int seconds)
{
        blk_stop_queue(q);
        INIT_WORK(&q->unplug_work, blk_unfreeze_work, q);
        q->unplug_timer.function = blk_unfreeze_timeout;
        mod_timer(&q->unplug_timer, msecs_to_jiffies(seconds*1000) + jiffies);
}

Totally untested and pretty hacky, but should work for a plain IDE
device (since it uses generic plugging, only the stacked devices alter
this). You should get the drift.

You may have to prevent IDE from re-entering the queueing handler on
finished completion of the park request, the best approach is likely to
check for a stopped queue in the ide request handler.

-- 
Jens Axboe

Re: HDAPS, Need to park the head for real

[Alejandro Bonilla Beeche]

On Tue, 2005-08-16 at 22:07 +0200, Jens Axboe wrote:
> On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote:
> If I were in your position, I would just implement this for ide (pata,
> not sata) right now, since that is what you need to support (or do some
> of these notebooks come with sata?). So it follows that you add an ide

Some notebooks are coming up with a Sata controller I think, but is
still and IDE drive. I think some T43's come with that.

But, I will ask or check again later if we ever need this feature for
SATA.

.Alejandro

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Yani Ioannou]

On 8/16/05, Alejandro Bonilla Beeche <abonilla@linuxwireless.org> wrote:
> On Tue, 2005-08-16 at 22:07 +0200, Jens Axboe wrote:
> > On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote:
> > If I were in your position, I would just implement this for ide (pata,
> > not sata) right now, since that is what you need to support (or do some
> > of these notebooks come with sata?). So it follows that you add an ide
> 
> Some notebooks are coming up with a Sata controller I think, but is
> still and IDE drive. I think some T43's come with that.
> 
> But, I will ask or check again later if we ever need this feature for
> SATA.

I believe T43s use a SATA->PATA bridge for their hard drives, so we
probably would.

(see http://www.thinkwiki.org/wiki/Category_talk:T43).

Yani

Re: HDAPS, Need to park the head for real

[Jens Axboe]

On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote:
> On Tue, 2005-08-16 at 22:07 +0200, Jens Axboe wrote:
> > On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote:
> > If I were in your position, I would just implement this for ide (pata,
> > not sata) right now, since that is what you need to support (or do some
> > of these notebooks come with sata?). So it follows that you add an ide
> 
> Some notebooks are coming up with a Sata controller I think, but is
> still and IDE drive. I think some T43's come with that.
> 
> But, I will ask or check again later if we ever need this feature for
> SATA.

Doing it for sata as well is just a little more work. The generic code
is the same, but you probably need to add a per-queue hook for filling
the request with the proper command setup. For ide that would be a
REQ_DRIVE_TASKFILE, for libata you need to look at the pass through
stuff. Everything else still applies.

You're welcome,
-- 
Jens Axboe

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Jon Escombe]

>>>On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote:
>>>If I were in your position, I would just implement this for ide (pata,
>>>not sata) right now, since that is what you need to support (or do some
>>>of these notebooks come with sata?). So it follows that you add an ide
>>>      
>>>
>>Some notebooks are coming up with a Sata controller I think, but is
>>still and IDE drive. I think some T43's come with that.
>>
>>But, I will ask or check again later if we ever need this feature for
>>SATA.
>>    
>>
I can confirm that T43's are using libata.
I've tweaked the passthrough code to return the status registers (so we 
can tell whether the disk is parking sucessfully) 
http://groups.google.co.uk/group/fa.linux.kernel/browse_frm/thread/bd6b65dfcd1a3227

Regards,
Jon.



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

Re: HDAPS, Need to park the head for real

[Avi Kivity]

Jens Axboe wrote:

>Ok, I'll give you some hints to get you started... What you really want
>to do, is:
>
>- Insert a park request at the front of the queue
>- On completion callback on that request, freeze the block queue and
>  schedule it for unfreeze after a given time
>
>  
>
how will this interact with command queuing? there is a danger from both 
commands previously queued but not yet completed, and commands that are 
queued after the park request. or is the park request a barrier?

Re: HDAPS, Need to park the head for real

[Jens Axboe]

On Wed, Aug 17 2005, Avi Kivity wrote:
> Jens Axboe wrote:
> 
> >Ok, I'll give you some hints to get you started... What you really want
> >to do, is:
> >
> >- Insert a park request at the front of the queue
> >- On completion callback on that request, freeze the block queue and
> > schedule it for unfreeze after a given time
> >
> > 
> >
> how will this interact with command queuing? there is a danger from both 
> commands previously queued but not yet completed, and commands that are 
> queued after the park request. or is the park request a barrier?

It doesn't interact with queueing, it doesn't matter what else is in the
queue. The park itself is not a barrier, since it should be placed as
next-to-execute at the front of the queue. Non-fs requests are never
reordered once inserted (since sorting on them doesn't make sense, the
io scheduler doesn't know what they are). Since the queue will not be
processed after the park has completed (it is frozen). So if the queue
currently looks like this:

[R0] <-> R1 <-> R2 <-> W1 <-> R3 <-> W2

(R is read, W is write, R0 is currently being processed), when you issue
the park the queue will look like:

[R0] <-> PARK <-> R1 <-> R2 <-> W1 <-> R3 <-> W2

Read completes, PARK will now be executed. While this happens, two more
writes are inserted somewhere in the queue. If successful, queue is
frozen in this state:

[] <-> R1 <-> W4 <-> R2 <-> W1 <-> W3 <-> R3 <-> W2

When the queue is thawed, R1 will be sent next.

-- 
Jens Axboe

Re: HDAPS, Need to park the head for real

[Pavel Machek]

Hi!

> I would suggest some sysfs file for doing this. The best approach would

Actually it is usefull for other devices, too... for power saving.

Some people call it "runtime power managment".

> sysfs attribute for this and we integrate a proper solution once the
> request type stuff is finalized. As the user api, I would suggest just
> echoing a timeout in seconds to the file. So:
> 
> # echo 5 > /sys/block/hda/device/freeze
> 
> would park the head, freeze queue, and unfreeze in 5 seconds.

Please make it "echo 1 > frozen", then userspace can do "echo 0 > frozen"
after five seconds.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: HDAPS, Need to park the head for real

[Adam Goode]

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

On Thu, 2005-08-18 at 22:49 +0200, Pavel Machek wrote:
> Please make it "echo 1 > frozen", then userspace can do "echo 0 > frozen"
> after five seconds.


What if the code to do "echo 0 > frozen" is swapped out to disk? ;)


Thanks,

Adam


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Dave Hansen]

On Thu, 2005-08-18 at 17:15 -0400, Adam Goode wrote:
> On Thu, 2005-08-18 at 22:49 +0200, Pavel Machek wrote:
> > Please make it "echo 1 > frozen", then userspace can do "echo 0 > frozen"
> > after five seconds.
>
> What if the code to do "echo 0 > frozen" is swapped out to disk? ;)

In the real world, to be really sure that you're not doing a trip out to
the disk, you'll need a daemon which doesn't do any allocations between
when it's notified and when it does the write to the control file.

In reality, that probably means a statically compiled daemon that
mlock()s itself, and any structures that it will need.  It _might_ even
need to keep an open file descriptor on the "frozen" file.  Because, in
theory, that file could be written out to the sysfs backing store.

-- Dave

Re: HDAPS, Need to park the head for real

[Pavel Machek]

Hi!

> > Please make it "echo 1 > frozen", then userspace can do "echo 0 > frozen"
> > after five seconds.
> 
> What if the code to do "echo 0 > frozen" is swapped out to disk? ;)

Emergency head parker needs to be pagelocked for other reasons. You do
not want to page it from disk while your notebook is in free fall.

								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: HDAPS, Need to park the head for real

[Jens Axboe]

On Thu, Aug 18 2005, Pavel Machek wrote:
> Hi!
> 
> > > Please make it "echo 1 > frozen", then userspace can do "echo 0 > frozen"
> > > after five seconds.
> > 
> > What if the code to do "echo 0 > frozen" is swapped out to disk? ;)
> 
> Emergency head parker needs to be pagelocked for other reasons. You do
> not want to page it from disk while your notebook is in free fall.

It's still a very bad idea imho, what if the head parker daemon is
killed for other reasons? The automatic timeout thawing the drive is
much saner.

-- 
Jens Axboe

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Jon Escombe]

>>>>Please make it "echo 1 > frozen", then userspace can do "echo 0 > frozen"
>>>>after five seconds.
>>>>        
>>>>
>>>What if the code to do "echo 0 > frozen" is swapped out to disk? ;)
>>>      
>>>
>>Emergency head parker needs to be pagelocked for other reasons. You do
>>not want to page it from disk while your notebook is in free fall.
>>    
>>
>
>It's still a very bad idea imho, what if the head parker daemon is
>killed for other reasons? The automatic timeout thawing the drive is
>much saner.
>  
>
For hard disk protection, I prefer the idea of the userspace code 
thawing the drive based on current accelerometer data, rather than 
simply waking up after x seconds (maybe you're running for a bus rather 
than falling off a table)...

To get the best of both worlds, could we maybe take a watchdog timer 
approach, and have the timeout reset by the userspace component 
periodically re-requesting freeze?

Regards,
Jon.


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

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Jens Axboe]

On Fri, Aug 19 2005, Jon Escombe wrote:
> 
> >>>>Please make it "echo 1 > frozen", then userspace can do "echo 0 > 
> >>>>frozen"
> >>>>after five seconds.
> >>>>       
> >>>>
> >>>What if the code to do "echo 0 > frozen" is swapped out to disk? ;)
> >>>     
> >>>
> >>Emergency head parker needs to be pagelocked for other reasons. You do
> >>not want to page it from disk while your notebook is in free fall.
> >>   
> >>
> >
> >It's still a very bad idea imho, what if the head parker daemon is
> >killed for other reasons? The automatic timeout thawing the drive is
> >much saner.
> > 
> >
> For hard disk protection, I prefer the idea of the userspace code 
> thawing the drive based on current accelerometer data, rather than 
> simply waking up after x seconds (maybe you're running for a bus rather 
> than falling off a table)...
> 
> To get the best of both worlds, could we maybe take a watchdog timer 
> approach, and have the timeout reset by the userspace component 
> periodically re-requesting freeze?

That would work, you can just define the semantics to be that echo
foo > frozen would add foo seconds to the timeout (or thaw it, if foo is
0).

-- 
Jens Axboe

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Stefan Rompf]

Dave Hansen wrote:

> In reality, that probably means a statically compiled daemon that
> mlock()s itself, and any structures that it will need.  It _might_ even
> need to keep an open file descriptor on the "frozen" file.  Because, in
> theory, that file could be written out to the sysfs backing store.

with such a hassle to make the parking API available, assure that the head 
parking daemon is not swapped out, can access the filedescriptor, has a 
priority high enough to start immediatly when needed, wouldn't that qualify 
for running in kernel space?

Stefan

RE: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Alejandro Bonilla]

> On Fri, Aug 19 2005, Jon Escombe wrote:
> > For hard disk protection, I prefer the idea of the userspace code
> > thawing the drive based on current accelerometer data, rather than
> > simply waking up after x seconds (maybe you're running for
> a bus rather
> > than falling off a table)...
> >
> > To get the best of both worlds, could we maybe take a
> watchdog timer
> > approach, and have the timeout reset by the userspace component
> > periodically re-requesting freeze?
>
> That would work, you can just define the semantics to be that echo
> foo > frozen would add foo seconds to the timeout (or thaw
> it, if foo is
> 0).

This one is really a hard one to ask for. I mean, if we can make it the way
that it will keep knowing that the accel is changing heavily, then it would
be great. This way we/users can implement other actions as well, not only
for HDAPS, but the fact of kicking any other daemon that we want to. i.e.
The theft system, kicking in laptop_mode if there is soft vibration for a
certain amount of seconds, making festival tell you that the PC is being
moved... Anything!

The fact is also that if we would only make a driver for HDAPS, we could
simply make it freeze for 8 seconds and done. How often do you drop the
laptop? How long does it take even if it rolls down the stairs? 4 Seconds
tops? But then, the driver would be boring. ;-)

.Alejandro

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Jon Escombe]

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

Jens Axboe wrote:

> Ok, I'll give you some hints to get you started... What you really want
>
>to do, is:
>
>- Insert a park request at the front of the queue
>- On completion callback on that request, freeze the block queue and
>  schedule it for unfreeze after a given time
>  
>

Am attaching a first attempt at a patch - for comments only - please 
don't apply to a production system. I've not delved into the IDE code 
before, so I've just been following my nose... In other words - It 
appears to work for me - but I may be doing something crazy ;)

Having said that, I tested with a utility that repeatedly froze/thawed 
hundreds of times while really hammering the disk with file copies, and 
nothing oopsed or failed to checksum afterwards...

To do:

Move the /proc interface to sysfs. At the moment it's just a simple 
'echo -n 1 > /proc/ide/hda/freeze' to freeze, and 0 to thaw.

Address Jens concerns about our userspace code falling over and leaving 
the machine hung. I favour retaining a binary on/off interface (rather 
than specifying a timeout up front), but having the IDE code auto-thaw 
on a timer.. That way we can just keep writing 1's to it while we're 
checking the accelerometer and wanting to keep it frozen, and if we 
should die then it'll wake up by itself after a second or so...

Same again for libata (for T43 owners).

Regards,
Jon.



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

[-- Attachment #2: ide_freeze.patch --]
[-- Type: text/x-patch, Size: 4882 bytes --]

diff -urN linux-2.6.13-rc6.original/drivers/ide/ide-io.c linux-2.6.13-rc6/drivers/ide/ide-io.c
--- linux-2.6.13-rc6.original/drivers/ide/ide-io.c	2005-06-17 20:48:29.000000000 +0100
+++ linux-2.6.13-rc6/drivers/ide/ide-io.c	2005-08-24 20:56:31.000000000 +0100
@@ -1181,6 +1181,16 @@
 		}
 
 		/*
+		 * Don't accept a request when the queue is stopped
+		 * (unless we are resuming from suspend)
+		 */
+		if (test_bit(QUEUE_FLAG_STOPPED, &drive->queue->queue_flags) && !blk_pm_resume_request(rq)) {
+			printk(KERN_ERR "%s: queue is stopped!\n", drive->name);
+			hwgroup->busy = 0;
+			break;
+		}
+
+		/*
 		 * Sanity: don't accept a request that isn't a PM request
 		 * if we are currently power managed. This is very important as
 		 * blk_stop_queue() doesn't prevent the elv_next_request()
@@ -1661,6 +1671,9 @@
 		where = ELEVATOR_INSERT_FRONT;
 		rq->flags |= REQ_PREEMPT;
 	}
+	if (action == ide_next)
+		where = ELEVATOR_INSERT_FRONT;
+
 	__elv_add_request(drive->queue, rq, where, 0);
 	ide_do_request(hwgroup, IDE_NO_IRQ);
 	spin_unlock_irqrestore(&ide_lock, flags);
diff -urN linux-2.6.13-rc6.original/drivers/ide/ide-proc.c linux-2.6.13-rc6/drivers/ide/ide-proc.c
--- linux-2.6.13-rc6.original/drivers/ide/ide-proc.c	2005-06-17 20:48:29.000000000 +0100
+++ linux-2.6.13-rc6/drivers/ide/ide-proc.c	2005-08-24 21:51:14.000000000 +0100
@@ -264,6 +264,122 @@
 	return -EINVAL;
 }
 
+static int proc_ide_read_freeze
+	(char *page, char **start, off_t off, int count, int *eof, void *data)
+{
+	ide_drive_t	*drive = (ide_drive_t *) data;
+	char		*out = page;
+	int		len;
+
+	proc_ide_settings_warn();
+
+	if (test_bit(QUEUE_FLAG_STOPPED, &drive->queue->queue_flags))
+		out += sprintf(out, "%s: queue is stopped\n", drive->name);
+	else
+		out += sprintf(out, "%s: queue not stopped\n", drive->name);
+
+	len = out - page;
+	PROC_IDE_READ_RETURN(page,start,off,count,eof,len);
+}
+
+void ide_end_freeze_rq(struct request *rq)
+{
+	struct completion	*waiting = rq->waiting;
+	u8			*argbuf = rq->buffer;
+
+	/* Spinlock is already acquired */
+	if (argbuf[3] == 0xc4) {
+		blk_stop_queue(rq->q);
+		printk(KERN_ERR "ide_end_freeze_rq(): Queue stopped...\n");
+	}
+	else
+		printk(KERN_ERR "ide_end_freeze_rq(): Head not parked...\n");
+/*
+	blk_stop_queue(rq->q);
+	printk(KERN_ERR "ide_end_freeze_rq(): Queue stopped...\n");
+*/
+	complete(waiting);
+}
+
+static int proc_ide_write_freeze(struct file *file, const char __user *buffer,
+				   unsigned long count, void *data)
+{
+	DECLARE_COMPLETION(wait);
+	unsigned long	val, flags;
+	char 		*buf, *s;	
+	struct request	rq;
+	ide_drive_t	*drive = (ide_drive_t *) data;
+	u8 		args[7], *argbuf = args;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	proc_ide_settings_warn();
+
+	if (count >= PAGE_SIZE)
+		return -EINVAL;
+
+	s = buf = (char *)__get_free_page(GFP_USER);
+	if (!buf)
+		return -ENOMEM;
+
+	if (copy_from_user(buf, buffer, count)) {
+		free_page((unsigned long)buf);
+		return -EFAULT;
+	}
+
+	buf[count] = '\0';
+	memset(&rq, 0, sizeof(rq));
+	memset(&args, 0, sizeof(args));
+
+	/* Ought to check we're the right sort of device - i.e. hard disk only */
+
+	/* STANDY IMMEDIATE COMMAND (spins down drive - more obvious for testing?)
+	argbuf[0] = 0xe0;
+	*/
+
+	/* UNLOAD IMMEDIATE COMMAND */
+	argbuf[0] = 0xe1;
+	argbuf[1] = 0x44;
+	argbuf[3] = 0x4c;
+	argbuf[4] = 0x4e;
+	argbuf[5] = 0x55;
+
+	/* Ought to have some sanity checking around these values */
+	val = simple_strtoul(buf, &s, 10);
+	if (val) {
+		/* Check we're not already frozen */
+		if (!test_bit(QUEUE_FLAG_STOPPED, &drive->queue->queue_flags)) {
+			/* Issue the park command & freeze */
+			ide_init_drive_cmd(&rq);
+
+			rq.flags = REQ_DRIVE_TASK;
+			rq.buffer = argbuf;
+			rq.waiting = &wait;
+			rq.end_io = ide_end_freeze_rq;
+
+			ide_do_drive_cmd(drive, &rq, ide_next);
+			wait_for_completion(&wait);
+			rq.waiting = NULL;
+		}
+		else
+			printk(KERN_ERR "proc_ide_write_freeze(): Queue already stopped...\n");
+	}
+	else {
+		/* Check we are frozen & unfreeze */ 
+		if (test_bit(QUEUE_FLAG_STOPPED, &drive->queue->queue_flags)) {
+			spin_lock_irqsave(&ide_lock, flags);
+			blk_start_queue(drive->queue);
+			spin_unlock_irqrestore(&ide_lock, flags);
+			printk(KERN_ERR "proc_ide_write_freeze(): Queue started...\n");
+		}
+		else
+			printk(KERN_ERR "proc_ide_write_freeze(): Queue not stopped...\n");
+	}
+	free_page((unsigned long)buf);
+	return count;
+}
+
 int proc_ide_read_capacity
 	(char *page, char **start, off_t off, int count, int *eof, void *data)
 {
@@ -390,6 +506,7 @@
 	{ "media",	S_IFREG|S_IRUGO,	proc_ide_read_media,	NULL },
 	{ "model",	S_IFREG|S_IRUGO,	proc_ide_read_dmodel,	NULL },
 	{ "settings",	S_IFREG|S_IRUSR|S_IWUSR,proc_ide_read_settings,	proc_ide_write_settings },
+	{ "freeze",	S_IFREG|S_IRUSR|S_IWUSR,proc_ide_read_freeze,	proc_ide_write_freeze },
 	{ NULL,	0, NULL, NULL }
 };
 

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Alan Cox]

You need the kernel side timeout. Consider this case

One page of memory holds the parking code
A second page is swapped to disk and holds the resume code

You park the disk
You wakeup
You got to page in the resume code

So you really do want the kernel helping to avoid a deadlock

@@ -1661,6 +1671,9 @@
                where = ELEVATOR_INSERT_FRONT;
                rq->flags |= REQ_PREEMPT;
        }
+       if (action == ide_next)
+               where = ELEVATOR_INSERT_FRONT;
+
        __elv_add_request(drive->queue, rq, where, 0);
        ide_do_request(hwgroup, IDE_NO_IRQ);
        spin_unlock_irqrestore(&ide_lock, flags);

Also puzzles me- why is this needed ?

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Jon Escombe]

Alan Cox wrote:
> @@ -1661,6 +1671,9 @@
>                 where = ELEVATOR_INSERT_FRONT;
>                 rq->flags |= REQ_PREEMPT;
>         }
> +       if (action == ide_next)
> +               where = ELEVATOR_INSERT_FRONT;
> +
>         __elv_add_request(drive->queue, rq, where, 0);
>         ide_do_request(hwgroup, IDE_NO_IRQ);
>         spin_unlock_irqrestore(&ide_lock, flags);
> 
> Also puzzles me- why is this needed ?

I wanted the park command to get in at the head of the queue (behind the 
currently executing request).

Contrary to the comments for ide_do_drive_cmd(), ide_next didn't appear 
to do anything to achieve this? At least from my initial testing before 
I made this change - it could take a second or so for the park command 
to be issued if the disk was busy....

Regards,
Jon.

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

Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real

[Jens Axboe]

On Thu, Aug 25 2005, Jon Escombe wrote:
> Alan Cox wrote:
> >@@ -1661,6 +1671,9 @@
> >                where = ELEVATOR_INSERT_FRONT;
> >                rq->flags |= REQ_PREEMPT;
> >        }
> >+       if (action == ide_next)
> >+               where = ELEVATOR_INSERT_FRONT;
> >+
> >        __elv_add_request(drive->queue, rq, where, 0);
> >        ide_do_request(hwgroup, IDE_NO_IRQ);
> >        spin_unlock_irqrestore(&ide_lock, flags);
> >
> >Also puzzles me- why is this needed ?
> 
> I wanted the park command to get in at the head of the queue (behind the 
> currently executing request).
> 
> Contrary to the comments for ide_do_drive_cmd(), ide_next didn't appear 
> to do anything to achieve this? At least from my initial testing before 
> I made this change - it could take a second or so for the park command 
> to be issued if the disk was busy....

That part seems to have been lost, apparently. The above patch is
correct.

-- 
Jens Axboe