* Re: Q on SATA/AHCI - AHCI driver changes for device reset and testing
[not found] <4D48560FCC5CEA4C8A337994ED7C762BB13AEBC2@rrsmsx505.amr.corp.intel.com>
@ 2009-03-21 3:51 ` Jeff Garzik
0 siblings, 0 replies; only message in thread
From: Jeff Garzik @ 2009-03-21 3:51 UTC (permalink / raw)
To: Konkle, Timothy A; +Cc: linux-ide@vger.kernel.org
Konkle, Timothy A wrote:
> Jeff,
>
>
>
> Hopefully this is an easy, quick question…
>
>
>
> I am trying to write code to stress test/diagnose SATA SSD drives under
> AHCI (on Linux obviously).
>
> It seems for speed and certain types of info (physical link, HBA
> settings and such), that I want to switch user level code from
> sg3_util/sg.ko down to changes directly in the ahci.ko module. Does
> this seem correct?
>
>
>
> Basically, I am trying to first issue COMReset to particular drives for
> instance (from a python script->shared lib C code), then reset bus and
> adjust speed and more… Pointers on locations to make code
> modifications? I was expecting to find an ioctl() like mechanism in
> ahci.c much like the scsi/sg modules… I am using kernel 2.6.24, though
> I can use later kernels too. Basically I am trying to build up a test
> and validation shared library that will be call able from python code
> and see controllers, devices, command lists, FIS data and build out a
> test library with data collection and COMReset as first stop.
>
>
>
>
>
> I’m just starting through device driver development with books such as
> Linux Device Drivers 3^rd ed, Essential Linux Device Drivers (can’t find
> that book’s code) and many others. So it seems that I have most data
> I’d need to reset a device in ahci.ko and just add in a /proc interface
> for user control to request a device reset via it’s HBA controller. Is
> ahci.c a poor choice as it is controller/used by higher level drivers
> such as libata, sd or other modules?
>
>
>
> Is there already source code in Linux that shows how to do this sort of
> thing? Everything I’ve seen so far uses slower and a bit higher level SG.
Support for online diagnostics and testing within libata is quite
limited, since that is not needed by the majority of our users.
The SG_IO ioctl and SCSI-specified ATA(12) and ATA(16) commands specify
various types of resets. Changes to libata to support these resets
would probably be the easiest initial change, and least amount of work.
Dumping full internals is probably not something we would want in the
kernel driver -- too much code space for too little user value -- but
something like networking's ETHTOOL_GREGS would be reasonable for SATA
drivers. Userspace could handle things from there.
Other controls like per-port SATA phy controls we have wanted for a
while; the appropriate place to put those is in sysfs, not procfs.
Jeff
^ permalink raw reply [flat|nested] only message in thread