From: David Liontooth <lionteeth@cogweb.net>
To: LKML <linux-kernel@vger.kernel.org>, Nick Cheng <support@areca.com.tw>
Subject: arcmsr: cascading failures
Date: Tue, 12 Jun 2012 08:22:33 -0700 [thread overview]
Message-ID: <4FD75EB9.4090503@cogweb.net> (raw)
On a system with Areca 1680 cards, the failure of a single drive leads
to a cascading failure of the other good drives:
The troubles starts with an arcmsr abort of the bad drive:
Jun 11 07:20:42 cartago kernel: arcmsr7: abort device command of scsi id
= 1 lun = 3
Jun 11 07:20:42 cartago kernel: arcmsr: executing bus reset
eh.....num_resets = 1, num_aborts = 16
Jun 11 07:20:42 cartago kernel: arcmsr7: executing hw bus reset .....
Jun 11 07:20:55 cartago kernel: arcmsr7: waiting for hw bus reset
return, retry=0
Jun 11 07:23:05 cartago kernel: arcmsr7: waiting for hw bus reset
return, retry=13
Jun 11 07:23:05 cartago kernel: arcmsr7: waiting for hw bus reset
return, RETRY TERMINATED!!
Jun 11 07:23:05 cartago kernel: sd 7:0:1:3: Device offlined - not ready
after error recovery
Jun 11 07:23:05 cartago kernel: sd 7:0:1:3: [sds] Unhandled error code
Jun 11 07:23:05 cartago kernel: sd 7:0:1:3: [sds] Result:
hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
Jun 11 07:23:05 cartago kernel: sd 7:0:1:3: [sds] CDB: Write(10): 2a 00
29 1d a5 8f 00 00 10 00
Jun 11 07:23:05 cartago kernel: end_request: I/O error, dev sds, sector
689808783
Jun 11 07:23:05 cartago kernel: sd 7:0:1:3: rejecting I/O to offline device
Jun 11 07:23:05 cartago kernel: XFS (sds1): xfs_do_force_shutdown(0x2)
called from line 891 of file fs/xfs/xfs_log.c.
Jun 11 07:23:05 cartago kernel: XFS (sds1): Log I/O Error Detected.
Shutting down filesystem
Jun 11 07:23:05 cartago kernel: XFS (sds1): Please umount the filesystem
and rectify the problem(s)
Jun 11 07:23:35 cartago kernel: XFS (sds1): xfs_log_force: error 5 returned.
So far, so good -- the drive has failed and been taken offline. The
kernel handles this fine, though it would be nice to have a way to tell
XFS to stop trying to shut down the file system -- it's a lost cause.
Now the trouble starts: arcmsr starts aborting device commands to other
drives:
Jun 11 07:23:36 cartago kernel: arcmsr7: abort device command of scsi id
= 3 lun = 1
Jun 11 07:23:40 cartago kernel: arcmsr7: abort device command of scsi id
= 3 lun = 1
Jun 11 07:23:44 cartago kernel: arcmsr7: abort device command of scsi id
= 1 lun = 5
Jun 11 07:23:48 cartago kernel: arcmsr: executing bus reset
eh.....num_resets = 2, num_aborts = 19
Jun 11 07:23:48 cartago kernel: arcmsr: there is an bus reset eh
proceeding.......
Udev notices a drive is missing and starts removing disk references --
this is a good working drive:
Jun 11 07:27:29 cartago udevd[17693]: removing watch on '/dev/sde1'
Jun 11 07:27:29 cartago udevd[17693]: no reference left, remove
'/dev/disk/by-id/scsi-2001b4d2070476002-part1'
Jun 11 07:27:29 cartago udevd[17693]: no reference left, remove
'/dev/disk/by-label/2007_05'
Jun 11 07:27:29 cartago udevd[17693]: no reference left, remove
'/dev/disk/by-path/pci-0000:06:00.0-scsi-0:0:1:2-part1'
Jun 11 07:27:29 cartago udevd[17693]: no reference left, remove
'/dev/disk/by-uuid/34c6f15b-427a-4414-8840-7e227efae0e3'
Jun 11 07:27:29 cartago udevd[17693]: device node '/dev/sde1' has sticky
bit set, skip removal
Jun 11 07:27:29 cartago udevd[17693]: passed -1 bytes to netlink monitor
0x2611130
Jun 11 07:27:29 cartago udevd[17693]: seq 2126 processed with 0
Jun 11 07:27:29 cartago udevd[1427]: seq 2126 done with 0
XFS gets busy trying to shut down a good drive:
Jun 11 07:27:29 cartago kernel: XFS (sde1): xfs_do_force_shutdown(0x1)
called from line 1052 of file fs/xfs/linux-2.6/xfs_b$
Jun 11 07:27:29 cartago kernel: XFS (sde1): I/O Error Detected. Shutting
down filesystem
Jun 11 07:27:29 cartago kernel: XFS (sde1): Please umount the filesystem
and rectify the problem(s)
arcmsr keeps trying to "recover" and spreads mayhem to all the other
drives -- there's around 20 of them:
Jun 11 07:28:12 cartago kernel: arcmsr7: abort device command of scsi id
= 3 lun = 1
Jun 11 07:28:16 cartago kernel: arcmsr: executing bus reset
eh.....num_resets = 4, num_aborts = 21
Jun 11 07:28:26 cartago kernel: sd 7:0:1:5: Device offlined - not ready
after error recovery
Jun 11 07:28:26 cartago kernel: sd 7:0:3:1: Device offlined - not ready
after error recovery
Jun 11 07:28:26 cartago kernel: sd 7:0:3:1: Device offlined - not ready
after error recovery
Jun 11 07:28:26 cartago kernel: sd 7:0:1:5: [sdg] Unhandled error code
Gory details available on request. The machine now will now not halt and
requires a very expensive hard reset.
Is there some way to keep this from happening? A failed drive should be
isolated and dropped; this is losing the whole army to save one dead man.
Cheers,
David
# modinfo arcmsr
filename: /lib/modules/3.0.26/kernel/drivers/scsi/arcmsr/arcmsr.ko
version: Driver Version 1.20.00.15 2010/08/05
license: Dual BSD/GPL
description: ARECA (ARC11xx/12xx/16xx/1880) SATA/SAS RAID Host Bus
Adapter
author: Nick Cheng <support@areca.com.tw>
srcversion: F9D834593FE182DC013DBD0
# uname -a
Linux cartago 3.0.26 #1 SMP Sat Apr 14 15:04:35 PDT 2012 x86_64 GNU/Linux
reply other threads:[~2012-06-12 15:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FD75EB9.4090503@cogweb.net \
--to=lionteeth@cogweb.net \
--cc=linux-kernel@vger.kernel.org \
--cc=support@areca.com.tw \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox