linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-scsi@kernel.org
Subject: [Bug 196543] Adaptec 6405H can not understand Queue full message from Disks.
Date: Mon, 31 Jul 2017 06:03:41 +0000	[thread overview]
Message-ID: <bug-196543-11613-oXt6z7TFeO@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-196543-11613@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=196543

--- Comment #1 from James.Bottomley@HansenPartnership.com ---
On Mon, 2017-07-31 at 02:26 +0000, bugzilla-daemon@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=196543
> 
>             Bug ID: 196543
>            Summary: Adaptec 6405H can not understand Queue full
> message
>                     from Disks.
>            Product: IO/Storage
>            Version: 2.5
>     Kernel Version: 4.11.11(Fedora26 Kernel)/3.10.0(RHEL 7.3)
>           Hardware: x86-64
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: SCSI
>           Assignee: linux-scsi@vger.kernel.org
>           Reporter: kiyomi.kakitsubata@gmail.com
>         Regression: No
> 
> Hi
> 
> I happened something different caused by SAS HBA.
> Adaptec 6405H can not understand Queue full message send by Disks.
> 
> Perhaps, normally, any other HBA receive Queue full message from SAS
> disks, it will wait send some command to disks. But Adaptec 6405H is
> not wait send command to disks, so, happen disk time out.
> 
> I think driver or firmware's bug,because other HBA like using
> mpt3sas, is not happened.
> 
> If you need,perhaps I will give SAS bus trace.

A bus trace might help.  The problem with the analysis above is that
QUEUE_FULL isn't handled in the driver or the transport, it's handled
at the scsi mid-layer level since it's a SCSI status return.  There
doesn't seem to be anywhere in the 94xx driver where it intercepts
queue full, so for what you theorise to be the problem, the intercept
would either have to be in firmware, or there would have to be some
generic problem in the mid-layer.  We might be able to track it down,
but we'd need more data.

James

-- 
You are receiving this mail because:
You are the assignee for the bug.

  reply	other threads:[~2017-07-31  6:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-31  2:26 [Bug 196543] New: Adaptec 6405H can not understand Queue full message from Disks bugzilla-daemon
2017-07-31  6:03 ` bugzilla-daemon [this message]
2017-08-02  1:35 ` [Bug 196543] " bugzilla-daemon
2017-08-02  8:14 ` bugzilla-daemon

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=bug-196543-11613-oXt6z7TFeO@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-scsi@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 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).