What's in libata-dev.git

What's in libata-dev.git

[Jeff Garzik]

This is a summary and diffstat of all the changes pending in branch
libata-dev.git#upstream for kernel 2.6.21.  Items of note:

* major sata_promise improvements, including PATA and ATAPI support
* new drivers sata_inic162x, pata_it8213, MPC52xx
* sata_via PATA port support
* other minor improvements

Patchsets ACK'd and about to be merged:

* Tejun's devres stuff
* Cell ATA driver
* sata_sis PATA port support


Adrian Bunk (1):
      drivers/ata/: make 4 functions static

Alan (5):
      pata_it8213: Add new driver for the IT8213 card
      sata_via: PATA support
      libata-sff: Don't try and activate channels which are not in use
      ahci: Remove jmicron fixup
      libata: PIIX3 support

Alan Cox (1):
      pci: Move PCI_VDEVICE from libata to core

Andrew Morton (1):
      libata piix3 support warning fix

Arjan van de Ven (1):
      user of the jiffies rounding patch: ATA subsystem

Conke Hu (1):
      Add pci class code for SATA & AHCI, and replace some magic numbers.

Dan Wolstenholme (1):
      [libata] sata_vsc: support PCI MSI

J J (1):
      ata_piix: add ICH7 on Acer 3682WLMi to laptop list

Jakub W. Jozwicki J (1):
      pata_sis: implement laptop list and add ASUS A6K/A6U

Jeff Garzik (2):
      [libata] trim trailing whitespace
      [libata] sata_vsc: build fix after PCI MSI feature addition

Mikael Pettersson (5):
      sata_promise: TX2plus PATA support
      sata_promise: ATAPI support
      sata_promise: ATAPI cleanup
      sata_promise: issue ATAPI commands as normal packets
      sata_promise: handle ATAPI_NODATA ourselves

Robert Hancock (1):
      sata_nv: add suspend/resume support v3 (Resubmit)

Sylvain Munaut (1):
      libata: Add support for the MPC52xx ATA controller

Tejun Heo (6):
      libata: straighten out ATA_ID_* constants
      libata: use ata_id_c_string()
      libata: handle pci_enable_device() failure while resuming
      libata: kill qc->nsect and cursect
      sata_inic162x: finally, driver for initio 162x SATA controllers, take #2
      sata_promise: kill qc->nsect

Uwe Koziolek (1):
      sata_sis: support SiS966/966L

 drivers/ata/Kconfig             |   26 +
 drivers/ata/Makefile            |    3 
 drivers/ata/ahci.c              |   20 
 drivers/ata/ata_piix.c          |   23 -
 drivers/ata/libata-core.c       |   81 +---
 drivers/ata/libata-eh.c         |    7 
 drivers/ata/libata-scsi.c       |   52 +-
 drivers/ata/libata-sff.c        |   22 +
 drivers/ata/pata_ali.c          |    8 
 drivers/ata/pata_cs5520.c       |    2 
 drivers/ata/pata_cs5530.c       |    8 
 drivers/ata/pata_hpt366.c       |   20 
 drivers/ata/pata_hpt37x.c       |   23 -
 drivers/ata/pata_hpt3x3.c       |    2 
 drivers/ata/pata_it8213.c       |  354 +++++++++++++++++
 drivers/ata/pata_it821x.c       |   20 
 drivers/ata/pata_jmicron.c      |    2 
 drivers/ata/pata_marvell.c      |    4 
 drivers/ata/pata_mpc52xx.c      |  563 +++++++++++++++++++++++++++
 drivers/ata/pata_pdc202xx_old.c |    5 
 drivers/ata/pata_serverworks.c  |   19 
 drivers/ata/pata_sil680.c       |    2 
 drivers/ata/pata_sis.c          |   34 +
 drivers/ata/pata_via.c          |   10 
 drivers/ata/pata_winbond.c      |   16 
 drivers/ata/sata_inic162x.c     |  809 ++++++++++++++++++++++++++++++++++++++++
 drivers/ata/sata_nv.c           |  239 ++++++++---
 drivers/ata/sata_promise.c      |  226 ++++++++++-
 drivers/ata/sata_qstor.c        |    2 
 drivers/ata/sata_sil.c          |   10 
 drivers/ata/sata_sil24.c        |    5 
 drivers/ata/sata_sis.c          |   79 ++-
 drivers/ata/sata_via.c          |  110 +++++
 drivers/ata/sata_vsc.c          |   44 ++
 drivers/pci/quirks.c            |    2 
 include/linux/ata.h             |   11 
 include/linux/libata.h          |   14 
 include/linux/pci_ids.h         |    3 
 38 files changed, 2554 insertions(+), 326 deletions(-)

Re: What's in libata-dev.git

[Mark Lord]

What happened to ATA Passthru command support for ATAPI?

Cheers

Re: What's in libata-dev.git

[Jeff Garzik]

Mark Lord wrote:
> What happened to ATA Passthru command support for ATAPI?

On Jan 19 in message <45B15D65.1060203@garzik.org> you were asked to 
send a patch that applies successfully to #upstream.

	Jeff

What's in libata-dev.git

[Jeff Garzik]

The following libata changes are queued for 2.6.19:

General
-------
* Move libata to drivers/ata
* Serial Attached SCSI (SAS) attachment API
* Increase lba28 max sectors from 200 to 256
* Take the opportunity to rename a bunch of functions, and one filename
* More error handling improvements

Driver-specific
---------------
* ahci: suspend/resume support
* ahci: support some new SiS controllers
* sata_via: new PCI ID
* sata_sil: remove unaffected configurations from mod15write blacklist


The 'upstream' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

contains the following updates:

 Documentation/DocBook/libata.tmpl    |   12 
 drivers/Kconfig                      |    2 
 drivers/Makefile                     |    1 
 drivers/ata/Kconfig                  |  493 ++
 drivers/ata/Makefile                 |   63 
 drivers/ata/ahci.c                   | 1684 +++++++++
 drivers/ata/ata_generic.c            |  252 +
 drivers/ata/ata_piix.c               | 1258 +++++++
 drivers/ata/libata-core.c            | 6143 +++++++++++++++++++++++++++++++++++
 drivers/ata/libata-eh.c              | 2246 ++++++++++++
 drivers/ata/libata-scsi.c            | 3322 ++++++++++++++++++
 drivers/ata/libata-sff.c             | 1109 ++++++
 drivers/ata/libata.h                 |  122 
 drivers/ata/pata_ali.c               |  679 +++
 drivers/ata/pata_amd.c               |  707 ++++
 drivers/ata/pata_artop.c             |  518 ++
 drivers/ata/pata_atiixp.c            |  306 +
 drivers/ata/pata_cmd64x.c            |  505 ++
 drivers/ata/pata_cs5520.c            |  336 +
 drivers/ata/pata_cs5530.c            |  387 ++
 drivers/ata/pata_cs5535.c            |  291 +
 drivers/ata/pata_cypress.c           |  227 +
 drivers/ata/pata_efar.c              |  342 +
 drivers/ata/pata_hpt366.c            |  478 ++
 drivers/ata/pata_hpt37x.c            | 1257 +++++++
 drivers/ata/pata_hpt3x2n.c           |  597 +++
 drivers/ata/pata_hpt3x3.c            |  226 +
 drivers/ata/pata_isapnp.c            |  156 
 drivers/ata/pata_it8172.c            |  288 +
 drivers/ata/pata_it821x.c            |  847 ++++
 drivers/ata/pata_jmicron.c           |  266 +
 drivers/ata/pata_legacy.c            |  949 +++++
 drivers/ata/pata_mpiix.c             |  313 +
 drivers/ata/pata_netcell.c           |  175 
 drivers/ata/pata_ns87410.c           |  236 +
 drivers/ata/pata_oldpiix.c           |  339 +
 drivers/ata/pata_opti.c              |  292 +
 drivers/ata/pata_optidma.c           |  547 +++
 drivers/ata/pata_pcmcia.c            |  393 ++
 drivers/ata/pata_pdc2027x.c          |  869 ++++
 drivers/ata/pata_pdc202xx_old.c      |  423 ++
 drivers/ata/pata_qdi.c               |  403 ++
 drivers/ata/pata_radisys.c           |  335 +
 drivers/ata/pata_rz1000.c            |  205 +
 drivers/ata/pata_sc1200.c            |  287 +
 drivers/ata/pata_serverworks.c       |  587 +++
 drivers/ata/pata_sil680.c            |  381 ++
 drivers/ata/pata_sis.c               | 1030 +++++
 drivers/ata/pata_sl82c105.c          |  388 ++
 drivers/ata/pata_triflex.c           |  285 +
 drivers/ata/pata_via.c               |  568 +++
 drivers/ata/pdc_adma.c               |  740 ++++
 drivers/ata/sata_mv.c                | 2465 ++++++++++++++
 drivers/ata/sata_nv.c                |  595 +++
 drivers/ata/sata_promise.c           |  844 ++++
 drivers/ata/sata_promise.h           |  157 
 drivers/ata/sata_qstor.c             |  730 ++++
 drivers/ata/sata_sil.c               |  728 ++++
 drivers/ata/sata_sil24.c             | 1227 ++++++
 drivers/ata/sata_sis.c               |  347 +
 drivers/ata/sata_svw.c               |  508 ++
 drivers/ata/sata_sx4.c               | 1502 ++++++++
 drivers/ata/sata_uli.c               |  300 +
 drivers/ata/sata_via.c               |  502 ++
 drivers/ata/sata_vsc.c               |  482 ++
 drivers/pci/quirks.c                 |    6 
 drivers/scsi/Kconfig                 |  138 
 drivers/scsi/Makefile                |   16 
 drivers/scsi/ahci.c                  | 1473 --------
 drivers/scsi/ata_piix.c              | 1008 -----
 drivers/scsi/libata-bmdma.c          | 1149 ------
 drivers/scsi/libata-core.c           | 6015 ----------------------------------
 drivers/scsi/libata-eh.c             | 2246 ------------
 drivers/scsi/libata-scsi.c           | 3173 ------------------
 drivers/scsi/libata.h                |  117 
 drivers/scsi/pdc_adma.c              |  740 ----
 drivers/scsi/sata_mv.c               | 2468 --------------
 drivers/scsi/sata_nv.c               |  595 ---
 drivers/scsi/sata_promise.c          |  844 ----
 drivers/scsi/sata_promise.h          |  157 
 drivers/scsi/sata_qstor.c            |  730 ----
 drivers/scsi/sata_sil.c              |  727 ----
 drivers/scsi/sata_sil24.c            | 1222 ------
 drivers/scsi/sata_sis.c              |  347 -
 drivers/scsi/sata_svw.c              |  508 --
 drivers/scsi/sata_sx4.c              | 1502 --------
 drivers/scsi/sata_uli.c              |  300 -
 drivers/scsi/sata_via.c              |  501 --
 drivers/scsi/sata_vsc.c              |  482 --
 include/asm-alpha/libata-portmap.h   |    1 
 include/asm-generic/libata-portmap.h |   12 
 include/asm-i386/libata-portmap.h    |    1 
 include/asm-ia64/libata-portmap.h    |    1 
 include/asm-powerpc/libata-portmap.h |    1 
 include/asm-sparc/libata-portmap.h   |    1 
 include/asm-sparc64/libata-portmap.h |    1 
 include/asm-x86_64/libata-portmap.h  |    1 
 include/linux/ata.h                  |   26 
 include/linux/libata.h               |   76 
 99 files changed, 45337 insertions(+), 26500 deletions(-)

Alan Cox:
      libata: rework legacy handling to remove much of the cruft
      libata: Add CompactFlash support

Alexey Dobriyan:
      CONFIG_PM=n slim: drivers/scsi/sata_sil*

Andres Salomon:
      [libata] sata_mv: errata check buglet fix

Brian King:
      libata: Add ata_host_set_init
      libata: Add ata_port_init
      libata: Move ata_probe_ent_alloc to libata_core
      libata: Add support for SATA attachment to SAS adapters

Henrik Kretzschmar:
      libata: change path to libata in libata.tmpl

Jay Cliburn:
      sata_via: Add SATA support for vt8237a

Jeff Garzik:
      [libata] ahci: add SiS PCI IDs
      [libata] some function renaming
      [libata] Kill 'count' var in ata_device_add()
      [ATA] Increase lba48 max-sectors from 200 to 256.
      Move libata to drivers/ata.
      libata: Remove SCSI_ prefix from Kconfig symbols
      libata: Separate libata.ko build from individual driver builds
      [libata] ata_piix: add missing kfree()
      libata: Make sure drivers/ata is a separate Kconfig menu
      Clean up drivers/ata/Kconfig a bit.
      libata: Grand renaming.
      Rename libata-bmdma.c to libata-sff.c.
      [libata] Add a bunch of PATA drivers.
      [libata] Trim trailing whitespace.
      [libata #pata-drivers] Trim trailing whitespace.
      [libata] Add pata_jmicron driver to Kconfig, Makefile

Pavel Roskin:
      libata: replace pci_module_init() with pci_register_driver()

Tejun Heo:
      sata_sil: remove unaffected drives from m15w blacklist
      ahci: relocate several internal functions
      ahci: cosmetic changes to ahci_start/stop_engine()
      ahci: simplify ahci_start_engine()
      libata: improve driver initialization and deinitialization
      ahci: separate out ahci_reset_controller() and ahci_init_controller()
      ahci: implement Power Management support
      libata: cosmetic changes to PM functions
      ahci: remove IRQ mask clearing from init_controller()
      libata: update ata_host_init() and rename it to ata_port_init_shost()
      libata: implement per-dev xfermask
      libata: implement dummy port
      libata: use dummy port for stolen legacy ports
      libata: replace ap->hard_port_no with ap->port_no
      libata: kill unused hard_port_no and legacy_mode
      libata: s/CONFIG_SCSI_SATA/CONFIG_[S]ATA/g in pci/quirks.c
      ata_piix: add map 01b for ICH7M

zhao, forrest:
      The redefinition of ahci_start_engine() and ahci_stop_engine()

Re: What's in libata-dev.git

[Sergei Shtylyov]

Hello.

Jeff Garzik wrote:
> The following libata changes are queued for 2.6.19:
> 
> General
> -------
> * Increase lba28 max sectors from 200 to 256

[...]

> Jeff Garzik:
[...]
>       [ATA] Increase lba48 max-sectors from 200 to 256.

    So was it for LBA28 or for LBA48?
    As for LBA28, it might be quite dangerous. Particularly, I know that IBM 
drives used to mistreated 256 as 0 in the past (bumped into that on a 8-year 
old drive which is still alive though).

WBR, Sergei

Re: What's in libata-dev.git

[Jeff Garzik]

Sergei Shtylyov wrote:
> Hello.
> 
> Jeff Garzik wrote:
>> The following libata changes are queued for 2.6.19:
>>
>> General
>> -------
>> * Increase lba28 max sectors from 200 to 256
> 
> [...]
> 
>> Jeff Garzik:
> [...]
>>       [ATA] Increase lba48 max-sectors from 200 to 256.
> 
>    So was it for LBA28 or for LBA48?
>    As for LBA28, it might be quite dangerous. Particularly, I know that 
> IBM drives used to mistreated 256 as 0 in the past (bumped into that on 
> a 8-year old drive which is still alive though).

That's a typo.  The first description ("lba28") is correct.

Let me know if your IBM drive has problems with current 
libata-dev.git#upstream...

	Jeff

Re: What's in libata-dev.git

[Sergei Shtylyov]

Hello.

Jeff Garzik wrote:

>>> The following libata changes are queued for 2.6.19:
>>>
>>> General
>>> -------
>>> * Increase lba28 max sectors from 200 to 256
>>
>>
>> [...]
>>
>>> Jeff Garzik:
>>
>> [...]
>>
>>>       [ATA] Increase lba48 max-sectors from 200 to 256.

>>    So was it for LBA28 or for LBA48?
>>    As for LBA28, it might be quite dangerous. Particularly, I know 
>> that IBM drives used to mistreated 256 as 0 in the past (bumped into 
>> that on a 8-year old drive which is still alive though).

> That's a typo.  The first description ("lba28") is correct.

> Let me know if your IBM drive has problems with current 
> libata-dev.git#upstream...

    It's not likely I'll be able to try it. But I'm absolutely sure that drive 
aborted the read commands with the sector count of 0 (i.e. 256 actually). The 
exact model was IBM DHEA-34331.
    255 sectors actually seems more safe bet.

WBR, Sergei

Re: What's in libata-dev.git

[Jeff Garzik]

Sergei Shtylyov wrote:
>    It's not likely I'll be able to try it. But I'm absolutely sure that 
> drive aborted the read commands with the sector count of 0 (i.e. 256 
> actually). The exact model was IBM DHEA-34331.
>    255 sectors actually seems more safe bet.

This sort of thing should be handled by quirks, depending on the 
controller and drive.

That's why I was asking for testing, to see if the current code already 
handles this.

	Jeff

Re: What's in libata-dev.git

[Linus Torvalds]

On Mon, 11 Sep 2006, Jeff Garzik wrote:

> Sergei Shtylyov wrote:
> >    It's not likely I'll be able to try it. But I'm absolutely sure that
> > drive aborted the read commands with the sector count of 0 (i.e. 256
> > actually). The exact model was IBM DHEA-34331.
> >    255 sectors actually seems more safe bet.
> 
> This sort of thing should be handled by quirks, depending on the controller
> and drive.

Please don't play games with peoples data-safety.

It ios absolutely INCORRECT to think that "things should work as 
documented, let's fix it up with quirks".

It's a hell of a lot better to instead say "people f*ck up, this is a 
known point of trouble, and let's just not push the envelope that hard".

Making max-sectors be 255 instead of 256 just _avoids_ the problem that 
the ATA protocol uses a single-byte control register for the sector 
number, and that "0" is supposed to mean "256", but people have been 
_known_ to get it wrong several times.

It's not like it's even strange and inexplicable that some drive 
controller would think that "zero means zero". Quite the reverse. It's a 
strange special case, and it's not surprising at all that people would 
have gotten it wrong several times independently.

It's not even like you'd get magically higher performance by using 256 
sectors, so there's simply no win from living dangerously. Only losses.

		Linus

Re: What's in libata-dev.git

[Jeff Garzik]

Linus Torvalds wrote:
> It's not even like you'd get magically higher performance by using 256 
> sectors, so there's simply no win from living dangerously. Only losses.

It's easy enough to change.  Does this mean you want drivers/ide changed 
too?  It's apparently been living dangerously for years and years.

	Jeff

Re: What's in libata-dev.git

[Helge Hafting]

Linus Torvalds wrote:
> On Mon, 11 Sep 2006, Jeff Garzik wrote:
>
>   
>> Sergei Shtylyov wrote:
>>     
>>>    It's not likely I'll be able to try it. But I'm absolutely sure that
>>> drive aborted the read commands with the sector count of 0 (i.e. 256
>>> actually). The exact model was IBM DHEA-34331.
>>>    255 sectors actually seems more safe bet.
>>>       
>> This sort of thing should be handled by quirks, depending on the controller
>> and drive.
>>     
>
> Please don't play games with peoples data-safety.
>
> It ios absolutely INCORRECT to think that "things should work as 
> documented, let's fix it up with quirks".
>   
How about a simple and harmless test?
When an IDE disk is accessed for the first time, perhaps when
the partition table is read - issue a 256-sector read and see
what happens.  If it works - fine.  If not, tag the thing as
supporting max 255 sectors.

No wrecking of file systems, and full performance for
the vast majority.

Helge Hafting

Re: What's in libata-dev.git

[Tejun Heo]

Helge Hafting wrote:
> How about a simple and harmless test?
> When an IDE disk is accessed for the first time, perhaps when
> the partition table is read - issue a 256-sector read and see
> what happens.  If it works - fine.  If not, tag the thing as
> supporting max 255 sectors.
> 
> No wrecking of file systems, and full performance for
> the vast majority.

Before implementing anything like that, we need a test case.  We don't 
know how a faulty drive reacts on such cases.  If it actively aborts the 
command, we can reduce the limit to 255 sectors after upper layer issues 
such command, no need to do it earlier.  If it times out, we can't do it 
during boot and it will suck later too.  If it silently corrupts data 
(highly unlikely), we need to detect the condition during boot.

I don't think it matters all that much anyway.  IDE has been running w/ 
256 sectors for a loooong time and someone who seeks performance from 
LBA28 only drive has bigger problems (also I don't think 255 would be 
noticeably slower than 256).

-- 
tejun

Re: What's in libata-dev.git

[Alan Cox]

Ar Llu, 2006-09-11 am 17:47 +0400, ysgrifennodd Sergei Shtylyov:
>     It's not likely I'll be able to try it. But I'm absolutely sure that drive 
> aborted the read commands with the sector count of 0 (i.e. 256 actually). The 
> exact model was IBM DHEA-34331.

Several people reported this problem when we tried 256 years ago in
drivers/ide. You might want to do 256 for SATA Jeff but please don't do
256 for PATA. Reading specs is too hard for some people ;)

Some drives abort the xfer, some just choked.

Re: What's in libata-dev.git

[Jeff Garzik]

Alan Cox wrote:
> Ar Llu, 2006-09-11 am 17:47 +0400, ysgrifennodd Sergei Shtylyov:
>>     It's not likely I'll be able to try it. But I'm absolutely sure that drive 
>> aborted the read commands with the sector count of 0 (i.e. 256 actually). The 
>> exact model was IBM DHEA-34331.
> 
> Several people reported this problem when we tried 256 years ago in
> drivers/ide. You might want to do 256 for SATA Jeff but please don't do
> 256 for PATA. Reading specs is too hard for some people ;)
> 
> Some drives abort the xfer, some just choked.

Where in drivers/ide is it limited to 255?

	Jeff

Re: What's in libata-dev.git

[Sergei Shtylyov]

Hello.

Jeff Garzik wrote:
>> Ar Llu, 2006-09-11 am 17:47 +0400, ysgrifennodd Sergei Shtylyov:

>>>     It's not likely I'll be able to try it. But I'm absolutely sure 
>>> that drive aborted the read commands with the sector count of 0 (i.e. 
>>> 256 actually). The exact model was IBM DHEA-34331.

>> Several people reported this problem when we tried 256 years ago in
>> drivers/ide. You might want to do 256 for SATA Jeff but please don't do
>> 256 for PATA. Reading specs is too hard for some people ;)

>> Some drives abort the xfer, some just choked.

> Where in drivers/ide is it limited to 255?

    Hm, indeed, it's 256 there...
    But the changelog in ide-probe.c suggests the were limited to 255 once 
upon a time. Also, hd.c still has this limit, and changelog talling why it was 
so...

WBR, Sergei

Re: What's in libata-dev.git

[Alan Cox]

Ar Llu, 2006-09-11 am 10:44 -0400, ysgrifennodd Jeff Garzik:
> > drivers/ide. You might want to do 256 for SATA Jeff but please don't do
> > 256 for PATA. Reading specs is too hard for some people ;)
> > 
> > Some drives abort the xfer, some just choked.
> 
> Where in drivers/ide is it limited to 255?

Being a sensible sanity check it was removed, and that was a small
mistake. Some 2.4 also has a 256 limit and it broken various transparent
raid units, older Maxtors(1Gb or so), some IBM drives etc. Got fixed in
-ac but never in base.

The failure pattern is pretty ugly too, your box runs and runs and
eventually you get a linear 256 sector I/O and it all blows up,
sometimes. The IBM's abort the xfer but the maxtors may or may not get
it right (its as if half the firmware has the right test).

We could perhaps do it by ATA version - 255 for ATA < 3 256 for ATA 3+,
lots for LBA48 ? Thats assuming you can show 256 sectors is faster than
255. I'd bet for normal I/O its unmeasurably small.

Alan

Re: What's in libata-dev.git

[Sergei Shtylyov]

Hello.

Alan Cox wrote:

>>>drivers/ide. You might want to do 256 for SATA Jeff but please don't do
>>>256 for PATA. Reading specs is too hard for some people ;)

>>>Some drives abort the xfer, some just choked.

>>Where in drivers/ide is it limited to 255?

> Being a sensible sanity check it was removed, and that was a small
> mistake. Some 2.4 also has a 256 limit and it broken various transparent
> raid units, older Maxtors(1Gb or so), some IBM drives etc. Got fixed in
> -ac but never in base.

> The failure pattern is pretty ugly too, your box runs and runs and
> eventually you get a linear 256 sector I/O and it all blows up,
> sometimes. The IBM's abort the xfer but the maxtors may or may not get
> it right (its as if half the firmware has the right test).

    So, this seems to have a long history... :-)
    I've also heard several years ago of the drives not getting anything over 
128 sectors right, but those should be really brain-damaged...

> We could perhaps do it by ATA version - 255 for ATA < 3 256 for ATA 3+,

    Wouldn't work, I'm afraid. That IBM drive is UltraATA/33, so no less than 
ATA-4...
    Well, after having referred to the ID data read from it, it's ATA-3 actually.

> lots for LBA48 ? Thats assuming you can show 256 sectors is faster than
> 255. I'd bet for normal I/O its unmeasurably small.

> Alan

WBR, Sergei

Re: What's in libata-dev.git

[Jens Axboe]

On Mon, Sep 11 2006, Alan Cox wrote:
> Ar Llu, 2006-09-11 am 10:44 -0400, ysgrifennodd Jeff Garzik:
> > > drivers/ide. You might want to do 256 for SATA Jeff but please don't do
> > > 256 for PATA. Reading specs is too hard for some people ;)
> > > 
> > > Some drives abort the xfer, some just choked.
> > 
> > Where in drivers/ide is it limited to 255?
> 
> Being a sensible sanity check it was removed, and that was a small
> mistake. Some 2.4 also has a 256 limit and it broken various transparent
> raid units, older Maxtors(1Gb or so), some IBM drives etc. Got fixed in
> -ac but never in base.
> 
> The failure pattern is pretty ugly too, your box runs and runs and
> eventually you get a linear 256 sector I/O and it all blows up,
> sometimes. The IBM's abort the xfer but the maxtors may or may not get
> it right (its as if half the firmware has the right test).

So this is a confirmed, broken case? Why has no one complained for 2.4
and 2.6?

> We could perhaps do it by ATA version - 255 for ATA < 3 256 for ATA 3+,

Might be sane, yep.

> lots for LBA48 ? Thats assuming you can show 256 sectors is faster than
> 255. I'd bet for normal I/O its unmeasurably small.

255 isn't faster than 256, measurably. But the alignment for "natural"
transfer sizes is much nicer with 256, that's the problem. You really
don't want 248 + 8 going down all the time, for instance. Perhaps it's
not a real problem, but it could be.

-- 
Jens Axboe

Re: What's in libata-dev.git

[Jeff Garzik]

Jens Axboe wrote:
> On Mon, Sep 11 2006, Alan Cox wrote:
>> We could perhaps do it by ATA version - 255 for ATA < 3 256 for ATA 3+,
> 
> Might be sane, yep.


Since we're doing this just for paranoia, and nobody can actually 
produce a problem case, it's safer just to hardcode 255 for all cases, 
than try to come up with a hueristic that won't be exercised for another 
decade...

Most new disks are lba48 anyway.  (should we use 65535 there too???)

	Jeff

Re: What's in libata-dev.git

[Jens Axboe]

On Mon, Sep 11 2006, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Mon, Sep 11 2006, Alan Cox wrote:
> >>We could perhaps do it by ATA version - 255 for ATA < 3 256 for ATA 3+,
> >
> >Might be sane, yep.
> 
> 
> Since we're doing this just for paranoia, and nobody can actually 
> produce a problem case, it's safer just to hardcode 255 for all cases, 
> than try to come up with a hueristic that won't be exercised for another 
> decade...

If it's a real problem, yes I agree. If it's just hand waving, then no.
The fact that 2.4 and 2.6 has been using 256 for ages really tells me
that no one has been affected by this. The SUSE bugzilla certainly
hasn't seen any entries on it either.

> Most new disks are lba48 anyway.  (should we use 65535 there too???)

Heh, good question. Given that the limit is so high, we might as well
just use 65535. It's not nearly as sensitive as the lba28 case.

-- 
Jens Axboe

Re: What's in libata-dev.git

[Jeff Garzik]

Jens Axboe wrote:
> On Mon, Sep 11 2006, Jeff Garzik wrote:
>> Jens Axboe wrote:
>>> On Mon, Sep 11 2006, Alan Cox wrote:
>>>> We could perhaps do it by ATA version - 255 for ATA < 3 256 for ATA 3+,
>>> Might be sane, yep.
>>
>> Since we're doing this just for paranoia, and nobody can actually 
>> produce a problem case, it's safer just to hardcode 255 for all cases, 
>> than try to come up with a hueristic that won't be exercised for another 
>> decade...
> 
> If it's a real problem, yes I agree. If it's just hand waving, then no.
> The fact that 2.4 and 2.6 has been using 256 for ages really tells me
> that no one has been affected by this. The SUSE bugzilla certainly
> hasn't seen any entries on it either.
> 
>> Most new disks are lba48 anyway.  (should we use 65535 there too???)
> 
> Heh, good question. Given that the limit is so high, we might as well
> just use 65535. It's not nearly as sensitive as the lba28 case.

Well, I _do_ think it's just hand waving, but OTOH I don't see much harm 
in using 255.  Contiguous 256-sector reads and writes have gotta be 
pretty rare.  But that's just a hand-waving guess too ;-)

	Jeff

Re: What's in libata-dev.git

[Jens Axboe]

On Mon, Sep 11 2006, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Mon, Sep 11 2006, Jeff Garzik wrote:
> >>Jens Axboe wrote:
> >>>On Mon, Sep 11 2006, Alan Cox wrote:
> >>>>We could perhaps do it by ATA version - 255 for ATA < 3 256 for ATA 3+,
> >>>Might be sane, yep.
> >>
> >>Since we're doing this just for paranoia, and nobody can actually 
> >>produce a problem case, it's safer just to hardcode 255 for all cases, 
> >>than try to come up with a hueristic that won't be exercised for another 
> >>decade...
> >
> >If it's a real problem, yes I agree. If it's just hand waving, then no.
> >The fact that 2.4 and 2.6 has been using 256 for ages really tells me
> >that no one has been affected by this. The SUSE bugzilla certainly
> >hasn't seen any entries on it either.
> >
> >>Most new disks are lba48 anyway.  (should we use 65535 there too???)
> >
> >Heh, good question. Given that the limit is so high, we might as well
> >just use 65535. It's not nearly as sensitive as the lba28 case.
> 
> Well, I _do_ think it's just hand waving, but OTOH I don't see much harm 
> in using 255.  Contiguous 256-sector reads and writes have gotta be 
> pretty rare.  But that's just a hand-waving guess too ;-)

Just check the default read-ahead size - it's 256 sectors. It's really
not that rare. The read-ahead case can be made a little more clever (and
it really should be), but still. I did some numbers on this when I wrote
the fcache code, and just a regular boot does generate some really big
requests. Big writes are trivial.

248 sector contig requests will in reality be just as fast as 256, I'm
more concerned about the alignment aspect of it. ATA does hit platter
speed fairly quickly. When I last measured a few months ago, for
sequential reads you are already there at 16 sectors (again rounded to
actual observed io in real life, raw it was around 6KiB). The really
nasty case is cache set to write through, there you really want every
milimeter of extra io size to get the performance up on writes.

-- 
Jens Axboe

Re: What's in libata-dev.git

[Linus Torvalds]

On Mon, 11 Sep 2006, Jens Axboe wrote:
> 
> So this is a confirmed, broken case? Why has no one complained for 2.4
> and 2.6?

Oh, I didn't even notice that we do that by default already. That's a bit 
scary - I remember people having their disks trashed.

Maybe the broken disks are old enough to not be an issue any more, or 
maybe something else makes it effectively impossible to trigger in 
practice?

You do need to get 32 pages of contiguous IO for it to happen, and while I 
don't see anything else that would limit it, maybe there is something that 
does? (Some other limiter like max_phys_segments might, but that 
particular one defaults to much more than 32)

Of course, we do hopefully handle requests that fail a lot more 
gracefully these days, so if the drive says it didn't do it, maybe we just 
fix it up properly, in a way we didn't use to.. Ie we may have fixed the 
thing that caused corruption just by fixing something else ;)

		Linus

Re: What's in libata-dev.git

[Jens Axboe]

On Mon, Sep 11 2006, Linus Torvalds wrote:
> 
> 
> On Mon, 11 Sep 2006, Jens Axboe wrote:
> > 
> > So this is a confirmed, broken case? Why has no one complained for 2.4
> > and 2.6?
> 
> Oh, I didn't even notice that we do that by default already. That's a bit 
> scary - I remember people having their disks trashed.
> 
> Maybe the broken disks are old enough to not be an issue any more, or 
> maybe something else makes it effectively impossible to trigger in 
> practice?

Well, as I said, I don't think we ever saw a case that was demonstrably
due to the 256 sector issue. And I really don't think it is as obscure a
fact that people seem to think it is.

> You do need to get 32 pages of contiguous IO for it to happen, and while I 
> don't see anything else that would limit it, maybe there is something that 
> does? (Some other limiter like max_phys_segments might, but that 
> particular one defaults to much more than 32)

It should be pretty trivial to reach, the other IDE limits are basically
way beyond 128kb of contig io. People are hitting this during boot even
I bet, so...

> Of course, we do hopefully handle requests that fail a lot more 
> gracefully these days, so if the drive says it didn't do it, maybe we just 
> fix it up properly, in a way we didn't use to.. Ie we may have fixed the 
> thing that caused corruption just by fixing something else ;)

If the firmware is really buggy in that it doesn't recognise the 0 case
as being 256, you'd see immediate transfer errors. This going by
unnoticed is highly unlikely.

-- 
Jens Axboe

Re: What's in libata-dev.git

[Alan Cox]

Ar Llu, 2006-09-11 am 21:51 +0200, ysgrifennodd Jens Axboe:
> Well, as I said, I don't think we ever saw a case that was demonstrably
> due to the 256 sector issue. And I really don't think it is as obscure a
> fact that people seem to think it is.

One of the ones I've got saved here is this thread. Paul goes on to
demonstrate that changing the 255<->256 limit makes 2.0/2.2/2.4 break or
not break.

--------

There is a potentially serious bug in ide-probe.c in which max_sectors
is set to 256 instead of 255. I am surprised that this hasn't bit anyone
else yet. Perhaps because you need a disk that is slow in comparison to 
the host in order for the queue to climb up to and then hit the 256, at
which point it then falls over. 


For example, with an old 700MB Maxtor on a "fast" 486, VL-bus, PIO, 
hdparm -c1 -m8 -u1, I could pretty much on demand generate the
following 
error by multiple builds, or by the final linking of any big project:


hdc: lost interrupt
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: drive not ready for command
<user space sees binary cruft in source files, etc etc...>


(Note that nothing in the status is really an error). With the
following 
patch, everything works as it should & no errors even under high load.
Patch is against 2.4.3pre2.


Paul.


--- drivers/ide/ide-probe.c~ Sat Mar 17 16:50:14 2001
+++ drivers/ide/ide-probe.c Sat Mar 17 16:58:33 2001
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/ide-probe.c Version 1.06 June 9, 2000
+ * linux/drivers/ide/ide-probe.c Version 1.07 March 18, 2001
*
* Copyright (C) 1994-1998 Linus Torvalds & authors (see below)
*/
@@ -25,6 +25,8 @@
* allowed for secondary flash card to be detectable
* with new flag : drive->ata_flash : 1;
* Version 1.06 stream line request queue and prep for cascade project.
+ * Version 1.07 max_sect <= 255; slower disks would get behind and
+ * then fall over when they get to 256. Paul G.
*/

#undef REALLY_SLOW_IO /* most systems can safely undef this */
@@ -772,10 +774,10 @@
for (unit = 0; unit < minors; ++unit) {
*bs++ = BLOCK_SIZE;
#ifdef CONFIG_BLK_DEV_PDC4030
- *max_sect++ = ((hwif->chipset == ide_pdc4030) ? 127 : 256);
+ *max_sect++ = ((hwif->chipset == ide_pdc4030) ? 127 : 255);
#else
/* IDE can do up to 128K per request. */
- *max_sect++ = 256;
+ *max_sect++ = 255;
#endif
*max_ra++ = MAX_READAHEAD;
}

Re: What's in libata-dev.git

[Greg Freemyer]

On 9/11/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Llu, 2006-09-11 am 21:51 +0200, ysgrifennodd Jens Axboe:
> > Well, as I said, I don't think we ever saw a case that was demonstrably
> > due to the 256 sector issue. And I really don't think it is as obscure a
> > fact that people seem to think it is.
>
> One of the ones I've got saved here is this thread. Paul goes on to
> demonstrate that changing the 255<->256 limit makes 2.0/2.2/2.4 break or
> not break.
>
<snip>

The whole thread is at http://lkml.org/lkml/2001/3/18/29

Greg
-- 
Greg Freemyer
The Norcross Group
Forensics for the 21st Century

Re: What's in libata-dev.git

[Jens Axboe]

On Tue, Sep 12 2006, Alan Cox wrote:
> Ar Llu, 2006-09-11 am 21:51 +0200, ysgrifennodd Jens Axboe:
> > Well, as I said, I don't think we ever saw a case that was demonstrably
> > due to the 256 sector issue. And I really don't think it is as obscure a
> > fact that people seem to think it is.
> 
> One of the ones I've got saved here is this thread. Paul goes on to
> demonstrate that changing the 255<->256 limit makes 2.0/2.2/2.4 break or
> not break.

I remember Paul's mails, and I'm pretty sure that the 256 sectors wasn't
the issue. This is one of the only cases I remember being reported to
lkml, unfortunately I cannot seem to locate the 2nd part of that
thread...

-- 
Jens Axboe

Re: What's in libata-dev.git

[Alan Cox]

Ar Llu, 2006-09-11 am 17:37 +0200, ysgrifennodd Jens Axboe:
> On Mon, Sep 11 2006, Alan Cox wrote:
> > sometimes. The IBM's abort the xfer but the maxtors may or may not get
> > it right (its as if half the firmware has the right test).
> 
> So this is a confirmed, broken case? Why has no one complained for 2.4
> and 2.6?

They did and proposed patches.

Alan

Re: What's in libata-dev.git

[Jens Axboe]

On Mon, Sep 11 2006, Alan Cox wrote:
> Ar Llu, 2006-09-11 am 17:37 +0200, ysgrifennodd Jens Axboe:
> > On Mon, Sep 11 2006, Alan Cox wrote:
> > > sometimes. The IBM's abort the xfer but the maxtors may or may not get
> > > it right (its as if half the firmware has the right test).
> > 
> > So this is a confirmed, broken case? Why has no one complained for 2.4
> > and 2.6?
> 
> They did and proposed patches.

Link?

-- 
Jens Axboe

Re: What's in libata-dev.git

[Jens Axboe]

On Mon, Sep 11 2006, Alan Cox wrote:
> Ar Llu, 2006-09-11 am 17:47 +0400, ysgrifennodd Sergei Shtylyov:
> >     It's not likely I'll be able to try it. But I'm absolutely sure that drive 
> > aborted the read commands with the sector count of 0 (i.e. 256 actually). The 
> > exact model was IBM DHEA-34331.
> 
> Several people reported this problem when we tried 256 years ago in
> drivers/ide. You might want to do 256 for SATA Jeff but please don't do
> 256 for PATA. Reading specs is too hard for some people ;)
> 
> Some drives abort the xfer, some just choked.

Ehm it's 256 now and it has been for a looong time. The few cases I've
seen where people claimed it broke, turned out to be something else.
I've still haven't seen a valid report on this.

It might sound obscure that 0 means 256 sectors, but it's really not a
hidden obscure fact - people do know. I'm all for being conservative
where it matters, but I'm siding with Jeff on this one. I suspect that
Windows uses 256 as well, which basically means that we're in the clear.

-- 
Jens Axboe

Re: What's in libata-dev.git

[Mark Lord]

Sergei Shtylyov wrote:
> ..
>> Jeff Garzik:
> [...]
>>       [ATA] Increase lba48 max-sectors from 200 to 256.
> 
>    So was it for LBA28 or for LBA48?
>    As for LBA28, it might be quite dangerous. Particularly, I know that 
> IBM drives used to mistreated 256 as 0 in the past (bumped into that on 
> a 8-year old drive which is still alive though).
..
>The exact model was IBM DHEA-34331. 

I've been travelling for the past month, so pardon the late tuning in here.
I've *never* encountered a drive that had this problem.
Controllers, yes, and those are easily dealt with in the chipset drivers.

But never drives.  Not since 1992 when I first took up Linux IDE stuff.

I have some 7-year old IBM drives here, and they certainly don't have
this problem either (but they do have working TCQ etc..).

I suspect Sergei simply had a bad controller card at the time.

Cheers

Re: What's in libata-dev.git

[Sergei Shtylyov]

Hello.

Mark Lord wrote:

>>>       [ATA] Increase lba48 max-sectors from 200 to 256.

>>    So was it for LBA28 or for LBA48?
>>    As for LBA28, it might be quite dangerous. Particularly, I know 
>> that IBM drives used to mistreated 256 as 0 in the past (bumped into 
>> that on a 8-year old drive which is still alive though).

> ..

>> The exact model was IBM DHEA-34331.

> I've been travelling for the past month, so pardon the late tuning in here.
> I've *never* encountered a drive that had this problem.
> Controllers, yes, and those are easily dealt with in the chipset drivers.
> 
> But never drives.  Not since 1992 when I first took up Linux IDE stuff.
> 
> I have some 7-year old IBM drives here, and they certainly don't have
> this problem either (but they do have working TCQ etc..).

    That was 8-year old Ultra33 drive, what TCQ? :-)

> I suspect Sergei simply had a bad controller card at the time.

    I can hardly imagine the reason why a PCI IDE controller (that was 
something like VT82C586 I think) would need to mess with the sector count reg. 
in PIO mode and return "command aborted" in the error reg... That was the 
exact sympthom IIRC.

> Cheers

WBR, Sergei

Re: What's in libata-dev.git

[Mark Lord]

Sergei Shtylyov wrote:
>..
>> I suspect Sergei simply had a bad controller card at the time.
> 
>    I can hardly imagine the reason why a PCI IDE controller (that was 
> something like VT82C586 I think) would need to mess with the sector 
> count reg. in PIO mode and return "command aborted" in the error reg... 
> That was the exact sympthom IIRC.

Ahh.. well, if it just returned command aborted, then Jeff's original
change would present no real danger --> any occurances would be detected.

But to answer the imaginative question, the *reason* why a PCI (or VLB) IDE
controller would mess with the registers, is because the makers have this
nasty habit of wanting to do data prefetching (and posting) to speed up
transfers, particularly PIO transfers.  And the only way they can do the
prefetching/posting "safely", is to snoop the taskfile registers and have
the contoller "know" their meanings.

This has lead to all kinds of lunacies, like the RZ1000, CMD640, and other
memorable disasters of mis-implementation.

Cheers!

What's in libata-dev.git

[Jeff Garzik]

The 'upstream' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

contains the following updates (queued for 2.6.18):

 drivers/ide/pci/amd74xx.c         |    7 
 drivers/scsi/Makefile             |    2 
 drivers/scsi/ahci.c               |  436 +++---
 drivers/scsi/ata_piix.c           |   25 
 drivers/scsi/libata-bmdma.c       |  143 ++
 drivers/scsi/libata-core.c        | 2525 ++++++++++++++++++++++++--------------
 drivers/scsi/libata-eh.c          | 1561 +++++++++++++++++++++++
 drivers/scsi/libata-scsi.c        |  408 +++---
 drivers/scsi/libata.h             |   24 
 drivers/scsi/pdc_adma.c           |   10 
 drivers/scsi/sata_mv.c            |   70 -
 drivers/scsi/sata_nv.c            |   13 
 drivers/scsi/sata_promise.c       |   39 
 drivers/scsi/sata_qstor.c         |   14 
 drivers/scsi/sata_sil.c           |   66 
 drivers/scsi/sata_sil24.c         |  615 +++++----
 drivers/scsi/sata_sis.c           |    3 
 drivers/scsi/sata_svw.c           |    5 
 drivers/scsi/sata_sx4.c           |   20 
 drivers/scsi/sata_uli.c           |    3 
 drivers/scsi/sata_via.c           |    3 
 drivers/scsi/sata_vsc.c           |   16 
 drivers/scsi/scsi.c               |   18 
 drivers/scsi/scsi_error.c         |   24 
 drivers/scsi/scsi_lib.c           |    2 
 drivers/scsi/scsi_transport_api.h |    6 
 include/linux/ata.h               |   34 
 include/linux/libata.h            |  386 ++++-
 include/linux/pci_ids.h           |    4 
 include/scsi/scsi_cmnd.h          |    1 
 include/scsi/scsi_host.h          |    1 
 31 files changed, 4764 insertions(+), 1720 deletions(-)

Alan Cox:
      libata: PIO 0
      libata - fix bracketing and DMA oops
      PATCH: libata. Add ->data_xfer method
      ata_piix formatting
      libata: Remove obsolete flag

Albert Lee:
      libata: interrupt driven pio for libata-core
      libata: interrupt driven pio for LLD
      libata irq-pio: add comments and cleanup
      libata irq-pio: rename atapi_packet_task() and comments
      libata irq-pio: simplify if condition in ata_dataout_task()
      libata irq-pio: cleanup ata_qc_issue_prot()
      libata: move atapi_send_cdb() and ata_dataout_task()
      [libata irq-pio] reorganize ata_pio_sector() and __atapi_pio_bytes()
      [libata irq-pio] reorganize "buf + offset" in ata_pio_sector()
      [libata irq-pio] use PageHighMem() to optimize the kmap_atomic() usage
      libata irq-pio: misc fixes
      libata irq-pio: merge the ata_dataout_task workqueue with ata_pio_task workqueue
      libata irq-pio: eliminate unnecessary queuing in ata_pio_first_block()
      libata irq-pio: add read/write multiple support
      libata-dev: determine err_mask when error is found
      libata-dev: filter out noisy ATAPI error messages
      libata-dev: Fix array index value in ata_rwcmd_protocol()
      libata-dev: Use new ata_queue_pio_task() for PIO polling task
      libata-dev: Use new AC_ERR_* flags
      libata-dev: Minor comment fix
      libata-dev: recognize WRITE_MULTI_FUA_EXT for r/w multiple
      libata-dev: Remove trailing whitespaces
      libata-dev: Fix merge problem with upstream
      libata-dev: Remove atapi_packet_task()
      libata-dev: Move out the HSM code from ata_host_intr()
      libata-dev: Minor fix for ata_hsm_move() to work with ata_host_intr()
      libata-dev: Let ata_hsm_move() work with both irq-pio and polling pio
      libata-dev: Convert ata_pio_task() to use the new ata_hsm_move()
      libata-dev: Cleanup unused enums/functions
      libata-dev: ata_check_atapi_dma() fix for ATA_FLAG_PIO_POLLING LLDDs
      libata-dev: Make the the in_wq check as an inline function
      libata-dev: irq-pio minor fixes (respin)
      libata-dev: fix the device err check sequence (respin)
      libata-dev: wait idle after reading the last data block
      libata-dev: print out information for ATAPI devices with CDB interrupts
      libata-dev: handle DRQ=1 ERR=1 (revised)
      libata-dev: irq-pio minor fix
      libata-dev: irq-pio minor fix 2
      libata: convert ATAPI_ENABLE_DMADIR to module parameter
      libata: Fix the HSM error_mask mapping (was: Re: libata-tj and SMART)
      libata: use qc->result_tf for temp taskfile storage
      libata: add pio flush for via atapi (was: Re: TR: ASUS A8V Deluxe, x86_64)
      libata: minor fix for irq-pio merge

Andrew Chew:
      sata_nv: Add MCP61 support

Bastiaan Jacques:
      ahci: add support for VIA VT8251

Jeff Garzik:
      [libata irq-pio] build fix
      [libata pdc_adma] update for removal of ATA_FLAG_NOINTR
      [libata pdc_adma] fix for new irq-driven PIO code
      [libata sata_mv] IRQ PIO build fix
      [libata] irq-pio: fix breakage related to err_mask merge
      [libata sata_promise] irq_pio: fix merge bug
      [libata] build fix after merging some pre-packet_task-removal code
      [libata irq-pio] s/assert/WARN_ON/
      [libata] build fix after cdb_len move
      sata_vsc build fix
      libata: irq-pio build fixes
      [libata] irq-pio: fix build breakage
      [libata] irq-pio: Fix merge mistake
      [libata] kill bogus cut-n-pasted comments in three drivers
      [libata] bump versions
      libata: Fix EH merge difference between this branch and upstream.
      libata: Add helper ata_shost_to_port()
      [libata sata_promise] Add PATA cable detection.
      [libata] libata-scsi, sata_mv: trim trailing whitespace

Luben Tuikov:
      SCSI: Introduce scsi_req_abort_cmd (REPOST)

Mark Lord:
      sata_mv: endian annotations

Tejun Heo:
      libata: increase LBA48 max sectors to 65535
      libata: fix ata_set_mode() return value
      libata: make ata_bus_probe() return negative errno on failure
      libata: separate out ata_spd_string()
      libata: convert do_probe_reset() to ata_do_reset()
      libata: implement ata_dev_enabled and disabled()
      libata: make ata_set_mode() handle no-device case properly
      libata: reorganize ata_set_mode()
      libata: don't disable devices from ata_set_mode()
      libata: preserve SATA SPD setting over hard resets
      libata: implement ata_dev_absent()
      libata: implement ap->sata_spd_limit and helpers
      libata: use SATA speed down in ata_drive_probe_reset()
      libata: add 5s sleep between resets
      libata: implement ata_down_xfermask_limit()
      libata: improve ata_bus_probe()
      libata: consider disabled devices in ata_dev_xfermask()
      libata: report device number when PIO fails
      libata: ata_dev_revalidate() printk update
      libata: ATA_FLAG_IN_EH is not used, kill it
      libata: clean up constants
      libata: rename ATA_FLAG_PORT_DISABLED to ATA_FLAG_DISABLED
      libata: clear only affected flags during ata_dev_configure()
      libata: clear ATA_DFLAG_PIO before setting it
      libata: add ATA_QCFLAG_IO
      libata: pass qc around intead of ap during PIO
      libata: always generate sense if qc->err_mask is non-zero
      libata: don't read TF directly from sense generation functions
      libata: add @cdb to ata_exec_internal()
      libata: dec scmd->retries for qcs with zero err_mask
      libata: separate out libata-eh.c
      libata: make some libata-core routines extern
      libata: print SControl in SATA link status info message
      ahci: do not fail softreset if PHY reports no device
      libata: set default cbl in probeinit
      libata: kill @verbose from ata_reset_fn_t
      libata: make reset methods complain when they fail
      sata_sil24: fix timeout calculation in sil24_softreset
      sata_sil24: better error message from softreset
      libata: implement ata_wait_register()
      ahci: use ata_wait_register()
      sata_sil24: use ata_wait_register()
      libata: disable failed devices only once in ata_bus_probe()
      libata: cosmetic update to ata_bus_probe()
      libata: export ata_set_sata_spd()
      sata_sil24: typo fix
      sata_sil24: rename PORT_IRQ_SDB_FIS to PORT_IRQ_SDB_NOTIFY
      sata_sil24: add more constants
      sata_sil24: consolidate host flags into SIL24_COMMON_FLAGS
      sata_sil24: implement loss of completion interrupt on PCI-X errta fix
      sata_sil24: implement sil24_init_port()
      sata_sil24: put port into known state before softresetting
      sata_sil24: kill 10ms sleep in softreset
      sata_sil24: reimplement hardreset
      sata_sil24: don't do hardreset during driver initialization
      sata_sil24: fix on-memory structure byteorder
      sata_sil24: enable 64bit
      SCSI: implement shost->host_eh_scheduled
      libata: silly fix in ata_scsi_start_stop_xlat()
      libata: rename ata_down_sata_spd_limit() and friends
      ahci: hardreset classification fix
      libata: unexport ata_scsi_error()
      libata: kill duplicate prototypes
      libata: fix ->phy_reset class code handling in ata_bus_probe()
      libata: clear ap->active_tag atomically w.r.t. command completion
      libata: hold host_set lock while finishing internal qc
      libata: use preallocated buffers
      libata: move ->set_mode() handling into ata_set_mode()
      libata: remove postreset handling from ata_do_reset()
      libata: implement qc->result_tf
      sata_sil24: update TF image only when necessary
      libata: init ap->cbl to ATA_CBL_SATA early
      libata: implement new SCR handling and port on/offline functions
      libata: use new SCR and on/offline functions
      libata: kill old SCR functions and sata_dev_present()
      libata: add dev->ap
      libata: use dev->ap
      libata: implement ATA printk helpers
      libata: use ATA printk helpers
      libata-eh-fw: add flags and operations for new EH
      libata-eh-fw: clear SError in ata_std_postreset()
      libata-eh-fw: use special reserved tag and qc for internal commands
      libata-eh-fw: update ata_qc_from_tag() to enforce normal/EH qc ownership
      libata-eh-fw: implement new EH scheduling via error completion
      libata-eh-fw: implement ata_port_schedule_eh() and ata_port_abort()
      libata-eh-fw: implement freeze/thaw
      libata-eh-fw: implement new EH scheduling from PIO
      libata-eh-fw: update ata_scsi_error() for new EH
      libata-eh-fw: update ata_exec_internal() for new EH
      libata-eh-fw: update SCSI command completion path for new EH
      libata-eh: add ATA and libata flags for new EH
      libata-eh: implement dev->ering
      libata-eh: implement ata_eh_info and ata_eh_context
      libata-eh: implement new EH
      libata-eh: implement BMDMA EH
      ata_piix: convert to new EH
      sata_sil: convert to new EH
      ahci: convert to new EH
      ahci: add PIOS interim interrupt handling
      sata_sil24: convert to new EH
      libata: fix irq-pio merge
      libata-ncq: add NCQ related ATA/libata constants and macros
      libata-ncq: pass ata_scsi_translate() return value to SCSI midlayer
      libata-ncq: rename ap->qactive to ap->qc_allocated
      libata-ncq: implement ap->qc_active, ap->sactive and complete helper
      libata-ncq: implement NCQ command translation and exclusion
      libata-ncq: update EH to handle NCQ
      libata-ncq: implement NCQ device configuration
      ahci: clean up AHCI constants in preparation for NCQ
      ahci: add HOST_CAP_NCQ constant
      ahci: kill pp->cmd_tbl_sg
      ahci: implement NCQ suppport
      sata_sil24: implement NCQ support
      libata: enforce default EH actions
      SCSI: make scsi_implement_eh() generic API for SCSI transports

Thomas Glanzmann:
      Add PCI ID for the Intel IDE Controller which is in the Intel Mac Minis shipped in first quarter 2006

What's in libata-dev.git

[Jeff Garzik]

Junio routinely posts these nice "What's in git.git" messages to the git
mailing list.  These posts are a useful guide to what's upcoming.

Since libata-dev.git contains a number of branches for ongoing
development projects, I thought a "What's in libata-dev.git" message
would be useful.


------------------------------------------------------------------------
branch: upstream (pending for 2.6.18)
parent: master
------------------------------------------------------------------------
Albert Lee:
      libata: convert ATAPI_ENABLE_DMADIR to module parameter

Jeff Garzik:
      [libata] kill bogus cut-n-pasted comments in three drivers
      [libata] bump versions
      libata: Fix EH merge difference between this branch and upstream.
      libata: Add helper ata_shost_to_port()

Tejun Heo:
      libata: fix ata_set_mode() return value
      libata: make ata_bus_probe() return negative errno on failure
      libata: separate out ata_spd_string()
      libata: convert do_probe_reset() to ata_do_reset()
      libata: implement ata_dev_enabled and disabled()
      libata: make ata_set_mode() handle no-device case properly
      libata: reorganize ata_set_mode()
      libata: don't disable devices from ata_set_mode()
      libata: preserve SATA SPD setting over hard resets
      libata: implement ata_dev_absent()
      libata: implement ap->sata_spd_limit and helpers
      libata: use SATA speed down in ata_drive_probe_reset()
      libata: add 5s sleep between resets
      libata: implement ata_down_xfermask_limit()
      libata: improve ata_bus_probe()
      libata: consider disabled devices in ata_dev_xfermask()
      libata: report device number when PIO fails
      libata: ata_dev_revalidate() printk update
      libata: ATA_FLAG_IN_EH is not used, kill it
      libata: clean up constants
      libata: rename ATA_FLAG_PORT_DISABLED to ATA_FLAG_DISABLED
      libata: clear only affected flags during ata_dev_configure()
      libata: clear ATA_DFLAG_PIO before setting it
      libata: add ATA_QCFLAG_IO
      libata: pass qc around intead of ap during PIO
      libata: always generate sense if qc->err_mask is non-zero
      libata: don't read TF directly from sense generation functions
      libata: add @cdb to ata_exec_internal()
      libata: dec scmd->retries for qcs with zero err_mask
      libata: separate out libata-eh.c
      libata: make some libata-core routines extern
      libata: print SControl in SATA link status info message
      ahci: do not fail softreset if PHY reports no device
      libata: set default cbl in probeinit
      libata: kill @verbose from ata_reset_fn_t
      libata: make reset methods complain when they fail
      sata_sil24: fix timeout calculation in sil24_softreset
      sata_sil24: better error message from softreset
      libata: implement ata_wait_register()
      ahci: use ata_wait_register()
      sata_sil24: use ata_wait_register()
      libata: disable failed devices only once in ata_bus_probe()
      libata: cosmetic update to ata_bus_probe()
      libata: export ata_set_sata_spd()
      sata_sil24: typo fix
      sata_sil24: rename PORT_IRQ_SDB_FIS to PORT_IRQ_SDB_NOTIFY
      sata_sil24: add more constants
      sata_sil24: consolidate host flags into SIL24_COMMON_FLAGS
      sata_sil24: implement loss of completion interrupt on PCI-X errta fix
      sata_sil24: implement sil24_init_port()
      sata_sil24: put port into known state before softresetting
      sata_sil24: kill 10ms sleep in softreset
      sata_sil24: reimplement hardreset
      sata_sil24: don't do hardreset during driver initialization
      sata_sil24: fix on-memory structure byteorder
      sata_sil24: enable 64bit


------------------------------------------------------------------------
branch: sii-m15w (update Mod15Write blacklist, now that errata is
		 handled better)
parent: upstream
------------------------------------------------------------------------
Tejun Heo:
      sata_sil: remove unaffected drives from m15w blacklist


------------------------------------------------------------------------
branch: sii-lbt (improve DMA handling, eliminate 64k legacy limits)
parent: sii-m15w
------------------------------------------------------------------------
Jeff Garzik:
      [libata sata_sil] Greatly improve DMA handling


------------------------------------------------------------------------
branch: sii-irq (use sii-specific interrupt handler)
parent: sii-m15w
------------------------------------------------------------------------
Jeff Garzik:
      [libata sata_sil] improved interrupt handling
      [libata sata_sil] update for new ata_qc_complete() 1-arg API
      libata: sata_sil build fix


------------------------------------------------------------------------
branch: promise-sata-pata (support for Promise PATA ports on SATA cards)
parent: upstream
------------------------------------------------------------------------
Erik Benada:
      [libata sata_promise] support PATA ports on SATA controllers

Jeff Garzik:
      [libata sata_promise] fix build breakage due to bad merge


------------------------------------------------------------------------
branch: pata-drivers (PATA drivers from Alan and Albert)
parent: upstream
------------------------------------------------------------------------
Alan Cox:
      Add libata CMD/SI680 driver
      [libata] Add PATA driver for Compaq Triflex
      [libata] Add PATA VIA driver.
      [libata] Add driver for PATA AMD/NVIDIA chips.
      libata: Update the AMD driver to support the AMD CS5536.
      libata: Add enablebits support to the triflex driver
      libata: Add enablebits to via driver
      [libata] Add new PATA driver pata_opti
      libata: AMD pata fixes
      libata: Fix opti pci enable bits as with the AMD bug
      libata: Fix enable bits for triflex
      libata: Clean up and fix the VIA PATA libata driver
      libata: Update TODO list for pata_amd
      libata: Updates to the MPIIX driver

Albert Lee:
      [libata] add driver for Promise PATA 2027x
      libata-dev-2.6: pdc2027x add ata_scsi_ioctl
      libata-dev-2.6: pdc2027x change comments
      libata-dev-2.6: pdc2027x move the PLL counter reading code
      libata-dev-2.6: pdc2027x PLL input clock detection fix
      libata-dev: Convert pdc2027x from PIO to MMIO
      libata-dev: pdc2027x use "long" for counter data type
      libata-dev: pdc2027x ATAPI DMA lost irq problem workaround
      libata: pata_pdc2027x minor fix
      libata: convert pata_pdc2027x to the new reset mechanism

Andrew Morton:
      pata_opti needs PCI

Jeff Garzik:
      [libata] pata_pdc2027x: update for recent ->host_stop() API changes
      [libata pata_pdc2027x] add documentation ref in header; trim trailing whitespace
      [libata pata_sil680] add to Makefile/Kconfig
      libata: Add makefile rules for pata_via driver.
      [libata] minor updates to PATA drivers
      [libata] constify PCI tables in PATA drivers
      [libata pata_via] fix warning
      libata: Add Intel MPIIX and "old PIIX" PATA drivers.
      [libata pata drivers] trim trailing whitespace
      [libata] remove 'ordered_flush' member from PATA drivers
      [libata pata] fix lingering old-style qc_issue_prot function declarations
      [libata pata_pdc2027x] use pci_iomap(), kzalloc() where appropriate
      [libata] s/ata_dev_present/ata_dev_enabled/ for several PATA drivers
      [libata pata] update for removal of .eh_strategy_handler from Scsi_Host_Template


------------------------------------------------------------------------
branch: nv-adma (ADMA version of sata_nv)
parent: upstream
------------------------------------------------------------------------
Jeff Garzik:
      [libata] ADMA version from sata_nv
      [libata] sata_nv: cleanups
      [libata] sata_nv: more cleanups
      [libata] sata_nv: fix ADMA qc_issue prototype for latest libata API
      [libata sata_nv] update for movement of eh_strategy_handler


------------------------------------------------------------------------
branch: max-sect (increase LBA48 max sectors)
parent: upstream
------------------------------------------------------------------------
Tejun Heo:
      libata: increase LBA48 max sectors to 65535


------------------------------------------------------------------------
branch: irq-pio (IRQ-driven PIO)
parent: upstream
------------------------------------------------------------------------
Albert Lee:
      libata: interrupt driven pio for libata-core
      libata: interrupt driven pio for LLD
      libata irq-pio: add comments and cleanup
      libata irq-pio: rename atapi_packet_task() and comments
      libata irq-pio: simplify if condition in ata_dataout_task()
      libata irq-pio: cleanup ata_qc_issue_prot()
      libata: move atapi_send_cdb() and ata_dataout_task()
      [libata irq-pio] reorganize ata_pio_sector() and __atapi_pio_bytes()
      [libata irq-pio] reorganize "buf + offset" in ata_pio_sector()
      [libata irq-pio] use PageHighMem() to optimize the kmap_atomic() usage
      libata irq-pio: misc fixes
      libata irq-pio: merge the ata_dataout_task workqueue with ata_pio_task workqueue
      libata irq-pio: eliminate unnecessary queuing in ata_pio_first_block()
      libata irq-pio: add read/write multiple support
      libata-dev: determine err_mask when error is found
      libata-dev: filter out noisy ATAPI error messages
      libata-dev: Fix array index value in ata_rwcmd_protocol()
      libata-dev: Use new ata_queue_pio_task() for PIO polling task
      libata-dev: Use new AC_ERR_* flags
      libata-dev: Minor comment fix
      libata-dev: recognize WRITE_MULTI_FUA_EXT for r/w multiple
      libata-dev: Remove trailing whitespaces
      libata-dev: Fix merge problem with upstream
      libata-dev: Remove atapi_packet_task()
      libata-dev: Move out the HSM code from ata_host_intr()
      libata-dev: Minor fix for ata_hsm_move() to work with ata_host_intr()
      libata-dev: Let ata_hsm_move() work with both irq-pio and polling pio
      libata-dev: Convert ata_pio_task() to use the new ata_hsm_move()
      libata-dev: Cleanup unused enums/functions
      libata-dev: ata_check_atapi_dma() fix for ATA_FLAG_PIO_POLLING LLDDs
      libata-dev: Make the the in_wq check as an inline function
      libata-dev: irq-pio minor fixes (respin)
      libata-dev: fix the device err check sequence (respin)
      libata-dev: wait idle after reading the last data block
      libata-dev: print out information for ATAPI devices with CDB interrupts
      libata-dev: handle DRQ=1 ERR=1 (revised)
      libata-dev: irq-pio minor fix
      libata-dev: irq-pio minor fix 2

Jeff Garzik:
      [libata irq-pio] build fix
      [libata pdc_adma] update for removal of ATA_FLAG_NOINTR
      [libata pdc_adma] fix for new irq-driven PIO code
      [libata sata_mv] IRQ PIO build fix
      [libata] irq-pio: fix breakage related to err_mask merge
      [libata sata_promise] irq_pio: fix merge bug
      [libata] build fix after merging some pre-packet_task-removal code
      [libata irq-pio] s/assert/WARN_ON/
      [libata] build fix after cdb_len move
      sata_vsc build fix
      libata: irq-pio build fixes
      [libata] irq-pio: fix build breakage
      [libata] irq-pio: Fix merge mistake


------------------------------------------------------------------------
branch: iomap (use lib/iomap in libata)
parent: git-merge-base iomap master
------------------------------------------------------------------------

Older work converting libata to use iomap.


------------------------------------------------------------------------
branch: ALL (merge of all useful libata-dev.git branches)
parent: upstream, sii-m15w, promise-sata-pata, pata-drivers, max-sect
------------------------------------------------------------------------

Re: What's in libata-dev.git

[Bastiaan Jacques]

Hi Jeff,

Do you intend to merge the "ahci: add support for VIA VT8251" patch?

Bastiaan