From: Mark Lord <liml@rtr.ca>
To: Tejun Heo <htejun@gmail.com>, Jeff Garzik <jgarzik@pobox.com>,
Alan Cox <alan@redhat.com>,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: Port Multiplier drives not always all found on cold plug
Date: Fri, 16 May 2008 13:27:59 -0400 [thread overview]
Message-ID: <482DC41F.9080901@rtr.ca> (raw)
In-Reply-To: <482DBC5C.3020904@rtr.ca>
Mark Lord wrote:
> Mark Lord wrote:
>> Mark Lord wrote:
>>> Tejun,
>>>
>>> Since enabling PMP support in sata_mv, there have been some recent
>>> reports of not all drives being found on a PM.
> ..
>> Mmmm.. one strange thing from the logs.
>> sata_mv reports "unexpected device interrupt" in a few places,
>> and then triggers EH to recover from it.
>> This could be what is causing the PMP enumerations to partially fail.
>>
>> I wonder why we're getting interrupts when supposedly idle/polling ?
>> Did something in libata miss reading ata_status to clear an IRQ ?
> ..
>
> Here, I've hacked my local copy of sata_mv to NOT trigger EH
> when it gets an unexpected device interrupt. This is how the driver
> has been for years, until recently.
>
> With this change, all drives on the PM are found (no surprise).
>
> So I guess the questions are:
>
> 1. Where are these unexpected interrupts coming from?
>
> The implication is that a command is being issued without NIEN=1,
> *or* the ata_status is not being read (to clear the pending IRQ)
> before we clear NIEN for a subsequent command.
..
Mmm.. libata looks totally clean there, verified with some printk's
placed in strategic locations.
Perhaps all commands to the PM itself (pmp=15) result in interrupts
on receipt of the response? The PM spec certainly implies this,
and doesn't mention NIEN at all.
I suppose that could be the source of them -- tracing in the driver
suggests that they all happen during/after issue of a PMP read command.
> 2. What to do about them in the driver?
..
I think by default, I'll just revert to having the driver ignore them,
the same as is done in the default methods in libata-core.c.
So far they do seem harmless in my testing here.
??
next prev parent reply other threads:[~2008-05-16 17:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-16 16:34 Port Multiplier drives not always all found on cold plug Mark Lord
2008-05-16 16:46 ` Mark Lord
2008-05-16 16:54 ` Mark Lord
2008-05-16 17:27 ` Mark Lord [this message]
2008-05-16 18:06 ` Mark Lord
2008-05-17 14:21 ` Tejun Heo
2008-05-17 17:32 ` Mark Lord
2008-05-17 17:52 ` Tejun Heo
2008-05-17 19:16 ` Mark Lord
2008-05-18 5:23 ` Tejun Heo
2008-06-02 3:38 ` JR Wilbert
2008-06-09 1:47 ` Tejun Heo
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=482DC41F.9080901@rtr.ca \
--to=liml@rtr.ca \
--cc=alan@redhat.com \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@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.