On 18/02/2011 8:16 PM, Tejun Heo wrote:
Hello,
On Fri, Feb 18, 2011 at 10:20:43AM +1100, Steven Haigh wrote:
With this patch applied, my rebuilt kernel based on 2.6.32.26 (due
to Xen Dom0 requirements) gives the following:
ata9: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
ata9: SError: { PHYRdyChg CommWake }
ata9: hard resetting link
ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
ata9: hard resetting link
ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
ata9: hard resetting link
ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
ata9: hard resetting link
ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata9: EH complete
So, retrying doesn't help at all.
I would really like to eliminate the possibility of it being my
esata enclosure or the sata -> esata cable by using another cable
and/or array for testing. New cables will be a few days off as I
don't have any of these cables hanging around. My gut feeling says
its the cable - as the enclosure works fine via the USB port -
however that isn't conlusive proof that the esata port is working as
it should!
Yeah, it looks like something is wrong with the setup. Please let us
know how the testing goes with the new cable (hopefully shorter).
Hmmm - the replacement SATA -> eSATA cables arrived today and I still
get the same problem. On a whim, I connected the same cable + adapter +
cradle to my i7 system running Fedora 14. This is not a sata_sil based
adapter, but I believe it may rule out both the cable & the cradle as
faulty.
[ 371.217646] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action
0xe frozen
[ 371.217700] ata6: irq_stat 0x00000040, connection status changed
[ 371.217750] ata6: SError: { RecovComm PHYRdyChg CommWake DevExch }
[ 371.217807] ata6: hard resetting link
[ 376.326257] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 376.347413] ata6.00: ATA-7: HDS728080PLA380, PF2OA60A, max UDMA/133
[ 376.347417] ata6.00: 160836480 sectors, multi 0: LBA48
[ 376.356485] ata6.00: failed to IDENTIFY (I/O error, err_mask=0x100)
[ 376.356490] ata6.00: revalidation failed (errno=-5)
[ 381.324129] ata6: hard resetting link
[ 381.629014] ata6: SATA link down (SStatus 0 SControl 300)
[ 381.629022] ata6: limiting SATA link speed to 1.5 Gbps
[ 386.626909] ata6: hard resetting link
[ 387.494543] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 387.533074] ata6.00: configured for UDMA/133
[ 387.533082] ata6: EH complete
[ 387.533262] scsi 5:0:0:0: Direct-Access ATA HDS728080PLA380
PF2O PQ: 0 ANSI: 5
[ 387.533504] sd 5:0:0:0: Attached scsi generic sg3 type 0
[ 387.533721] sd 5:0:0:0: [sdc] 160836480 512-byte logical blocks:
(82.3 GB/76.6 GiB)
[ 387.533790] sd 5:0:0:0: [sdc] Write Protect is off
[ 387.533794] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[ 387.533823] sd 5:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 387.534037] sdc: sdc1
[ 387.549830] sd 5:0:0:0: [sdc] Attached SCSI disk
I found it interesting that the drive failed to ident multiple times,
however retrying eventually worked.
Could it just be that the cradle is slow to initialise and therefore the
sata_sil adapter gives up before the cradle is actually ready?
Following this logic, I tried powering up the cradle before connecting
the esata cable. I don't see anything in dmesg connecting the esata
cable AFTER the cradle has been powered on. Maybe the cradle disables
the esata connection if theres no cable connected on powerup?
--
Steven Haigh
Email: netwiz@xxxxxxxxx
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
