From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Raoul Bhatia [IPAX]" <r.bhatia@ipax.at>
Cc: linux-scsi@vger.kernel.org
Subject: Re: aic94xx driver woes continued
Date: Thu, 20 Mar 2008 14:01:54 -0500 [thread overview]
Message-ID: <1206039714.3038.40.camel@localhost.localdomain> (raw)
In-Reply-To: <47E2B044.70705@ipax.at>
On Thu, 2008-03-20 at 19:43 +0100, Raoul Bhatia [IPAX] wrote:
> hi there,
>
> we find ourself in the same situation as posted on this list before [1]
>
> first of all, the hardware details:
>
> System:
> > Tyan Transport GT24-B3992
> > Motherboard: Tyan B3992
> > Dual Opteron 2218 (Dual-Core)
> > 8GB RAM
>
> SAS Controller:
> > product: AIC-9410W SAS (Razor ASIC RAID)=20
> > vendor: Adaptec
>
> > controler-bios: BIOS present (1,1), 1820
> > controler-sequencer: Firmware version 1.1 (V30)
>
> Harddisks:
> > 4x Seagate Cheetah 15K.5 ST373455SS
>
> There is a Software Raid10 on top of those 4 disks.
> > vanilla kernel 2.6.25-rc5
> > Debian GNU/Linux 4.0, AMD64
>
>
> coming to the problem description itself:
>
> the server is booted, the raid is working as intended
> > md4 : active raid10 sdb9[1] sda9[0] sdd9[3] sdc9[2]
> > 100181120 blocks 64K chunks 2 near-copies [4/4] [UUUU]
>
> now we mount /dev/md4 to /home, cd there and run an io intensive task
> such as stress, tiobench (or even raid-reinit is enough)
> > stress --hdd 20 --hdd-bytes 2gb --hdd-noclean
>
> soon we see:
> > aic94xx: escb_tasklet_complete: REQ_TASK_ABORT, reason=0x6
> > sas: command 0xffff81023fb2ca80, task 0xffff81023ea7ab40, timed out:
> EH_NOT_HANDLED
> > ...
> > sas: Enter sas_scsi_recover_host
> > sas: trying to find task 0xffff81023ea7ab40
> > sas: sas_scsi_find_task: aborting task 0xffff81023ea7ab40
> > ...
> > sas: --- Exit sas_scsi_recover_host
>
> please se the attached logfile.
This is all normal. Seagate drives are known for throwing protocol
errors under stress at certain revs of firmware. That's what
REQ_TASK_ABORT, reason=0x6 is.
Your logs indicate that the recovery occurred correctly (as in all tasks
were eventually retried), so it doesn't show an actual problem.
> sometimes even a disk is kicked out of the raid configuration.
This would be abnormal, if you have a log of this, could you post it. I
assume it was because of I/O errors?
James
next prev parent reply other threads:[~2008-03-20 19:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-20 18:43 aic94xx driver woes continued Raoul Bhatia [IPAX]
2008-03-20 19:01 ` James Bottomley [this message]
2008-03-20 19:14 ` Raoul Bhatia [IPAX]
2008-03-29 22:36 ` Luben Tuikov
2008-03-20 19:15 ` Raoul Bhatia [IPAX]
2008-03-20 19:18 ` Raoul Bhatia [IPAX]
2008-03-20 19:57 ` James Bottomley
2008-03-20 20:21 ` Raoul Bhatia [IPAX]
2008-03-20 21:08 ` Raoul Bhatia [IPAX]
2008-03-20 21:17 ` James Bottomley
2008-03-20 22:18 ` Alexis Bruemmer
2008-03-26 14:34 ` Raoul Bhatia [IPAX]
2008-03-29 22:39 ` Luben Tuikov
2008-03-29 22:33 ` Luben Tuikov
2008-03-31 20:23 ` Raoul Bhatia [IPAX]
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=1206039714.3038.40.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=linux-scsi@vger.kernel.org \
--cc=r.bhatia@ipax.at \
/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