* Add more debug output to sas_scsi_recover_host or sas_eh_handle_sas_errors
@ 2008-04-07 14:22 Raoul Bhatia [IPAX]
2008-04-07 14:36 ` James Bottomley
0 siblings, 1 reply; 3+ messages in thread
From: Raoul Bhatia [IPAX] @ 2008-04-07 14:22 UTC (permalink / raw)
To: linux-scsi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
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.
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+i4bEaTXmVQ/cvsRAtLnAKCFPvCanPoq6+Fum4qqU3oR6/HXYACfQTBk
f4zXUKWVFOtTrLNxOdMNFzI=
=np9J
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Add more debug output to sas_scsi_recover_host or sas_eh_handle_sas_errors
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]
0 siblings, 1 reply; 3+ messages in thread
From: James Bottomley @ 2008-04-07 14:36 UTC (permalink / raw)
To: Raoul Bhatia [IPAX]; +Cc: linux-scsi
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.
Did reducing the queue depth and increasing the retries have any
mitigating effect at all?
The correct fix, which is to handle the REQ_TASK_ABORT on the fly is
still in the works.
James
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Add more debug output to sas_scsi_recover_host or sas_eh_handle_sas_errors
2008-04-07 14:36 ` James Bottomley
@ 2008-04-07 15:16 ` Raoul Bhatia [IPAX]
0 siblings, 0 replies; 3+ messages in thread
From: Raoul Bhatia [IPAX] @ 2008-04-07 15:16 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi
-----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-----
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-04-07 15:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 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).