[PATCH-RFC] (was: Re: Sata Sil3512 bug?; Promise SATA300 TX4)
Hello.
There appears to be a hardware bug in that it chokes on scatterlist
if the last item is larger than 164 bytes.
The patch that follows fixes my problem on 2.6.22.
I can't think of a way to avoid second pass over scatterlist without
duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
--- a/drivers/ata/sata_promise.c2007-07-09 03:32:17.0 +0400
+++ b/drivers/ata/sata_promise.c2007-10-27 17:20:03.0 +0400
@@ -531,6 +531,80 @@
memcpy(buf+31, cdb, cdb_len);
}
+/**
+ * pdc_qc_prep - Fill PCI IDE PRD table
+ * @qc: Metadata associated with taskfile to be transferred
+ *
+ * Fill PCI IDE PRD (scatter-gather) table with segments
+ * associated with the current disk command.
+ * Make sure hardware does not choke on it.
+ *
+ * LOCKING:
+ * spin_lock_irqsave(host lock)
+ *
+ */
+static void pdc_qc_prep(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc-ap;
+ struct scatterlist *sg;
+ unsigned int idx;
+ const u32 SG_COUNT_ASIC_BUG = 41*4;
+
+ if (!(qc-flags ATA_QCFLAG_DMAMAP))
+ return;
+
+ WARN_ON(qc-__sg == NULL);
+ WARN_ON(qc-n_elem == 0 qc-pad_len == 0);
+
+ idx = 0;
+ ata_for_each_sg(sg, qc) {
+ u32 addr, offset;
+ u32 sg_len, len;
+
+ /* determine if physical DMA addr spans 64K boundary.
+* Note h/w doesn't support 64-bit, so we unconditionally
+* truncate dma_addr_t to u32.
+*/
+ addr = (u32) sg_dma_address(sg);
+ sg_len = sg_dma_len(sg);
+
+ while (sg_len) {
+ offset = addr 0x;
+ len = sg_len;
+ if ((offset + sg_len) 0x1)
+ len = 0x1 - offset;
+
+ ap-prd[idx].addr = cpu_to_le32(addr);
+ ap-prd[idx].flags_len = cpu_to_le32(len 0x);
+ VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx, addr, len);
+
+ idx++;
+ sg_len -= len;
+ addr += len;
+ }
+ }
+
+ if (idx) {
+ u32 len = ap-prd[idx - 1].flags_len;
+ if (len SG_COUNT_ASIC_BUG) {
+ u32 addr, len;
+
+ VPRINTK(Last PRD split\n);
+
+ len = le32_to_cpu(ap-prd[idx - 1].flags_len) -
SG_COUNT_ASIC_BUG;
+ addr = le32_to_cpu(ap-prd[idx - 1].addr);
+ ap-prd[idx - 1].flags_len = cpu_to_le32(len);
+ VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx, addr, len);
+
+ ap-prd[idx].flags_len = cpu_to_le32(SG_COUNT_ASIC_BUG);
+ ap-prd[idx].addr = cpu_to_le32(addr + len);
+ idx++;
+ VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx, addr + len,
SG_COUNT_ASIC_BUG);
+ }
+ ap-prd[idx - 1].flags_len |= cpu_to_le32(ATA_PRD_EOT);
+ }
+}
+
static void pdc_qc_prep(struct ata_queued_cmd *qc)
{
struct pdc_port_priv *pp = qc-ap-private_data;
@@ -540,7 +614,7 @@
switch (qc-tf.protocol) {
case ATA_PROT_DMA:
- ata_qc_prep(qc);
+ pdc_qc_prep(qc);
/* fall through */
case ATA_PROT_NODATA:
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RFC] (was: Re: Sata Sil3512 bug?; Promise SATA300 TX4)
On Sat, 27 Oct 2007 17:24:32 +0400, Alexander Sabourenkov wrote: There appears to be a hardware bug in that it chokes on scatterlist if the last item is larger than 164 bytes. The patch that follows fixes my problem on 2.6.22. I can't think of a way to avoid second pass over scatterlist without duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c). --- a/drivers/ata/sata_promise.c 2007-07-09 03:32:17.0 +0400 +++ b/drivers/ata/sata_promise.c 2007-10-27 17:20:03.0 +0400 Interesting, but can you please give more background information? I.e., how did you determine the existence of this bug? And please cc: the sata_promise maintainer on sata_promise patches. (Hint: that's me) And please choose a Subject: that makes it absolutely clear what the post is about. Sata Sil3512 bug doesn't exactly sound like something the sata_promise maintainer needs to look at. Meanwhile I'll check the Promise driver(s) to see if there's something about SG table formatting restrictions there. /Mikael - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?; Promise SATA300 TX4
Hello. Tejun Heo wrote: Does the attached patch help? It does somehow force 1.5GB/s mode, and it does change the pattern of 'configured for UDMAxxx' messages that come along with errors, and it causes the following error: ata3: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t4 ata3: hotplug_status 0x10 ata3: soft resetting link ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata3.00: configured for UDMA/133 ata3: EH complete for both drives on TX4 on startup, but read errors are still there. dmesgs at http://lxnt.info/linux/libata-dev/patch0/ READY [] -- ./lxnt - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?; Promise SATA300 TX4
Alexander Sabourenkov wrote: Hello. So, my bet for your second report is your hardware went through something similar as above. Thanks for the insight. Let's dismiss it then. Back to the TX4, I tried libata-dev.git cloned at about 20:00 UTC 19.10, no perceived difference - parallel read from two drives causes a lot of errors. dmesgs with boot and errors are at http://lxnt.info/linux/libata-dev/ I don't know what to try next. Any ideas? Does the attached patch help? -- tejun diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 68699b3..4c93fee 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -6435,6 +6435,7 @@ int sata_link_init_spd(struct ata_link *link) spd = (scontrol 4) 0xf; if (spd) link-hw_sata_spd_limit = (1 spd) - 1; + link-hw_sata_spd_limit = 1; link-sata_spd_limit = link-hw_sata_spd_limit;
Re[2]: Sata Sil3512 bug?; Promise SATA300 TX4
Hello Alexander, Friday, October 19, 2007, 11:06:02 PM, you wrote: I don't know what to try next. Any ideas? I'm no kernel hacker, so i'll take a shot. I assume you have done most already... * hardware (Tested/without/or used another: motherboard, videocard, memory, hard drives, power supply, all other hardware) * tried a more n00b-proof distribution. As far as i know you have all those flags with gentoo. A mistake is easily made. * Tested with the latest official drivers (redhat) from the Promise site. And installing that OS on a disk. I assume they made working drivers, so it should work with it... * Does it work correctly with Windows? This would be the steps i would take to determine the cause of the problem. Finally, my 2.6.23 kernel is done. I'm going try to install it now. Tomorrow the results :) -- Best regards, MisterEmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?; Promise SATA300 TX4
Hello. So, my bet for your second report is your hardware went through something similar as above. Thanks for the insight. Let's dismiss it then. Back to the TX4, I tried libata-dev.git cloned at about 20:00 UTC 19.10, no perceived difference - parallel read from two drives causes a lot of errors. dmesgs with boot and errors are at http://lxnt.info/linux/libata-dev/ I don't know what to try next. Any ideas? -- ./lxnt - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?; Promise SATA300 TX4
Hello. I have done some quick tests with 2.6.23/amd64 and unfortunately, the very same problem persists. By the way, 8 in (port_status 0x2008) stands for PDC_OVERRUN_ERR = (1 19), /* S/G byte count larger than HD requires */ Does by any chance 'S/G' here somehow relate to 'sg in the 'sg-chaining work' there is so much talk about on the -kernel mailing list? In a somewhat parallel development, write errors caused my (other) md RAID-1 to lose one drive while copying data under 2.6.22 from TX4-attached drives to onboard-VIA-attached ones. Device: VIA VT6420 00:0f.0 0104: 1106:3149 (rev 80) Boot: Oct 17 21:28:25 host sata_via :00:0f.0: version 2.2 Oct 17 21:28:25 host ACPI: PCI Interrupt :00:0f.0[B] - GSI 20 (level, low) - IRQ 17 Oct 17 21:28:25 host sata_via :00:0f.0: routed to hard irq line 10 Oct 17 21:28:25 host scsi4 : sata_via Oct 17 21:28:25 host scsi5 : sata_via Oct 17 21:28:25 host ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Oct 17 21:28:25 host ata6.00: ATA-7: ST3200827AS, 3.AAH, max UDMA/133 Oct 17 21:28:25 host ata6.00: 390721968 sectors, multi 0: LBA48 NCQ (depth 0/32) Oct 17 21:28:25 host ata6.00: configured for UDMA/133 ... the first two port resets: Oct 17 23:10:50 host ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Oct 17 23:10:50 host ata6.00: (BMDMA stat 0x4) Oct 17 23:10:50 host ata6.00: cmd ca/00:08:e7:30:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 out Oct 17 23:10:50 host res 51/84:08:e7:30:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) Oct 17 23:10:50 host ata6: soft resetting port Oct 17 23:10:50 host ata6.00: configured for UDMA/133 Oct 17 23:10:50 host ata6: EH complete Oct 17 23:10:50 host sd 5:0:0:0: [sdd] 390721968 512-byte hardware sectors (200050 MB) Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Write Protect is off Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Oct 17 23:10:50 host ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Oct 17 23:10:50 host ata6.00: (BMDMA stat 0x5) Oct 17 23:10:50 host ata6.00: cmd ca/00:f8:4f:31:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 126976 out Oct 17 23:10:50 host res 51/84:f8:4f:31:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) Oct 17 23:10:50 host ata6: soft resetting port Oct 17 23:10:50 host ata6.00: configured for UDMA/133 Oct 17 23:10:50 host ata6: EH complete Oct 17 23:10:50 host sd 5:0:0:0: [sdd] 390721968 512-byte hardware sectors (200050 MB) Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Write Protect is off Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ... and multiple unsuccessful port resets follow: Oct 17 23:11:57 host ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Oct 17 23:11:57 host ata6.00: cmd 25/00:08:7f:bf:28/00:00:16:00:00/e0 tag 0 cdb 0x0 data 4096 in Oct 17 23:11:57 host res 40/00:f8:4f:31:00/00:00:00:00:00/e0 Emask 0x4 (timeout) Oct 17 23:12:02 host ata6: port is slow to respond, please be patient (Status 0xd0) Oct 17 23:12:07 host ata6: soft resetting port Oct 17 23:12:37 host ata6.00: qc timeout (cmd 0xec) Oct 17 23:12:37 host ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4) Oct 17 23:12:37 host ata6.00: revalidation failed (errno=-5) Oct 17 23:12:37 host ata6: failed to recover some devices, retrying in 5 secs Oct 17 23:12:47 host ata6: port is slow to respond, please be patient (Status 0xd0) Oct 17 23:12:52 host ata6: soft resetting port Oct 17 23:13:22 host ata6.00: qc timeout (cmd 0xec) Oct 17 23:13:22 host ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4) Oct 17 23:13:22 host ata6.00: revalidation failed (errno=-5) Oct 17 23:13:22 host ata6.00: limiting speed to UDMA/133:PIO3 Oct 17 23:13:22 host ata6: failed to recover some devices, retrying in 5 secs Oct 17 23:13:32 host ata6: port is slow to respond, please be patient (Status 0xd0) Oct 17 23:13:37 host ata6: soft resetting port Oct 17 23:14:08 host ata6.00: qc timeout (cmd 0xec) Oct 17 23:14:08 host ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4) Oct 17 23:14:08 host ata6.00: revalidation failed (errno=-5) Oct 17 23:14:08 host ata6.00: disabled Oct 17 23:14:08 host ata6: EH complete Oct 17 23:14:08 host sd 5:0:0:0: [sdd] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK Oct 17 23:14:08 host end_request: I/O error, dev sdd, sector 371769215 Oct 17 23:14:08 host raid1: sdd1: rescheduling sector 371769152 Oct 17 23:14:08 host sd 5:0:0:0: [sdd] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK Oct 17 23:14:08 host end_request: I/O error, dev sdd, sector 390379327 Oct 17 23:14:08 host md: super_written gets error=-5, uptodate=0 Oct 17 23:14:08 host raid1: Disk failure on sdd1, disabling device. I'm unable to reproduce this on 2.6.23, so this is of historic interest only. -- ./lxnt - To
Re[2]: Sata Sil3512 bug?; Promise SATA300 TX4
Hello, Wednesday, October 3, 2007, 10:31:17 AM, you wrote: Mikael Pettersson wrote: I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? (please don't top-post) There are no known data-corruption issues with Promise SATA cards. However, some of them, especially the 2nd generation SATA300 TX4, are known to trigger intermittent error interrupts (that are dealt with but may cause a speed reduction) in some systems. We're still scratching our heads on that issue. But see this thread: http://marc.info/?l=linux-idem=119122463403033w=2 http://www.spinics.net/lists/linux-ide/msg14868.html Personally I would not recommend Promise SATA300 TX4 at the moment. After all the problems i had with the sweex 3512 cards i returned them to the shop and decided to buy a Sata300 TX4 (because the shop nearby had one. Unfortunately the shops in the region don't have Highpoints) Things looked promising when i inserted the card in both Intel D815EEA motherboards. No problems detecting the hard drives (unlike with the 3512 cards). With the 3512 i had LOTS of error messages and corrupt data when writing to it. Using a separate videocard, instead of the onboard one, seemed to reduce the amount of errors. But after some heavy reading/writing with the promise i got 2 errors. (see log file). But i did'nt find any corrupt files. I can not reproduce the error. I'm not sure if these are the intermittent error interrupts Mikael Pettersson mentioned? ps: as you can i see i got at the boot some errors from the boot disk (hda). I not sure what is wrong with it. Sometimes it produce these errors. Used a non-destructive read-write test with badblocks but no bad sectors found. I don't know if this could influence the sata controller. Alexander Sabourenkov can you please tell me where i can find the Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond, reset failed thread you mentioned? I also see that the driver is now at version 2.10. Is there something really critical changed? I've tried testing with Debian stable (2.6.18-4-686; sata_promise: 1.04) and with Debian Unstable (2.6.22-2-686; sata_promise: 2.07). 2.6.23 is not in the repositories yet. So basically the question is this. Can i trust the SATA300 TX4 or should i buy a Highpoint RocketRAID 1640/1740?. I can order such device online but i need to be sure that it works correctly :( -- Best regards, MisterEmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re[2]: Sata Sil3512 bug?; Promise SATA300 TX4
Hello Alexander,
Wednesday, October 17, 2007, 2:54:25 PM, you wrote:
Log file got lost. Please post relevant parts inline.
Sorry, i totally forgot to include them.
I can not reproduce the errors. Last times hda did not give errors. So i'm
not sure if it is related to each other. (in the thread you mentioned
that you can't explain the fixing of problem from Peter Favrholdt, so
maybe it has indeed something to do with the libata)
ct 16 14:10:59 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:10:59 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:10:59 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:12:49 fileserver kernel: kjournald starting. Commit interval 5
seconds
Oct 16 14:12:49 fileserver kernel: EXT3 FS on sda1, internal journal
Oct 16 14:12:49 fileserver kernel: EXT3-fs: mounted filesystem with ordered
data mode.
Oct 16 14:13:34 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:13:34 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:13:34 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hdb: DMA disabled
Oct 16 14:17:21 fileserver kernel: ide0: reset: success
Oct 16 14:32:51 fileserver kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr
0x0 action 0x2
Oct 16 14:32:51 fileserver kernel: ata1.00: (port_status 0x2008)
Oct 16 14:32:51 fileserver kernel: ata1.00: cmd
c8/00:00:77:f6:6c/00:00:00:00:00/e4 tag 0 cdb 0x0 data 131072 in
Oct 16 14:32:51 fileserver kernel: res
50/00:00:76:f7:6c/00:00:00:00:00/e4 Emask 0x2 (HSM violation)
Oct 16 14:32:51 fileserver kernel: ata1: soft resetting port
Oct 16 14:32:51 fileserver kernel: ata1: SATA link up 3.0 Gbps (SStatus 123
SControl 300)
Oct 16 14:32:51 fileserver kernel: ata1.00: configured for UDMA/133
Oct 16 14:32:51 fileserver kernel: ata1: EH complete
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte
hardware sectors (500108 MB)
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
Oct 16 14:44:09 fileserver kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 16 14:48:48 fileserver kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr
0x0 action 0x2
Oct 16 14:48:48 fileserver kernel: ata1.00: (port_status 0x2008)
Oct 16 14:48:48 fileserver kernel: ata1.00: cmd
25/00:00:3f:d0:26/00:01:23:00:00/e0 tag 0 cdb 0x0 data 131072 in
Oct 16 14:48:48 fileserver kernel: res
50/00:00:3e:d1:26/00:00:23:00:00/e0 Emask 0x2 (HSM violation)
Oct 16 14:48:48 fileserver kernel: ata1: soft resetting port
Oct 16 14:48:49 fileserver kernel: ata1: SATA link up 3.0 Gbps (SStatus 123
SControl 300)
Oct 16 14:48:49 fileserver kernel: ata1.00: configured for UDMA/133
Oct 16 14:48:49 fileserver kernel: ata1: EH complete
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte
hardware sectors (500108 MB)
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
Since you have the hardware, do the tests and decide for yourself.
I'd try copying one (big, preferably over 160G ) disk onto another (with
dd) for a start,
while waiting for answers on mailing lists.
I can order that 1740 online, but returning something is always more
Re: Sata Sil3512 bug?; Promise SATA300 TX4
Hi, MisterE wrote: Tonight i will try the Asus motherboard with 1 drive and much I/O. And i will create a new array which takes 7 hours. But how often/hours do you need to try something to prove it does not fail :P On one box I had problems with the SATA300 TX4 using 2.6.21 through 2.6.22 (different versions). I have 4x500GB Seagate ES SATA drives connected. The system would run fine, but when put to a stress - i.e. loaded on all sata ports one or two ports would fail - one after the other. I have _always_ been able to make it fail doing: dd if=/dev/sda of=/dev/null bs=1M dd if=/dev/sdb of=/dev/null bs=1M dd if=/dev/sdc of=/dev/null bs=1M dd if=/dev/sdd of=/dev/null bs=1M The ports would freeze before running long - e.g. in less than an hour. This can be done without even starting the array (mdadm). Therefore no data corruption will happen. The above issue was fixed by updating to vanilla 2.6.23.1. Until then I have been running with 2.6.21-rc2 with a Mikael Petterson patch to force the SATA to 1.5Gbps (this could possibly be accomplished by jumpers on the drives as well - but I didn't try that). I have another system (Dell PE1800 = different from the above) running 24x7 using vanilla linux 2.6.19.5. This system has been running without hickups for more than a year (current uptime 135 days). Hope this helps, Best regards, Peter - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?
MisterE wrote: Oct 13 13:01:26 fileserver kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x240 action 0x0 Oct 13 13:01:26 fileserver kernel: ata4.00: (BMDMA2 stat 0x650001) Oct 13 13:01:26 fileserver kernel: ata4.00: cmd ca/00:f8:47:e1:5e/00:00:00:00:00/e4 tag 0 cdb 0x0 data 126976 out Oct 13 13:01:26 fileserver kernel: res 51/04:98:a7:e1:5e/00:00:00:00:00/e4 Emask 0x1 (device error) Oct 13 13:01:26 fileserver kernel: ata4.00: configured for UDMA/100 Oct 13 13:01:26 fileserver kernel: ata4: EH complete Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA I'm not sure if it will result in corrupt data? But i don't trust it anymore. That looks like a data transmission error. When you're transferring massive amount of data, things like that can happen and it won't cause data corruption. You people advise me to not buy the Promise SATA300 TX4 controller and this Sweex PU102 (3512) seems to have problems. Not much choices left except the really expensive solutions. Is it really so hard to build a controller without problems?!? :( It seems so. :-( -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?
MisterE wrote: Hello, Alexander, does these problems with the Promise SATA300 TX4 happen to everyone? Most probably not, as I think it would have been fixed much faster then. I was waiting for a) release of 2.6.23, and b) me completing the move to another flat to retest all the latest developments in mainline and libata-dev. With a) done and b) almost done, I'll retest and report any issues quite soon. Besides, there is a report of TX4 and 2.6.23 not showing problems that were there with 2.6.22, ( see Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond, reset failed thread). The only alternatives are using soft-raid products as normal controllers. Does anyone have experiences with the following products? * Highpoint RocketRAID 1640 (150 MB/s) * Highpoint RocketRAID 1740 (300 MB/s) * Adaptec 1210SA For any kind of non-hobby task I'd skip trying to build a disk array to buying a SATA-SCSI/SATA-iSCSI box. While I had many mind-boggling issues with various combinations of SATA HDDs, onboard and standalone controllers, Promise and Infortrend disk arrays worked quite reliably. -- ./lxnt - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re[2]: Sata Sil3512 bug?
Hello, Alexander, does these problems with the Promise SATA300 TX4 happen to everyone? The only alternatives are using soft-raid products as normal controllers. Does anyone have experiences with the following products? * Highpoint RocketRAID 1640 (150 MB/s) * Highpoint RocketRAID 1740 (300 MB/s) * Adaptec 1210SA Wednesday, October 3, 2007, 10:31:17 AM, you wrote: Mikael Pettersson wrote: I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? (please don't top-post) There are no known data-corruption issues with Promise SATA cards. However, some of them, especially the 2nd generation SATA300 TX4, are known to trigger intermittent error interrupts (that are dealt with but may cause a speed reduction) in some systems. We're still scratching our heads on that issue. But see this thread: http://marc.info/?l=linux-idem=119122463403033w=2 http://www.spinics.net/lists/linux-ide/msg14868.html Personally I would not recommend Promise SATA300 TX4 at the moment. -- Best regards, MisterEmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re[2]: Sata Sil3512 bug?
Hello Tejun, unfortunately. I today tried to build the array (4x500GB, so it is still building) and i got again a error: Oct 13 12:17:56 fileserver kernel: raid5: device sdc1 operational as raid disk 2 Oct 13 12:17:56 fileserver kernel: raid5: device sdb1 operational as raid disk 1 Oct 13 12:17:56 fileserver kernel: raid5: device sda1 operational as raid disk 0 Oct 13 12:17:56 fileserver kernel: raid5: allocated 4204kB for md0 Oct 13 12:17:56 fileserver kernel: raid5: raid level 5 set md0 active with 3 out of 4 devices, algorithm 2 Oct 13 12:17:56 fileserver kernel: RAID5 conf printout: Oct 13 12:17:56 fileserver kernel: --- rd:4 wd:3 Oct 13 12:17:56 fileserver kernel: disk 0, o:1, dev:sda1 Oct 13 12:17:56 fileserver kernel: disk 1, o:1, dev:sdb1 Oct 13 12:17:56 fileserver kernel: disk 2, o:1, dev:sdc1 Oct 13 12:18:24 fileserver kernel: RAID5 conf printout: Oct 13 12:18:24 fileserver kernel: --- rd:4 wd:3 Oct 13 12:18:24 fileserver kernel: disk 0, o:1, dev:sda1 Oct 13 12:18:24 fileserver kernel: disk 1, o:1, dev:sdb1 Oct 13 12:18:24 fileserver kernel: disk 2, o:1, dev:sdc1 Oct 13 12:18:24 fileserver kernel: disk 3, o:1, dev:sdd1 Oct 13 12:18:24 fileserver kernel: md: recovery of RAID array md0 Oct 13 12:18:24 fileserver kernel: md: minimum _guaranteed_ speed: 1000 KB/sec/disk. Oct 13 12:18:24 fileserver kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for recovery. Oct 13 12:18:24 fileserver kernel: md: using 128k window, over a total of 488383936 blocks. Oct 13 13:01:26 fileserver kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x240 action 0x0 Oct 13 13:01:26 fileserver kernel: ata4.00: (BMDMA2 stat 0x650001) Oct 13 13:01:26 fileserver kernel: ata4.00: cmd ca/00:f8:47:e1:5e/00:00:00:00:00/e4 tag 0 cdb 0x0 data 126976 out Oct 13 13:01:26 fileserver kernel: res 51/04:98:a7:e1:5e/00:00:00:00:00/e4 Emask 0x1 (device error) Oct 13 13:01:26 fileserver kernel: ata4.00: configured for UDMA/100 Oct 13 13:01:26 fileserver kernel: ata4: EH complete Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA I'm not sure if it will result in corrupt data? But i don't trust it anymore. You people advise me to not buy the Promise SATA300 TX4 controller and this Sweex PU102 (3512) seems to have problems. Not much choices left except the really expensive solutions. Is it really so hard to build a controller without problems?!? :( Thursday, October 4, 2007, 3:27:18 AM, you wrote: Hello, MisterE wrote: I build another setup with almost the same hardware. This motherboard had already the latest bios. I notice that the computer does almost never find the hard drive although the controller is found every time (with lspci). What do you mean by almost never? Does it find the harddisk sometimes? Also, please post kernel boot log after disk detection failure. lspci result just indicates only that the PCI device is present. So i get no drive (sda) assigned. I don't always see the bios screen from the controller at startup. And in the past it showed the hard drive. So i could not experiment with this motherboard. Can you re-seat the controller or move it to another slot and see whether things change? After that i installed Windows XP and used the orginal (sweex) drivers with the first motherboard. This also makes the data corrupt. So it seems not to be an linux problem. So there is something wrong with the motherboard or the 3512 controller. After that i plugged both hard drives (ide with windows and sata disk) to the Asus board. No data corruption. So the hard disks are'nt the problem either. Hmmm... It's relieving to know that the problem isn't caused by sata_sil but I don't have much idea than it seems like something goes wrong on the PCI bus. :-( I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? I see occasional bug reports on sata_promise but AFAIK there haven't been any data corruption report. Mikael knows much better about promise controllers. Thanks. -- Best regards, MisterEmailto:[EMAIL PROTECTED] kern.log Description: Binary data
Re: Re[2]: Sata Sil3512 bug?
On Tue, 2 Oct 2007 21:20:23 +0200, MisterE wrote: I build another setup with almost the same hardware. This motherboard had already the latest bios. I notice that the computer does almost never find the hard drive although the controller is found every time (with lspci). So i get no drive (sda) assigned. I don't always see the bios screen from the controller at startup. And in the past it showed the hard drive. So i could not experiment with this motherboard. After that i installed Windows XP and used the orginal (sweex) drivers with the first motherboard. This also makes the data corrupt. So it seems not to be an linux problem. So there is something wrong with the motherboard or the 3512 controller. After that i plugged both hard drives (ide with windows and sata disk) to the Asus board. No data corruption. So the hard disks are'nt the problem either. I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? (please don't top-post) There are no known data-corruption issues with Promise SATA cards. However, some of them, especially the 2nd generation SATA300 TX4, are known to trigger intermittent error interrupts (that are dealt with but may cause a speed reduction) in some systems. We're still scratching our heads on that issue. /Mikael Friday, September 28, 2007, 6:55:47 PM, you wrote: Alan Cox wrote: sda1 are corrupted (2 to 4 blocks missing). Copying that data back to Windows and it give the same results in Quickpar. So reading does not have problems. The data written to hda1 is correct. We've got a whole pile of reports like this with the 3512 and almost always Nvidia chipset, plus reports of BIOS updates fixing it. That you see something similar on intel boards is a bit worrying. Multiple sil3112/3512 + nvidia chipset problem doesn't usually involve device errors or timeouts. It usually corrupts data silently. And, yeah, data corruption on intel board is really disturbing. MisterE, do you have any processor powersaving mechanism enabled? If so, can you disable all and see whether that changes anything? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?
Mikael Pettersson wrote: I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? (please don't top-post) There are no known data-corruption issues with Promise SATA cards. However, some of them, especially the 2nd generation SATA300 TX4, are known to trigger intermittent error interrupts (that are dealt with but may cause a speed reduction) in some systems. We're still scratching our heads on that issue. But see this thread: http://marc.info/?l=linux-idem=119122463403033w=2 http://www.spinics.net/lists/linux-ide/msg14868.html Personally I would not recommend Promise SATA300 TX4 at the moment. -- ./lxnt - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re[2]: Sata Sil3512 bug?
Hello Alexander, Wednesday, October 3, 2007, 10:31:17 AM, you wrote: Mikael Pettersson wrote: I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? (please don't top-post) There are no known data-corruption issues with Promise SATA cards. However, some of them, especially the 2nd generation SATA300 TX4, are known to trigger intermittent error interrupts (that are dealt with but may cause a speed reduction) in some systems. We're still scratching our heads on that issue. But see this thread: http://marc.info/?l=linux-idem=119122463403033w=2 http://www.spinics.net/lists/linux-ide/msg14868.html Personally I would not recommend Promise SATA300 TX4 at the moment. That is not hopefull. Highpoint does not have sata controllers (Except softraid controllers). Other (real raid controllers) brands are too expensive or/and does not have a PCI interface. Maybe i should keep those 3512 cards? How are the user experiences with these controllers (except nvidia boards)? Because i don't really trust the intel boards so using the Asus would be an option. -- Best regards, MisterEmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?
That is not hopefull. Highpoint does not have sata controllers (Except softraid controllers). Other (real raid controllers) brands are too There are pretty much no real RAID controllers in the ATA world except the very high end pricy ones. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?
There are pretty much no real RAID controllers in the ATA world except the very high end pricy ones. Can anyone comment on the reliability or otherwise of Marvell 885X6081 controllers? Supermicro do a reasonably priced non-RAID 8 drive SATA card using it: http://www.supermicro.com/products/accessories/addon/AoC-SAT2-MV8.cfm Regards, Richard - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?
Hello, MisterE wrote: I build another setup with almost the same hardware. This motherboard had already the latest bios. I notice that the computer does almost never find the hard drive although the controller is found every time (with lspci). What do you mean by almost never? Does it find the harddisk sometimes? Also, please post kernel boot log after disk detection failure. lspci result just indicates only that the PCI device is present. So i get no drive (sda) assigned. I don't always see the bios screen from the controller at startup. And in the past it showed the hard drive. So i could not experiment with this motherboard. Can you re-seat the controller or move it to another slot and see whether things change? After that i installed Windows XP and used the orginal (sweex) drivers with the first motherboard. This also makes the data corrupt. So it seems not to be an linux problem. So there is something wrong with the motherboard or the 3512 controller. After that i plugged both hard drives (ide with windows and sata disk) to the Asus board. No data corruption. So the hard disks are'nt the problem either. Hmmm... It's relieving to know that the problem isn't caused by sata_sil but I don't have much idea than it seems like something goes wrong on the PCI bus. :-( I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? I see occasional bug reports on sata_promise but AFAIK there haven't been any data corruption report. Mikael knows much better about promise controllers. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re[2]: Sata Sil3512 bug?
Hello Tejun, I build another setup with almost the same hardware. This motherboard had already the latest bios. I notice that the computer does almost never find the hard drive although the controller is found every time (with lspci). So i get no drive (sda) assigned. I don't always see the bios screen from the controller at startup. And in the past it showed the hard drive. So i could not experiment with this motherboard. After that i installed Windows XP and used the orginal (sweex) drivers with the first motherboard. This also makes the data corrupt. So it seems not to be an linux problem. So there is something wrong with the motherboard or the 3512 controller. After that i plugged both hard drives (ide with windows and sata disk) to the Asus board. No data corruption. So the hard disks are'nt the problem either. I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? Friday, September 28, 2007, 6:55:47 PM, you wrote: Alan Cox wrote: sda1 are corrupted (2 to 4 blocks missing). Copying that data back to Windows and it give the same results in Quickpar. So reading does not have problems. The data written to hda1 is correct. We've got a whole pile of reports like this with the 3512 and almost always Nvidia chipset, plus reports of BIOS updates fixing it. That you see something similar on intel boards is a bit worrying. Multiple sil3112/3512 + nvidia chipset problem doesn't usually involve device errors or timeouts. It usually corrupts data silently. And, yeah, data corruption on intel board is really disturbing. MisterE, do you have any processor powersaving mechanism enabled? If so, can you disable all and see whether that changes anything? -- Best regards, MisterEmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re[2]: Sata Sil3512 bug?
Hello Tejun, I've tried with 2 sata cables. Cables which don't give problems with the Asus motherboard. I also now use a new decent power supply (corsair vx450) for the intel. Before it, i used an Fortron supply. But it had no sata connectors so i used converter adapters. But replacing the supply did'nt solve it. btw. If i copy/delete from the Western Digital to my Windows pc (via winscp or samba) i don't get error messages. Only when i write to it. The data itself seems to get corrupted; tested with par2. uploaded with winscp (windows) to the western digital (sda1). Uploaded the same data to hda1. Tested the data on both drives with par2verify. Most files on sda1 are corrupted (2 to 4 blocks missing). Copying that data back to Windows and it give the same results in Quickpar. So reading does not have problems. The data written to hda1 is correct. I now inserted a videocard, instead of using the onboard card. And at first hand it looked solved, but some (much less) errors still happens. I did not change anything in the bios. The card: 02:00.0 VGA compatible controller: nVidia Corporation NV10 [GeForce 256 SDR] (rev 10) How can a videocard influence this? I wanted to build a fileserver, using the intel motherboard. Bacause of the fact that it has a onboard videocard. I can use the asus if i have to. But if it is a bug it can better be solved :) I have some other similar motherboards like the intel laying around. With and without onboard videocard. I also have a second D815EEA (probably still has an older BIOS, i have updated the current one because when i inserted my second 128MB memory it did not gave any picture on the onboard video card). So i can do some experiments if i have to. Hope, this helps... Friday, September 28, 2007, 2:25:05 PM, you wrote: Hello, MisterE wrote: I've tried the controller in another motherboard, the ASUS CUSL2 (with similar specs) and i don't have any problems. Can you help? I've included some logs with may be of use. Did you use the same cable on both machines? Also, does the problem go away if you power the hard drive from the power supply of the other machine? -- Best regards, MisterEmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?
Alan Cox wrote: sda1 are corrupted (2 to 4 blocks missing). Copying that data back to Windows and it give the same results in Quickpar. So reading does not have problems. The data written to hda1 is correct. We've got a whole pile of reports like this with the 3512 and almost always Nvidia chipset, plus reports of BIOS updates fixing it. That you see something similar on intel boards is a bit worrying. Multiple sil3112/3512 + nvidia chipset problem doesn't usually involve device errors or timeouts. It usually corrupts data silently. And, yeah, data corruption on intel board is really disturbing. MisterE, do you have any processor powersaving mechanism enabled? If so, can you disable all and see whether that changes anything? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?
sda1 are corrupted (2 to 4 blocks missing). Copying that data back to Windows and it give the same results in Quickpar. So reading does not have problems. The data written to hda1 is correct. We've got a whole pile of reports like this with the 3512 and almost always Nvidia chipset, plus reports of BIOS updates fixing it. That you see something similar on intel boards is a bit worrying. Alan - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sata Sil3512 bug?
Hello, MisterE wrote: I've tried the controller in another motherboard, the ASUS CUSL2 (with similar specs) and i don't have any problems. Can you help? I've included some logs with may be of use. Did you use the same cable on both machines? Also, does the problem go away if you power the hard drive from the power supply of the other machine? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Sata Sil3512 bug?
Hello, First off, i'm quite new to linux. I don't know the official way's to report bugs. I'm not even sure that the bug is sata driver related. I hope you can do some suggestions. I recently bought 2 Sweex Sata controllers (without raid). This device contains the Sil3512 chip. I connected it to my D815EEA motherboard with a samsung hard drive. When i mounted it and connected to it with WinScp or samba i got hangs; a couple of seconds the filetransfer stopped. The logs in var and the screen are spooled with errors like in samsung error.txt. I now have bought some Western Digitals drives. I get similar problems (wd error.txt), but nog hangs. I've tried the controller in another motherboard, the ASUS CUSL2 (with similar specs) and i don't have any problems. Can you help? I've included some logs with may be of use. btw: i use Debian unstable. I use the same hd with the OS (IDE drive) on both systems, so we can exclude a faulty OS. -- Best regards, MisterE mailto:[EMAIL PROTECTED]Sep 24 17:42:43 fileserver kernel: NTFS driver 2.1.28 [Flags: R/W MODULE]. Sep 24 17:42:43 fileserver kernel: NTFS volume version 3.1. Sep 24 17:44:05 fileserver kernel: NTFS volume version 3.1. Sep 24 17:44:36 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Sep 24 17:44:36 fileserver kernel: ata2.00: (BMDMA2 stat 0x6c0009) Sep 24 17:44:36 fileserver kernel: ata2.00: cmd c8/00:0c:a8:01:bd/00:00:00:00:00/e1 tag 0 cdb 0x0 data 6144 in Sep 24 17:44:36 fileserver kernel: res 51/04:00:b3:01:bd/00:00:00:00:00/e1 Emask 0x1 (device error) Sep 24 17:44:36 fileserver kernel: ata2.00: configured for UDMA/100 Sep 24 17:44:36 fileserver kernel: ata2: EH complete Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Write Protect is off Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 24 17:44:36 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Sep 24 17:44:36 fileserver kernel: ata2.00: (BMDMA2 stat 0x6d0009) Sep 24 17:44:36 fileserver kernel: ata2.00: cmd c8/00:07:38:19:bd/00:00:00:00:00/e1 tag 0 cdb 0x0 data 3584 in Sep 24 17:44:36 fileserver kernel: res 51/04:00:3e:19:bd/00:00:00:00:00/e1 Emask 0x1 (device error) Sep 24 17:44:36 fileserver kernel: ata2.00: configured for UDMA/100 Sep 24 17:44:36 fileserver kernel: ata2: EH complete Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Write Protect is off Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 24 17:45:06 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 24 17:45:06 fileserver kernel: ata2.00: cmd c8/00:80:3f:21:bd/00:00:00:00:00/e1 tag 0 cdb 0x0 data 65536 in Sep 24 17:45:06 fileserver kernel: res 40/00:00:3e:19:bd/00:00:00:00:00/e1 Emask 0x4 (timeout) Sep 24 17:45:07 fileserver kernel: ata2: soft resetting port Sep 24 17:45:07 fileserver kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Sep 24 17:45:07 fileserver kernel: ata2.00: configured for UDMA/100 Sep 24 17:45:07 fileserver kernel: ata2: EH complete Sep 24 17:45:07 fileserver kernel: sd 1:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) Sep 24 17:45:07 fileserver kernel: sd 1:0:0:0: [sda] Write Protect is off Sep 24 17:45:07 fileserver kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Sep 24 17:45:07 fileserver kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 24 17:45:37 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 24 17:45:37 fileserver kernel: ata2.00: cmd c8/00:80:3f:24:bd/00:00:00:00:00/e1 tag 0 cdb 0x0 data 65536 in Sep 24 17:45:37 fileserver kernel: res 40/00:00:3e:19:bd/00:00:00:00:00/e1 Emask 0x4 (timeout) Sep 24 17:45:37 fileserver kernel: ata2: soft resetting port Sep 24 17:45:37 fileserver kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Sep 24 17:45:37 fileserver kernel: ata2.00: configured for UDMA/100 Sep 24 17:45:37 fileserver kernel: ata2: EH complete Sep 24 17:45:37 fileserver kernel: sd 1:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) Sep 24 17:45:37 fileserver kernel: sd 1:0:0:0: [sda] Write Protect is off Sep 24 17:45:37 fileserver kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Sep 24 17:45:37 fileserver kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUASep 25 14:09:57 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x240 action 0x0 Sep 25
