From: Tejun Heo <htejun@gmail.com>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: jeff@garzik.org, kurt@roeckx.be, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.25-rc6] sata_promise: fix hardreset hotplug quirk
Date: Sun, 23 Mar 2008 12:21:39 +0900 [thread overview]
Message-ID: <47E5CCC3.3000301@gmail.com> (raw)
In-Reply-To: <200803221421.m2MEL1oY021558@harpo.it.uu.se>
Hello, Mikael.
Mikael Pettersson wrote:
> There is an undocumented hardware quirk in Promise's SATA controllers,
> where a SATA COMRESET causes the controller to signal hotplug events.
> These unexpected interrupts confuse libata's error handler and cause
> a sequence of failed reset attempts until EH finally gives up.
Actually, this is common to many SATA controllers. Lots of them raise
PHY event or hotplug interrupt during COMRESET and they all plug PHY
events from ->freeze.
> Although SATA hotplug status and control is per-port, it resides in
> a single register shared by all ports. Therefore accesses to it must
> be serialised: the controller's host->lock is used for that. The
> interrupt handler is also adjusted so its hotplug register accesses
> are inside the region protected by host->lock.
Hmmm... This is supposed to be handled by setting ap->lock appropriately
and ap->lock already is initialized to &host->lock, so sticking with
ap->lock is the right thing to do.
> +static void pdc_sata_disable_hotplug(const struct ata_port *ap)
> +{
> + struct ata_host *host = ap->host;
> + void __iomem *host_mmio = host->iomap[PDC_MMIO_BAR];
> + unsigned int hotplug_offset = pdc_sata_hotplug_offset(ap);
> + unsigned int ata_no = pdc_sata_ata_port_to_ata_no(ap);
> + u32 hotplug_status;
> +
> + spin_lock(&host->lock);
> +
> + hotplug_status = readl(host_mmio + hotplug_offset);
> + hotplug_status |= 0x11 << (ata_no + 16);
> + writel(hotplug_status, host_mmio + hotplug_offset);
> + readl(host_mmio + hotplug_offset); /* flush */
> +
> + spin_unlock(&host->lock);
> +}
> +
> +static void pdc_sata_enable_hotplug(const struct ata_port *ap)
> +{
> + struct ata_host *host = ap->host;
> + void __iomem *host_mmio = host->iomap[PDC_MMIO_BAR];
> + unsigned int hotplug_offset = pdc_sata_hotplug_offset(ap);
> + unsigned int ata_no = pdc_sata_ata_port_to_ata_no(ap);
> + u32 hotplug_status;
> +
> + spin_lock(&host->lock);
> +
> + hotplug_status = readl(host_mmio + hotplug_offset);
> + hotplug_status |= 0x11 << ata_no;
> + hotplug_status &= ~(0x11 << (ata_no + 16));
> + writel(hotplug_status, host_mmio + hotplug_offset);
> + readl(host_mmio + hotplug_offset); /* flush */
> +
> + spin_unlock(&host->lock);
> +}
> +
> static void pdc_freeze(struct ata_port *ap)
> {
> void __iomem *mmio = ap->ioaddr.cmd_addr;
> @@ -643,6 +717,12 @@ static void pdc_freeze(struct ata_port *
> readl(mmio + PDC_CTLSTAT); /* flush */
> }
>
> +static void pdc_sata_freeze(struct ata_port *ap)
> +{
> + pdc_sata_disable_hotplug(ap);
> + pdc_freeze(ap);
> +}
->freeze() is called with ap->lock held, trying to lock host->lock
inside pdc_sata_enable/disable_hotplug() will result in deadlock. Have
you tested w/ SMP configuration or spinlock debugging turned on?
--
tejun
next prev parent reply other threads:[~2008-03-23 3:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-22 14:21 [PATCH 2.6.25-rc6] sata_promise: fix hardreset hotplug quirk Mikael Pettersson
2008-03-23 3:21 ` Tejun Heo [this message]
2008-03-23 10:30 ` Mikael Pettersson
2008-03-23 12:07 ` Tejun Heo
2008-03-23 17:41 ` [PATCH 2.6.25-rc6] sata_promise: fix hardreset hotplug events, take 2 Mikael Pettersson
2008-03-24 2:19 ` Tejun Heo
2008-03-25 2:32 ` Jeff Garzik
2008-03-25 2:37 ` Tejun Heo
2008-03-25 3:32 ` Tejun Heo
2008-03-25 3:53 ` Jeff Garzik
2008-03-25 2:31 ` Jeff Garzik
2008-04-11 21:11 ` Kurt Roeckx
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=47E5CCC3.3000301@gmail.com \
--to=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=kurt@roeckx.be \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@it.uu.se \
/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).