From: Hans Verkuil <hverkuil@xs4all.nl>
To: Anand Kumar Santhanam <AnandKumar.Santhanam@pmcs.com>
Cc: Jack Wang <xjtuwjp@gmail.com>, lindar_liu <lindar_liu@usish.com>,
linux-scsi@vger.kernel.org
Subject: Re: The pm80xx driver hangs in 3.10 with the Adaptec 71605H HBA
Date: Sun, 14 Jul 2013 10:45:19 +0200 [thread overview]
Message-ID: <51E2651F.1040905@xs4all.nl> (raw)
In-Reply-To: <E5DEE6F468524847995699AD11E8088501B28CAA@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>
Hi Anand,
On 07/12/2013 03:14 PM, Anand Kumar Santhanam wrote:
> Hans,
>
> I reviewed the code changes and I did not see major differences except
> for the fact that in adaptec driver we have 64 interrupt handlers to
> handle 64 MSI-X.
> This was optimized in open src driver to use only 1 interrupt handler.
> Can you pls make this change to the open src driver (i.e have multiple
> interrupt handlers for multiple MSI-X) and check?
I've looked at this more closely, and I wonder whether there isn't a race condition
here. When an interrupt arrives you put the interrupt vector in pm8001_ha->int_vector,
then schedule the tasklet. But what if two interrupts with different vectors arrive
in quick succession before the tasklet got a chance to run? In that case the tasklet
will only see the second vector, not the first. Rather scary.
I have not actually seen any issues with this, but by definition race conditions are
hard to reproduce and I haven't done any serious testing with this card. For now I
will run with the quick and dirty msi.diff (http://hverkuil.home.xs4all.nl/msi.diff).
I see two solutions: either use the 64 interrupt handlers as done in the adaptec
driver, or you can change int_vector into a u64 and use it as a bitmask to record
all interrupt vectors that have arrived.
BTW, another difference between the linux kernel driver and the adaptec version are
several of the defines in pm8001_defs.h: e.g. MPI_QUEUE is 256 in the adaptec driver,
while it is 1024 in the kernel driver. There are other differences as well.
Are all the changes in the kernel correct? I would like to have a confirmation of
that before I am going to trust my data to this driver.
It clearly hasn't been tested with actual hardware :-(
Regards,
Hans
next prev parent reply other threads:[~2013-07-14 8:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 11:02 The pm80xx driver hangs in 3.10 with the Adaptec 71605H HBA Hans Verkuil
[not found] ` <CAD+HZHUc7wULDUpKq24rmcVC9MCcgaoO4i1LxGcW-q-y-c3tcQ@mail.gmail.com>
[not found] ` <201307121419.50786.hansverk@cisco.com>
[not found] ` <E5DEE6F468524847995699AD11E8088501B28CAA@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>
2013-07-14 8:45 ` Hans Verkuil [this message]
2013-07-15 8:53 ` Jack Wang
2013-07-15 12:37 ` Anand Kumar Santhanam
2013-07-15 13:02 ` Hans Verkuil
2013-07-15 13:08 ` Jack Wang
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=51E2651F.1040905@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=AnandKumar.Santhanam@pmcs.com \
--cc=lindar_liu@usish.com \
--cc=linux-scsi@vger.kernel.org \
--cc=xjtuwjp@gmail.com \
/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