| Message ID | 4AFCC0D4.9020708@gmail.com |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On Thu, 12 Nov 2009 20:13:40 -0600 Robert Hancock <hancockrwd@gmail.com> 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 <hancockrwd@gmail.com> Acked-by: Alan Cox <alan@linux.intel.com> And we should probably thin down the EXPERIMENTALs in the drivers too. I'll take a look at those in a bit -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <hancockrwd@gmail.com> 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
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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..
> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.. ]
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..
El Fri, 13 Nov 2009 18:25:15 +0000 Alan Cox <alan@lxorguk.ukuu.org.uk> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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..
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.
On Fri, 13 Nov 2009 23:58:45 +0100 Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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"..
On Sat, 14 Nov 2009 00:46:29 +0100 Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 14 November 2009 01:15:10 Alan Cox wrote: > On Sat, 14 Nov 2009 00:46:29 +0100 > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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.. :)
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.
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..
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 <mjg59@srcf.ucam.org> AuthorDate: Wed Oct 3 01:24:16 2007 +0100 Commit: Jeff Garzik <jeff@garzik.org> 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.
> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.. ]
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<hancockrwd@gmail.com> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 <hancockrwd@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html