* Re: 2.6.24.3: regular sata drive resets - worrisome? [not found] <200803201518.32109.hpj@urpla.net> @ 2008-03-21 4:48 ` Andrew Morton 2008-03-21 18:32 ` Roger Heflin 2008-03-29 12:58 ` Tejun Heo 0 siblings, 2 replies; 11+ messages in thread From: Andrew Morton @ 2008-03-21 4:48 UTC (permalink / raw) To: Hans-Peter Jansen; +Cc: linux-kernel, linux-ide (cc linux-ide) (regression?) On Thu, 20 Mar 2008 15:18:31 +0100 Hans-Peter Jansen <hpj@urpla.net> wrote: > Hi, > > since I upgraded to 2.6.24.3 on one of my production systems, I see > regular device resets like these: > > Mar 20 14:33:03 lisa5 kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > Mar 20 14:33:03 lisa5 kernel: ata2.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 > Mar 20 14:33:03 lisa5 kernel: res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) > Mar 20 14:33:03 lisa5 kernel: ata2.00: status: { DRDY } > Mar 20 14:33:03 lisa5 kernel: ata2: hard resetting link > Mar 20 14:33:05 lisa5 kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 0) > Mar 20 14:33:05 lisa5 kernel: ata2.00: configured for UDMA/100 > Mar 20 14:33:05 lisa5 kernel: ata2: EH complete > Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: [sdc] 488397168 512-byte hardware sectors (250059 MB) > Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: [sdc] Write Protect is off > Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 > Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > Mar 20 14:36:11 lisa5 kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > Mar 20 14:36:11 lisa5 kernel: ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 > Mar 20 14:36:11 lisa5 kernel: res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) > Mar 20 14:36:11 lisa5 kernel: ata3.00: status: { DRDY } > Mar 20 14:36:11 lisa5 kernel: ata3: hard resetting link > Mar 20 14:36:13 lisa5 kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) > Mar 20 14:36:13 lisa5 kernel: ata3.00: configured for UDMA/100 > Mar 20 14:36:13 lisa5 kernel: ata3: EH complete > Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: [sdd] 488397168 512-byte hardware sectors (250059 MB) > Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: [sdd] Write Protect is off > Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 > Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > > Should I be worried? smartd doesn't show anything suspicious on those. > > It's been 4 samsung drives at all hanging on a sata sil 3124: > > 29: PCI 202.0: 0104 RAID bus controller > [Created at pci.273] > Unique ID: LHB6.kPnnhej1LTC > Parent ID: bSAa.qlvrYsPk2G3 > SysFS ID: /devices/pci0000:00/0000:00:0a.0/0000:02:02.0 > SysFS BusID: 0000:02:02.0 > Hardware Class: storage > Model: "Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3124 PCI-X Serial ATA Controller" > Vendor: pci 0x1095 "Silicon Image, Inc. (formerly CMD Technology Inc)" > Device: pci 0x3124 "SiI 3124 PCI-X Serial ATA Controller" > SubVendor: pci 0x1095 "Silicon Image, Inc. (formerly CMD Technology Inc)" > SubDevice: pci 0x7124 > Revision: 0x01 > Driver: "sata_sil24" > Memory Range: 0xfc9ffc00-0xfc9ffc7f (rw,non-prefetchable) > Memory Range: 0xfc9f0000-0xfc9f7fff (rw,non-prefetchable) > I/O Ports: 0xac00-0xac0f (rw) > Memory Range: 0xfc900000-0xfc97ffff (ro,prefetchable,disabled) > IRQ: 17 (20116954 events) > Driver Info #0: > Driver Status: sata_sil24 is active > Driver Activation Cmd: "modprobe sata_sil24" > Config Status: cfg=no, avail=yes, need=no, active=unknown > Attached to: #15 (PCI bridge) > > 27: IDE 100.0: 10600 Disk > [Created at block.188] > Unique ID: DQI9.0o8IZwvZth7 > Parent ID: LHB6.kPnnhej1LTC > SysFS ID: /block/sdb > SysFS BusID: 1:0:0:0 > SysFS Device Link: /devices/pci0000:00/0000:00:0a.0/0000:02:02.0/host1/target1:0:0/1:0:0:0 > Hardware Class: disk > Model: "SAMSUNG SP2504C" > Vendor: "SAMSUNG" > Device: "SP2504C" > Revision: "VT10" > Serial ID: "S09QJ1GYA03006" > Driver: "sata_sil24", "sd" > Device File: /dev/sdb > Device > Files: /dev/sdb, /dev/disk/by-path/pci-0000:02:02.0-scsi-0:0:0:0, /dev/disk/by-id/1ATA_SAMSUNG_SP2504C_S09QJ1GYA03006 > Device Number: block 8:16-8:31 > Geometry (Logical): CHS 30401/255/63 > Size: 488397168 sectors a 512 bytes > Config Status: cfg=no, avail=yes, need=no, active=unknown > Attached to: #20 (RAID bus controller) > > 28: IDE 200.0: 10600 Disk > [Created at block.188] > Unique ID: gbYD.jbwYSfXQ1s1 > Parent ID: LHB6.kPnnhej1LTC > SysFS ID: /block/sdc > SysFS BusID: 2:0:0:0 > SysFS Device Link: /devices/pci0000:00/0000:00:0a.0/0000:02:02.0/host2/target2:0:0/2:0:0:0 > Hardware Class: disk > Model: "SAMSUNG SP2504C" > Vendor: "SAMSUNG" > Device: "SP2504C" > Revision: "VT10" > Serial ID: "S09QJ1GYA03003" > Driver: "sata_sil24", "sd" > Device File: /dev/sdc > Device > Files: /dev/sdc, /dev/disk/by-path/pci-0000:02:02.0-scsi-1:0:0:0, /dev/disk/by-id/1ATA_SAMSUNG_SP2504C_S09QJ1GYA03003 > Device Number: block 8:32-8:47 > Geometry (Logical): CHS 30401/255/63 > Size: 488397168 sectors a 512 bytes > Config Status: cfg=no, avail=yes, need=no, active=unknown > Attached to: #20 (RAID bus controller) > > 29: IDE 300.0: 10600 Disk > [Created at block.188] > Unique ID: 8noH.C6Upa9vrTP5 > Parent ID: LHB6.kPnnhej1LTC > SysFS ID: /block/sdd > SysFS BusID: 3:0:0:0 > SysFS Device Link: /devices/pci0000:00/0000:00:0a.0/0000:02:02.0/host3/target3:0:0/3:0:0:0 > Hardware Class: disk > Model: "SAMSUNG SP2504C" > Vendor: "SAMSUNG" > Device: "SP2504C" > Revision: "VT10" > Serial ID: "S09QJ1GYA02991" > Driver: "sata_sil24", "sd" > Device File: /dev/sdd > Device > Files: /dev/sdd, /dev/disk/by-path/pci-0000:02:02.0-scsi-2:0:0:0, /dev/disk/by-id/1ATA_SAMSUNG_SP2504C_S09QJ1GYA02991 > Device Number: block 8:48-8:63 > Geometry (Logical): CHS 30401/255/63 > Size: 488397168 sectors a 512 bytes > Config Status: cfg=no, avail=yes, need=no, active=unknown > Attached to: #20 (RAID bus controller) > > 30: IDE 400.0: 10600 Disk > [Created at block.188] > Unique ID: by2M.RNPEDP68X7E > Parent ID: LHB6.kPnnhej1LTC > SysFS ID: /block/sde > SysFS BusID: 4:0:0:0 > SysFS Device Link: /devices/pci0000:00/0000:00:0a.0/0000:02:02.0/host4/target4:0:0/4:0:0:0 > Hardware Class: disk > Model: "SAMSUNG SP2504C" > Vendor: "SAMSUNG" > Device: "SP2504C" > Revision: "VT10" > Serial ID: "S09QJ1GYA02990" > Driver: "sata_sil24", "sd" > Device File: /dev/sde > Device > Files: /dev/sde, /dev/disk/by-path/pci-0000:02:02.0-scsi-3:0:0:0, /dev/disk/by-id/1ATA_SAMSUNG_SP2504C_S09QJ1GYA02990 > Device Number: block 8:64-8:79 > Geometry (Logical): CHS 30401/255/63 > Size: 488397168 sectors a 512 bytes > Config Status: cfg=no, avail=yes, need=no, active=unknown > Attached to: #20 (RAID bus controller) > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-21 4:48 ` 2.6.24.3: regular sata drive resets - worrisome? Andrew Morton @ 2008-03-21 18:32 ` Roger Heflin 2008-03-21 23:06 ` Hans-Peter Jansen 2008-03-29 12:58 ` Tejun Heo 1 sibling, 1 reply; 11+ messages in thread From: Roger Heflin @ 2008-03-21 18:32 UTC (permalink / raw) To: Andrew Morton; +Cc: Hans-Peter Jansen, linux-kernel, linux-ide Andrew Morton wrote: > (cc linux-ide) > (regression?) > > On Thu, 20 Mar 2008 15:18:31 +0100 Hans-Peter Jansen <hpj@urpla.net> wrote: > >> Hi, >> >> since I upgraded to 2.6.24.3 on one of my production systems, I see >> regular device resets like these: Hans, What kernel were you using before you updated to that kernel? >> >> Mar 20 14:33:03 lisa5 kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen >> Mar 20 14:33:03 lisa5 kernel: ata2.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 >> Mar 20 14:33:03 lisa5 kernel: res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) >> Mar 20 14:33:03 lisa5 kernel: ata2.00: status: { DRDY } >> Mar 20 14:33:03 lisa5 kernel: ata2: hard resetting link >> Mar 20 14:33:05 lisa5 kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 0) >> Mar 20 14:33:05 lisa5 kernel: ata2.00: configured for UDMA/100 >> Mar 20 14:33:05 lisa5 kernel: ata2: EH complete >> Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: [sdc] 488397168 512-byte hardware sectors (250059 MB) >> Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: [sdc] Write Protect is off >> Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 >> Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA >> Mar 20 14:36:11 lisa5 kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen >> Mar 20 14:36:11 lisa5 kernel: ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 >> Mar 20 14:36:11 lisa5 kernel: res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) >> Mar 20 14:36:11 lisa5 kernel: ata3.00: status: { DRDY } >> Mar 20 14:36:11 lisa5 kernel: ata3: hard resetting link >> Mar 20 14:36:13 lisa5 kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) >> Mar 20 14:36:13 lisa5 kernel: ata3.00: configured for UDMA/100 >> Mar 20 14:36:13 lisa5 kernel: ata3: EH complete >> Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: [sdd] 488397168 512-byte hardware sectors (250059 MB) >> Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: [sdd] Write Protect is off >> Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 >> Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA >> >> Should I be worried? smartd doesn't show anything suspicious on those. >> Andrew, I don't think it is a recent regression, I have seen it happening for a while on my machine, I don't think it is causing any crashes but I am getting unexplained events about 1x per month that appear to deadlock a number of things (machine is up, but top won't run and vmstat actually gets a FP exception on the second sample, and a number of other things have issues until reboot). I have 4 identical disks, 2 on a sata_sil and 2 on another controller, the ones on the sil controller have this behavior, I have seen it in 2.6.23.1, FC7-2.6.23.15-80 and FC7-2.6.22.9-91. My sil is a 4-port 3114 PCI card, and my disks are 500GB Western Digital disks. I have a fairly long run with 20-30 events on the 2 disks on the sata_sil and no events on the identical non-sil disks that had previously been getting resets (when on the sil controller), and since they are under software raid5 all 4 disks should have very very similar IO loads. Roger ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-21 18:32 ` Roger Heflin @ 2008-03-21 23:06 ` Hans-Peter Jansen 0 siblings, 0 replies; 11+ messages in thread From: Hans-Peter Jansen @ 2008-03-21 23:06 UTC (permalink / raw) To: Roger Heflin; +Cc: Andrew Morton, linux-kernel, linux-ide Am Freitag, 21. März 2008 schrieb Roger Heflin: > Andrew Morton wrote: > > (cc linux-ide) > > (regression?) > > > > On Thu, 20 Mar 2008 15:18:31 +0100 Hans-Peter Jansen <hpj@urpla.net> wrote: > >> Hi, > >> > >> since I upgraded to 2.6.24.3 on one of my production systems, I see > >> regular device resets like these: > > Hans, > > What kernel were you using before you updated to that kernel? You don't what to know that ;-) (cough 2.6.11 cough) > >> Mar 20 14:33:03 lisa5 kernel: ata2.00: exception Emask 0x0 SAct 0x0 > >> SErr 0x0 action 0x2 frozen Mar 20 14:33:03 lisa5 kernel: ata2.00: cmd > >> ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 Mar 20 14:33:03 lisa5 > >> kernel: res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 > >> (timeout) Mar 20 14:33:03 lisa5 kernel: ata2.00: status: { DRDY } > >> Mar 20 14:33:03 lisa5 kernel: ata2: hard resetting link > >> Mar 20 14:33:05 lisa5 kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 > >> SControl 0) Mar 20 14:33:05 lisa5 kernel: ata2.00: configured for > >> UDMA/100 Mar 20 14:33:05 lisa5 kernel: ata2: EH complete > >> Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: [sdc] 488397168 512-byte > >> hardware sectors (250059 MB) Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: > >> [sdc] Write Protect is off Mar 20 14:33:05 lisa5 kernel: sd 2:0:0:0: > >> [sdc] Mode Sense: 00 3a 00 00 Mar 20 14:33:05 lisa5 kernel: sd > >> 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't > >> support DPO or FUA Mar 20 14:36:11 lisa5 kernel: ata3.00: exception > >> Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Mar 20 14:36:11 lisa5 > >> kernel: ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 Mar 20 > >> 14:36:11 lisa5 kernel: res > >> 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Mar 20 > >> 14:36:11 lisa5 kernel: ata3.00: status: { DRDY } > >> Mar 20 14:36:11 lisa5 kernel: ata3: hard resetting link > >> Mar 20 14:36:13 lisa5 kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 > >> SControl 0) Mar 20 14:36:13 lisa5 kernel: ata3.00: configured for > >> UDMA/100 Mar 20 14:36:13 lisa5 kernel: ata3: EH complete > >> Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: [sdd] 488397168 512-byte > >> hardware sectors (250059 MB) Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: > >> [sdd] Write Protect is off Mar 20 14:36:13 lisa5 kernel: sd 3:0:0:0: > >> [sdd] Mode Sense: 00 3a 00 00 Mar 20 14:36:13 lisa5 kernel: sd > >> 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't > >> support DPO or FUA > >> > >> Should I be worried? smartd doesn't show anything suspicious on those. > > Andrew, > > I don't think it is a recent regression, I have seen it happening for a > while on my machine, I don't think it is causing any crashes but I am > getting unexplained events about 1x per month that appear to deadlock a > number of things (machine is up, but top won't run and vmstat actually > gets a FP exception on the second sample, and a number of other things > have issues until reboot). Well, that doesn't sound reassuring, does it? > I have 4 identical disks, 2 on a sata_sil and 2 on another controller, > the ones on the sil controller have this behavior, I have seen it in > 2.6.23.1, FC7-2.6.23.15-80 and FC7-2.6.22.9-91. My sil is a 4-port 3114 > PCI card, and my disks are 500GB Western Digital disks. I have a fairly > long run with 20-30 events on the 2 disks on the sata_sil and no events > on the identical non-sil disks that had previously been getting resets > (when on the sil controller), and since they are under software raid5 all > 4 disks should have very very similar IO loads. Okay, those resets may happen without further consequences, but they're disturbing nevertheless. BTW, I'm preparing a hardware reorg, which will eliminate this controller during this weekend.. Well, to be correct, the other is the one, that really nags me for some time now (3ware 9xxx-8). Swapping both with one Areca 1130, which performes _much_ better. Pete ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-21 4:48 ` 2.6.24.3: regular sata drive resets - worrisome? Andrew Morton 2008-03-21 18:32 ` Roger Heflin @ 2008-03-29 12:58 ` Tejun Heo 2008-03-30 0:14 ` Hans-Peter Jansen 1 sibling, 1 reply; 11+ messages in thread From: Tejun Heo @ 2008-03-29 12:58 UTC (permalink / raw) To: Andrew Morton; +Cc: Hans-Peter Jansen, linux-kernel, linux-ide Hello, Hans. Andrew Morton wrote: >> since I upgraded to 2.6.24.3 on one of my production systems, I see >> regular device resets like these: >> >> Mar 20 14:33:03 lisa5 kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen >> Mar 20 14:33:03 lisa5 kernel: ata2.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 >> Mar 20 14:33:03 lisa5 kernel: res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Ouch, timeout on FLUSH_EXT. Are all errors on cmd ea? >> Should I be worried? smartd doesn't show anything suspicious on those. Can you please post the result of "smartctl -a /dev/sdX"? >> It's been 4 samsung drives at all hanging on a sata sil 3124: FLUSH_EXT timing out usually indicates that the drive is having problem writing out what it has in its cache to the media. There was one case where FLUSH_EXT timeout was caused by the driver failing to switch controller back from NCQ mode before issuing FLUSH_EXT but that was on sata_nv. There hasn't been any similar problem on sata_sil24. Thanks. -- tejun ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-29 12:58 ` Tejun Heo @ 2008-03-30 0:14 ` Hans-Peter Jansen 2008-03-30 0:54 ` Tejun Heo 0 siblings, 1 reply; 11+ messages in thread From: Hans-Peter Jansen @ 2008-03-30 0:14 UTC (permalink / raw) To: Tejun Heo; +Cc: Andrew Morton, linux-kernel, linux-ide Hi Tejun, thanks for picking this issue up. Am Samstag, 29. März 2008 schrieb Tejun Heo: > Hello, Hans. > > Andrew Morton wrote: > >> since I upgraded to 2.6.24.3 on one of my production systems, I see > >> regular device resets like these: > >> > >> Mar 20 14:33:03 lisa5 kernel: ata2.00: exception Emask 0x0 SAct 0x0 > >> SErr 0x0 action 0x2 frozen Mar 20 14:33:03 lisa5 kernel: ata2.00: cmd > >> ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 Mar 20 14:33:03 lisa5 > >> kernel: res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 > >> (timeout) > > Ouch, timeout on FLUSH_EXT. Are all errors on cmd ea? > > >> Should I be worried? smartd doesn't show anything suspicious on those. > > Can you please post the result of "smartctl -a /dev/sdX"? Here's the last smart report from two of the offending drives. As noted before, I did the hardware reorganization, replaced the dog slow 3ware 9500S-8 and the SiI 3124 with a single Areca 1130 and retired the drives for now, but a nephew already showed interest. What do you think, can I cede those drives with a clear conscience? The Hardware_ECC_Recovered values are really worrisome, aren't they? sdc: smartctl version 5.38 [i686-suse-linux-gnu] Copyright (C) 2002-7 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint P120 series Device Model: SAMSUNG SP2504C Serial Number: S09QJ1GYA03006 Firmware Version: VT100-33 User Capacity: 250.059.350.016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 T13 1532D revision 4a Local Time is: Sun Mar 23 01:13:37 2008 CET ==> WARNING: May need -F samsung3 enabled; see manual for details. SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (4866) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 81) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 82 3 Spin_Up_Time 0x0007 100 100 025 Pre-fail Always - 5952 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 23 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 17647 10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 253 002 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 19 190 Airflow_Temperature_Cel 0x0022 124 124 000 Old_age Always - 38 194 Temperature_Celsius 0x0022 124 124 000 Old_age Always - 38 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 162956700 196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 253 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 202 TA_Increase_Count 0x0032 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 17624 - # 2 Short offline Completed without error 00% 17601 - # 3 Short offline Completed without error 00% 17577 - # 4 Short offline Completed without error 00% 17553 - # 5 Short offline Completed without error 00% 17528 - # 6 Short offline Completed without error 00% 17504 - # 7 Extended offline Completed without error 00% 17489 - # 8 Short offline Completed without error 00% 17480 - # 9 Short offline Completed without error 00% 17456 - #10 Short offline Completed without error 00% 17432 - #11 Short offline Completed without error 00% 17408 - #12 Short offline Completed without error 00% 17384 - #13 Short offline Completed without error 00% 17360 - #14 Short offline Completed without error 00% 17336 - #15 Extended offline Completed without error 00% 17320 - #16 Short offline Completed without error 00% 17311 - #17 Short offline Completed without error 00% 17287 - #18 Short offline Completed without error 00% 17263 - #19 Short offline Completed without error 00% 17239 - SMART Selective Self-Test Log Data Structure Revision Number (0) should be 1 SMART Selective self-test log data structure revision number 0 Warning: ATA Specification requires selective self-test log data structure revision number = 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. sdd: smartctl version 5.38 [i686-suse-linux-gnu] Copyright (C) 2002-7 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint P120 series Device Model: SAMSUNG SP2504C Serial Number: S09QJ1GYA03003 Firmware Version: VT100-33 User Capacity: 250.059.350.016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 T13 1532D revision 4a Local Time is: Sun Mar 23 01:13:38 2008 CET ==> WARNING: May need -F samsung3 enabled; see manual for details. SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (4836) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 80) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 79 3 Spin_Up_Time 0x0007 100 100 025 Pre-fail Always - 5952 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 23 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 17648 10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 253 002 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 19 190 Airflow_Temperature_Cel 0x0022 118 118 000 Old_age Always - 40 194 Temperature_Celsius 0x0022 118 118 000 Old_age Always - 40 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 162520674 196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 253 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 202 TA_Increase_Count 0x0032 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 17626 - # 2 Short offline Completed without error 00% 17602 - # 3 Short offline Completed without error 00% 17578 - # 4 Short offline Completed without error 00% 17554 - # 5 Short offline Completed without error 00% 17530 - # 6 Short offline Completed without error 00% 17506 - # 7 Extended offline Completed without error 00% 17490 - # 8 Short offline Completed without error 00% 17482 - # 9 Short offline Completed without error 00% 17457 - #10 Short offline Completed without error 00% 17433 - #11 Short offline Completed without error 00% 17409 - #12 Short offline Completed without error 00% 17385 - #13 Short offline Completed without error 00% 17361 - #14 Short offline Completed without error 00% 17337 - #15 Extended offline Completed without error 00% 17321 - #16 Short offline Completed without error 00% 17313 - #17 Short offline Completed without error 00% 17289 - #18 Short offline Completed without error 00% 17264 - #19 Short offline Completed without error 00% 17240 - SMART Selective Self-Test Log Data Structure Revision Number (0) should be 1 SMART Selective self-test log data structure revision number 0 Warning: ATA Specification requires selective self-test log data structure revision number = 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. > >> It's been 4 samsung drives at all hanging on a sata sil 3124: > > FLUSH_EXT timing out usually indicates that the drive is having problem > writing out what it has in its cache to the media. There was one case > where FLUSH_EXT timeout was caused by the driver failing to switch > controller back from NCQ mode before issuing FLUSH_EXT but that was on > sata_nv. There hasn't been any similar problem on sata_sil24. Hmm, I didn't noticed any data distortions, and if there where, they live on as copies in their new home.. Thanks, Pete ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-30 0:14 ` Hans-Peter Jansen @ 2008-03-30 0:54 ` Tejun Heo 2008-03-30 12:00 ` Hans-Peter Jansen 0 siblings, 1 reply; 11+ messages in thread From: Tejun Heo @ 2008-03-30 0:54 UTC (permalink / raw) To: Hans-Peter Jansen; +Cc: Andrew Morton, linux-kernel, linux-ide Hello, Hans-Peter Jansen wrote: >>>> Should I be worried? smartd doesn't show anything suspicious on those. >> Can you please post the result of "smartctl -a /dev/sdX"? > > Here's the last smart report from two of the offending drives. As noted > before, I did the hardware reorganization, replaced the dog slow 3ware > 9500S-8 and the SiI 3124 with a single Areca 1130 and retired the drives > for now, but a nephew already showed interest. What do you think, can I > cede those drives with a clear conscience? The Hardware_ECC_Recovered > values are really worrisome, aren't they? Different vendors use different scales for the raw values. The value is still pegged at the highest so it could be those raw values are okay or that the vendor just doesn't update value field accordingly. My P120 says 0 for the raw value and 904635 for hardware ECC recovered so there is some difference. What do other non-failing drives say about those values? > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 82 > 3 Spin_Up_Time 0x0007 100 100 025 Pre-fail Always - 5952 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 23 > 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 > 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 > 8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail Offline - 0 > 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 17647 > 10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail Always - 0 > 11 Calibration_Retry_Count 0x0012 253 002 000 Old_age Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 19 > 190 Airflow_Temperature_Cel 0x0022 124 124 000 Old_age Always - 38 > 194 Temperature_Celsius 0x0022 124 124 000 Old_age Always - 38 > 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 162956700 > 196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 > 197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 > 198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 > 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > 200 Multi_Zone_Error_Rate 0x000a 253 100 000 Old_age Always - 0 > 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 > 202 TA_Increase_Count 0x0032 253 253 000 Old_age Always - 0 Hmmm... If the drive is failing FLUSHs, I would expect to see elevated reallocation counters and maybe some pending counts. Aieee.. weird. >>>> It's been 4 samsung drives at all hanging on a sata sil 3124: >> FLUSH_EXT timing out usually indicates that the drive is having problem >> writing out what it has in its cache to the media. There was one case >> where FLUSH_EXT timeout was caused by the driver failing to switch >> controller back from NCQ mode before issuing FLUSH_EXT but that was on >> sata_nv. There hasn't been any similar problem on sata_sil24. > > Hmm, I didn't noticed any data distortions, and if there where, they live > on as copies in their new home.. It should have appeared as read errors. Maybe the drive successfully wrote those sectors after 30+ secs timeout. -- tejun ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-30 0:54 ` Tejun Heo @ 2008-03-30 12:00 ` Hans-Peter Jansen 2008-03-30 12:41 ` Roger Heflin 0 siblings, 1 reply; 11+ messages in thread From: Hans-Peter Jansen @ 2008-03-30 12:00 UTC (permalink / raw) To: Tejun Heo; +Cc: Andrew Morton, linux-kernel, linux-ide, Roger Heflin Am Sonntag, 30. März 2008 schrieb Tejun Heo: > Hello, > > Hans-Peter Jansen wrote: > >>>> Should I be worried? smartd doesn't show anything suspicious on > >>>> those. > >> > >> Can you please post the result of "smartctl -a /dev/sdX"? > > > > Here's the last smart report from two of the offending drives. As noted > > before, I did the hardware reorganization, replaced the dog slow 3ware > > 9500S-8 and the SiI 3124 with a single Areca 1130 and retired the > > drives for now, but a nephew already showed interest. What do you > > think, can I cede those drives with a clear conscience? The > > Hardware_ECC_Recovered values are really worrisome, aren't they? > > Different vendors use different scales for the raw values. The value is > still pegged at the highest so it could be those raw values are okay or > that the vendor just doesn't update value field accordingly. My P120 > says 0 for the raw value and 904635 for hardware ECC recovered so there > is some difference. What do other non-failing drives say about those > values? The only non-failing drive was sdf as it was running in standby mode in this md raid 5 ensemble: 20080323-011337-sdc.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 162956700 20080323-011337-sdc.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 20080323-011337-sdc.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 20080323-011337-sdc.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 20080323-011337-sdc.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 20080323-011338-sdd.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 162520674 20080323-011338-sdd.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 20080323-011338-sdd.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 20080323-011338-sdd.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 20080323-011338-sdd.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 20080323-011338-sde.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 148429049 20080323-011338-sde.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 20080323-011338-sde.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 20080323-011338-sde.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 20080323-011338-sde.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 20080323-011339-sdf.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 1559 20080323-011339-sdf.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 20080323-011339-sdf.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 20080323-011339-sdf.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 20080323-011339-sdf.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > Hmmm... If the drive is failing FLUSHs, I would expect to see elevated > reallocation counters and maybe some pending counts. Aieee.. weird. But there are no reallocations nor any pending sectors on any of them. > >>>> It's been 4 samsung drives at all hanging on a sata sil 3124: > >> > >> FLUSH_EXT timing out usually indicates that the drive is having > >> problem writing out what it has in its cache to the media. There was > >> one case where FLUSH_EXT timeout was caused by the driver failing to > >> switch controller back from NCQ mode before issuing FLUSH_EXT but that > >> was on sata_nv. There hasn't been any similar problem on sata_sil24. > > > > Hmm, I didn't noticed any data distortions, and if there where, they > > live on as copies in their new home.. > > It should have appeared as read errors. Maybe the drive successfully ^^^^ write (I guess) > wrote those sectors after 30+ secs timeout. That would point to some driver issue, wouldn't it? Roger Heflin also experienced similar behavior with that controller, which wasn't reproducible with another. I can offer to you rebuilding that md in a test environment, and giving you access to it, if you're interested. Anyway, thanks for caring Tejun, Pete ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-30 12:00 ` Hans-Peter Jansen @ 2008-03-30 12:41 ` Roger Heflin 2008-03-30 21:02 ` Hein-Pieter van Braam 2008-03-31 4:33 ` Tejun Heo 0 siblings, 2 replies; 11+ messages in thread From: Roger Heflin @ 2008-03-30 12:41 UTC (permalink / raw) To: Hans-Peter Jansen; +Cc: Tejun Heo, Andrew Morton, linux-kernel, linux-ide Hans-Peter Jansen wrote: > Am Sonntag, 30. März 2008 schrieb Tejun Heo: >> Hello, >> >> Hans-Peter Jansen wrote: >>>>>> Should I be worried? smartd doesn't show anything suspicious on >>>>>> those. >>>> Can you please post the result of "smartctl -a /dev/sdX"? >>> Here's the last smart report from two of the offending drives. As noted >>> before, I did the hardware reorganization, replaced the dog slow 3ware >>> 9500S-8 and the SiI 3124 with a single Areca 1130 and retired the >>> drives for now, but a nephew already showed interest. What do you >>> think, can I cede those drives with a clear conscience? The >>> Hardware_ECC_Recovered values are really worrisome, aren't they? >> Different vendors use different scales for the raw values. The value is >> still pegged at the highest so it could be those raw values are okay or >> that the vendor just doesn't update value field accordingly. My P120 >> says 0 for the raw value and 904635 for hardware ECC recovered so there >> is some difference. What do other non-failing drives say about those >> values? > > The only non-failing drive was sdf as it was running in standby mode in this > md raid 5 ensemble: > > 20080323-011337-sdc.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 162956700 > 20080323-011337-sdc.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 > 20080323-011337-sdc.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 > 20080323-011337-sdc.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 > 20080323-011337-sdc.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > 20080323-011338-sdd.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 162520674 > 20080323-011338-sdd.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 > 20080323-011338-sdd.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 > 20080323-011338-sdd.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 > 20080323-011338-sdd.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > 20080323-011338-sde.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 148429049 > 20080323-011338-sde.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 > 20080323-011338-sde.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 > 20080323-011338-sde.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 > 20080323-011338-sde.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > 20080323-011339-sdf.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 1559 > 20080323-011339-sdf.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 > 20080323-011339-sdf.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 > 20080323-011339-sdf.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 > 20080323-011339-sdf.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > >> Hmmm... If the drive is failing FLUSHs, I would expect to see elevated >> reallocation counters and maybe some pending counts. Aieee.. weird. > > But there are no reallocations nor any pending sectors on any of them. > >>>>>> It's been 4 samsung drives at all hanging on a sata sil 3124: >>>> FLUSH_EXT timing out usually indicates that the drive is having >>>> problem writing out what it has in its cache to the media. There was >>>> one case where FLUSH_EXT timeout was caused by the driver failing to >>>> switch controller back from NCQ mode before issuing FLUSH_EXT but that >>>> was on sata_nv. There hasn't been any similar problem on sata_sil24. >>> Hmm, I didn't noticed any data distortions, and if there where, they >>> live on as copies in their new home.. >> It should have appeared as read errors. Maybe the drive successfully > ^^^^ > write (I guess) >> wrote those sectors after 30+ secs timeout. > > That would point to some driver issue, wouldn't it? Roger Heflin also > experienced similar behavior with that controller, which wasn't > reproducible with another. > > I can offer to you rebuilding that md in a test environment, and giving > you access to it, if you're interested. > > Anyway, thanks for caring Tejun, > Pete > Here are the errors I get, though look at it closer, I am don't appear to be getting the reset, just this error from time to time: sd 9:0:0:0: [sde] 976773168 512-byte hardware sectors (500108 MB) sd 9:0:0:0: [sde] Write Protect is off sd 9:0:0:0: [sde] Mode Sense: 00 3a 00 00 sd 9:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x280000 action 0x0 ata8.00: BMDMA2 stat 0x687d8009 ata8.00: cmd 25/00:80:a7:00:1d/00:01:1d:00:00/e0 tag 0 cdb 0x0 data 196608 in res 51/04:8f:98:01:1d/00:00:1d:00:00/f0 Emask 0x1 (device error) ata8.00: configured for UDMA/100 ata8: EH complete sd 7:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) sd 7:0:0:0: [sdd] Write Protect is off sd 7:0:0:0: [sdd] Mode Sense: 00 3a 00 00 sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA I have 4 identical disks, with all 4 connected to the SIL controller all give some errors, moving 2 of the disks to a promise controller makes the errors go away on the 2 connected to the promise controller. All drives are part of a software raid5 array. Startup looks like this: sata_sil 0000:00:09.0: version 2.3 ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 16 (level, low) -> IRQ 20 sata_sil 0000:00:09.0: Applying R_ERR on DMA activate FIS errata fix scsi7 : sata_sil scsi8 : sata_sil scsi9 : sata_sil scsi10 : sata_sil ata8: SATA max UDMA/100 cmd 0xf8942080 ctl 0xf894208a bmdma 0xf8942000 irq 20 ata9: SATA max UDMA/100 cmd 0xf89420c0 ctl 0xf89420ca bmdma 0xf8942008 irq 20 ata10: SATA max UDMA/100 cmd 0xf8942280 ctl 0xf894228a bmdma 0xf8942200 irq 20 ata11: SATA max UDMA/100 cmd 0xf89422c0 ctl 0xf89422ca bmdma 0xf8942208 irq 20 Right now I am running 2.6.23.15-80.fc7, but have also got the errors under 2.6.23.1 Roger ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-30 12:41 ` Roger Heflin @ 2008-03-30 21:02 ` Hein-Pieter van Braam 2008-03-31 4:33 ` Tejun Heo 1 sibling, 0 replies; 11+ messages in thread From: Hein-Pieter van Braam @ 2008-03-30 21:02 UTC (permalink / raw) To: Roger Heflin; +Cc: linux-ide On Sun, 2008-03-30 at 07:41 -0500, Roger Heflin wrote: > Hans-Peter Jansen wrote: > > Am Sonntag, 30. März 2008 schrieb Tejun Heo: > >> Hello, > >> > >> Hans-Peter Jansen wrote: > >>>>>> Should I be worried? smartd doesn't show anything suspicious on > >>>>>> those. > >>>> Can you please post the result of "smartctl -a /dev/sdX"? > >>> Here's the last smart report from two of the offending drives. As noted > >>> before, I did the hardware reorganization, replaced the dog slow 3ware > >>> 9500S-8 and the SiI 3124 with a single Areca 1130 and retired the > >>> drives for now, but a nephew already showed interest. What do you > >>> think, can I cede those drives with a clear conscience? The > >>> Hardware_ECC_Recovered values are really worrisome, aren't they? > >> Different vendors use different scales for the raw values. The value is > >> still pegged at the highest so it could be those raw values are okay or > >> that the vendor just doesn't update value field accordingly. My P120 > >> says 0 for the raw value and 904635 for hardware ECC recovered so there > >> is some difference. What do other non-failing drives say about those > >> values? > > > > The only non-failing drive was sdf as it was running in standby mode in this > > md raid 5 ensemble: > > > > 20080323-011337-sdc.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 162956700 > > 20080323-011337-sdc.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 > > 20080323-011337-sdc.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 > > 20080323-011337-sdc.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 > > 20080323-011337-sdc.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > > 20080323-011338-sdd.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 162520674 > > 20080323-011338-sdd.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 > > 20080323-011338-sdd.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 > > 20080323-011338-sdd.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 > > 20080323-011338-sdd.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > > 20080323-011338-sde.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 148429049 > > 20080323-011338-sde.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 > > 20080323-011338-sde.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 > > 20080323-011338-sde.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 > > 20080323-011338-sde.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > > 20080323-011339-sdf.log:195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 1559 > > 20080323-011339-sdf.log:196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 > > 20080323-011339-sdf.log:197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 > > 20080323-011339-sdf.log:198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 > > 20080323-011339-sdf.log:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > > > >> Hmmm... If the drive is failing FLUSHs, I would expect to see elevated > >> reallocation counters and maybe some pending counts. Aieee.. weird. > > > > But there are no reallocations nor any pending sectors on any of them. > > > >>>>>> It's been 4 samsung drives at all hanging on a sata sil 3124: > >>>> FLUSH_EXT timing out usually indicates that the drive is having > >>>> problem writing out what it has in its cache to the media. There was > >>>> one case where FLUSH_EXT timeout was caused by the driver failing to > >>>> switch controller back from NCQ mode before issuing FLUSH_EXT but that > >>>> was on sata_nv. There hasn't been any similar problem on sata_sil24. > >>> Hmm, I didn't noticed any data distortions, and if there where, they > >>> live on as copies in their new home.. > >> It should have appeared as read errors. Maybe the drive successfully > > ^^^^ > > write (I guess) > >> wrote those sectors after 30+ secs timeout. > > > > That would point to some driver issue, wouldn't it? Roger Heflin also > > experienced similar behavior with that controller, which wasn't > > reproducible with another. > > > > I can offer to you rebuilding that md in a test environment, and giving > > you access to it, if you're interested. > > > > Anyway, thanks for caring Tejun, > > Pete > > > > Here are the errors I get, though look at it closer, I am don't appear to be > getting the reset, just this error from time to time: > > sd 9:0:0:0: [sde] 976773168 512-byte hardware sectors (500108 MB) > sd 9:0:0:0: [sde] Write Protect is off > sd 9:0:0:0: [sde] Mode Sense: 00 3a 00 00 > sd 9:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO > or FUA > ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x280000 action 0x0 > ata8.00: BMDMA2 stat 0x687d8009 > ata8.00: cmd 25/00:80:a7:00:1d/00:01:1d:00:00/e0 tag 0 cdb 0x0 data 196608 in > res 51/04:8f:98:01:1d/00:00:1d:00:00/f0 Emask 0x1 (device error) > ata8.00: configured for UDMA/100 > ata8: EH complete > sd 7:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) > sd 7:0:0:0: [sdd] Write Protect is off > sd 7:0:0:0: [sdd] Mode Sense: 00 3a 00 00 > sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO > or FUA > > I have 4 identical disks, with all 4 connected to the SIL controller all give > some errors, moving 2 of the disks to a promise controller makes the errors go > away on the 2 connected to the promise controller. All drives are part of a > software raid5 array. > > Startup looks like this: > sata_sil 0000:00:09.0: version 2.3 > ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 16 (level, low) -> IRQ 20 > sata_sil 0000:00:09.0: Applying R_ERR on DMA activate FIS errata fix > scsi7 : sata_sil > scsi8 : sata_sil > scsi9 : sata_sil > scsi10 : sata_sil > ata8: SATA max UDMA/100 cmd 0xf8942080 ctl 0xf894208a bmdma 0xf8942000 irq 20 > ata9: SATA max UDMA/100 cmd 0xf89420c0 ctl 0xf89420ca bmdma 0xf8942008 irq 20 > ata10: SATA max UDMA/100 cmd 0xf8942280 ctl 0xf894228a bmdma 0xf8942200 irq 20 > ata11: SATA max UDMA/100 cmd 0xf89422c0 ctl 0xf89422ca bmdma 0xf8942208 irq 20 > > Right now I am running 2.6.23.15-80.fc7, but have also got the errors under 2.6.23.1 I know this is probably not too helpful, but I had the same or similar problems on a sata_nv based controller back in 2.6.20 ish times. I never reported it, sadly... but I managed to get them to go away by disabling adma on the controller. Probably not very helpful, 2 cents, and all :) > > Roger > -- > To unsubscribe from this list: send the line "unsubscribe linux-ide" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-30 12:41 ` Roger Heflin 2008-03-30 21:02 ` Hein-Pieter van Braam @ 2008-03-31 4:33 ` Tejun Heo 2008-04-01 19:27 ` Roger Heflin 1 sibling, 1 reply; 11+ messages in thread From: Tejun Heo @ 2008-03-31 4:33 UTC (permalink / raw) To: Roger Heflin; +Cc: Hans-Peter Jansen, Andrew Morton, linux-kernel, linux-ide Roger Heflin wrote: >> The only non-failing drive was sdf as it was running in standby mode >> in this md raid 5 ensemble: >> >> 20080323-011337-sdc.log:195 Hardware_ECC_Recovered 0x001a 100 >> 100 000 Old_age Always - 162956700 >> 20080323-011338-sde.log:195 Hardware_ECC_Recovered 0x001a 100 >> 100 000 Old_age Always - 148429049 Hmmm... looks similar. >>> Hmmm... If the drive is failing FLUSHs, I would expect to see elevated >>> reallocation counters and maybe some pending counts. Aieee.. weird. >> >> But there are no reallocations nor any pending sectors on any of them. Yeah, indded. >>>>>>> It's been 4 samsung drives at all hanging on a sata sil 3124: >>>>> FLUSH_EXT timing out usually indicates that the drive is having >>>>> problem writing out what it has in its cache to the media. There was >>>>> one case where FLUSH_EXT timeout was caused by the driver failing to >>>>> switch controller back from NCQ mode before issuing FLUSH_EXT but that >>>>> was on sata_nv. There hasn't been any similar problem on sata_sil24. >>>> Hmm, I didn't noticed any data distortions, and if there where, they >>>> live on as copies in their new home.. >>> It should have appeared as read errors. Maybe the drive successfully >> ^^^^ >> write (I guess) I actually meant read. For the corrupted data to get transferred to other disks, it should have been read as wrong values but such things should never happen as ECC checks would fail. >>> wrote those sectors after 30+ secs timeout. >> >> That would point to some driver issue, wouldn't it? Roger Heflin also >> experienced similar behavior with that controller, which wasn't >> reproducible with another. Roger's problem is different one. I'll talk about it below. >> I can offer to you rebuilding that md in a test environment, and >> giving you access to it, if you're interested. Can you hook up those failed drives to a different controller? Say, ahci or ata_piix and put them under write load (ext3 w/ barrier=1 and copying lots of files into it should work) and see whether the problem reproduces? > Here are the errors I get, though look at it closer, I am don't appear > to be getting the reset, just this error from time to time: > > sd 9:0:0:0: [sde] 976773168 512-byte hardware sectors (500108 MB) > sd 9:0:0:0: [sde] Write Protect is off > sd 9:0:0:0: [sde] Mode Sense: 00 3a 00 00 > sd 9:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't > support DPO or FUA > ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x280000 action 0x0 > ata8.00: BMDMA2 stat 0x687d8009 > ata8.00: cmd 25/00:80:a7:00:1d/00:01:1d:00:00/e0 tag 0 cdb 0x0 data > 196608 in > res 51/04:8f:98:01:1d/00:00:1d:00:00/f0 Emask 0x1 (device error) > ata8.00: configured for UDMA/100 That's device abort error on read. The drive just can't read sector one of the requested sectors and it's not sata_sil24. It's a bmdma one. > I have 4 identical disks, with all 4 connected to the SIL controller all > give some errors, moving 2 of the disks to a promise controller makes > the errors go away on the 2 connected to the promise controller. All > drives are part of a software raid5 array. Ah.. okay, sata_sil. Roger, the moving and errors are not very likely to have anything to do with each other. The only possibility is transmission problems but the drive didn't report transport error (ICRC) and it's more likely that the drive was experiencing temporary failures. It's also possible that the drive set ABRT although there was some problem with the transport tho. If you move the drive back to the sata_sil, do those problems appear again? Anyways, this doesn't really have anything to do with what Hans is seeing. Thanks. -- tejun ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.24.3: regular sata drive resets - worrisome? 2008-03-31 4:33 ` Tejun Heo @ 2008-04-01 19:27 ` Roger Heflin 0 siblings, 0 replies; 11+ messages in thread From: Roger Heflin @ 2008-04-01 19:27 UTC (permalink / raw) To: Tejun Heo; +Cc: Hans-Peter Jansen, Andrew Morton, linux-kernel, linux-ide Tejun Heo wrote: >>> I can offer to you rebuilding that md in a test environment, and >>> giving you access to it, if you're interested. > > Can you hook up those failed drives to a different controller? Say, > ahci or ata_piix and put them under write load (ext3 w/ barrier=1 and > copying lots of files into it should work) and see whether the problem > reproduces? I can move switch the disks to a sata_promise controller, I also have a sata_via controller but I cannot get those disks to work at all on it (it initially sees the disk, but does not finish init). I don't on the machine that those disks are on have any other sata controllers. > >> Here are the errors I get, though look at it closer, I am don't appear >> to be getting the reset, just this error from time to time: >> >> sd 9:0:0:0: [sde] 976773168 512-byte hardware sectors (500108 MB) >> sd 9:0:0:0: [sde] Write Protect is off >> sd 9:0:0:0: [sde] Mode Sense: 00 3a 00 00 >> sd 9:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't >> support DPO or FUA >> ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x280000 action 0x0 >> ata8.00: BMDMA2 stat 0x687d8009 >> ata8.00: cmd 25/00:80:a7:00:1d/00:01:1d:00:00/e0 tag 0 cdb 0x0 data >> 196608 in >> res 51/04:8f:98:01:1d/00:00:1d:00:00/f0 Emask 0x1 (device error) >> ata8.00: configured for UDMA/100 > > That's device abort error on read. The drive just can't read sector one > of the requested sectors and it's not sata_sil24. It's a bmdma one. > >> I have 4 identical disks, with all 4 connected to the SIL controller >> all give some errors, moving 2 of the disks to a promise controller >> makes the errors go away on the 2 connected to the promise >> controller. All drives are part of a software raid5 array. > > Ah.. okay, sata_sil. Roger, the moving and errors are not very likely > to have anything to do with each other. The only possibility is > transmission problems but the drive didn't report transport error (ICRC) > and it's more likely that the drive was experiencing temporary failures. > It's also possible that the drive set ABRT although there was some > problem with the transport tho. > > If you move the drive back to the sata_sil, do those problems appear > again? Anyways, this doesn't really have anything to do with what Hans > is seeing. I can swap the disk around next time I reboot the machine, the 2 on the promise will go to the sil and the 2 on the sil will go to the promise, from past testing I expect the disk on the sil to have the errors and the ones on the promise to not have errors. After I looked at the error more carefully and I though that too, I had originally thought I was getting resets also but I was wrong on that. Roger ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-04-01 19:28 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200803201518.32109.hpj@urpla.net>
2008-03-21 4:48 ` 2.6.24.3: regular sata drive resets - worrisome? Andrew Morton
2008-03-21 18:32 ` Roger Heflin
2008-03-21 23:06 ` Hans-Peter Jansen
2008-03-29 12:58 ` Tejun Heo
2008-03-30 0:14 ` Hans-Peter Jansen
2008-03-30 0:54 ` Tejun Heo
2008-03-30 12:00 ` Hans-Peter Jansen
2008-03-30 12:41 ` Roger Heflin
2008-03-30 21:02 ` Hein-Pieter van Braam
2008-03-31 4:33 ` Tejun Heo
2008-04-01 19:27 ` Roger Heflin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).