From: "Raoul Bhatia [IPAX]" <r.bhatia@ipax.at>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: Add more debug output to sas_scsi_recover_host or sas_eh_handle_sas_errors
Date: Mon, 07 Apr 2008 17:16:10 +0200 [thread overview]
Message-ID: <47FA3ABA.7080306@ipax.at> (raw)
In-Reply-To: <1207578974.3838.4.camel@localhost.localdomain>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hello james,
James Bottomley wrote:
> On Mon, 2008-04-07 at 16:22 +0200, Raoul Bhatia [IPAX] wrote:
>> is there any sens in adding more debug output to sas_scsi_recover_host
>> or sas_eh_handle_sas_errors?
>>
>> e.g. put out SAS_ADDR(task->dev->sas_addr) so that we know whether
>> the error is always occuring on one phy/port/etc. ?
>>
>> the reason for doing this is basically my problems with the aic94xx
>> driver, outlined in http://marc.info/?t=120603924200004.
>
> Probably not really ... it looks like a standard protocol error thrown
> by a Seagate driver, as I said.
the only information from seagate was: you have the latest firmware,
please verify with a different controller.
unfortunatly, until now i haven't been able to test with another disk
and/or controller.
> Did reducing the queue depth and increasing the retries have any
> mitigating effect at all?
mhm, i cannot say for sure as i played a lot with different sequencer
version (which i directly got from adaptec). but as far as i can tell
it did not have a big impact and the errors usually start to appear
within 3-6 minutes.
during my last test (second test with kernel 2.6.20-rc8, default queue
depth) it took 22 minutes, but this happens very seldom.
> The correct fix, which is to handle the REQ_TASK_ABORT on the fly is
> still in the works.
ok, do you have any eta for this? what about luben's comment in the
previous thread?
someone from adaptec took a look into this issue. i am currently asking
whether i am allowed forward the conversation to you (or any other
kernel developer who is interested).
the discussion was basically about a pci-bus vs sas-bus (realtime-bus)
issue.
cheers,
raoul
- --
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at
Technischer Leiter
IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at
Barawitzkagasse 10/2/2/11 email. office@ipax.at
1190 Wien tel. +43 1 3670030
FN 277995t HG Wien fax. +43 1 3670030 15
____________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH+jq6EaTXmVQ/cvsRAnKUAJ9ONuV1Lak/fERAUKhg5fthiAOZ3gCfWsnN
huvPOsvdov+zKVTyj5jj7pc=
=l6F2
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2008-04-07 15:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-07 14:22 Add more debug output to sas_scsi_recover_host or sas_eh_handle_sas_errors Raoul Bhatia [IPAX]
2008-04-07 14:36 ` James Bottomley
2008-04-07 15:16 ` Raoul Bhatia [IPAX] [this message]
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=47FA3ABA.7080306@ipax.at \
--to=r.bhatia@ipax.at \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-scsi@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.