* What's in libata-dev.git
@ 2006-09-11 13:22 Jeff Garzik
2006-09-11 13:35 ` Sergei Shtylyov
0 siblings, 1 reply; 36+ messages in thread
From: Jeff Garzik @ 2006-09-11 13:22 UTC (permalink / raw)
To: linux-ide; +Cc: linux-kernel, Andrew Morton, Linus Torvalds
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()
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 13:22 What's in libata-dev.git Jeff Garzik
@ 2006-09-11 13:35 ` Sergei Shtylyov
2006-09-11 13:37 ` Jeff Garzik
2006-10-04 17:57 ` Mark Lord
0 siblings, 2 replies; 36+ messages in thread
From: Sergei Shtylyov @ 2006-09-11 13:35 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 13:35 ` Sergei Shtylyov
@ 2006-09-11 13:37 ` Jeff Garzik
2006-09-11 13:47 ` Sergei Shtylyov
2006-10-04 17:57 ` Mark Lord
1 sibling, 1 reply; 36+ messages in thread
From: Jeff Garzik @ 2006-09-11 13:37 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 13:37 ` Jeff Garzik
@ 2006-09-11 13:47 ` Sergei Shtylyov
2006-09-11 13:49 ` Jeff Garzik
2006-09-11 15:02 ` Alan Cox
0 siblings, 2 replies; 36+ messages in thread
From: Sergei Shtylyov @ 2006-09-11 13:47 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 13:47 ` Sergei Shtylyov
@ 2006-09-11 13:49 ` Jeff Garzik
2006-09-11 14:53 ` Linus Torvalds
2006-09-11 15:02 ` Alan Cox
1 sibling, 1 reply; 36+ messages in thread
From: Jeff Garzik @ 2006-09-11 13:49 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 15:02 ` Alan Cox
@ 2006-09-11 14:44 ` Jeff Garzik
2006-09-11 15:05 ` Sergei Shtylyov
2006-09-11 15:28 ` Alan Cox
2006-09-11 15:06 ` Jens Axboe
1 sibling, 2 replies; 36+ messages in thread
From: Jeff Garzik @ 2006-09-11 14:44 UTC (permalink / raw)
To: Alan Cox
Cc: Sergei Shtylyov, linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 13:49 ` Jeff Garzik
@ 2006-09-11 14:53 ` Linus Torvalds
2006-09-11 15:24 ` Jeff Garzik
2006-09-12 8:42 ` Helge Hafting
0 siblings, 2 replies; 36+ messages in thread
From: Linus Torvalds @ 2006-09-11 14:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Sergei Shtylyov, linux-ide, linux-kernel, Andrew Morton
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 13:47 ` Sergei Shtylyov
2006-09-11 13:49 ` Jeff Garzik
@ 2006-09-11 15:02 ` Alan Cox
2006-09-11 14:44 ` Jeff Garzik
2006-09-11 15:06 ` Jens Axboe
1 sibling, 2 replies; 36+ messages in thread
From: Alan Cox @ 2006-09-11 15:02 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Jeff Garzik, linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 14:44 ` Jeff Garzik
@ 2006-09-11 15:05 ` Sergei Shtylyov
2006-09-11 15:28 ` Alan Cox
1 sibling, 0 replies; 36+ messages in thread
From: Sergei Shtylyov @ 2006-09-11 15:05 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alan Cox, linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 15:02 ` Alan Cox
2006-09-11 14:44 ` Jeff Garzik
@ 2006-09-11 15:06 ` Jens Axboe
1 sibling, 0 replies; 36+ messages in thread
From: Jens Axboe @ 2006-09-11 15:06 UTC (permalink / raw)
To: Alan Cox
Cc: Sergei Shtylyov, Jeff Garzik, linux-ide, linux-kernel,
Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 15:28 ` Alan Cox
@ 2006-09-11 15:21 ` Sergei Shtylyov
2006-09-11 15:37 ` Jens Axboe
1 sibling, 0 replies; 36+ messages in thread
From: Sergei Shtylyov @ 2006-09-11 15:21 UTC (permalink / raw)
To: Alan Cox
Cc: Jeff Garzik, linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 14:53 ` Linus Torvalds
@ 2006-09-11 15:24 ` Jeff Garzik
2006-09-12 8:42 ` Helge Hafting
1 sibling, 0 replies; 36+ messages in thread
From: Jeff Garzik @ 2006-09-11 15:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sergei Shtylyov, linux-ide, linux-kernel, Andrew Morton
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 14:44 ` Jeff Garzik
2006-09-11 15:05 ` Sergei Shtylyov
@ 2006-09-11 15:28 ` Alan Cox
2006-09-11 15:21 ` Sergei Shtylyov
2006-09-11 15:37 ` Jens Axboe
1 sibling, 2 replies; 36+ messages in thread
From: Alan Cox @ 2006-09-11 15:28 UTC (permalink / raw)
To: Jeff Garzik
Cc: Sergei Shtylyov, linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 15:28 ` Alan Cox
2006-09-11 15:21 ` Sergei Shtylyov
@ 2006-09-11 15:37 ` Jens Axboe
2006-09-11 15:50 ` Jeff Garzik
` (2 more replies)
1 sibling, 3 replies; 36+ messages in thread
From: Jens Axboe @ 2006-09-11 15:37 UTC (permalink / raw)
To: Alan Cox
Cc: Jeff Garzik, Sergei Shtylyov, linux-ide, linux-kernel,
Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 15:37 ` Jens Axboe
@ 2006-09-11 15:50 ` Jeff Garzik
2006-09-11 20:01 ` Jens Axboe
2006-09-11 16:04 ` Linus Torvalds
2006-09-11 16:26 ` Alan Cox
2 siblings, 1 reply; 36+ messages in thread
From: Jeff Garzik @ 2006-09-11 15:50 UTC (permalink / raw)
To: Jens Axboe
Cc: Alan Cox, Sergei Shtylyov, linux-ide, linux-kernel,
Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 15:37 ` Jens Axboe
2006-09-11 15:50 ` Jeff Garzik
@ 2006-09-11 16:04 ` Linus Torvalds
2006-09-11 19:51 ` Jens Axboe
2006-09-11 16:26 ` Alan Cox
2 siblings, 1 reply; 36+ messages in thread
From: Linus Torvalds @ 2006-09-11 16:04 UTC (permalink / raw)
To: Jens Axboe
Cc: Alan Cox, Jeff Garzik, Sergei Shtylyov, linux-ide, linux-kernel,
Andrew Morton
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 15:37 ` Jens Axboe
2006-09-11 15:50 ` Jeff Garzik
2006-09-11 16:04 ` Linus Torvalds
@ 2006-09-11 16:26 ` Alan Cox
2006-09-11 19:51 ` Jens Axboe
2 siblings, 1 reply; 36+ messages in thread
From: Alan Cox @ 2006-09-11 16:26 UTC (permalink / raw)
To: Jens Axboe
Cc: Jeff Garzik, Sergei Shtylyov, linux-ide, linux-kernel,
Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 16:04 ` Linus Torvalds
@ 2006-09-11 19:51 ` Jens Axboe
2006-09-11 23:00 ` Alan Cox
0 siblings, 1 reply; 36+ messages in thread
From: Jens Axboe @ 2006-09-11 19:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jens Axboe, Alan Cox, Jeff Garzik, Sergei Shtylyov, linux-ide,
linux-kernel, Andrew Morton
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 16:26 ` Alan Cox
@ 2006-09-11 19:51 ` Jens Axboe
0 siblings, 0 replies; 36+ messages in thread
From: Jens Axboe @ 2006-09-11 19:51 UTC (permalink / raw)
To: Alan Cox
Cc: Jeff Garzik, Sergei Shtylyov, linux-ide, linux-kernel,
Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 15:50 ` Jeff Garzik
@ 2006-09-11 20:01 ` Jens Axboe
2006-09-11 20:14 ` Jeff Garzik
0 siblings, 1 reply; 36+ messages in thread
From: Jens Axboe @ 2006-09-11 20:01 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alan Cox, Sergei Shtylyov, linux-ide, linux-kernel,
Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 20:01 ` Jens Axboe
@ 2006-09-11 20:14 ` Jeff Garzik
2006-09-11 20:23 ` Jens Axboe
0 siblings, 1 reply; 36+ messages in thread
From: Jeff Garzik @ 2006-09-11 20:14 UTC (permalink / raw)
To: Jens Axboe
Cc: Alan Cox, Sergei Shtylyov, linux-ide, linux-kernel,
Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 20:14 ` Jeff Garzik
@ 2006-09-11 20:23 ` Jens Axboe
0 siblings, 0 replies; 36+ messages in thread
From: Jens Axboe @ 2006-09-11 20:23 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alan Cox, Sergei Shtylyov, linux-ide, linux-kernel,
Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 23:00 ` Alan Cox
@ 2006-09-11 22:53 ` Greg Freemyer
2006-09-12 5:22 ` Jens Axboe
1 sibling, 0 replies; 36+ messages in thread
From: Greg Freemyer @ 2006-09-11 22:53 UTC (permalink / raw)
To: Alan Cox
Cc: Jens Axboe, Linus Torvalds, Jens Axboe, Jeff Garzik,
Sergei Shtylyov, linux-ide, linux-kernel, Andrew Morton
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 19:51 ` Jens Axboe
@ 2006-09-11 23:00 ` Alan Cox
2006-09-11 22:53 ` Greg Freemyer
2006-09-12 5:22 ` Jens Axboe
0 siblings, 2 replies; 36+ messages in thread
From: Alan Cox @ 2006-09-11 23:00 UTC (permalink / raw)
To: Jens Axboe
Cc: Linus Torvalds, Jens Axboe, Jeff Garzik, Sergei Shtylyov,
linux-ide, linux-kernel, Andrew Morton
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;
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 23:00 ` Alan Cox
2006-09-11 22:53 ` Greg Freemyer
@ 2006-09-12 5:22 ` Jens Axboe
1 sibling, 0 replies; 36+ messages in thread
From: Jens Axboe @ 2006-09-12 5:22 UTC (permalink / raw)
To: Alan Cox
Cc: Linus Torvalds, Jeff Garzik, Sergei Shtylyov, linux-ide,
linux-kernel, Andrew Morton
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 14:53 ` Linus Torvalds
2006-09-11 15:24 ` Jeff Garzik
@ 2006-09-12 8:42 ` Helge Hafting
2006-09-13 1:50 ` Tejun Heo
1 sibling, 1 reply; 36+ messages in thread
From: Helge Hafting @ 2006-09-12 8:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff Garzik, Sergei Shtylyov, linux-ide, linux-kernel, Andrew Morton
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-12 8:42 ` Helge Hafting
@ 2006-09-13 1:50 ` Tejun Heo
0 siblings, 0 replies; 36+ messages in thread
From: Tejun Heo @ 2006-09-13 1:50 UTC (permalink / raw)
To: Helge Hafting
Cc: Linus Torvalds, Jeff Garzik, Sergei Shtylyov, linux-ide,
linux-kernel, Andrew Morton
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-09-11 13:35 ` Sergei Shtylyov
2006-09-11 13:37 ` Jeff Garzik
@ 2006-10-04 17:57 ` Mark Lord
2006-10-04 18:03 ` Sergei Shtylyov
1 sibling, 1 reply; 36+ messages in thread
From: Mark Lord @ 2006-10-04 17:57 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Jeff Garzik, linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-10-04 17:57 ` Mark Lord
@ 2006-10-04 18:03 ` Sergei Shtylyov
2006-10-04 18:48 ` Mark Lord
0 siblings, 1 reply; 36+ messages in thread
From: Sergei Shtylyov @ 2006-10-04 18:03 UTC (permalink / raw)
To: Mark Lord
Cc: Jeff Garzik, linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-10-04 18:03 ` Sergei Shtylyov
@ 2006-10-04 18:48 ` Mark Lord
0 siblings, 0 replies; 36+ messages in thread
From: Mark Lord @ 2006-10-04 18:48 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Jeff Garzik, linux-ide, linux-kernel, Andrew Morton, Linus Torvalds
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!
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2007-01-24 17:26 ` Mark Lord
@ 2007-01-24 19:19 ` Jeff Garzik
0 siblings, 0 replies; 36+ messages in thread
From: Jeff Garzik @ 2007-01-24 19:19 UTC (permalink / raw)
To: Mark Lord; +Cc: linux-ide, LKML
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2007-01-24 7:26 Jeff Garzik
@ 2007-01-24 17:26 ` Mark Lord
2007-01-24 19:19 ` Jeff Garzik
0 siblings, 1 reply; 36+ messages in thread
From: Mark Lord @ 2007-01-24 17:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, LKML
What happened to ATA Passthru command support for ATAPI?
Cheers
^ permalink raw reply [flat|nested] 36+ messages in thread
* What's in libata-dev.git
@ 2007-01-24 7:26 Jeff Garzik
2007-01-24 17:26 ` Mark Lord
0 siblings, 1 reply; 36+ messages in thread
From: Jeff Garzik @ 2007-01-24 7:26 UTC (permalink / raw)
To: linux-ide; +Cc: LKML
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(-)
^ permalink raw reply [flat|nested] 36+ messages in thread
* What's in libata-dev.git
@ 2006-05-24 7:08 Jeff Garzik
0 siblings, 0 replies; 36+ messages in thread
From: Jeff Garzik @ 2006-05-24 7:08 UTC (permalink / raw)
To: linux-ide; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: What's in libata-dev.git
2006-04-18 9:54 Jeff Garzik
@ 2006-04-18 15:07 ` Bastiaan Jacques
0 siblings, 0 replies; 36+ messages in thread
From: Bastiaan Jacques @ 2006-04-18 15:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
Hi Jeff,
Do you intend to merge the "ahci: add support for VIA VT8251" patch?
Bastiaan
^ permalink raw reply [flat|nested] 36+ messages in thread
* What's in libata-dev.git
@ 2006-04-18 9:54 Jeff Garzik
2006-04-18 15:07 ` Bastiaan Jacques
0 siblings, 1 reply; 36+ messages in thread
From: Jeff Garzik @ 2006-04-18 9:54 UTC (permalink / raw)
To: linux-ide; +Cc: linux-kernel
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
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2007-01-24 19:19 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-11 13:22 What's in libata-dev.git Jeff Garzik
2006-09-11 13:35 ` Sergei Shtylyov
2006-09-11 13:37 ` Jeff Garzik
2006-09-11 13:47 ` Sergei Shtylyov
2006-09-11 13:49 ` Jeff Garzik
2006-09-11 14:53 ` Linus Torvalds
2006-09-11 15:24 ` Jeff Garzik
2006-09-12 8:42 ` Helge Hafting
2006-09-13 1:50 ` Tejun Heo
2006-09-11 15:02 ` Alan Cox
2006-09-11 14:44 ` Jeff Garzik
2006-09-11 15:05 ` Sergei Shtylyov
2006-09-11 15:28 ` Alan Cox
2006-09-11 15:21 ` Sergei Shtylyov
2006-09-11 15:37 ` Jens Axboe
2006-09-11 15:50 ` Jeff Garzik
2006-09-11 20:01 ` Jens Axboe
2006-09-11 20:14 ` Jeff Garzik
2006-09-11 20:23 ` Jens Axboe
2006-09-11 16:04 ` Linus Torvalds
2006-09-11 19:51 ` Jens Axboe
2006-09-11 23:00 ` Alan Cox
2006-09-11 22:53 ` Greg Freemyer
2006-09-12 5:22 ` Jens Axboe
2006-09-11 16:26 ` Alan Cox
2006-09-11 19:51 ` Jens Axboe
2006-09-11 15:06 ` Jens Axboe
2006-10-04 17:57 ` Mark Lord
2006-10-04 18:03 ` Sergei Shtylyov
2006-10-04 18:48 ` Mark Lord
-- strict thread matches above, loose matches on Subject: below --
2007-01-24 7:26 Jeff Garzik
2007-01-24 17:26 ` Mark Lord
2007-01-24 19:19 ` Jeff Garzik
2006-05-24 7:08 Jeff Garzik
2006-04-18 9:54 Jeff Garzik
2006-04-18 15:07 ` Bastiaan Jacques
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.