Libata PATA status

Libata PATA status

[Alan Cox]

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

Re: Libata PATA status

[Kyle Moffett]

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,

Re: Libata PATA status

[Mikael Pettersson]

On Tue, 3 Jul 2007 23:04:26 -0400, Kyle Moffett wrote:
> 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).

And I'd be happy to test a libata pmac driver on Heathrow (Beige G3)
and KeyLargo ATA-3/UniNorth ATA-6 (eMac G4).

Re: Libata PATA status

[Alan Cox]

> 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

Re: Libata PATA status

[Alan Cox]

On 04 Jul 2007 15:00:26 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > 
> > Post SRST 
> What is SRST?
> 
> My personal wish list feature would be a little forwarder driver
> to forward /dev/hd* to /dev/sd* for this; then old IDE could be
> disabled without risking breaking old root file systems.

That would be udevd for new systems or "ln -s" for old ones ? 

I don't see a way to build that "simple" forwarder because the device
allocation is now dynamic rather than tied to specific device on specific
port - a concept with really no meaning any more.

Alan

Re: Libata PATA status

[Alan Cox]

On 04 Jul 2007 15:00:26 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > 
> > Post SRST 
> What is SRST?


Sorry missed the first question.

SRST is the reset signal used when you want to set up (or beat back into
sanity) an IDE bus. It causes a specific set of actions that put the
drives back into a partly known state and hopefully lets you sort
problems out - much like a SCS bus reset.

Re: Libata PATA status

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> Post SRST 
What is SRST?

My personal wish list feature would be a little forwarder driver
to forward /dev/hd* to /dev/sd* for this; then old IDE could be
disabled without risking breaking old root file systems.

-Andi

Re: Libata PATA status

[Andi Kleen]

On Wed, Jul 04, 2007 at 01:17:46PM +0100, Alan Cox wrote:
> On 04 Jul 2007 15:00:26 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
> 
> > Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > > 
> > > Post SRST 
> > What is SRST?
> > 
> > My personal wish list feature would be a little forwarder driver
> > to forward /dev/hd* to /dev/sd* for this; then old IDE could be
> > disabled without risking breaking old root file systems.
> 
> That would be udevd for new systems or "ln -s" for old ones ? 

Then old kernels couldn't be booted anymore.

> 
> I don't see a way to build that "simple" forwarder because the device
> allocation is now dynamic rather than tied to specific device on specific
> port - a concept with really no meaning any more.

Sure for SATA. But surely for PATA it would be possible to fake
the mapping of the old driver? Doing it simple minded (e.g. only
for the builtin devices) would be probably sufficient.

-Andi

Re: Libata PATA status

[Alan Cox]

> > > disabled without risking breaking old root file systems.
> > 
> > That would be udevd for new systems or "ln -s" for old ones ? 
> 
> Then old kernels couldn't be booted anymore.

Why not. I boot back and forth randomly between old and new IDE kernels
without problems. The root fs loaded is set in kernel or grub (or on most
distros nowdays by label scanning from initrd) so just works. Then mount
label or uuid based mounting does the rest.

> Sure for SATA. But surely for PATA it would be possible to fake
> the mapping of the old driver? Doing it simple minded (e.g. only
> for the builtin devices) would be probably sufficient.

You could probably reliably map "hda/b/c/d" initially with some kind of
forwarder providing nobody hot plugged them.  Just not sure I see the
point of doing it kernel side.

Alan

Re: Libata PATA status

[Andi Kleen]

> You could probably reliably map "hda/b/c/d" initially with some kind of
> forwarder providing nobody hot plugged them.  Just not sure I see the

PATA hotplug? 

SATA systems typically already use /dev/sda*, it just applies to PATA.

> point of doing it kernel side.

The point would be that old user land just works without any changes.
I know that is a virtue that has gone out of fashion recently
with udev and sysfs, but older distributions that weren't
that sysfs-layout-of-the-week dependent used to be fairly kernel version
independent.  I always found that very useful.

The hda->sda move would be the only "radical" change that prevents booting for
a long time (the last one before that was the 2.5 modutils transition)

-Andi

Re: Libata PATA status

[Alan Cox]

On Wed, 4 Jul 2007 15:29:30 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> > You could probably reliably map "hda/b/c/d" initially with some kind of
> > forwarder providing nobody hot plugged them.  Just not sure I see the
> 
> PATA hotplug? 
> 
> SATA systems typically already use /dev/sda*, it just applies to PATA.

We support PATA warm plugging sort of already and it'll go further in
time. Mostly this is relevant to laptops

Re: Libata PATA status

[Rod Whitby]

Alan Cox wrote:
> Chipsets
> ========
> ARTOP
> 	No reports, but nobody appears to be using one

The NSLU2-Linux project (http://www.nslu2-linux.org) relies on the
pata-artop driver for the arm/ixp4xx-based Iomega NAS100d and D-Link
DSM-G600 NAS devices (both of which are supported in recent mainline
kernels).

Latest kernels (2.6.22-rc5 is the latest we've tested) have no reported
problems with pata-artop.  We have a handful of people (including
myself) who we know are using 2.6.22-rc5 on those devices and are
booting from the internal drive using the pata-artop driver.

I'm happy for anyone to contact me in the future if new versions of the
pata-artop driver need to be tested.  There are people using it :-)

> 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.

Our project is also working on adding support to the kernel for the
Freecom FSG-3 NAS device.  It uses the sata-via driver for it's VIA_6421
chipset, but the main drive is a PATA drive (the device also has an
eSATA external port).

We're currently stuck at 2.6.18 with vendor patches for scsi/sata-via,
and would love to move to 2.6.22 and libata, but are having problems
with the latest sata-via driver for this chipset booting from an IDE
drive.  I'll contact you separately for this issue (as it's off-topic on
this thread).

Thanks,

-- Rod Whitby
-- NSLU2-Linux Project Lead

Re: Libata PATA status

[Jeff Garzik]

Andi Kleen wrote:
> My personal wish list feature would be a little forwarder driver
> to forward /dev/hd* to /dev/sd* for this; then old IDE could be
> disabled without risking breaking old root file systems.


That's on the long-term TODO list.

libata is moving towards making libata-scsi an optional module (will 
always be around for ATAPI, and for compat with current ATA), and 
driving ATA disks as a native block driver, rather than having SCSI do 
the work for us.

libata's qc_issue/qc_complete high level API and internal modularity 
were designed to make this possible.  It is easy to see in the current 
code how libata-scsi is merely a user of the qc_issue/qc_complete API, 
with all the low-level details isolated away from that module.

Addendum:  Remember too, /dev/hdX is not just a major/minor pair, but a 
userspace interface, complete with expected ioctl support.

	Jeff

Re: Libata PATA status (pata_artop)

[Michael-Luke Jones]

On 5 Jul 2007, at 23:27, Rod Whitby wrote:

> Alan Cox wrote:
>> Chipsets
>> ========
>> ARTOP
>> 	No reports, but nobody appears to be using one
>
> The NSLU2-Linux project (http://www.nslu2-linux.org) relies on the
> pata-artop driver for the arm/ixp4xx-based Iomega NAS100d and D-Link
> DSM-G600 NAS devices (both of which are supported in recent mainline
> kernels).
>
> Latest kernels (2.6.22-rc5 is the latest we've tested) have no  
> reported
> problems with pata-artop.  We have a handful of people (including
> myself) who we know are using 2.6.22-rc5 on those devices and are
> booting from the internal drive using the pata-artop driver.

Though we have no reported problems, we are carrying a local patch to  
the pata_artop driver:

http://trac.nslu2-linux.org/kernel/browser/trunk/patches/2.6.22/15- 
nas100d-pata-artop-single-port.patch

This used to be because of a long delay when probing the non-existent  
second ATA port on these embedded ARM devices, but the comment in the  
patch has since been updated suggesting some negative interaction  
with USB (??).

I don't have this machine so can't comment further on this issue,

M-L

sata-via failure on 2.6.22 for via 6421 chipset (Was: Libata PATA status)

[Rod Whitby]

Rod Whitby wrote:
> Our project is also working on adding support to the kernel for the
> Freecom FSG-3 NAS device.  It uses the sata-via driver for it's VIA_6421
> chipset, but the main drive is a PATA drive (the device also has an
> eSATA external port).
> 
> We're currently stuck at 2.6.18 with vendor patches for scsi/sata-via,
> and would love to move to 2.6.22 and libata, but are having problems
> with the latest sata-via driver for this chipset booting from an IDE
> drive.  I'll contact you separately for this issue (as it's off-topic on
> this thread).

Here is the dmesg output of the sata-via driver failing to access the
internal PATA disk on the Freecom FSG-3 running mainline 2.6.22.  The
other two SATA ports are unused on this device (one is not connected at
all on the PCB, the other is an external eSATA port).

Any advice on how to debug this failure further would be greatly
appreciated.

> PCI: enabling device 0000:00:0c.0 (0000 -> 0001)
> sata_via 0000:00:0c.0: routed to hard irq line 6
> scsi0 : sata_via
> scsi1 : sata_via
> scsi2 : sata_via
> ata1: SATA max UDMA/133 cmd 0x00011420 ctl 0x0001142a bmdma 0x00011400 irq 22
> ata2: SATA max UDMA/133 cmd 0x00011430 ctl 0x0001143a bmdma 0x00011408 irq 22
> ata3: PATA max UDMA/133 cmd 0x00011440 ctl 0x0001144a bmdma 0x00011410 irq 22
> ata1: SATA link down (SStatus 0 SControl 310)
> ata2: SATA link down (SStatus 0 SControl 310)
> ata3.00: ATA-7: HDT722516DLAT80, V43OA96A, max UDMA/133
> ata3.00: 321672960 sectors, multi 0: LBA48
> ata3.00: limited to UDMA/33 due to 40-wire cable
> ata3.00: configured for UDMA/33
> scsi 2:0:0:0: Direct-Access     ATA      HDT722516DLAT80  V43O PQ: 0 ANSI: 5
> sd 2:0:0:0: [sda] 321672960 512-byte hardware sectors (164697 MB)
> sd 2:0:0:0: [sda] Write Protect is off
> sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPA
> sd 2:0:0:0: [sda] 321672960 512-byte hardware sectors (164697 MB)
> sd 2:0:0:0: [sda] Write Protect is off
> sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPA
>  sda: sda1 sda2 sda3 sda4
> sd 2:0:0:0: [sda] Attached SCSI disk
> ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata3.00: cmd c8/00:02:4f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 1024 in
>          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata3: soft resetting port
> ata3.00: qc timeout (cmd 0x27)
> ata3.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (321672960)
> ata3.00: failed to set xfermode (err_mask=0x40)
> ata3: failed to recover some devices, retrying in 5 secs
> ata3: soft resetting port
> ata3.00: qc timeout (cmd 0x27)
> ata3.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (321672960)
> ata3.00: failed to set xfermode (err_mask=0x40)
> ata3.00: limiting speed to UDMA/33:PIO3
> ata3: failed to recover some devices, retrying in 5 secs
> ata3: soft resetting port
> ata3.00: qc timeout (cmd 0x27)
> ata3.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (321672960)
> ata3.00: failed to set xfermode (err_mask=0x40)
> ata3.00: disabled
> ata3: EH complete
> sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> end_request: I/O error, dev sda, sector 79
> ReiserFS: sda1: warning: sh-2006: read_super_block: bread failed (dev sda1, blo)
> sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> end_request: I/O error, dev sda, sector 191
> ReiserFS: sda1: warning: sh-2006: read_super_block: bread failed (dev sda1, blo)
> sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> end_request: I/O error, dev sda, sector 65
> sd 2:0:0:0: [sda] READ CAPACITY failed
> sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> sd 2:0:0:0: [sda] Sense not available.
> EXT3-fs: unable to read superblock
> sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> end_request: I/O error, dev sda, sector 65
> sd 2:0:0:0: [sda] Write Protect is off
> EXT2-fs: unable to read superblock

-- Rod

Re: sata-via failure on 2.6.22 for via 6421 chipset (Was: Libata PATA status)

[Alan Cox]

> Any advice on how to debug this failure further would be greatly
> appreciated.

Still looking at this. For the moment I've merged the 1 port hack but it
would nice to see where the USB goes mad on a trace which also has all
the libata debug enabled.

(Turn on ATA_DEBUG and ATA_VERBOSE_DEBUG in libata.h)

> 
> > PCI: enabling device 0000:00:0c.0 (0000 -> 0001)
> > sata_via 0000:00:0c.0: routed to hard irq line 6
> > scsi0 : sata_via
> > scsi1 : sata_via
> > scsi2 : sata_via
> > ata1: SATA max UDMA/133 cmd 0x00011420 ctl 0x0001142a bmdma 0x00011400 irq 22
> > ata2: SATA max UDMA/133 cmd 0x00011430 ctl 0x0001143a bmdma 0x00011408 irq 22
> > ata3: PATA max UDMA/133 cmd 0x00011440 ctl 0x0001144a bmdma 0x00011410 irq 22
> > ata1: SATA link down (SStatus 0 SControl 310)
> > ata2: SATA link down (SStatus 0 SControl 310)
> > ata3.00: ATA-7: HDT722516DLAT80, V43OA96A, max UDMA/133
> > ata3.00: 321672960 sectors, multi 0: LBA48
> > ata3.00: limited to UDMA/33 due to 40-wire cable
> > ata3.00: configured for UDMA/33
> > scsi 2:0:0:0: Direct-Access     ATA      HDT722516DLAT80  V43O PQ: 0 ANSI: 5
> > sd 2:0:0:0: [sda] 321672960 512-byte hardware sectors (164697 MB)
> > sd 2:0:0:0: [sda] Write Protect is off
> > sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPA
> > sd 2:0:0:0: [sda] 321672960 512-byte hardware sectors (164697 MB)
> > sd 2:0:0:0: [sda] Write Protect is off
> > sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPA
> >  sda: sda1 sda2 sda3 sda4
> > sd 2:0:0:0: [sda] Attached SCSI disk
> > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > ata3.00: cmd c8/00:02:4f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 1024 in
> >          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> > ata3: soft resetting port
> > ata3.00: qc timeout (cmd 0x27)
> > ata3.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (321672960)
> > ata3.00: failed to set xfermode (err_mask=0x40)
> > ata3: failed to recover some devices, retrying in 5 secs
> > ata3: soft resetting port
> > ata3.00: qc timeout (cmd 0x27)
> > ata3.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (321672960)
> > ata3.00: failed to set xfermode (err_mask=0x40)
> > ata3.00: limiting speed to UDMA/33:PIO3
> > ata3: failed to recover some devices, retrying in 5 secs
> > ata3: soft resetting port
> > ata3.00: qc timeout (cmd 0x27)
> > ata3.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (321672960)
> > ata3.00: failed to set xfermode (err_mask=0x40)
> > ata3.00: disabled
> > ata3: EH complete
> > sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> > end_request: I/O error, dev sda, sector 79
> > ReiserFS: sda1: warning: sh-2006: read_super_block: bread failed (dev sda1, blo)
> > sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> > end_request: I/O error, dev sda, sector 191
> > ReiserFS: sda1: warning: sh-2006: read_super_block: bread failed (dev sda1, blo)
> > sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> > end_request: I/O error, dev sda, sector 65
> > sd 2:0:0:0: [sda] READ CAPACITY failed
> > sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> > sd 2:0:0:0: [sda] Sense not available.
> > EXT3-fs: unable to read superblock
> > sd 2:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> > end_request: I/O error, dev sda, sector 65
> > sd 2:0:0:0: [sda] Write Protect is off
> > EXT2-fs: unable to read superblock
> 
> -- Rod


-- 
--
	"Alan, I'm getting a bit worried about you."
				-- Linus Torvalds