Problem mit SATA [Gelöst]

[jmar83]

Hallo zusammen

Wo liegt hier das Problem?

- Controller defekt? (LSI SAS3041X-L)
- Festplatten defekt (Western Digital Green 1.5 TB)
- Kabel sitzt nicht richtig?
- Kabel zu lang?
- Software-Bug?
- Firmware-Bug in der LSI-Controller-Karte?

Zumindest heisst es was von defekten Sektoren, allerdings stellt sich die Frage ob dem tatsächlich so sei...? Vor allem finde ich es schräg, dass wegen ein paar defekten Sektoren letztendlich die ganze Festplatte (/dev/sdb) vom Controller getrennt wird. Macht irgendwie auch keinen Sin...?




Feb 18 18:14:50 debian6sparc kernel: [ 3220.813972] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45fdc0)
Feb 18 18:14:50 debian6sparc kernel: [ 3220.903078] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 69 1c 68 00 00 80 00
Feb 18 18:14:50 debian6sparc kernel: [ 3221.003310] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45fdc0) (sn=202429)
Feb 18 18:14:50 debian6sparc kernel: [ 3221.113729] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45fa40)
Feb 18 18:14:50 debian6sparc kernel: [ 3221.202861] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 69 1e e0 00 02 00 00
Feb 18 18:14:50 debian6sparc kernel: [ 3221.302899] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45fa40) (sn=202431)
Feb 18 18:14:50 debian6sparc kernel: [ 3221.413396] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45f880)
Feb 18 18:14:50 debian6sparc kernel: [ 3221.502568] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 69 1c e8 00 01 f8 00
Feb 18 18:14:51 debian6sparc kernel: [ 3221.602594] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45f880) (sn=202434)
Feb 18 18:14:51 debian6sparc kernel: [ 3221.713093] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45f0a0)
Feb 18 18:14:51 debian6sparc kernel: [ 3221.802243] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 69 1a 60 00 00 08 00
Feb 18 18:14:51 debian6sparc kernel: [ 3221.902270] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45f0a0) (sn=202435)
Feb 18 18:14:51 debian6sparc kernel: [ 3222.012760] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45efc0)
Feb 18 18:14:51 debian6sparc kernel: [ 3222.101905] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 69 22 e0 00 02 08 00
Feb 18 18:14:51 debian6sparc kernel: [ 3222.201936] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45efc0) (sn=202437)
Feb 18 18:14:51 debian6sparc kernel: [ 3222.312505] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45fce0)
Feb 18 18:14:51 debian6sparc kernel: [ 3222.401715] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 69 20 e8 00 01 f8 00
Feb 18 18:14:51 debian6sparc kernel: [ 3222.501842] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45fce0) (sn=202440)
Feb 18 18:14:51 debian6sparc kernel: [ 3222.612504] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45ec40)
Feb 18 18:14:52 debian6sparc kernel: [ 3222.701685] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 69 1c 60 00 00 08 00
Feb 18 18:14:52 debian6sparc kernel: [ 3222.801800] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45ec40) (sn=202441)
Feb 18 18:14:52 debian6sparc kernel: [ 3222.912484] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45f6c0)
Feb 18 18:14:52 debian6sparc kernel: [ 3223.001697] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2b ac 25 50 00 00 10 00
Feb 18 18:14:52 debian6sparc kernel: [ 3223.101818] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45f6c0) (sn=202443)
Feb 18 18:14:52 debian6sparc kernel: [ 3223.212514] mptscsih: ioc1: attempting task abort! (sc=fffff8123e3befc0)
Feb 18 18:14:52 debian6sparc kernel: [ 3223.301758] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2b aa eb a8 00 00 10 00
Feb 18 18:14:52 debian6sparc kernel: [ 3223.401874] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123e3befc0) (sn=202445)
Feb 18 18:14:52 debian6sparc kernel: [ 3223.512568] mptscsih: ioc1: attempting target reset! (sc=fffff8123b45fdc0)
Feb 18 18:14:53 debian6sparc kernel: [ 3223.604121] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 69 1c 68 00 00 80 00
Feb 18 18:14:56 debian6sparc kernel: [ 3227.558427] mptscsih: ioc1: target reset: SUCCESS (sc=fffff8123b45fdc0)
Feb 18 18:14:58 debian6sparc kernel: [ 3229.086163] mptscsih: ioc1: attempting bus reset! (sc=fffff8123b45fdc0)
Feb 18 18:14:58 debian6sparc kernel: [ 3229.174202] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 69 1c 68 00 00 80 00
Feb 18 18:14:58 debian6sparc kernel: [ 3229.369947] Kernel unaligned access at TPC[10149bb0] mptsas_firmware_event_work+0xd70/0x1178 [mptsas]
Feb 18 18:14:58 debian6sparc kernel: [ 3229.493224] Kernel unaligned access at TPC[10149bd0] mptsas_firmware_event_work+0xd90/0x1178 [mptsas]
Feb 18 18:14:59 debian6sparc kernel: [ 3229.616389] Kernel unaligned access at TPC[10149bb0] mptsas_firmware_event_work+0xd70/0x1178 [mptsas]
Feb 18 18:14:59 debian6sparc kernel: [ 3229.739563] Kernel unaligned access at TPC[10149bd0] mptsas_firmware_event_work+0xd90/0x1178 [mptsas]
Feb 18 18:14:59 debian6sparc kernel: [ 3229.739756] mptscsih: ioc1: bus reset: SUCCESS (sc=fffff8123b45fdc0)
Feb 18 18:14:59 debian6sparc kernel: [ 3229.947158] Kernel unaligned access at TPC[10149bb0] mptsas_firmware_event_work+0xd70/0x1178 [mptsas]
Feb 18 18:15:11 debian6sparc kernel: [ 3241.901668] mptscsih: ioc1: attempting host reset! (sc=fffff8123b45fdc0)
Feb 18 18:15:11 debian6sparc kernel: [ 3241.990825] mptbase: ioc1: Initiating recovery
Feb 18 18:15:18 debian6sparc kernel: [ 3248.635333] iscsi_trgt: Logical Unit Reset (05) issued on tid:1 lun:0 by sid:4611687354162216961 (Function Complete)
Feb 18 18:15:25 debian6sparc kernel: [ 3255.969823] mptscsih: ioc1: host reset: SUCCESS (sc=fffff8123b45fdc0)
Feb 18 18:16:12 debian6sparc kernel: [ 3302.813647] mptscsih: ioc1: attempting task abort! (sc=fffff8123e3bea80)
Feb 18 18:16:12 debian6sparc kernel: [ 3302.902718] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 86 e0 00 02 00 00
Feb 18 18:16:12 debian6sparc kernel: [ 3303.001368] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123e3bea80) (sn=204463)
Feb 18 18:16:12 debian6sparc kernel: [ 3303.111846] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45f7a0)
Feb 18 18:16:12 debian6sparc kernel: [ 3303.200915] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 8c e0 00 02 00 00
Feb 18 18:16:12 debian6sparc kernel: [ 3303.299665] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45f7a0) (sn=204465)
Feb 18 18:16:12 debian6sparc kernel: [ 3303.410168] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45f340)
Feb 18 18:16:12 debian6sparc kernel: [ 3303.499229] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 90 e8 00 02 00 00
Feb 18 18:16:13 debian6sparc kernel: [ 3303.597886] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45f340) (sn=204468)
Feb 18 18:16:13 debian6sparc kernel: [ 3303.708410] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45e000)
Feb 18 18:16:13 debian6sparc kernel: [ 3303.797576] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 8a e0 00 00 08 00
Feb 18 18:16:13 debian6sparc kernel: [ 3303.896237] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45e000) (sn=204469)
Feb 18 18:16:13 debian6sparc kernel: [ 3304.006831] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45f880)
Feb 18 18:16:13 debian6sparc kernel: [ 3304.096033] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 90 e0 00 00 08 00
Feb 18 18:16:13 debian6sparc kernel: [ 3304.194802] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45f880) (sn=204472)
Feb 18 18:16:13 debian6sparc kernel: [ 3304.305525] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45e380)
Feb 18 18:16:13 debian6sparc kernel: [ 3304.394798] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 92 e8 00 00 38 00
Feb 18 18:16:13 debian6sparc kernel: [ 3304.493639] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45e380) (sn=204473)
Feb 18 18:16:13 debian6sparc kernel: [ 3304.604376] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45f5e0)
Feb 18 18:16:14 debian6sparc kernel: [ 3304.693640] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 93 20 00 00 e0 00
Feb 18 18:16:14 debian6sparc kernel: [ 3304.792383] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45f5e0) (sn=204475)
Feb 18 18:16:14 debian6sparc kernel: [ 3304.903075] mptscsih: ioc1: attempting task abort! (sc=fffff8123b45f0a0)
Feb 18 18:16:14 debian6sparc kernel: [ 3304.992345] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 94 00 00 00 e8 00
Feb 18 18:16:14 debian6sparc kernel: [ 3305.091108] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123b45f0a0) (sn=204477)
Feb 18 18:16:14 debian6sparc kernel: [ 3305.201862] mptscsih: ioc1: attempting task abort! (sc=fffff8123e3bf340)
Feb 18 18:16:14 debian6sparc kernel: [ 3305.291086] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2b ad c4 68 00 00 10 00
Feb 18 18:16:14 debian6sparc kernel: [ 3305.389835] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123e3bf340) (sn=204479)
Feb 18 18:16:14 debian6sparc kernel: [ 3305.500572] mptscsih: ioc1: attempting task abort! (sc=fffff8123e3bfb20)
Feb 18 18:16:14 debian6sparc kernel: [ 3305.589797] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2b ac 25 60 00 00 10 00
Feb 18 18:16:15 debian6sparc kernel: [ 3305.688534] mptscsih: ioc1: task abort: FAILED (rv=2003) (sc=fffff8123e3bfb20) (sn=204481)
Feb 18 18:16:15 debian6sparc kernel: [ 3305.799278] mptscsih: ioc1: attempting target reset! (sc=fffff8123e3bea80)
Feb 18 18:16:15 debian6sparc kernel: [ 3305.890803] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 86 e0 00 02 00 00
Feb 18 18:16:15 debian6sparc kernel: [ 3306.167439] mptscsih: ioc1: target reset: SUCCESS (sc=fffff8123e3bea80)
Feb 18 18:16:17 debian6sparc kernel: [ 3307.631119] mptscsih: ioc1: attempting bus reset! (sc=fffff8123e3bea80)
Feb 18 18:16:17 debian6sparc kernel: [ 3307.719197] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 86 e0 00 02 00 00
Feb 18 18:16:20 debian6sparc kernel: [ 3310.621629] Kernel unaligned access at TPC[10149bb0] mptsas_firmware_event_work+0xd70/0x1178 [mptsas]
Feb 18 18:16:20 debian6sparc kernel: [ 3310.744813] Kernel unaligned access at TPC[10149bd0] mptsas_firmware_event_work+0xd90/0x1178 [mptsas]
Feb 18 18:16:21 debian6sparc kernel: [ 3311.616236] mptscsih: ioc1: bus reset: SUCCESS (sc=fffff8123e3bea80)
Feb 18 18:16:26 debian6sparc kernel: [ 3316.633590] Kernel unaligned access at TPC[101491dc] mptsas_firmware_event_work+0x39c/0x1178 [mptsas]
Feb 18 18:16:26 debian6sparc kernel: [ 3316.756778] Kernel unaligned access at TPC[1014925c] mptsas_firmware_event_work+0x41c/0x1178 [mptsas]
Feb 18 18:16:26 debian6sparc kernel: [ 3316.879927] Kernel unaligned access at TPC[101492a4] mptsas_firmware_event_work+0x464/0x1178 [mptsas]
Feb 18 18:16:26 debian6sparc kernel: [ 3317.003026] Kernel unaligned access at TPC[101492ac] mptsas_firmware_event_work+0x46c/0x1178 [mptsas]
Feb 18 18:16:26 debian6sparc kernel: [ 3317.126112] end_device-0:1: mptsas: ioc1: removing sata device: fw_channel 0, fw_id 1, phy 1,sas_addr 0x1221000001000000
Feb 18 18:16:26 debian6sparc kernel: [ 3317.126120] phy-0:1: mptsas: ioc1: delete phy 1, phy-obj (0xfffff8123f100800)
Feb 18 18:16:26 debian6sparc kernel: [ 3317.126141] port-0:1: mptsas: ioc1: delete port 1, sas_addr (0x1221000001000000)
Feb 18 18:16:26 debian6sparc kernel: [ 3317.143397] sd 0:0:1:0: [sdb] Synchronizing SCSI cache
Feb 18 18:16:31 debian6sparc kernel: [ 3321.701616] mptscsih: ioc1: attempting host reset! (sc=fffff8123e3bea80)
Feb 18 18:16:31 debian6sparc kernel: [ 3321.790685] mptbase: ioc1: Initiating recovery
Feb 18 18:16:40 debian6sparc kernel: [ 3330.632553] iscsi_trgt: Logical Unit Reset (05) issued on tid:1 lun:0 by sid:4611687354162216961 (Function Complete)
Feb 18 18:16:45 debian6sparc kernel: [ 3335.769513] mptscsih: ioc1: host reset: SUCCESS (sc=fffff8123e3bea80)
Feb 18 18:16:55 debian6sparc kernel: [ 3345.858477] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:55 debian6sparc kernel: [ 3345.947541] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:55 debian6sparc kernel: [ 3346.036624] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:55 debian6sparc kernel: [ 3346.125624] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:55 debian6sparc kernel: [ 3346.214608] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:55 debian6sparc kernel: [ 3346.303583] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:55 debian6sparc kernel: [ 3346.392562] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:55 debian6sparc kernel: [ 3346.481554] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:55 debian6sparc kernel: [ 3346.570541] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:55 debian6sparc kernel: [ 3346.659448] sd 0:0:1:0: Device offlined - not ready after error recovery
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748510] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748522] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748530] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 94 00 00 00 e8 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748545] end_request: I/O error, dev sdb, sector 762156032
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748557] raid1: Disk failure on sdb, disabling device.
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748559] raid1: Operation continuing on 1 devices.
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748632] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748636] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748641] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 93 20 00 00 e0 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748652] end_request: I/O error, dev sdb, sector 762155808
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748682] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748685] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748691] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 92 e8 00 00 38 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748701] end_request: I/O error, dev sdb, sector 762155752
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748715] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748719] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748724] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 90 e0 00 00 08 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748734] end_request: I/O error, dev sdb, sector 762155232
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748745] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748749] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748754] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 8a e0 00 00 08 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748764] end_request: I/O error, dev sdb, sector 762153696
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748783] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748787] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748792] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 90 e8 00 02 00 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748802] end_request: I/O error, dev sdb, sector 762155240
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748865] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748868] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748874] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 8c e0 00 02 00 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.748884] end_request: I/O error, dev sdb, sector 762154208
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812221] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812225] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812232] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2b ac 25 60 00 00 10 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812245] end_request: I/O error, dev sdb, sector 732702048
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812274] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812278] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812283] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2b ad c4 68 00 00 10 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812293] end_request: I/O error, dev sdb, sector 732808296
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812313] sd 0:0:1:0: [sdb] Unhandled error code
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812316] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812322] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2d 6d 86 e0 00 02 00 00
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812332] end_request: I/O error, dev sdb, sector 762152672
Feb 18 18:16:59 debian6sparc kernel: [ 3346.812394] end_request: I/O error, dev sdb, sector 1465661226
Feb 18 18:16:59 debian6sparc kernel: [ 3346.813578] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

[jmar83]

Noch ein paar Links zum Thema:

- http://codeverge.com/opensuse.org.help. ... ng/1840380
- https://blog.fastmail.com/2010/08/18/sc ... -timeouts/
- https://bugzilla.redhat.com/show_bug.cgi?id=653706

[NAB]

Vor allem finde ich es schräg, dass wegen ein paar defekten Sektoren letztendlich die ganze Festplatte (/dev/sdb) vom Controller getrennt wird. Macht irgendwie auch keinen Sin...?

Naja ... die Festplatte hält sich beide Ohren zu und tut, als würde sie den Controller nicht mehr hören ... was soll die dann noch in einem Raid-Array?

Außerdem wird sie nicht vom Controller getrennt. Sie reagiert nicht mehr, der Controller resettet den gesamten Bus, danach ist sie anscheinend wieder da ... der Kernel erklärt sie bei 18:16:55 für "not ready after error recovery". Eigentlich würde ich da noch eine Timeout-Meldung erwarten. Bei 18:16:59 scheint sie wieder zu antworten, schmeißt gleich den nächsten Schreibfehler, dann schmeißt der Kernel sie aus dem Array. Es ist vorallem die Platte, die nicht mehr mit dem Controller und daher mit dem Kernel redet.

Wann tritt das denn auf? Direkt bei jedem Booten? Zufällig nach ner Stunde Nichtstun? Oder genau dann, wenn du große Datenmengen auf das Array schreibst?

Und seit wann tritt das auf? Seit heute? Seit 5 Jahren? Seit dem letzten Kernel-Update (Gibt's da überhaupt noch eins?)?

Die Western Digital Green hatten doch so einen nervigen Stromsparmechanismus, der die Köpfe dauernd parkt ... hast du den ausgeschaltet?

Und gibt's ne neuere Firmware für die Festplatten?

Ob's wirklich defekte Sektoren sind, müsste dir smartctl verraten. Kommst du an die Werte ran?

Interessant ist die Zeitspanne. Bei 3220.813972 versucht er einen "attempting task abort!" und 200 ms später weiß er schon, dass der "task abort" fehlgeschlagen ist ... das sieht nicht nach einem Timeout aus. Das sieht erst mal so aus, als ob die Festplatte sofort eine Fehlermeldung zurückgibt. Andererseits wird sowas hier:
https://bugzilla.redhat.com/show_bug.cgi?id=483424
als Treiberproblem bezeichnet. Dort hilft es einigen Leuten, "smartd" zu deaktivieren.

[jmar83]

Vielen Dank für die Tipps!!

Es ist folgendermassen: Die beiden Festplatten hatte ich vorher in einem anderen Rechner, dort lief alles problemlos und es gab keine solchen Fehlermeldungen - nie. Der Fehler ist aufgetreten, als ich grössere Datenmengen geschrieben habe. Der Rechner "debian6sparc" fungiert als ISCSI-Target mit SW-RAID1, welches für Backups von virtuellen Maschinen verwendet wird. Und ja, der Fehler ist während dem Sichern entstanden!

Debian Wheezy (für SPARC) kann ich leider nicht verwenden, weil dabei eine scheinbar eine "Race Condition" beim Zugriff auf die Boot-Platten entsteht. (Nur bei der Sun Blade 2500 Silver - bei der Ultra 45 habe ich das Problem nicht.) Bei Lenny oder Squeeze ist dies nicht der Fall, deshalb verwende ich halt Squeeze. (Eigentlich ist mir die alte Distri ziemlich egal, und sollte für das ISCSI-Target mit SW-RAID1 doch kein Problem sein?)

Repository-Quellen für "squeeze-backports" (um dem Kernel zu aktualisieren) konnte ich bisher nirgendwo finden, exisiteren die überhaupt noch?

Den Festplatten habe ich die neuste Firmware verpasst (nicht heute, sondern damals bevor ich sie im ersten Server (Fileserver) verwendet habe. Ca. Mitte 2015) und den Stromsparmechanismus habe ich ebenfalls ausgeschaltet, mit einem Tool XYZ.exe welches ich unter DOS (glaube "Free DOS) mit einem bestimmten Parameter ausgeführt habe.

An die SMART-Werte komme ich auch nicht wirklich ran, interessanterweise erkennt Smartctl die Platten eh nur wenn man die Parameter "-d scsi" (und NICHT "-d sat"!!) sowie "-t permissive" verwendet. Und auch dann ist es scheinbar nicht in der Lage die SMART-Werte richtig auszugeben. Was ich aber in dieser Situation erhalte, ist die korrekte Modellbezeichnung der Festplatte...

Dass die SATA-Kabel nicht richtig sitzen, oder diese zu lang sind (der LSI-Controller sowie die Platten sind meines Wissens für SATA-II ausgelegt) glaube ich ehrlich gesagt weniger...

Wäre es evtl. eine Idee, den RAID-Verbund aufzulösen, dann die verdächtige Festplatte per "fsck" (oder sonst einem Tool) auf defekte Sektoren zu prüfen, diese ggf., falls vorhanden, als defekt zu markieren/auszuschliessen und dann den RAID-Verbund wieder neu zusammenzusetzen? Das ist, was ich mir als ersten Schritt überlegt habe...

[NAB]

Dass die SATA-Kabel nicht richtig sitzen, oder diese zu lang sind (der LSI-Controller sowie die Platten sind meines Wissens für SATA-II ausgelegt) glaube ich ehrlich gesagt weniger...

Naja ... Sata hat ziemlich besch***ene Kontakte ... Kabel mal abziehen und wieder dranstecken kann nicht schaden. Ruhig mehrmals um eventuellen Belag von den Kontakten zu reiben.

Wäre es evtl. eine Idee, den RAID-Verbund aufzulösen, dann die verdächtige Festplatte per "fsck" (oder sonst einem Tool) auf defekte Sektoren zu prüfen,

Welche Ausfallzeiten darf die Kiste denn haben? Eigentlich musst du den Raidverbund gar nicht auflösen ... die Festplatte muss nur raus und wo dran gehängt werden, wo du die Smart-Werte auslesen kannst. Dann könntest du sie noch mal mit "badblocks" komplett mit ihrem eigenen Inhalt vollschreiben - das zieht sich allerdings Stunden. Wenn das keine Fehler gibt, setzt du sie quasi unverändert wieder ein.

Ich glaube nicht, dass es an defekten Sektoren auf der Platte liegt. Das sind Schreiboperationen, die da bei dir schieflaufen. Wenn die Platte beim Schreiben auf einen defekten Sektor stößt, schnappt sie sich einen Reservesektor und du erfährst davon gar nichts. Da müsste die Platte schon sämtliche Reservesektoren aufgebraucht haben und dürfte wesentlich mehr Probleme machen.

Apropos Stromsparmechanismus ... die WD Green haben ja zwei. Diesen komischen idle3 Timer, den du vermutlich ausgeschaltet hast, und das normale APM. Kannst du das mit
hdparm -B 254
ausschalten? (Oder 255, wenn's geht)

diese ggf., falls vorhanden, als defekt zu markieren/auszuschliessen und dann den RAID-Verbund wieder neu zusammenzusetzen?

Vergisses. Wenn wirklich defekte Sektoren schuld sind, kommt die in den Müll.

Da sind doch VMs im Spiel? Sind dir die zahlreichen Treffer bei Google aufgefallen, wo vmware im Spiel war? Die habe ich allerdings nicht verstanden und hielt sie für irrelevant.

Probiere mal, "smartmontools" zu deinstallieren. Ändert das was?

[jmar83]

"Welche Ausfallzeiten darf die Kiste denn haben?"

Bin noch in der Testphase, deshalb auch die Sache mit der "Reparatur" der möglicherweise (halb)defekten SATA-Platte... falls die Platte dann wirklich Probleme hat, dann werde ich diese im Produktivbetrieb natürlich austauschen. Vorerst möchte ich einfach versuchen, Fehler einzugrenzen und auszuschliessen...

"Diesen komischen idle3 Timer, den du vermutlich ausgeschaltet hast"

Ja, exakt das war's. Die APM-Sache war mir aber nicht bekannt bis jetzt, viele Dank!!

"Da sind doch VMs im Spiel?"

Ja, ich verwende aber kein vmware, sondern "phpVirtualBox"... das läuft natürlich aber nicht auf der SPARC-Maschine, diese fungiert wie gesagt nur als ISCSI-Target, wo Backups der virt. Maschinen abgelegt werden. "phpVirtualBox" läuft bei mir z. Zt. auf Windows 7 (man möge mir verzeihen hier im Debian-Forum - die Treiberunterstützung für den RAID-Controller war ein Problem), wo ein Laufwerk I: mit dem "M$ ISCSI Initiator" nach 192.168.0.33 gemappt wurde.

Unter phpVirtualBox kann ich dann "Appliance exportieren" anwählen, und unter I:\meine_vm_2018_02_21.ovX oder so ein Backup anlegen. (Eigentlich relativ simpel) Und genau während dem "Export" einer rund 14GB grossen Linux-VM ist das Problem, welches ich beschreiben habe, aufgetreten...

Um anderswo die Platten zu testen, hätte ich z. Zt. gerade nur einen USB-to-SATA-Adapter, aber damit kann man, soviel ich weiss, keine SMART-Werte auslesen?

Eine weitere Mögichkeit wäre, das "HDD Low Level Format Tool" (http://hddguru.com/software/HDD-LLF-Low ... rmat-Tool/) per USB unter Windows mal drüberlaufen zu lassen. Wenn das den Vorgang abschliessen kann, dann ist die Platte meistens noch einigermassen i.O, na ja..

Sonst evtl. mal den Controller durch irgend einen anderen Anderen ersetzen, muss ja nix spezielles sein bei SW-RAID1, brauche einfach einen für den "normalen" PCI- (günstig) oder auch PCI-X-Bus (einiges teurer und weniger verbreitet, also besser nur PCI) plus SATA-II-Unterstützung...

"Probiere mal, "smartmontools" zu deinstallieren. Ändert das was?"

Ich denke nicht dass das was ändert, kann es aber zumindest versuchen damit... ist das die "smartd"-Sache von deinem ersten Beitrag? Sonst könnte ich einfach den Dienst ausser Kraft setzen beim starten, dass dieser nicht mehr automatisch startet..

[jmar83]

Von wegen die WD Green "WDC WD15EARX-00P" hätten nur SATA-II... muss mich korrigieren, das ist falsch: https://www.heise.de/preisvergleich/wes ... 29486.html

Wenn ich mich richtig erinnere, dann hat meine andere Sun-Kiste, die "Ultra45", ebenfalls einen SATA-II-Controllerchip (also gleicher Standard wie beim LSI SAS3041X-L in der Blade 2500 Silver, meinem ISCSI-Target)

Nun ist mir schon früher aufgefallen, dass meine Ultra45 grundsätzlich immer Probleme hatte mit SATA-III-Platten an ihrem LSI-SATA-II-Controller... einmal mit einer SSD, das andere Mal mit einer "Western Digital Purple", welche ich dann durch eine "Seagate Video" (https://www.toppreise.ch/prod_171246.html) ersetzt habe. Und dann gings problemlos!! (Ich habe diese Video-Platten absichtlich gekauft, da diese relativ zuverlässig sein sollen und nicht allzu hochgezüchtet sind mit < 7200 RPM)

Des weiteren mag ich mich auch an solch komische Meldungen erinnern, defekte Sektoren obwohl ich die Datenträger damals neu gekauft und das erste Mal in Betrieb genommen habe..

Mal schauen, ob ich an den beiden WD Green-Platten irgendnen Jumper setzen kann, um damit SATA-II vorzutäuschen.

-> Eigentlich sollte es ja automatisch kompatibel sein, und eine SATA-III-Platte sollte an einem SATA-II-Controller dann halt mir nur 3.0GBit/s laufen. Das Ganze ist allerdings eher theoretisch. Und vor allem ein Controller von LSI (=eigentlich keine Consumer-Ware!) sollte das im Prinzip automatisch regeln können.

[jmar83]

...und im vorherigen Server wo die Platten verwendet wurden, da war ganz sicher auf kein SATA-III-Controller drin: https://www.cnet.com/products/koutech-p ... a-133-pci/ (finde gerade keine Details, die Firma scheint es nicht mehr zu geben: http://www.kouwell.com.tw/ )

Eigentlich ein ziemlich billiges Teil, aber es lief immer problemlos - die hat auch keine Probleme gemacht mit SATA-X vs. SATA-Y... also evtl. doch ein LSI-spezifisches Problem...?

[NAB]

Ja, ich verwende aber kein vmware, sondern "phpVirtualBox".

Wenn ich das recht verstehe, greift phpVirtualBox doch von "außen" auf die VMs zu, es hat also nichts mit VMs zu tun sondern das native Win7 sichert einfach fette Dateien über ISCSI.

Man könnte natürlich mal auf Samba umstellen ... wär aber schade.

Um anderswo die Platten zu testen, hätte ich z. Zt. gerade nur einen USB-to-SATA-Adapter, aber damit kann man, soviel ich weiss, keine SMART-Werte auslesen?

Das kann man so pauschal nicht sagen. Es kommt immer darauf an, welche SATA-Kommandos der Sata-USB-Konverter zu unterstützen beliebt. Dazu kommt, dass einige USB-Sata-Adapter sich ne falsche Blockgröße zurechtlügen. Eine olle Kiste mit echtem Sata-Anschluss wäre problemfreier.

Eine weitere Mögichkeit wäre, das "HDD Low Level Format Tool"

Das sieht nach Bauernfängerei aus ... aber bei 0 Euro kann man nicht viel falsch machen.

Ich denke nicht dass das was ändert, kann es aber zumindest versuchen damit... ist das die "smartd"-Sache von deinem ersten Beitrag? Sonst könnte ich einfach den Dienst ausser Kraft setzen beim starten, dass dieser nicht mehr automatisch startet..

Ich hatte damals (ich glaube, es war Wheezy) üblen Ärger mit "smart". Ich hab's nicht so ganz verstanden, aber über Udev-Regeln wird udisks angewiesen, regelmäßig Smart-Kommandos an die Platten zu schicken, auch ganz ohne smartd. Aufgrund von Firmware-Bugs kann das einige Platten komplett aus den Puschen hauen, wenn sie gerade unter hoher Last stehen oder im Standby sind. Entweder recherchierst du das gründlich, oder du deinstallierst einfach "smartmontools".

Des weiteren mag ich mich auch an solch komische Meldungen erinnern, defekte Sektoren obwohl ich die Datenträger damals neu gekauft und das erste Mal in Betrieb genommen habe..

Sicherlich kann man sich auch defekte Neuware aus dem Laden holen ... tut hier aber nichts zur Sache.

also evtl. doch ein LSI-spezifisches Problem...?

Die ganzen Grübeleien bringen dich doch nicht weiter. Der LSI-Controller ist definitiv nicht pauschal inkompatibel zu Sata3. Aber es gibt immer wieder Platten-Firmware, die mit der LSI-Firmware nicht klarkommt. Und dann geht das Schuldgeschiebe los, wer da was versaut hat. Nun dürften sowohl Controller als auch Platte längst aus dem Support sein, von der Seite hast du also keine Hilfe zu erwarten.

Bevor du einen neuen Controller kaufst, solltest du erst gucken, ob's für den alten noch ne neuere Firmware gibt. Wobei ich nicht weiß, wie du die mit einer Sparc aufspielen solltest.

Und auch wenn du deine Sparc ganz doll lieb hast ... mit nem neuen Intel Celeron hast du gleich 6 Sata-Anschlüsse gratis und kannst nach Belieben billige 15-Euro-Controller stecken. Und du darfst sogar mal neue Software benutzen und nen Bugreport abschicken;)

[jmar83]

Vielen Dank für dein kompetentes Feedback!!

Wenn ich das recht verstehe, greift phpVirtualBox doch von "außen" auf die VMs zu, es hat also nichts mit VMs zu tun sondern das native Win7 sichert einfach fette Dateien über ISCSI.

Exakt. Bei ISCSI sehe ich den Vorteil, dass ich mich nicht um Berechtigungen kümmern muss. Ausser um das generelle Login für das ISCSI-Target. Die virt. ISCSI-Datenträger verhalten sich halt wie ne Festplatte, mit Dateisystem und allem drum und dran...

Das kann man so pauschal nicht sagen. Es kommt immer darauf an, welche SATA-Kommandos der Sata-USB-Konverter zu unterstützen beliebt. Dazu kommt, dass einige USB-Sata-Adapter sich ne falsche Blockgröße zurechtlügen. Eine olle Kiste mit echtem Sata-Anschluss wäre problemfreier.

Hätte noch ein paar solche USB-to-SATA-Teiler, müsste diese mal einzeln testen...

Das sieht nach Bauernfängerei aus ... aber bei 0 Euro kann man nicht viel falsch machen.

Klar, ist nicht wirklich ein "low level format". Wipen trifft eher zu. Die kostenpflichtige Version ist ein wenig schneller, aber wenn die Platte über USB angeschlossen ist, ist es meist eh nicht allzu schnell.

Ich hatte damals (ich glaube, es war Wheezy) üblen Ärger mit "smart". Ich hab's nicht so ganz verstanden, aber über Udev-Regeln wird udisks angewiesen, regelmäßig Smart-Kommandos an die Platten zu schicken, auch ganz ohne smartd. Aufgrund von Firmware-Bugs kann das einige Platten komplett aus den Puschen hauen, wenn sie gerade unter hoher Last stehen oder im Standby sind. Entweder recherchierst du das gründlich, oder du deinstallierst einfach "smartmontools".

OK - wenn schon "deinstallieren", nicht "deaktivieren"!!

Bevor du einen neuen Controller kaufst, solltest du erst gucken, ob's für den alten noch ne neuere Firmware gibt. Wobei ich nicht weiß, wie du die mit einer Sparc aufspielen solltest.

Ja, unter Linux wird's evtl. kein Tool geben um die Karte zu flashen. Wenn schon unter Solaris. Unter Windows sowieso.
Nachtrag: Doch, gibt es! Halt einfach vorkompiliertes, proprietäres Zeugs welches nur für bestimmte Distris (z.b. RedHat) in einer bestimmten Version und für die x64/x64-Plattform verfügbar ist.

Und auch wenn du deine Sparc ganz doll lieb hast ... mit nem neuen Intel Celeron hast du gleich 6 Sata-Anschlüsse gratis und kannst nach Belieben billige 15-Euro-Controller stecken. Und du darfst sogar mal neue Software benutzen und nen Bugreport abschicken;)

Hehe

[jmar83]

Nachtrag:

"und kannst nach Belieben billige 15-Euro-Controller stecken."

...SPARC-Linux macht aber auch so ziemlich einiges mit, was Treiber für nicht-Sun-Hardware betrifft. Unter Debian 7 (mit backports-Kernel) habe ich sogar schon x86-Grafikkarten von Nvidia zum laufen gebracht.

[jmar83]

Also die Meldung mit den defekten Sektoren ist nicht mehr aufgetreten, nachdem ich den Jumper (2. von links) für den SATA-II-Modus der SATA-III-Platte "Western Digital Green 1.5TB" gesetzt habe.

Zwar hat es noch Warnungen ausgeben, inkl. ein paar Zeilen "Kernel unaligned access at TPC[10125bb0] mptsas_firmware_event_work+0xd70/0x1178 [mptsas]", jedoch waren diese Probleme nicht in der Lange, das RAID-Array auf "degraded", oder das System in einen unbrauchbaren Zustand zu versetzen.

Auch ist mir aufgefallen, dass mit den gesetzten Jumpern die Datenrate beim Benchmark nicht mehr ständig auf und ab geht. Ich habe einfach das dem ISCSI-Target gemappte Windows-Laufwerk I:/ mit dem "ATTO Disk Benchmark" stressgetestet und dabei ca. 20-30GB an Daten transferriert: http://www.chip.de/downloads/ATTO-Disk- ... 02004.html - dies noch während dem re-sync der RAID-Datenträger, der letztendlich erfolgreich verlief. Die Meldungen kommen aber immer dann, wenn die Sache stark beansprucht wird. Aber scheinbar werden die Probleme irgendwie "abgefangen", na ja..(?)

Bezüglich smartmontools muss ich mich korrigeren, es ist nicht so dass gar nix angezeigt wird. Mit dem Befehl "smartctl --all /dev/sdX -d scsi -T permissive" erhalte ich das korrekte Datenträger-Modell UND die Meldung "Smart Status OK". (oder ähnlich) Was aber schräg ist, ist dass ich "-d scsi" angeben muss - wenn schon "-d sat" würde ich meinen!

Hier wäre noch die Meldungen: http://freetexthost.com/1no1m21n33

"mdadm: sending ioctl 20001261 to a partition!" kommt dann zum Vorschein, wenn ich "mdadm --detail /dev/md0" (resp. "mdadm --detail /dev/md/0") eingebe, diese Meldung ist also gar kein Problem!

Auf anderen Seiten habe ich gelesen, dass diese (die aktuellen) Log-Meldungen nicht weiter tragisch sind, wenn man davon genervt sei könne man einfach das Logging-Level herunterschrauben. Mache ich aber nicht, sicher nicht!!