Remove the experimental tag on Parallel ATA drivers. Though some of the
individual PATA drivers are still marked as experimental, as a group they can
hardly be considered to be, given they've been used in various distros for some
time.
Signed-off-by: Robert Hancock <[email protected]>
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index f2df6e2..33133c6 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -3,7 +3,7 @@
#
menuconfig ATA
- tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
+ tristate "Serial ATA and Parallel ATA drivers"
depends on HAS_IOMEM
depends on BLOCK
depends on !(M32R || M68K) || BROKEN
On Thu, 12 Nov 2009 20:13:40 -0600
Robert Hancock <[email protected]> wrote:
> Remove the experimental tag on Parallel ATA drivers. Though some of the
> individual PATA drivers are still marked as experimental, as a group they can
> hardly be considered to be, given they've been used in various distros for some
> time.
>
> Signed-off-by: Robert Hancock <[email protected]>
Acked-by: Alan Cox <[email protected]>
And we should probably thin down the EXPERIMENTALs in the drivers too.
I'll take a look at those in a bit
On Friday 13 November 2009 03:13:40 Robert Hancock wrote:
> Remove the experimental tag on Parallel ATA drivers. Though some of the
> individual PATA drivers are still marked as experimental, as a group they can
> hardly be considered to be, given they've been used in various distros for some
> time.
>
> Signed-off-by: Robert Hancock <[email protected]>
Fine but please update status of following host drivers that were
marked as "stable" prematurely by commit e3389cb first:
PATA_PDC_OLD: needs to be marked as EXPERIMENTAL (or just BROKEN)
- known reliability problems with UDMA
PATA_ALI: EXPERIMENTAL
- ATAPI DMA is still broken
PATA_CMD64X: EXPERIMENTAL
- potential data corruption issues remains unfixed for CMD64[3,6]
PATA_SIS: EXPERIMENTAL
- missing MWDMA support on newer controllers
They are all old & known problems and not present in
[ "old", "deprecated", "legacy" ] counterparts.
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index f2df6e2..33133c6 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -3,7 +3,7 @@
> #
>
> menuconfig ATA
> - tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
> + tristate "Serial ATA and Parallel ATA drivers"
> depends on HAS_IOMEM
> depends on BLOCK
> depends on !(M32R || M68K) || BROKEN
--
Bartlomiej Zolnierkiewicz
> Fine but please update status of following host drivers that were
> marked as "stable" prematurely by commit e3389cb first:
>
> PATA_PDC_OLD: needs to be marked as EXPERIMENTAL (or just BROKEN)
> - known reliability problems with UDMA
A few odd reports apparently linked to specific chip revs. It's at
least as stable as the old IDE one which doesn't work on my hardware. I'd
love to get it working on everything but neither driver does and I don't
think we are likely to ever extract more docs from Promise.
> PATA_ALI: EXPERIMENTAL
> - ATAPI DMA is still broken
Not experimental as we default to not doing ATAPI DMA. Glancing over the
code I notice the ALI C2/C3 workaround probably wants adding to the old
driver as it can do nasty things otherwise. (See the reset function in
the pata_ali driver)
> PATA_CMD64X: EXPERIMENTAL
> - potential data corruption issues remains unfixed for CMD64[3,6]
Patch in testing, and unlike the old IDE one it doesn't cripple the
controller but implements the proper workaround in full including
permitting parallel PIO command streams. I'll push that back through
stable once done.
> PATA_SIS: EXPERIMENTAL
> - missing MWDMA support on newer controllers
Yes seems someone fixed that in the old driver but didn't forward port
it. Trivial and fixed.
BTW - its wrong in the old driver as far as I can see - it doesn't clip
the DMA mode to the PIO limit as required by the documentation and the
ATA standard. Remember the same timings are used for both PIO and MWDMA
cycles.
> They are all old & known problems and not present in
> [ "old", "deprecated", "legacy" ] counterparts.
Which has its own different set of problems.
Any others spring to mind while you are at it ?
Alan
On Friday 13 November 2009 19:25:15 Alan Cox wrote:
> > Fine but please update status of following host drivers that were
> > marked as "stable" prematurely by commit e3389cb first:
> >
> > PATA_PDC_OLD: needs to be marked as EXPERIMENTAL (or just BROKEN)
> > - known reliability problems with UDMA
>
> A few odd reports apparently linked to specific chip revs. It's at
> least as stable as the old IDE one which doesn't work on my hardware. I'd
> love to get it working on everything but neither driver does and I don't
> think we are likely to ever extract more docs from Promise.
"A few odd reports..." is a big understatement here..
> > PATA_ALI: EXPERIMENTAL
> > - ATAPI DMA is still broken
>
> Not experimental as we default to not doing ATAPI DMA. Glancing over the
Which is a regression compared to the "old IDE" driver.
> code I notice the ALI C2/C3 workaround probably wants adding to the old
> driver as it can do nasty things otherwise. (See the reset function in
> the pata_ali driver)
Please let the driver's maintainer know about it.
One would wonder why workaround hasn't been back-ported to stable driver
but said one is not familiar with kernel development process' definitions
of such words as "progress", "working with", "consensus" and "technical
honesty".
> > PATA_CMD64X: EXPERIMENTAL
> > - potential data corruption issues remains unfixed for CMD64[3,6]
>
> Patch in testing, and unlike the old IDE one it doesn't cripple the
> controller but implements the proper workaround in full including
> permitting parallel PIO command streams. I'll push that back through
> stable once done.
This patch is way too complex and risky for -rc, let alone -stable.
> > PATA_SIS: EXPERIMENTAL
> > - missing MWDMA support on newer controllers
>
> Yes seems someone fixed that in the old driver but didn't forward port
You mean like someone fixed the non-experimental driver back in October
2007 and the author of the experimental one didn't care to port over
the fix for two years?
Indeed a very bad thing and much worse than not porting back fixes from
experimental stuff to a stable code. As the author of the original fix
I would like to stand corrected and publicly apologize for my negligence.
> it. Trivial and fixed.
I can't see a fix anywhere but I'll assume that I can't look for it
properly (I'm really sorry for it).
> BTW - its wrong in the old driver as far as I can see - it doesn't clip
> the DMA mode to the PIO limit as required by the documentation and the
> ATA standard. Remember the same timings are used for both PIO and MWDMA
> cycles.
Please let the driver's maintainer know.
> > They are all old & known problems and not present in
> > [ "old", "deprecated", "legacy" ] counterparts.
>
> Which has its own different set of problems.
Which doesn't matter at all here.
Progress is not about replacing one set of slightly buggy drivers
with another slightly buggy one. At least this was the old definition
of the word..
> Any others spring to mind while you are at it ?
HPA handling related patches that were "being worked on" if you really
would like to know..
--
Bartlomiej Zolnierkiewicz
> > Not experimental as we default to not doing ATAPI DMA. Glancing over the
>
> Which is a regression compared to the "old IDE" driver.
And given the two drivers show the difference when exactly the sequence
of I/O writes/reads occurs one that nobody plans to worry about as its
clearly some kind of hardware timing issue.
> > code I notice the ALI C2/C3 workaround probably wants adding to the old
> > driver as it can do nasty things otherwise. (See the reset function in
> > the pata_ali driver)
>
> Please let the driver's maintainer know about it.
>
> One would wonder why workaround hasn't been back-ported to stable driver
It's in the stable driver, might not be in drivers/ide. The note about it
being missing was posted out to various people at the time so I guess it
got missed
> > > PATA_CMD64X: EXPERIMENTAL
> > > - potential data corruption issues remains unfixed for CMD64[3,6]
> >
> > Patch in testing, and unlike the old IDE one it doesn't cripple the
> > controller but implements the proper workaround in full including
> > permitting parallel PIO command streams. I'll push that back through
> > stable once done.
>
> This patch is way too complex and risky for -rc, let alone -stable.
How would you know - I've not posted it yet ? And btw I don't plan to
post it for the -rc. Nor would simply posting a serializing hack fix it.
It might make it less likely to occur but that isn't a fix.
> > it. Trivial and fixed.
>
> I can't see a fix anywhere but I'll assume that I can't look for it
> properly (I'm really sorry for it).
Fixed as in I fixed it now. Which is why I just noticed the old IDE ones
are buggy. I'll add it to the next patch sets for Jeff, along with the
Toshiba driver and some other bits.
Alan
On 11/13/2009 02:39 PM, Bartlomiej Zolnierkiewicz wrote:
>> Any others spring to mind while you are at it ?
>
> HPA handling related patches that were "being worked on" if you really
> would like to know..
Can you elaborate on this one?
Thanks for posting all these issues to linux-ide, and getting them
discussed. It is appreciated.
Jeff
On Friday 13 November 2009 22:30:07 Alan Cox wrote:
> > > > PATA_CMD64X: EXPERIMENTAL
> > > > - potential data corruption issues remains unfixed for CMD64[3,6]
> > >
> > > Patch in testing, and unlike the old IDE one it doesn't cripple the
> > > controller but implements the proper workaround in full including
> > > permitting parallel PIO command streams. I'll push that back through
> > > stable once done.
> >
> > This patch is way too complex and risky for -rc, let alone -stable.
>
> How would you know - I've not posted it yet ? And btw I don't plan to
I prefer to not talk about "virtual" patches (especially since I'm still
waiting for HPA fixes promised in May) and the only patch so far was the one
from two weeks ago:
http://article.gmane.org/gmane.linux.ide/43136
[ it has still unfixed problems.. ]
--
Bartlomiej Zolnierkiewicz
On Friday 13 November 2009 22:57:51 Jeff Garzik wrote:
> On 11/13/2009 02:39 PM, Bartlomiej Zolnierkiewicz wrote:
> >> Any others spring to mind while you are at it ?
> >
> > HPA handling related patches that were "being worked on" if you really
> > would like to know..
>
>
> Can you elaborate on this one?
Certain someone announced that he was working on porting my IDE HPA work to
libata, after almost half a year there is nothing out of it and all my queries
regarding the status of said work are ignored..
I begin to assume that such announcement was just a well planned strategy to
put stop to my (then ongoing) attempts in reaching other libata developers in
helping me with porting the code..
--
Bartlomiej Zolnierkiewicz
El Fri, 13 Nov 2009 18:25:15 +0000
Alan Cox <[email protected]> escribió:
>
> > PATA_ALI: EXPERIMENTAL
> > - ATAPI DMA is still broken
>
> Not experimental as we default to not doing ATAPI DMA. Glancing over the
> code I notice the ALI C2/C3 workaround probably wants adding to the old
> driver as it can do nasty things otherwise. (See the reset function in
> the pata_ali driver)
FWIW I have a Motherboard with Ali chipset and have been using ATAPI DMA
(forcing it via proc) without issues since the DMA was disabled by default.
lspci -v
IDE interface: ALi Corporation M5229 IDE (rev c7) (prog-if 8a [Master SecP PriP])
Subsystem: ASRock Incorporation Device 5229
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 21
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
[virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
I/O ports at ff00 [size=16]
Capabilities: <access denied>
Kernel driver in use: pata_ali
Kernel modules: ata_generic
>
> Alan
>
> http://article.gmane.org/gmane.linux.ide/43136
>
> [ it has still unfixed problems.. ]
Which of course you haven't bothered to point out or explain.
On Friday 13 November 2009 23:42:51 Alan Cox wrote:
>
> > http://article.gmane.org/gmane.linux.ide/43136
> >
> > [ it has still unfixed problems.. ]
>
> Which of course you haven't bothered to point out or explain.
I meant problems reported by Mikulas:
http://thread.gmane.org/gmane.linux.ide/43069/focus=43136
Maybe they were fixed in your local tree but how would anyone know that given
that there haven't been any updates on the problem for the last two weeks..
--
Bartlomiej Zolnierkiewicz
On Friday 13 November 2009 19:25:15 Alan Cox wrote:
> > Fine but please update status of following host drivers that were
> > marked as "stable" prematurely by commit e3389cb first:
> >
> > PATA_PDC_OLD: needs to be marked as EXPERIMENTAL (or just BROKEN)
> > - known reliability problems with UDMA
>
> A few odd reports apparently linked to specific chip revs. It's at
> least as stable as the old IDE one which doesn't work on my hardware. I'd
Skipping the technical merit of the quoted text for the moment -- I find
the fact that you keep calling the present IDE host drivers (that many
developers helped to fix) as "old" ones or "buggy" ones rather degrading
for their (this includes me of course) hard work.
Especially given your complete lack of familiarity with post-2004 changes.
See for yourself, *50* mostly _trivial_ patches during *5* years:
[ "git log --follow --since="5 years ago" drivers/ide|grep "Author: Alan Cox" -B1 -A3"
output edited for easier reading ]
commit d878829 piix: The Sony TZ90 needs the cable type hardcoding
commit ccd32e2 ide: Switch to a common address
commit 1bee4d1 pdc202xx_old: remove surplus initialiser
commit d3bad45 dtc2278: note on docs
commit 9702b5d ide: Stop mapping ROMs
commit 7859557 ide: Fix a theoretical Ooops case
commit 2074a10 ide/pci/serverworks.c: Fix corruption/timeouts with MegaIDE
commit 640b31b sl82c105: Switch to ref counting API
commit 846c11a ide: remove a ton of pointless #undef REALLY_SLOW_IO
commit 8693d3e siimage: DRAC4 note
commit fdb77da ide-floppy: Fix unformatted media crash
commit 3e9e4c8 ide/generic: Jmicron has its own drivers now
commit ee2f344 [PATCH] ide-cd: Handle strange interrupt on the Intel ESB2
commit 6451956 [PATCH] ide: complete switch to pci_get
commit b148900 [PATCH] ide: more conversion to pci_get APIs
commit 23a1b2a [PATCH] via82cxxx: handle error condition properly
commit c333526 [PATCH] JMB 368 PATA detection
commit 3a42bb2 [PATCH] ide: add sanity checking to ide taskfile ioctl
commit 3719bc5 [PATCH] ide-generic: jmicron fix
commit 652aa16 [PATCH] IDE: more pci_find cleanup
commit 913759a [PATCH] ide: Fix crash on repeated reset
commit 5ac2469 [PATCH] ide: backport piix fixes from libata into the legacy..
commit bbb3bbd [PATCH] non-libata driver for Jmicron devices
commit 40cddf2 [PATCH] sis5513: Switch to pci refcounting
commit 970a613 [PATCH] serverworks: Switch to pci refcounted interfaces
commit 1424e50 [PATCH] piix: Use refcounted interface when searching for a ..
commit 28a2a3f [PATCH] Fix 2.6.18-rc6 IDE breakage, add missing ident neede..
commit a7dec1e [PATCH] Missing PCI id update for VIA IDE
commit 79860a9 [PATCH] PATCH: 2.6.18 oops on boot fix for IDE
commit 15e0c69 [PATCH] ide: fix Jmicron support
commit faab17b [PATCH] Fix problem with ATAPI DMA on IT8212 in Linux
commit 3706a87 [PATCH] Set err_stops_fifo for newer Promise as well
commit 57e834e [PATCH] ide: clean up pdc202xx_old so its more readable (don..
commit f201f50 [PATCH] ide: housekeeping on IDE drivers
commit da574af [PATCH] ide: fix error handling for drives which clear the F..
commit 2930d1b [PATCH] SC1200 debug printk
commit 19c1ef5 [PATCH] ide: clean up siimage
commit 1a1276e [PATCH] Old IDE, fix SATA detection for cabling
commit 4fb0f76 [PATCH] Fix IDE locking error
commit dbe217a [PATCH] IDE CD end-of media error fix
commit d266ab8 [PATCH] Small fixes backported to old IDE SiS driver
commit 0c866b5 [PATCH] ide: set latency when resetting it821x out of firmwa..
commit d7d7634 [PATCH] ide: clean up the garbage in eighty_ninty_three
commit da9091e [PATCH] ide: it8212 backport for Bartlomiej IDE
commit bb732d7 [PATCH] ide: fix crashes with hotplug serverworks
commit b39b01f [PATCH] ide: fix the HPT366 driver layer
commit b189346 [PATCH] ide: ide-generic, allow for capture of other unsuppo..
commit 68ad991 [PATCH] ide: IDE timing violation on reset
commit 58ecd15 [PATCH] ide: samsung SN-124 works perfectly well with DMA
commit 6efd936 [PATCH] ide: fix ide-disk inability to handle LBA only devic..
Despite this it seems that at least LWN.net seems to treat your opinions with
completely undeserved seriousness.. Weird.
--
Bartlomiej Zolnierkiewicz
On Fri, 13 Nov 2009 23:58:45 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Friday 13 November 2009 23:42:51 Alan Cox wrote:
> >
> > > http://article.gmane.org/gmane.linux.ide/43136
> > >
> > > [ it has still unfixed problems.. ]
> >
> > Which of course you haven't bothered to point out or explain.
>
> I meant problems reported by Mikulas:
>
> http://thread.gmane.org/gmane.linux.ide/43069/focus=43136
>
> Maybe they were fixed in your local tree but how would anyone know that given
> that there haven't been any updates on the problem for the last two weeks..
Yeah its fixed - well I think so. I've not chased it up further yet
because I've been working on far more important things than an anicent IDE
controller patch that isn't an -rc candidate anyway.
(basically you need to also set priv->dma_live if you are the only device
or nothing is live but doing DMA)
Alan
On Saturday 14 November 2009 00:46:29 Bartlomiej Zolnierkiewicz wrote:
> On Friday 13 November 2009 19:25:15 Alan Cox wrote:
> > > Fine but please update status of following host drivers that were
> > > marked as "stable" prematurely by commit e3389cb first:
> > >
> > > PATA_PDC_OLD: needs to be marked as EXPERIMENTAL (or just BROKEN)
> > > - known reliability problems with UDMA
> >
> > A few odd reports apparently linked to specific chip revs. It's at
> > least as stable as the old IDE one which doesn't work on my hardware. I'd
>
> Skipping the technical merit of the quoted text for the moment -- I find
> the fact that you keep calling the present IDE host drivers (that many
> developers helped to fix) as "old" ones or "buggy" ones rather degrading
> for their (this includes me of course) hard work.
>
> Especially given your complete lack of familiarity with post-2004 changes.
>
> See for yourself, *50* mostly _trivial_ patches during *5* years:
>
> [ "git log --follow --since="5 years ago" drivers/ide|grep "Author: Alan Cox" -B1 -A3"
> output edited for easier reading ]
I've also looked at ATA side of the things for the last *3* years now:
$ git log --follow --since="3 years ago" drivers/ata|grep "Author: Alan Cox"|wc -l
173
[ ~5 patches a month and most of the work was to bring PATA on the level that
old IDE code has offered back in 2005.. ]
also before people start calling me names or teach me about "accumulated
credibility" concept:
I'm in no way trying to deny people's past achievements (hey, I got inspired
by Alan's work myself in early days) but I would like to raise the awareness
that these days it is a way more difficult than it was in the past to make
significant and/or large scale changes so new people are stuck in Catch22 when
it comes to "accumulated credibility"..
--
Bartlomiej Zolnierkiewicz
On Sat, 14 Nov 2009 00:46:29 +0100
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Friday 13 November 2009 19:25:15 Alan Cox wrote:
> > > Fine but please update status of following host drivers that were
> > > marked as "stable" prematurely by commit e3389cb first:
> > >
> > > PATA_PDC_OLD: needs to be marked as EXPERIMENTAL (or just BROKEN)
> > > - known reliability problems with UDMA
> >
> > A few odd reports apparently linked to specific chip revs. It's at
> > least as stable as the old IDE one which doesn't work on my hardware. I'd
>
> Skipping the technical merit of the quoted text for the moment -- I find
You mean the content ?
> the fact that you keep calling the present IDE host drivers (that many
> developers helped to fix) as "old" ones or "buggy" ones rather degrading
As you quoted the old PDC202xx driver does not work on my test hardware.
The libata one does. That is what is popularly known as a "fact". I'm not
entirely happy with either PDC driver for older chips and I've spent
considerable time grovelling through old drivers, alternate drivers and
what little documentation exists to try and figure it out in more detail.
The lost IRQ recovery patches seem to have helped a fair bit, and your
UDMA33 fix likewise.
> for their (this includes me of course) hard work.
All because you wouldn't work on the libata ones which had a future. You
are forgetting of course to mention that a good deal of analysis went
into deciding to switch to libata and teach libata to do PATA devices.
Stuff I'd say has proved to be bang on the mark as every PC class system
now has SATA, already has the SATA stack and in many cases have devices
where the PATA and SATA ports interact so must be driven by the same
stack. Now that CF is dying I'd say its pretty much proven the right
choice.
I am *really* glad to see that with the wireless you are contributing
heavily to both the old and new. If only you'd done that with PATA we
would all have been better off.
Alan
On Saturday 14 November 2009 01:15:10 Alan Cox wrote:
> On Sat, 14 Nov 2009 00:46:29 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > On Friday 13 November 2009 19:25:15 Alan Cox wrote:
> > > > Fine but please update status of following host drivers that were
> > > > marked as "stable" prematurely by commit e3389cb first:
> > > >
> > > > PATA_PDC_OLD: needs to be marked as EXPERIMENTAL (or just BROKEN)
> > > > - known reliability problems with UDMA
> > >
> > > A few odd reports apparently linked to specific chip revs. It's at
> > > least as stable as the old IDE one which doesn't work on my hardware. I'd
> >
> > Skipping the technical merit of the quoted text for the moment -- I find
>
> You mean the content ?
>
> > the fact that you keep calling the present IDE host drivers (that many
> > developers helped to fix) as "old" ones or "buggy" ones rather degrading
>
> As you quoted the old PDC202xx driver does not work on my test hardware.
> The libata one does. That is what is popularly known as a "fact". I'm not
You want facts? Here we go:
https://bugzilla.redhat.com/show_bug.cgi?id=250349
https://bugzilla.novell.com/show_bug.cgi?id=457037
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/399616
> entirely happy with either PDC driver for older chips and I've spent
> considerable time grovelling through old drivers, alternate drivers and
> what little documentation exists to try and figure it out in more detail.
>
> The lost IRQ recovery patches seem to have helped a fair bit, and your
> UDMA33 fix likewise.
I regret this work -- because of it I share the blame for the new driver
and keep getting complains about it..
> > for their (this includes me of course) hard work.
>
> All because you wouldn't work on the libata ones which had a future. You
The rest of your mail is "the same good old straw-man" to put me back
into specially created for me by you & co. "difficult to work with" box.
Guys, "the devil" has been long out of the box.. :)
--
Bartlomiej Zolnierkiewicz
On Sat, Nov 14, 2009 at 12:46:29AM +0100, Bartlomiej Zolnierkiewicz wrote:
> Skipping the technical merit of the quoted text for the moment -- I find
> the fact that you keep calling the present IDE host drivers (that many
> developers helped to fix) as "old" ones or "buggy" ones rather degrading
> for their (this includes me of course) hard work.
Without making any judgement about the relative quality of the drivers
in their role as IDE drivers, the fact that ACPI hotplug works with
libata and doesn't work with drivers/ide means that, rationally,
distributions need to use the libata stack for the more common parts.
There simply isn't the same level of integration between drivers/ide and
the rest of the OS.
--
Matthew Garrett | [email protected]
On Saturday 14 November 2009 03:29:51 Matthew Garrett wrote:
> On Sat, Nov 14, 2009 at 12:46:29AM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> > Skipping the technical merit of the quoted text for the moment -- I find
> > the fact that you keep calling the present IDE host drivers (that many
> > developers helped to fix) as "old" ones or "buggy" ones rather degrading
> > for their (this includes me of course) hard work.
>
> Without making any judgement about the relative quality of the drivers
> in their role as IDE drivers, the fact that ACPI hotplug works with
> libata and doesn't work with drivers/ide means that, rationally,
> distributions need to use the libata stack for the more common parts.
This doesn't change the fact that there are real regressions present in
libata host drivers and people who should be responsible for fixing them
are just ignoring them..
> There simply isn't the same level of integration between drivers/ide and
> the rest of the OS.
Fully agreed but it doesn't change anything for issues discussed.
On the side note -- certain distributions, I'm sure you know which one
I mean specifically [1], "helped" a lot in making sure that such level
of integration would be very difficult to achieve (ACPI hotplug was
added later than some distributions, again you know which one I mean
specifically [1], switched to libata _only_ for PATA).
[1] The one whose developers love to blame every damn single problem
on everybody else from PC hardware designers ;) through BIOS' writers
to ordinary users.. instead (if only from time to time) considering
that there could be something wrong with their own development process
if they constantly miss fixes done by their competitors..
--
Bartlomiej Zolnierkiewicz
On Saturday 14 November 2009 03:54:01 Bartlomiej Zolnierkiewicz wrote:
> On Saturday 14 November 2009 03:29:51 Matthew Garrett wrote:
> > On Sat, Nov 14, 2009 at 12:46:29AM +0100, Bartlomiej Zolnierkiewicz wrote:
> >
> > > Skipping the technical merit of the quoted text for the moment -- I find
> > > the fact that you keep calling the present IDE host drivers (that many
> > > developers helped to fix) as "old" ones or "buggy" ones rather degrading
> > > for their (this includes me of course) hard work.
> >
> > Without making any judgement about the relative quality of the drivers
> > in their role as IDE drivers, the fact that ACPI hotplug works with
> > libata and doesn't work with drivers/ide means that, rationally,
> > distributions need to use the libata stack for the more common parts.
>
> This doesn't change the fact that there are real regressions present in
> libata host drivers and people who should be responsible for fixing them
> are just ignoring them..
>
> > There simply isn't the same level of integration between drivers/ide and
> > the rest of the OS.
>
> Fully agreed but it doesn't change anything for issues discussed.
>
> On the side note -- certain distributions, I'm sure you know which one
> I mean specifically [1], "helped" a lot in making sure that such level
> of integration would be very difficult to achieve (ACPI hotplug was
> added later than some distributions, again you know which one I mean
> specifically [1], switched to libata _only_ for PATA).
I've checked this now:
23 January 2007 F7 Test1 development freeze
..
31 May 2007 F7 General Availability
vs.
ommit 237d8440cb2b104a3b97fc971a9bce67960bb616
Author: Matthew Garrett <[email protected]>
AuthorDate: Wed Oct 3 01:24:16 2007 +0100
Commit: Jeff Garzik <[email protected]>
CommitDate: Fri Oct 12 14:55:45 2007 -0400
libata: Integrate ACPI-based PATA/SATA hotplug - version 5
Modern laptops with hotswap bays still tend to utilise a PATA interface
on a SATA bridge, generally with the host controller in some legacy
emulation mode rather than AHCI. This means that the existing hotplug
code in libata is unable to work. The ACPI specification states that
...
Please take a look at dates and author of the commit.
You helped create such situation in the first place and now you try to
use it as an technical argument to justify past decisions.
Anyway it doesn't matter here at all.
Why are people even bringing this or quality of "old" IDE host drivers
in the discussion as a justification for the quality of _new_ drivers?
Double standards and hypocrisy comes to a mind.
--
Bartlomiej Zolnierkiewicz
> > As you quoted the old PDC202xx driver does not work on my test hardware.
> > The libata one does. That is what is popularly known as a "fact". I'm not
>
> You want facts? Here we go:
So you spent the day searching bugzillas.. congratulations. Btw you
missed one. I have a total of four reports I know about.
> I regret this work -- because of it I share the blame for the new driver
> and keep getting complains about it..
Amazing.. I don't.
I look forward to receiving patches from Red Hat, SuSE or Ubuntu.
Alan
On Saturday 14 November 2009 17:04:38 Alan Cox wrote:
> > > As you quoted the old PDC202xx driver does not work on my test hardware.
> > > The libata one does. That is what is popularly known as a "fact". I'm not
> >
> > You want facts? Here we go:
>
> So you spent the day searching bugzillas.. congratulations. Btw you
Lol, how come's that you know better then me what I do? :)
[ I didn't spend a single minute on it, some good people pinged me for help
and gave me bugzilla numbers.. ]
--
Bartlomiej Zolnierkiewicz
On 11/12/2009 09:13 PM, Robert Hancock wrote:
> Remove the experimental tag on Parallel ATA drivers. Though some of the
> individual PATA drivers are still marked as experimental, as a group they can
> hardly be considered to be, given they've been used in various distros for some
> time.
>
> Signed-off-by: Robert Hancock<[email protected]>
>
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index f2df6e2..33133c6 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -3,7 +3,7 @@
> #
>
> menuconfig ATA
> - tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
> + tristate "Serial ATA and Parallel ATA drivers"
> depends on HAS_IOMEM
> depends on BLOCK
applied