Alan Cox posted an updated LibATA PATA (IDE) status report on the lkml. Improved from a previous status report [story] he noted, "current kernels now support HPA (Host Protected Area) but default to honouring it. Probably a wrong default for PATA but we need to decide the right way to expose it nicely." He went on to note, "no PATA hotplug support yet. Need warmplug helpers for some chipsets (eg some intel ICH) to avoid risk of hangs."
Later in the report he listed around 40 chipsets describing LibATA's PATA support for each, ranging from "rock solid" for ATIIXP and "solid" for AMD, TRIFLEX, MARVELL, MPIIX, OLDPIIX, NETCELL, RZ1000, SERVERWORKS, SIL680, and VIA, to "still experimental" for NS87410 and "no idea" for IT8213. When asked about support for PowerPC drivers, Alan replied, "I'm not aware of anyone having done any PPC ports yet, although a couple of people have asked and said they would look at it. Currently our coverage is incomplete for some embedded and obscure platforms, of which the macintrash is probably the least 'obscure'."
From: Alan Cox [email blocked] To: linux-ide, [email blocked], Subject: Libata PATA status Date: Tue, 3 Jul 2007 18:51:16 +0100 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Libata General with respect to PATA ==================================== Wrong port and IRQ reporting - IRQ now fixed by Tejun, port reporting fixes sent to Andrew. All these are cosmetic and don't harm debug. Still can't user set drive speed or user issue commands at a given speed. Needed to allow users to bump cable rules, fix strange stuff and for some emulated chips to issue RAID control ATA packets in PIO0 (no I've no idea why they only work in PIO0 ;)). No serialization of channel pairs. PATA General ============ Current kernels now support HPA (Host Protected Area) but default to honouring it. Probably a wrong default for PATA but we need to decide the right way to expose it nicely. Cable detection should now be sane. Still issues with SATA bridges. Some test hacks in my code base but nothing for upstream yet. My tree has global DMA control aka ide=nodma. Need to decide the best way to push a version of this. Ancient non IORDY capable devices need patches still in my devel tree Post SRST we need to decide what to do about mode setting - do we put the controller in PIO0 specifically ? My tree does and this seems to help on non PC systems. No PATA hotplug support yet. Need warmplug helpers for some chipsets (eg some intel ICH) to avoid risk of hangs. Chipsets ======== PIIX Tejun should have the MWDMA bugs fixed otherwise so far so good. Mostly maintained by other people. ACPI Driver needs a rewrite based upon what has been learned about the BIOS handling of the ACPI methods. On the TODO list ALI 2.6.22rc7 fixed the last known non-atapi bug. Stil some ATAPI problem reports unresolved AMD Solid. ACPI tweaks in my tree for Nvidia cable detect and pushed to -mm. Target for 2.6.23 ARTOP No reports, but nobody appears to be using one ATIIXP Rock solid. For SATA side use AHCI CMD640 Seems to work but still little testing CMD64X Tested on x86, needs more Sparc/Alpha feedback CS5520 Solid for PIO. No virtual DMA support (and none likely unless its contributed) CS5530 Obscure hang bug fix just sent to -mm tree but not observed in real world use. Otherwise stable CS5535 No reports CYPRESS Needs someone with an ancient Alpha. May drop entirely EFAR Seems solid. Needs some PIIX updates cross checking for EFAR relevance. Low priority GENERIC Fix for "DMA set up but not used" bug in -git HPT366 Seems to be solid. Needs a backport of the chip detect changes Sergei just finished for old IDE. Low priority no real impact from their lack HPT37X Working but some further work required to get it behaving on all combinations HPT3X2N Still has problems on some systems. Tracking the work being done in old-ide which seems to behave similarly HPT3X3 Solid PIO support sent to -mm. DMA is problematic. Doesn't work with old IDE at all so not too problematic. Doesn't work in base kernel ISAPNP Seems to work, no bug reports but not many users IT8212 Multiple fixes, should now be stable in RAID and Pass-through modes thanks to driver fixes and core fixes from Tejun IT8213 No idea JMICRON Works reliably. No recent changes LEGACY Works ok. Complete rewrite in progress to clean up all the pre-PCI support TRIFLEX Solid, no recent changes. MARVELL Solid, will be replaced by PATA AHCI-like support in time (but not by me) MPIIX Solid, no recent changes OLDPIIX Solid, no recent changes NETCELL Solid, no recent changes NS87410 Still experimental, almost no users OPTIPIO Very much experimental but seems to work OPTIDMA Very much experimental, but seems to work. Only one user known however PCMCIA Works reliably. Some problems with IRQ routing on some CF cards that seem to be card related. Works on systems with no DMA API support as of patches sent to -mm PDC_OLD 2.6.22-git has cable detection bug fixed QDI Works, will be folded into LEGACY rewrite RADISYS Very experimental, no changes, low priority RZ1000 Solid, works, no changes SC1200 Single channel only still. Needs work for dual channel -mm has fix for a DMA hang bug SERVERWORKS Solid, no changes of note SIL680 Solid, no recent changes SIS Current tree fixes crash on boot some users reported, code cleanups, no other major changes for pure PATA devices VIA Solid. Sent acpi patch for -mm to try and fix the one remaining mystery "how to spot VIA with onboard SATA bridges properly. If you've got a VIA board with SATA ports that appear as PATA channels please drop me an email as I'd like to get more info on what is affected. WINBOND No changes, still experimental
From: Kyle Moffett [email blocked] To: Alan Cox [email blocked] Subject: Re: Libata PATA status Date: Tue, 3 Jul 2007 23:04:26 -0400 On Jul 03, 2007, at 13:51:16, Alan Cox wrote: > Libata General with respect to PATA > ==================================== > > [...snip...] > > Chipsets > ======== > > [...snip...] I'd love to try to poke holes in the libata PATA support, but sadly it doesn't look like any of my systems built-in ATA chipsets are supported yet. Has anyone started a rewrite of the PPC/PowerMac IDE driver? The current one is in "drivers/ide/ppc/pmac.c", and supports these chipsets: OHare ATA Heathrow ATA KeyLargo ATA-3 KeyLargo ATA-4 UniNorth ATA-6 (IE: Kauai) K2 ATA-6 Shasta ATA-6 I'd be willing to test drivers for the UniNorth ATA-6 and K2 ATA-6, as well as possibly the KeyLargo ATA-3/4, depending on what the old MDD G4 in my closet has. Sadly my libata-foo is insufficient for me to do anything useful (other than thoroughly testing my backup- restoration procedure, maybe :-D). Cheers,
From: Alan Cox [email blocked] To: Kyle Moffett [email blocked] Subject: Re: Libata PATA status Date: Wed, 4 Jul 2007 10:21:29 +0100 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 > I'd love to try to poke holes in the libata PATA support, but sadly > it doesn't look like any of my systems built-in ATA chipsets are > supported yet. Has anyone started a rewrite of the PPC/PowerMac IDE > driver? The current one is in "drivers/ide/ppc/pmac.c", and supports > these chipsets: I'm not aware of anyone having done any PPC ports yet, although a couple of people have asked and said they would look at it. Currently our coverage is incomplete for some embedded and obscure platforms, of which the macintrash is probably the least 'obscure'. Alan
CMD64X on sparc64 is looking good
As reported in:
http://marc.info/?l=linux-sparc&m=118356839704129&w=2
With dma enabled? Is this
With dma enabled? Is this better than the old driver? But .. nevertheless, I am still searching for the fitting scsi controller on <online action site>. ;)
Switching to Libata drivers
Hi! I'm using a vanilla kernel (2.6.22) and am trying to switch from the old IDE drivers to libata for my PATA hard disk (currently the root is /dev/hda2). I've compiled a kernel with just the libata portion but when I try to boot I get the following message: vfs: cannot open root device UUID=blahblah or unknown-block (0,0)
My /etc/fstab and /boot/grub/menu.lst have the correct UUID for the root fs, what can be wrong here that it can't properly find the root fs ?
More information:
1. Libata and PATA are configured _not_ as a module, they're static in the kernel.
2. I'm not using initrd.
3. I've tried to boot from grub with root=/dev/sda2 instead of using UUID, but had the same error.
4. I've an force2 motherboard and am using the CONFIG_PATA_AMD option.
Thanks in advance for any comment about this.
JC
Re: Switching to Libata drivers
This isn't generally a help forum, but is your PATA device even being detected? It should show up in the boot messages; you can use [Shift]-[PgUp] to scroll back. And make sure that your filesystem is also staticly compiled.
Re: Switching to Libata drivers
I don't think that JC is still waiting for an answer, but for all those people coming here via Google and having the same problem: the kernel _is not_ able to understand UUIDs. Some (mostly Debian-based) distributions offer this via their initramfs (that's kinda initrd v2.0): the initramfs contains userspace tools, including vol_id from udev, and use this to convert UUIDs into device names like hdXY.
To sum it up: either use your old initramfs that the stock kernel was using, or don't use UUIDs.
Thank you Alan!
Thank you so much for you hard work on PATA. I recently moved from the standard Ubuntu Kernel 2.6.20-16 to compile my own 2.6.22.1 with some new settings
Using hdparm on new MSI P35 Platinum (core2duo)
before: Timing buffered disk reads: 6 MB in 3.75 seconds = 1.60 MB/sec
after : Timing buffered disk reads: 214 MB in 3.02 seconds = 70.82 MB/sec
You have made such a difference to my quality of life. It's like going from dial-up to adsl! I hope you get to read this or it is passed on by someone who knows you.
Bob, London