Re: [PATCH] scsi_execute_async() should add to the tail of the queue
Jens Axboe wrote: > On Tue, Dec 19 2006, Arjan van de Ven wrote: >> On Tue, 2006-12-19 at 10:35 +0200, Dan Aloni wrote: >>> Hello, >>> >>> scsi_execute_async() has replaced scsi_do_req() a few versions ago, >>> but it also incurred a change of behavior. I noticed that over-queuing >>> a SCSI device using that function causes I/Os to be starved from >>> low-level queuing for no justified reason. >>> >>> I think it makes much more sense to perserve the original behaviour >>> of scsi_do_req() and add the request to the tail of the queue. >> Hi, >> >> some things should really be added to the head of the queue, like >> maintenance requests and error handling requests. Are you sure this is >> the right change? At least I'd expect 2 apis, one for a head and one for >> a "normal" queueing... > > It does sounds broken - head insertion should only be used for careful > internal commands, not be the default way user issued commands. Looking > at the current users, the patch makes sense to me. > It's worth noting that the hdaps disk protection patches rely on the current behaviour to add 'IDLE IMMEDIATE WITH UNLOAD' commands to the head of the queue.. Another function, or a new parameter for queue position would be needed to retain this functionality - any preference for either? Regards, Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi_execute_async() should add to the tail of the queue
Jens Axboe wrote: On Tue, Dec 19 2006, Arjan van de Ven wrote: On Tue, 2006-12-19 at 10:35 +0200, Dan Aloni wrote: Hello, scsi_execute_async() has replaced scsi_do_req() a few versions ago, but it also incurred a change of behavior. I noticed that over-queuing a SCSI device using that function causes I/Os to be starved from low-level queuing for no justified reason. I think it makes much more sense to perserve the original behaviour of scsi_do_req() and add the request to the tail of the queue. Hi, some things should really be added to the head of the queue, like maintenance requests and error handling requests. Are you sure this is the right change? At least I'd expect 2 apis, one for a head and one for a normal queueing... It does sounds broken - head insertion should only be used for careful internal commands, not be the default way user issued commands. Looking at the current users, the patch makes sense to me. It's worth noting that the hdaps disk protection patches rely on the current behaviour to add 'IDLE IMMEDIATE WITH UNLOAD' commands to the head of the queue.. Another function, or a new parameter for queue position would be needed to retain this functionality - any preference for either? Regards, Jon. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is there any Hard-disk shock-protection for 2.6.18 and above?
Jens Axboe oracle.com> writes: > > On Tue, Nov 21 2006, Pavel Machek wrote: > > Hi! > > > > > Well, the actual question is the following, > > > I read about HDAPS on thinkWiki. But there is no known-to-work patch for > > > 2.6.18 and above to enable queue-freezing/harddisk parking. > > > After some googeling and digging in gamne i read that someone said that > > > there are plans for some generic support for HD-parking in the kernel > > > and thus making such patches obsolete. > > > My quesiotn just is if this is true and if there are any chances that > > > the kernel will support that soonly. > > ... > > > So i hope this issue can be adressed soon. but i also know that most of > > > you are very busy and i can not evaluate how difficult such a change > > > would be. However if anyone wants to test some things or more > > > information, i am ready. Just CC me :) > > > > I'm afraid we need your help with development here. Porting old patch > > to 2.6.19-rc6 should be easy, and then you can start 'how do I > > makethis generic' debate. > > 2.6.19 will finally have the generic block layer commands, so this can > be implemented properly. > That's good to know. Sounds like we'll be able to have another attempt at getting this functionality upstream.. In the meantime, the current code has been cleaned up and updated to work with 2.6.18. Patches are on the hdaps-devel list. http://sourceforge.net/mailarchive/forum.php?forum=hdaps-devel (or gmane for an easier view ;) Regards, Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is there any Hard-disk shock-protection for 2.6.18 and above?
Jens Axboe jens.axboe at oracle.com writes: On Tue, Nov 21 2006, Pavel Machek wrote: Hi! Well, the actual question is the following, I read about HDAPS on thinkWiki. But there is no known-to-work patch for 2.6.18 and above to enable queue-freezing/harddisk parking. After some googeling and digging in gamne i read that someone said that there are plans for some generic support for HD-parking in the kernel and thus making such patches obsolete. My quesiotn just is if this is true and if there are any chances that the kernel will support that soonly. ... So i hope this issue can be adressed soon. but i also know that most of you are very busy and i can not evaluate how difficult such a change would be. However if anyone wants to test some things or more information, i am ready. Just CC me :) I'm afraid we need your help with development here. Porting old patch to 2.6.19-rc6 should be easy, and then you can start 'how do I makethis generic' debate. 2.6.19 will finally have the generic block layer commands, so this can be implemented properly. That's good to know. Sounds like we'll be able to have another attempt at getting this functionality upstream.. In the meantime, the current code has been cleaned up and updated to work with 2.6.18. Patches are on the hdaps-devel list. http://sourceforge.net/mailarchive/forum.php?forum=hdaps-devel (or gmane for an easier view ;) Regards, Jon. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real
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(_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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real
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) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real
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)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.0 +0100
+++ linux-2.6.13-rc6/drivers/ide/ide-io.c 2005-08-24 20:56:31.0 +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, >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(_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.0 +0100
+++ linux-2.6.13-rc6/drivers/ide/ide-proc.c 2005-08-24 21:51:14.0 +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, >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(, 0, sizeof(rq));
+ memset(, 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, , 10);
+ if (val) {
+ /* Check we're not already frozen */
+
Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real
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)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.0 +0100
+++ linux-2.6.13-rc6/drivers/ide/ide-io.c 2005-08-24 20:56:31.0 +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.0 +0100
+++ linux-2.6.13-rc6/drivers/ide/ide-proc.c 2005-08-24 21:51:14.0 +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
Re: [patch] libata passthrough - return register data from HDIO_* commands
John W. Linville wrote: On Fri, Aug 19, 2005 at 03:06:27PM -0400, John W. Linville wrote: On Mon, Aug 15, 2005 at 11:11:02PM +0100, Jon Escombe wrote: Here is a first attempt at a patch to return register data from the libata passthrough HDIO ioctl handlers, I needed this as the ATA 'unload immediate' command returns the success in the lbal register. Overall, I like the patch. I trust your assertion that it actually works... :-) I have a few comments... Well, apparently "Jon Escombe <[EMAIL PROTECTED]>" is not a good address. I got a delivery failur notification email from his mail server. Hopefully Jon reads the lists... :-) John Thanks, will take a look at the comments. Not sure why the email bounced, but I will give you another email address so you could forward me the notification (if you still have it?) Regards, Jon. __ Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real
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) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] libata passthrough - return register data from HDIO_* commands
John W. Linville wrote: On Fri, Aug 19, 2005 at 03:06:27PM -0400, John W. Linville wrote: On Mon, Aug 15, 2005 at 11:11:02PM +0100, Jon Escombe wrote: Here is a first attempt at a patch to return register data from the libata passthrough HDIO ioctl handlers, I needed this as the ATA 'unload immediate' command returns the success in the lbal register. Overall, I like the patch. I trust your assertion that it actually works... :-) I have a few comments... Well, apparently Jon Escombe [EMAIL PROTECTED] is not a good address. I got a delivery failur notification email from his mail server. Hopefully Jon reads the lists... :-) John Thanks, will take a look at the comments. Not sure why the email bounced, but I will give you another email address so you could forward me the notification (if you still have it?) Regards, Jon. __ Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real
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) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] libata passthrough - return register data from HDIO_* commands
Here is a first attempt at a patch to return register data from the
libata passthrough HDIO ioctl handlers, I needed this as the ATA
'unload immediate' command returns the success in the lbal register.
This patch applies on top of 2.6.12 and Jeffs
2.6.12-git4-passthru1.patch. (Apologies, but Thunderbird appears to
have replaced the tabs with spaces).
One oddity is that the sr_result field is correctly being set in
ata_gen_ata_desc_sense(), however the high word is different when
we're back in the ioctl hander. I've coded round this for now by only
checking the low word, but this needs more investigation.
Jeff, could this functionality be incorporated into the pasthrough
patch when complete?
I'd failed to realise that scsi_finish_command() sets the high byte of
the result field to DRIVER_SENSE when there is sense data. Patch updated
to reflect this...
Haven't had any feedback on the patch itself - but this now does what I
wanted it do to. (I can't find a way to make Thunderbird retain tabs in
the message body, so sending as an attachment).
Regards,
Jon.
__
Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk)--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -89,6 +89,7 @@
u8 args[4], *argbuf = NULL;
int argsize = 0;
struct scsi_request *sreq;
+ unsigned char *sb, *desc;
if (NULL == (void *)arg)
return -EINVAL;
@@ -100,6 +101,9 @@
if (!sreq)
return -EINTR;
+ sb = sreq->sr_sense_buffer;
+ desc = sb + 8;
+
memset(scsi_cmd, 0, sizeof(scsi_cmd));
if (args[3]) {
@@ -109,12 +113,12 @@
return -ENOMEM;
scsi_cmd[1] = (4 << 1); /* PIO Data-in */
- scsi_cmd[2] = 0x0e; /* no off.line or cc, read from dev,
+ scsi_cmd[2] = 0x2e; /* no off.line, read from dev, request cc
block count in sector count field */
sreq->sr_data_direction = DMA_FROM_DEVICE;
} else {
scsi_cmd[1] = (3 << 1); /* Non-data */
- /* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
+ scsi_cmd[2] = 0x20; /* no off.line or data xfer, request check condtion */
sreq->sr_data_direction = DMA_NONE;
}
@@ -135,16 +139,24 @@
from scsi_ioctl_send_command() for default case... */
scsi_wait_req(sreq, scsi_cmd, argbuf, argsize, (10*HZ), 5);
- if (sreq->sr_result) {
+ if (!sreq->sr_result == ((DRIVER_SENSE << 24) + SAM_STAT_CHECK_CONDITION)) {
rc = -EIO;
goto error;
}
- /* Need code to retrieve data from check condition? */
+ /* Retrieve data from check condition */
+ args[1] = desc[3];
+ args[2] = desc[5];
+ args[3] = desc[7];
+ args[4] = desc[9];
+ args[5] = desc[11];
+ args[0] = desc[13];
if ((argbuf)
&& copy_to_user((void *)(arg + sizeof(args)), argbuf, argsize))
rc = -EFAULT;
+ if (copy_to_user(arg, args, sizeof(args)))
+ rc = -EFAULT;
error:
scsi_release_request(sreq);
@@ -171,6 +183,7 @@
u8 scsi_cmd[MAX_COMMAND_SIZE];
u8 args[7];
struct scsi_request *sreq;
+ unsigned char *sb, *desc;
if (NULL == (void *)arg)
return -EINVAL;
@@ -181,7 +194,7 @@
memset(scsi_cmd, 0, sizeof(scsi_cmd));
scsi_cmd[0] = ATA_16;
scsi_cmd[1] = (3 << 1); /* Non-data */
- /* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
+ scsi_cmd[2] = 0x20; /* no off.line, or data xfer, request cc */
scsi_cmd[4] = args[1];
scsi_cmd[6] = args[2];
scsi_cmd[8] = args[3];
@@ -195,18 +208,29 @@
goto error;
}
+ sb = sreq->sr_sense_buffer;
+ desc = sb + 8;
+
sreq->sr_data_direction = DMA_NONE;
/* Good values for timeout and retries? Values below
from scsi_ioctl_send_command() for default case... */
scsi_wait_req(sreq, scsi_cmd, NULL, 0, (10*HZ), 5);
- if (sreq->sr_result) {
+ if (!sreq->sr_result == ((DRIVER_SENSE << 24) + SAM_STAT_CHECK_CONDITION)) {
rc = -EIO;
goto error;
}
- /* Need code to retrieve data from check condition? */
+ /* Retrieve data from check condition */
+ args[1] = desc[3];
+ args[2] = desc[5];
+ args[3] = desc[7];
+ args[4] = desc[9];
+ args[5] = desc[11];
+ args[0] = desc[13];
+ if (copy_to_user(arg, args, sizeof(args)))
+ rc = -EFAULT;
error:
scsi_release_request(sreq);
return rc;
Re: [patch] libata passthrough - return register data from HDIO_* commands
Here is a first attempt at a patch to return register data from the
libata passthrough HDIO ioctl handlers, I needed this as the ATA
'unload immediate' command returns the success in the lbal register.
This patch applies on top of 2.6.12 and Jeffs
2.6.12-git4-passthru1.patch. (Apologies, but Thunderbird appears to
have replaced the tabs with spaces).
One oddity is that the sr_result field is correctly being set in
ata_gen_ata_desc_sense(), however the high word is different when
we're back in the ioctl hander. I've coded round this for now by only
checking the low word, but this needs more investigation.
Jeff, could this functionality be incorporated into the pasthrough
patch when complete?
I'd failed to realise that scsi_finish_command() sets the high byte of
the result field to DRIVER_SENSE when there is sense data. Patch updated
to reflect this...
Haven't had any feedback on the patch itself - but this now does what I
wanted it do to. (I can't find a way to make Thunderbird retain tabs in
the message body, so sending as an attachment).
Regards,
Jon.
__
Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk)--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -89,6 +89,7 @@
u8 args[4], *argbuf = NULL;
int argsize = 0;
struct scsi_request *sreq;
+ unsigned char *sb, *desc;
if (NULL == (void *)arg)
return -EINVAL;
@@ -100,6 +101,9 @@
if (!sreq)
return -EINTR;
+ sb = sreq-sr_sense_buffer;
+ desc = sb + 8;
+
memset(scsi_cmd, 0, sizeof(scsi_cmd));
if (args[3]) {
@@ -109,12 +113,12 @@
return -ENOMEM;
scsi_cmd[1] = (4 1); /* PIO Data-in */
- scsi_cmd[2] = 0x0e; /* no off.line or cc, read from dev,
+ scsi_cmd[2] = 0x2e; /* no off.line, read from dev, request cc
block count in sector count field */
sreq-sr_data_direction = DMA_FROM_DEVICE;
} else {
scsi_cmd[1] = (3 1); /* Non-data */
- /* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
+ scsi_cmd[2] = 0x20; /* no off.line or data xfer, request check condtion */
sreq-sr_data_direction = DMA_NONE;
}
@@ -135,16 +139,24 @@
from scsi_ioctl_send_command() for default case... */
scsi_wait_req(sreq, scsi_cmd, argbuf, argsize, (10*HZ), 5);
- if (sreq-sr_result) {
+ if (!sreq-sr_result == ((DRIVER_SENSE 24) + SAM_STAT_CHECK_CONDITION)) {
rc = -EIO;
goto error;
}
- /* Need code to retrieve data from check condition? */
+ /* Retrieve data from check condition */
+ args[1] = desc[3];
+ args[2] = desc[5];
+ args[3] = desc[7];
+ args[4] = desc[9];
+ args[5] = desc[11];
+ args[0] = desc[13];
if ((argbuf)
copy_to_user((void *)(arg + sizeof(args)), argbuf, argsize))
rc = -EFAULT;
+ if (copy_to_user(arg, args, sizeof(args)))
+ rc = -EFAULT;
error:
scsi_release_request(sreq);
@@ -171,6 +183,7 @@
u8 scsi_cmd[MAX_COMMAND_SIZE];
u8 args[7];
struct scsi_request *sreq;
+ unsigned char *sb, *desc;
if (NULL == (void *)arg)
return -EINVAL;
@@ -181,7 +194,7 @@
memset(scsi_cmd, 0, sizeof(scsi_cmd));
scsi_cmd[0] = ATA_16;
scsi_cmd[1] = (3 1); /* Non-data */
- /* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
+ scsi_cmd[2] = 0x20; /* no off.line, or data xfer, request cc */
scsi_cmd[4] = args[1];
scsi_cmd[6] = args[2];
scsi_cmd[8] = args[3];
@@ -195,18 +208,29 @@
goto error;
}
+ sb = sreq-sr_sense_buffer;
+ desc = sb + 8;
+
sreq-sr_data_direction = DMA_NONE;
/* Good values for timeout and retries? Values below
from scsi_ioctl_send_command() for default case... */
scsi_wait_req(sreq, scsi_cmd, NULL, 0, (10*HZ), 5);
- if (sreq-sr_result) {
+ if (!sreq-sr_result == ((DRIVER_SENSE 24) + SAM_STAT_CHECK_CONDITION)) {
rc = -EIO;
goto error;
}
- /* Need code to retrieve data from check condition? */
+ /* Retrieve data from check condition */
+ args[1] = desc[3];
+ args[2] = desc[5];
+ args[3] = desc[7];
+ args[4] = desc[9];
+ args[5] = desc[11];
+ args[0] = desc[13];
+ if (copy_to_user(arg, args, sizeof(args)))
+ rc = -EFAULT;
error:
scsi_release_request(sreq);
return rc;
[patch] libata passthrough - return register data from HDIO_* commands
Here is a first attempt at a patch to return register data from the
libata passthrough HDIO ioctl handlers, I needed this as the ATA 'unload
immediate' command returns the success in the lbal register. This patch
applies on top of 2.6.12 and Jeffs 2.6.12-git4-passthru1.patch.
(Apologies, but Thunderbird appears to have replaced the tabs with spaces).
One oddity is that the sr_result field is correctly being set in
ata_gen_ata_desc_sense(), however the high word is different when we're
back in the ioctl hander. I've coded round this for now by only checking
the low word, but this needs more investigation.
Jeff, could this functionality be incorporated into the pasthrough patch
when complete?
Regards,
Jon.
--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -89,6 +89,7 @@
u8 args[4], *argbuf = NULL;
int argsize = 0;
struct scsi_request *sreq;
+unsigned char *sb, *desc;
if (NULL == (void *)arg)
return -EINVAL;
@@ -100,6 +101,9 @@
if (!sreq)
return -EINTR;
+sb = sreq->sr_sense_buffer;
+desc = sb + 8;
+
memset(scsi_cmd, 0, sizeof(scsi_cmd));
if (args[3]) {
@@ -109,12 +113,12 @@
return -ENOMEM;
scsi_cmd[1] = (4 << 1); /* PIO Data-in */
-scsi_cmd[2] = 0x0e; /* no off.line or cc, read from dev,
+scsi_cmd[2] = 0x2e; /* no off.line, read from dev, request cc
block count in sector count field */
sreq->sr_data_direction = DMA_FROM_DEVICE;
} else {
scsi_cmd[1] = (3 << 1); /* Non-data */
-/* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
+scsi_cmd[2] = 0x20; /* no off.line or data xfer, request
check condtion */
sreq->sr_data_direction = DMA_NONE;
}
@@ -135,16 +139,24 @@
from scsi_ioctl_send_command() for default case... */
scsi_wait_req(sreq, scsi_cmd, argbuf, argsize, (10*HZ), 5);
-if (sreq->sr_result) {
+if ((sreq->sr_result & 0x) != SAM_STAT_CHECK_CONDITION) {
rc = -EIO;
goto error;
}
-/* Need code to retrieve data from check condition? */
+/* Retrieve data from check condition */
+args[1] = desc[3];
+args[2] = desc[5];
+args[3] = desc[7];
+args[4] = desc[9];
+args[5] = desc[11];
+args[0] = desc[13];
if ((argbuf)
&& copy_to_user((void *)(arg + sizeof(args)), argbuf, argsize))
rc = -EFAULT;
+if (copy_to_user(arg, args, sizeof(args)))
+rc = -EFAULT;
error:
scsi_release_request(sreq);
@@ -171,6 +183,7 @@
u8 scsi_cmd[MAX_COMMAND_SIZE];
u8 args[7];
struct scsi_request *sreq;
+unsigned char *sb, *desc;
if (NULL == (void *)arg)
return -EINVAL;
@@ -181,7 +194,7 @@
memset(scsi_cmd, 0, sizeof(scsi_cmd));
scsi_cmd[0] = ATA_16;
scsi_cmd[1] = (3 << 1); /* Non-data */
-/* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
+scsi_cmd[2] = 0x20; /* no off.line, or data xfer, request cc */
scsi_cmd[4] = args[1];
scsi_cmd[6] = args[2];
scsi_cmd[8] = args[3];
@@ -195,18 +208,29 @@
goto error;
}
+sb = sreq->sr_sense_buffer;
+desc = sb + 8;
+
sreq->sr_data_direction = DMA_NONE;
/* Good values for timeout and retries? Values below
from scsi_ioctl_send_command() for default case... */
scsi_wait_req(sreq, scsi_cmd, NULL, 0, (10*HZ), 5);
-if (sreq->sr_result) {
+if ((sreq->sr_result & 0x) != SAM_STAT_CHECK_CONDITION) {
rc = -EIO;
goto error;
}
-/* Need code to retrieve data from check condition? */
+/* Retrieve data from check condition */
+args[1] = desc[3];
+args[2] = desc[5];
+args[3] = desc[7];
+args[4] = desc[9];
+args[5] = desc[11];
+args[0] = desc[13];
+if (copy_to_user(arg, args, sizeof(args)))
+rc = -EFAULT;
error:
scsi_release_request(sreq);
return rc;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] libata passthrough - return register data from HDIO_* commands
Here is a first attempt at a patch to return register data from the
libata passthrough HDIO ioctl handlers, I needed this as the ATA 'unload
immediate' command returns the success in the lbal register. This patch
applies on top of 2.6.12 and Jeffs 2.6.12-git4-passthru1.patch.
(Apologies, but Thunderbird appears to have replaced the tabs with spaces).
One oddity is that the sr_result field is correctly being set in
ata_gen_ata_desc_sense(), however the high word is different when we're
back in the ioctl hander. I've coded round this for now by only checking
the low word, but this needs more investigation.
Jeff, could this functionality be incorporated into the pasthrough patch
when complete?
Regards,
Jon.
--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -89,6 +89,7 @@
u8 args[4], *argbuf = NULL;
int argsize = 0;
struct scsi_request *sreq;
+unsigned char *sb, *desc;
if (NULL == (void *)arg)
return -EINVAL;
@@ -100,6 +101,9 @@
if (!sreq)
return -EINTR;
+sb = sreq-sr_sense_buffer;
+desc = sb + 8;
+
memset(scsi_cmd, 0, sizeof(scsi_cmd));
if (args[3]) {
@@ -109,12 +113,12 @@
return -ENOMEM;
scsi_cmd[1] = (4 1); /* PIO Data-in */
-scsi_cmd[2] = 0x0e; /* no off.line or cc, read from dev,
+scsi_cmd[2] = 0x2e; /* no off.line, read from dev, request cc
block count in sector count field */
sreq-sr_data_direction = DMA_FROM_DEVICE;
} else {
scsi_cmd[1] = (3 1); /* Non-data */
-/* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
+scsi_cmd[2] = 0x20; /* no off.line or data xfer, request
check condtion */
sreq-sr_data_direction = DMA_NONE;
}
@@ -135,16 +139,24 @@
from scsi_ioctl_send_command() for default case... */
scsi_wait_req(sreq, scsi_cmd, argbuf, argsize, (10*HZ), 5);
-if (sreq-sr_result) {
+if ((sreq-sr_result 0x) != SAM_STAT_CHECK_CONDITION) {
rc = -EIO;
goto error;
}
-/* Need code to retrieve data from check condition? */
+/* Retrieve data from check condition */
+args[1] = desc[3];
+args[2] = desc[5];
+args[3] = desc[7];
+args[4] = desc[9];
+args[5] = desc[11];
+args[0] = desc[13];
if ((argbuf)
copy_to_user((void *)(arg + sizeof(args)), argbuf, argsize))
rc = -EFAULT;
+if (copy_to_user(arg, args, sizeof(args)))
+rc = -EFAULT;
error:
scsi_release_request(sreq);
@@ -171,6 +183,7 @@
u8 scsi_cmd[MAX_COMMAND_SIZE];
u8 args[7];
struct scsi_request *sreq;
+unsigned char *sb, *desc;
if (NULL == (void *)arg)
return -EINVAL;
@@ -181,7 +194,7 @@
memset(scsi_cmd, 0, sizeof(scsi_cmd));
scsi_cmd[0] = ATA_16;
scsi_cmd[1] = (3 1); /* Non-data */
-/* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
+scsi_cmd[2] = 0x20; /* no off.line, or data xfer, request cc */
scsi_cmd[4] = args[1];
scsi_cmd[6] = args[2];
scsi_cmd[8] = args[3];
@@ -195,18 +208,29 @@
goto error;
}
+sb = sreq-sr_sense_buffer;
+desc = sb + 8;
+
sreq-sr_data_direction = DMA_NONE;
/* Good values for timeout and retries? Values below
from scsi_ioctl_send_command() for default case... */
scsi_wait_req(sreq, scsi_cmd, NULL, 0, (10*HZ), 5);
-if (sreq-sr_result) {
+if ((sreq-sr_result 0x) != SAM_STAT_CHECK_CONDITION) {
rc = -EIO;
goto error;
}
-/* Need code to retrieve data from check condition? */
+/* Retrieve data from check condition */
+args[1] = desc[3];
+args[2] = desc[5];
+args[3] = desc[7];
+args[4] = desc[9];
+args[5] = desc[11];
+args[0] = desc[13];
+if (copy_to_user(arg, args, sizeof(args)))
+rc = -EFAULT;
error:
scsi_release_request(sreq);
return rc;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
IBM HDAPS - how to freeze i/o?
The HDAPS (IBM ThinkPad Hard Disk Active Protection System) project currently has working code to read the accelerometer data, and to park the hard disk. However, we're going to need a way to keep the disk idle following the park command, as any subsequent command reaching the disk may reactivate the drive before it's safe to resume. Is there any mechanism available in the kernel to 'freeze' the i/o queue? Thanks, Jon. __ Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IBM HDAPS - how to freeze i/o?
The HDAPS (IBM ThinkPad Hard Disk Active Protection System) project currently has working code to read the accelerometer data, and to park the hard disk. However, we're going to need a way to keep the disk idle following the park command, as any subsequent command reaching the disk may reactivate the drive before it's safe to resume. Is there any mechanism available in the kernel to 'freeze' the i/o queue? Thanks, Jon. __ Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: IBM HDAPS, I need a tip.
hard drive parking was already sorted out. We have a script that does this and works great parking the heads. Would have to disagree with you here. Jens' ATA7 parking code is a great start but we still have a couple of issues to address before it's usable for this purpose. (1) it only works on a subset of the devices that the Windows driver works for, and (2) we need a way to freeze the device for a short period so that the next I/O request doesn't wake it up before it hits the floor... The problem here is that we have 10 different models. One will have 20 as X and the others will have 500 as x. Some will increment in 20 when you move them 45Deg, and some will increment 50. How can you determine from an shake, to a fall? If there really are devices with resting values of 20 then I would agree we have a problem. I've tried on a few different Thinkpads and have always seen resting values of several hundreds. If this is true for all, I would like to think we could estimate a sensible value that works for everyone... Regards, Jon. __ Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: IBM HDAPS, I need a tip.
Thanks to development of the driver from some nice guys, we are able to get data from the accelerometer. There is one problem. How do we calibrate the values that are outputed from the userspace? All PC's get a different value, and we can't really find the best solution. What is the scientific and smartest way to do this? I'm not convinced we need to get so hung up on the calibration. Sure, each laptop has somewhat different resting values - but surely what we're looking for is any rate of change in either the X or Y values thats over a predefined 'safe' threshold? (I would imagine that we're only going to find that safe threshold from some imaginative testing once we've got the head parking sorted) Just my 2p worth, Jon. __ Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: IBM HDAPS, I need a tip.
Thanks to development of the driver from some nice guys, we are able to get data from the accelerometer. There is one problem. How do we calibrate the values that are outputed from the userspace? All PC's get a different value, and we can't really find the best solution. What is the scientific and smartest way to do this? I'm not convinced we need to get so hung up on the calibration. Sure, each laptop has somewhat different resting values - but surely what we're looking for is any rate of change in either the X or Y values thats over a predefined 'safe' threshold? (I would imagine that we're only going to find that safe threshold from some imaginative testing once we've got the head parking sorted) Just my 2p worth, Jon. __ Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: IBM HDAPS, I need a tip.
hard drive parking was already sorted out. We have a script that does this and works great parking the heads. Would have to disagree with you here. Jens' ATA7 parking code is a great start but we still have a couple of issues to address before it's usable for this purpose. (1) it only works on a subset of the devices that the Windows driver works for, and (2) we need a way to freeze the device for a short period so that the next I/O request doesn't wake it up before it hits the floor... The problem here is that we have 10 different models. One will have 20 as X and the others will have 500 as x. Some will increment in 20 when you move them 45Deg, and some will increment 50. How can you determine from an shake, to a fall? If there really are devices with resting values of 20 then I would agree we have a problem. I've tried on a few different Thinkpads and have always seen resting values of several hundreds. If this is true for all, I would like to think we could estimate a sensible value that works for everyone... Regards, Jon. __ Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))
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) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
