THANK YOU! :)

it appears this might be related to some of the errors a friend of mine got 
(ref: Re: recovering data on a failed raid-0 installation).

after a bit more research, it does appears that a kernel bug in combination 
with some "fast and loose" protocol usage on a laptop IDE interface may have 
been at fault.

more research on this forthcoming when a drive imager device arrives 
tomorrow....

******* error output
the error reported in his case was:

ata3 status = status 0x51 { DriveReady SeekComplete Error } 
0x40 {Unrecoverable Error } <repeated 5 times>

scsi error 2010 0x8000002 
return code = sdb current sense key medium error 
additional sense unrecovered read error 
auto realocate failed. 
end request i/o error /dev/sdb sector 22629482 
I/O error in filesystem  
md0 metadata device md0 block 0x29a1578 
xfs log mount recovery error failed error 5
xfs log mount failed mount i/o error .... kernel panic! .....

On Thursday 30 March 2006 10:26, you wrote:

Party line: It's a faulty cable (on both drives? triggered by rsync?
Doesn't show up under 'badblocks'? hah!)

Check out the linux-ide archive for my (and others) reports.

I've had lots of issues like this - spurious and IMHO incorrect error
messages. Only certain types of disk access cause them - xfs_repair and
rsync seem to tickle it.

With 2.6.15 I had lots of *very* scary moments with multiple disk
failures on a raid5 during xfs_repair.
I think it's down to the 'basic' error handling in the libata code and
certain disks/controllers being loose with the protocol. They then
identified problems in 'fua' (IIRC) handling which was pulled for 2.6.16.

2.6.16 seems to be much better (fewer 'odd' errors reported and md
doesn't mind)

David
PS Mitchell - you're still using Verizon and I still live off the edge
of their known world (in the UK) so I don't expect you'll get this reply
- hard luck my friend - get a better ISP!)

Mitchell Laks wrote:

quoted

Hi,

I have a production server in place at a remote site.
I have a single system drive that is an ide drive
and two data drives that are on a via SATA controller in a raid1
configuration.

I am monitoring the /var/log/messages and I get messages every few days

Mar 22 23:31:36 A1 kernel: ata6: status=0x51 { DriveReady SeekComplete
Error } Mar 22 23:31:36 A1 kernel: ata6: error=0x84 { DriveStatusError
BadCRC }

Mar 23 23:20:12 A1 kernel: ata5: status=0x51 { DriveReady SeekComplete
Error } Mar 23 23:20:12 A1 kernel: ata5: error=0x84 { DriveStatusError
BadCRC } Mar 23 23:32:03 A1 kernel: ata6: status=0x51 { DriveReady
SeekComplete Error } Mar 23 23:32:04 A1 kernel: ata6: error=0x84 {
DriveStatusError BadCRC }

Mar 24 23:22:45 A1 kernel: ata5: status=0x51 { DriveReady SeekComplete
Error } Mar 24 23:22:45 A1 kernel: ata5: error=0x84 { DriveStatusError
BadCRC }


Mar 27 23:16:57 A1 kernel: ata5: status=0x51 { DriveReady SeekComplete
Error } Mar 27 23:16:57 A1 kernel: ata5: error=0x84 { DriveStatusError
BadCRC }

Mar 28 23:10:16 A1 kernel: ata5: status=0x51 { DriveReady SeekComplete
Error } Mar 28 23:10:17 A1 kernel: ata5: error=0x84 { DriveStatusError
BadCRC } Mar 28 23:23:32 A1 kernel: ata6: status=0x51 { DriveReady
SeekComplete Error } Mar 28 23:23:32 A1 kernel: ata6: error=0x84 {
DriveStatusError BadCRC }


Mar 29 23:33:26 A1 kernel: ata6: status=0x51 { DriveReady SeekComplete
Error } Mar 29 23:33:26 A1 kernel: ata6: error=0x84 { DriveStatusError
BadCRC }

Interestingly by the logs I see that they have occured

March 1,2,3,8,14,17x3,20x4,21,22,23x2,24,27,28x2,29.

(x2 means two errors as in above example).

Also they occur during the activity of the cron job I do at 11pm to rsync
backup the sata drive raid 1 to another server.

here is the output of dmesg:


ata5: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023
88:407f
ata5: dev 0 ATA, max UDMA/133, 781422768 sectors: lba48
ata5: dev 0 configured for UDMA/133
scsi4 : sata_via
ata6: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023
88:407f
ata6: dev 0 ATA, max UDMA/133, 781422768 sectors: lba48
ata6: dev 0 configured for UDMA/133
scsi5 : sata_via
 Vendor: ATA       Model: WDC WD4000YR-01P  Rev: 01.0
 Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 781422768 512-byte hdwr sectors (400088 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 781422768 512-byte hdwr sectors (400088 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host4/bus0/target0/lun0: p1
Attached scsi disk sda at scsi4, channel 0, id 0, lun 0
 Vendor: ATA       Model: WDC WD4000YR-01P  Rev: 01.0
 Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
SCSI device sdb: drive cache: write back
/dev/scsi/host5/bus0/target0/lun0: p1
Attached scsi disk sdb at scsi5, channel 0, id 0, lun 0


Am I correct in assuming that the sata drives are giving me these errors,
and what shall I do? Could it possibly be a problem with the sata
controller rather than the drives?

me@A1:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
     390708736 blocks [2/2] [UU]

unused devices: <none>

I have done some testing with different sata controllers and recently
switched another server from the built in
sata controller on the A8v (via8237 controller) motherboard to  an add in
pci promise sata II150 card.

I think I have seen conflicts between the sata_via and sata_promise and I
already have a sata_promise card in the system for future expandability.

I am running the debian stock 2.6.12-1-386 kernel and debian sarge with
mdadm ii  mdadm          1.9.0-4sarge1  Manage MD devices aka Linux
Software Raid


1:/var/log# lsmod|grep sata
sata_via                8452  2
sata_promise            9988  0
libata                 44164  2 sata_via,sata_promise
scsi_mod              129096  4 sr_mod,sata_promise,libata,sd_mod

Thank you very much.

Mitchell
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html