libata PATA support - work items?

libata PATA support - work items?

[Albert Lee]

Hi, 

  I guess many people like me are looking forward to libata PATA support.
If OK, I would like to help on the task. (The motivation is PATA HBA hotplug on ppc64 
boxes and it can be functional if the PATA support and drivers like pdc2027x accepted in libata.) 
I've read Jeff's valuable dev guide (http://linux.yyz.us/sata/devel.html) and ATA-6 spec;
also read some code of IDE and libata core. Hopefully I could be something helpful. :-)
Is there any direction for PATA or any item needs work first?

The following PATA work items were previously collected from the mailing list:
    1. ATAPI
       1.1 possibly avoid REPORT LUNS for ATAPI devices
       1.2 when check condition occurs, automatically request sense inside 
            driver, and put that data into the sense buffer.
       1.3 make INQUIRY report SCSI version MMC-3 (or later...)
       1.4 support strange sector sizes
    2. C/H/S addressing; libata currently hardcoded to use LBA
    3. add PATA device errata/blacklist info
   (Any missing items?)

Need your advice, thanks.

Albert

Re: libata PATA support - work items?

[Eric Mudama]

On Thu, 30 Dec 2004 18:42:33 +0800, Albert Lee <albertcc@tw.ibm.com> wrote:
>     2. C/H/S addressing; libata currently hardcoded to use LBA


Are there really people who want to run a newer 2.4 or a 2.6 kernel,
who have disks that do not support LBA mode?  CHS will never address
more than 32GB of the drive (unless you use vendor unique
implementations) and heck, most companies don't even build drives that
small anymore...  CHS is very messy, LBA is so much simpler.   Can we
just stick with that?

--eric

Re: libata PATA support - work items?

[Greg Freemyer]

On Sat, 1 Jan 2005 12:19:20 -0700, Eric Mudama <edmudama@gmail.com> wrote:
> On Thu, 30 Dec 2004 18:42:33 +0800, Albert Lee <albertcc@tw.ibm.com> wrote:
> >     2. C/H/S addressing; libata currently hardcoded to use LBA
> 
> 
> Are there really people who want to run a newer 2.4 or a 2.6 kernel,
> who have disks that do not support LBA mode?  CHS will never address
> more than 32GB of the drive (unless you use vendor unique
> implementations) and heck, most companies don't even build drives that
> small anymore...  CHS is very messy, LBA is so much simpler.   Can we
> just stick with that?
> 
> --eric

I may be in the minority, but my company does computer forensics.  We
routinely connect old drives to Linux boxes and make dd images of
them.

We definately need CHS support at some level in the kernel.  If this
were ever dropped, we would have to quit using Linux for this job.

FYI, there are hundreds if not thousands of companies that provide
this service.  The current standard for the industry is to perform
these images from a DOS boot floppy, but using Linux is far superior
in my mind and there is a small but growing body of professionals
using Linux for Computer Forensic Imaging.

Greg
-- 
Greg Freemyer

Re: libata PATA support - work items?

[Eric Mudama]

On Mon, 3 Jan 2005 15:56:58 -0500, Greg Freemyer
<greg.freemyer@gmail.com> wrote:
> I may be in the minority, but my company does computer forensics.  We
> routinely connect old drives to Linux boxes and make dd images of
> them.
> 
> We definately need CHS support at some level in the kernel.  If this
> were ever dropped, we would have to quit using Linux for this job.
> 
> FYI, there are hundreds if not thousands of companies that provide
> this service.  The current standard for the industry is to perform
> these images from a DOS boot floppy, but using Linux is far superior
> in my mind and there is a small but growing body of professionals
> using Linux for Computer Forensic Imaging.

Would it be a problem to keep any of the existing 2.4 or non-libata
2.6 systems around?  Since you're doing it now, I wouldn't expect it
to be a problem to keep them running so you can continue connecting to
very old hard drives.

I'm simply trying to say that it'd be nice if future libata stayed
focused on non-CHS mode stuff, since CHS has been obsolete from the
ATA specifications for years.  Revision 5 of the ATA-3 specification,
6 October 1995, made LBA support mandatory for all disk drives
claiming support of that level of the spec.  Over 9 years ago.

Obviously, forensics and data recovery are cases where you might be
working with 9+ year old hard drive, but for that I would think we can
keep the existing PATA drivers around if maintaining an older system
wasn't an option, for those who need it.

Would that work?

--eric

Re: libata PATA support - work items?

[Bartlomiej Zolnierkiewicz]

Hi,

On Mon, 3 Jan 2005 14:20:40 -0700, Eric Mudama <edmudama@gmail.com> wrote:
> On Mon, 3 Jan 2005 15:56:58 -0500, Greg Freemyer
> <greg.freemyer@gmail.com> wrote:
> > I may be in the minority, but my company does computer forensics.  We
> > routinely connect old drives to Linux boxes and make dd images of
> > them.
> >
> > We definately need CHS support at some level in the kernel.  If this
> > were ever dropped, we would have to quit using Linux for this job.
> >
> > FYI, there are hundreds if not thousands of companies that provide
> > this service.  The current standard for the industry is to perform
> > these images from a DOS boot floppy, but using Linux is far superior
> > in my mind and there is a small but growing body of professionals
> > using Linux for Computer Forensic Imaging.
> 
> Would it be a problem to keep any of the existing 2.4 or non-libata
> 2.6 systems around?  Since you're doing it now, I wouldn't expect it
> to be a problem to keep them running so you can continue connecting to
> very old hard drives.
> 
> I'm simply trying to say that it'd be nice if future libata stayed
> focused on non-CHS mode stuff, since CHS has been obsolete from the
> ATA specifications for years.  Revision 5 of the ATA-3 specification,
> 6 October 1995, made LBA support mandatory for all disk drives
> claiming support of that level of the spec.  Over 9 years ago.
> 
> Obviously, forensics and data recovery are cases where you might be
> working with 9+ year old hard drive, but for that I would think we can
> keep the existing PATA drivers around if maintaining an older system
> wasn't an option, for those who need it.
> 
> Would that work?

Existing IDE drivers are not going away any time soon (not 2.6.x at least)
and if/when this happens we shouldn't drop CHS support completely
from the kernel - IMHO it is quite easy to add CHS support to libata.
I also agree that libata PATA development should be focused on LBA
but I don't see any problem in keeping CHS support around...

Cheers,
Bartlomiej

Re: libata PATA support - work items?

[Jeff Garzik]

Albert Lee wrote:
> The following PATA work items were previously collected from the mailing list:
>     1. ATAPI
>        1.1 possibly avoid REPORT LUNS for ATAPI devices
>        1.2 when check condition occurs, automatically request sense inside 
>             driver, and put that data into the sense buffer.
>        1.3 make INQUIRY report SCSI version MMC-3 (or later...)
>        1.4 support strange sector sizes
>     2. C/H/S addressing; libata currently hardcoded to use LBA
>     3. add PATA device errata/blacklist info
>    (Any missing items?)
> 
> Need your advice, thanks.

Yes, this seems like an accurate list to me.

I would probably prioritize #3 as the most important, followed by C/H/S
support.

	Jeff

Re: libata PATA support - work items?

[Jeff Garzik]

Eric Mudama wrote:
> On Thu, 30 Dec 2004 18:42:33 +0800, Albert Lee <albertcc@tw.ibm.com> wrote:
> 
>>    2. C/H/S addressing; libata currently hardcoded to use LBA
> 
> 
> 
> Are there really people who want to run a newer 2.4 or a 2.6 kernel,
> who have disks that do not support LBA mode?  CHS will never address
> more than 32GB of the drive (unless you use vendor unique
> implementations) and heck, most companies don't even build drives that
> small anymore...  CHS is very messy, LBA is so much simpler.   Can we
> just stick with that?


Well.......  :)

Originally when I started libata, I targetted it at modern PCI IDE BMDMA 
(i.e. Intel ICH4-like) controllers, with an eye towards FIS-based 
controllers such as Intel AHCI or SiI 3124.

As a result, I intentionally hardcoded several things such as LBA 
support, when writing libata.

Over time, I have consistently seen these "hardcode it" decisions 
reversed, and the hardcoding removed, mainly to add support for 
controllers that are an existing PATA chip (with no SATA modifications) 
glued next to a PATA->SATA transparent bridge.  These controllers 
essentially require PATA support.  Also, in the community, Bart, Alan 
Cox, and others (hi Albert) have been interested in supporting some PATA 
controllers with libata.

So while my original intention with libata was "Bart does the IDE driver 
for PATA, and I do the IDE driver for SATA", and make a clean break, it 
seems that libata is moving more and more towards eventually having full 
PATA support for many controllers, with all that entails.

So, that said, I think it is important for libata to fully support PATA, 
if it is to support it at all.  That means handling the errata that Alan 
always bugs me about, and that means handling C/H/S support as well.

	Jeff

Re: libata PATA support - work items?

[Jeff Garzik]

Bartlomiej Zolnierkiewicz wrote:
> Existing IDE drivers are not going away any time soon (not 2.6.x at least)
> and if/when this happens we shouldn't drop CHS support completely
> from the kernel - IMHO it is quite easy to add CHS support to libata.
> I also agree that libata PATA development should be focused on LBA
> but I don't see any problem in keeping CHS support around...


I don't think it's a problem to support C/H/S in libata.  libata already 
has to handle lba28/lba48, CHS would simply be a third instance of the 
"fill read/write taskfile" code.

	Jeff

Re: libata PATA support - work items?

[Alan Cox]

On Maw, 2005-01-04 at 23:41, Jeff Garzik wrote:
> So, that said, I think it is important for libata to fully support PATA, 
> if it is to support it at all.  That means handling the errata that Alan 
> always bugs me about, and that means handling C/H/S support as well.

I think so. If it supports all the features of the old IDE layer we get
to have a party when we eliminate the need for drivers/ide once and for
all.

That means
- Hotplug (controller and disk)
- CHS
- "Not quite generic" IDE DMA (eg CS5520)
- VDMA (eg CS5520)
- IORDY timers (not handled well in drivers/ide but needed)
- Funky Maxtor "LBA48.. maybe" oddments
- Missing slave detection
- Controller errata hooks (modes, drives, timings, "dont touch during an
I/O" etc)
- Drive nIEN bugs
- No nIEN cases
- Drives that don't do some DMA/modes right
- Crazy shit "Don't DMA from the page below 640K" (not handled by
drivers/ide but an AMD errata
	fixed by using a PS/2 mouse)
- Serialize (RZ1000, CMD640, some 469, etc)
- Bandwidth arbiter (not in drivers/ide but needed)
- Non PCI shared IRQ mess 8(

Hopefully most of this can be buried away in a pata-errata.c 8)

Re: libata PATA support - work items?

[Jeff Garzik]

Alan Cox wrote:
> That means
> - Hotplug (controller and disk)

mostly either there, or easy to add

> - CHS

nod


> - "Not quite generic" IDE DMA (eg CS5520)
> - VDMA (eg CS5520)

existing hooks can handle these


> - IORDY timers (not handled well in drivers/ide but needed)

I think I know what this is.


> - Funky Maxtor "LBA48.. maybe" oddments

details?


> - Missing slave detection

Not missing, master/slave has been working for ages.  Needed for 
combined mode, where a SATA device can appear as a slave.


> - Controller errata hooks (modes, drives, timings, "dont touch during an
> I/O" etc)

Controller hooks for most situations already exist, for the most part. 
Device hooks are what is lacking.


> - Drive nIEN bugs

ditto above ("device hooks are lacking")


> - No nIEN cases

already handled in at least one case (AHCI)


> - Drives that don't do some DMA/modes right

easily doable with existing hooks


> - Crazy shit "Don't DMA from the page below 640K" (not handled by
> drivers/ide but an AMD errata
> 	fixed by using a PS/2 mouse)

heh, interesting


> - Serialize (RZ1000, CMD640, some 469, etc)

non-trivial but doable (and planned-for)


> - Bandwidth arbiter (not in drivers/ide but needed)

interesting


> - Non PCI shared IRQ mess 8(

details?

Thanks,

	Jeff

Re: libata PATA support - work items?

[Alan Cox]

On Mer, 2005-01-05 at 02:42, Jeff Garzik wrote:
> > - IORDY timers (not handled well in drivers/ide but needed)
> I think I know what this is.

The SII has support for this in the h/w btw (see the docs). Otherwise
IDE as a protocol can get stuck if the drive enters rotating doorstop
mode at the wrong moment.

> > - Funky Maxtor "LBA48.. maybe" oddments
> details?

There are a couple of "yes we do LBA48" "no we don't do this command in
LBA48" cases with maxtors (Cache flush is one, the stroke stuff triggers
another)

> > - Missing slave detection
> 
> Not missing, master/slave has been working for ages.  Needed for 
> combined mode, where a SATA device can appear as a slave.

No no - some devices have a master and a slave on them when you detect
but only one disk attached because they forgot to bother decoding it in
the adapter (eg some pcmcia with microdrives). This causes bad shit
especially with hal style automounting.

> > - Bandwidth arbiter (not in drivers/ide but needed)
> interesting

Its effectively serialize I think that is needed but with >1 at a time.

> > - Non PCI shared IRQ mess 8(
> details?

ISA IRQ lines - two controllers, one IRQ but edge triggered and not
sharable directly. The core old IDE code actually supports all of this
and people have run stuff like 6 ISA IDE controllers in a PC.[1]

Alan
[1] Seek medical advice before trying this at home

Re: libata PATA support - work items?

[Bartlomiej Zolnierkiewicz]

On Wed, 05 Jan 2005 00:50:05 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-01-04 at 23:41, Jeff Garzik wrote:
> > So, that said, I think it is important for libata to fully support PATA,
> > if it is to support it at all.  That means handling the errata that Alan
> > always bugs me about, and that means handling C/H/S support as well.
> 
> I think so. If it supports all the features of the old IDE layer we get
> to have a party when we eliminate the need for drivers/ide once and for
> all.
> 
> That means
> - Hotplug (controller and disk)
> - CHS
> - "Not quite generic" IDE DMA (eg CS5520)
> - VDMA (eg CS5520)
> - IORDY timers (not handled well in drivers/ide but needed)
> - Funky Maxtor "LBA48.. maybe" oddments
> - Missing slave detection
> - Controller errata hooks (modes, drives, timings, "dont touch during an
> I/O" etc)
> - Drive nIEN bugs
> - No nIEN cases
> - Drives that don't do some DMA/modes right
> - Crazy shit "Don't DMA from the page below 640K" (not handled by
> drivers/ide but an AMD errata
>         fixed by using a PS/2 mouse)
> - Serialize (RZ1000, CMD640, some 469, etc)
> - Bandwidth arbiter (not in drivers/ide but needed)
> - Non PCI shared IRQ mess 8(
> 
> Hopefully most of this can be buried away in a pata-errata.c 8)

:-)

few more:
- Power Management for devices
- 32 bit I/O support
- Multiple Mode PIO support
- Host Protected Area support
  (can be done from user-space but "coldplug" is needed)
- ide-{cd,disk,floppy,tape}.c specific quirks

Re: libata PATA support - work items?

[Albert Lee]

For the 1st item,
- add PATA device errata/blacklist info
Is there any detail or draft design idea available?

For
- C/H/S addressing.
 I've an old Segate drive which support CHS-only at hand.
Maybe I can work on it first.

  BTW, what items are required for the PATA lowlevel driver like pdc2027x
to move out of the libata-dev tree to production tree? Do we have to finish all items?


Albert

----- Original Message ----- 
From: "Jeff Garzik" <jgarzik@pobox.com>
To: "Albert Lee" <albertcc@tw.ibm.com>
Cc: "Bartlomiej Zolnierkiewicz" <bzolnier@gmail.com>; "IDE Linux" <linux-ide@vger.kernel.org>; "Doug Maxey" <dwm@maxeymade.com>;
"Alan Cox" <alan@lxorguk.ukuu.org.uk>
Sent: Wednesday, January 05, 2005 7:32 AM
Subject: Re: libata PATA support - work items?


> Albert Lee wrote:
> > The following PATA work items were previously collected from the mailing list:
> >     1. ATAPI
> >        1.1 possibly avoid REPORT LUNS for ATAPI devices
> >        1.2 when check condition occurs, automatically request sense inside
> >             driver, and put that data into the sense buffer.
> >        1.3 make INQUIRY report SCSI version MMC-3 (or later...)
> >        1.4 support strange sector sizes
> >     2. C/H/S addressing; libata currently hardcoded to use LBA
> >     3. add PATA device errata/blacklist info
> >    (Any missing items?)
> >
> > Need your advice, thanks.
>
> Yes, this seems like an accurate list to me.
>
> I would probably prioritize #3 as the most important, followed by C/H/S
> support.
>
> Jeff
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: libata PATA support - work items?

[Alan Cox]

On Iau, 2005-01-06 at 08:51, Albert Lee wrote:
> For the 1st item,
> - add PATA device errata/blacklist info
> Is there any detail or draft design idea available?

There is a fair bit of code in drivers/ide. Most of it is handling drive
problems that occurred with early DMA drives and it uses the
model/firmware info in the ident string to match drives that claim to do
DMA but do not and drives that claim not to but can.

The logic is fairly simple and the database is easily transported or
shared. It is fairly important because some of these old drives
corrupted data if used DMA. (see drivers/ide/ide-dma.c)

For PIO problem drives where there is a need to keep PIO modes chosen
carefully then ide-lib has a list (ide_pio_blacklist) and the ide-io
code knows about pio modes and older style EIDE cycle timing reports
(ide_get_best_pio_mode)

IDE CD has some DMA blacklists for ATAPI but they should be viewed with
caution as many entries were due to a bug in our atapi implementation
that was fixed long ago.

> For
> - C/H/S addressing.
>  I've an old Segate drive which support CHS-only at hand.
> Maybe I can work on it first.

That seems the logical start - many of the worst drive errata only apply
to old CHS drives anyway.

Re: libata PATA support - work items?

[Bartlomiej Zolnierkiewicz]

On Thu, 06 Jan 2005 21:29:42 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Iau, 2005-01-06 at 08:51, Albert Lee wrote:
> > For the 1st item,
> > - add PATA device errata/blacklist info
> > Is there any detail or draft design idea available?
> 
> There is a fair bit of code in drivers/ide. Most of it is handling drive
> problems that occurred with early DMA drives and it uses the
> model/firmware info in the ident string to match drives that claim to do
> DMA but do not and drives that claim not to but can.
> 
> The logic is fairly simple and the database is easily transported or
> shared. It is fairly important because some of these old drives
> corrupted data if used DMA. (see drivers/ide/ide-dma.c)
> 
> For PIO problem drives where there is a need to keep PIO modes chosen
> carefully then ide-lib has a list (ide_pio_blacklist) and the ide-io
> code knows about pio modes and older style EIDE cycle timing reports
> (ide_get_best_pio_mode)

There was some rumor (?) that this blacklist was created on CMD640
controller programmed with wrong timings...

BTW ide_get_best_pio_mode(), it is really misleading
(i.e. recent PIO tuning bug in it821x.c).

> IDE CD has some DMA blacklists for ATAPI but they should be viewed with
> caution as many entries were due to a bug in our atapi implementation
> that was fixed long ago.

There is only a common DMA blacklist in ide-dma.c.