Skip to contentSkip to conversation

Add more debug output to sas_scsi_recover_host or sas_eh_handle_sas_errors

DISCUSSION Raoul Bhatia [IPAX] 2 participants 3 messages Apr 7, 2008 SCSI

lore
Share & tools
lore
#0 lore raw

-----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. [email protected]
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            [email protected]
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-----

maintainer
#1 lore raw
Quoted 8 lines · Raoul Bhatia [IPAX]

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

#2 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello james,

Quoted 4 lines · James Bottomley
Quoted 3 lines · Raoul Bhatia [IPAX]

is there any sens in adding more debug output to sas_scsi_recover_host or sas_eh_handle_sas_errors?

Quoted 8 lines
Quoted 5 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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. [email protected]
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            [email protected]
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-----