[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070425112533.19d4a1aa@the-village.bc.nu>
Date: Wed, 25 Apr 2007 11:25:33 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Tejun Heo <htejun@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Berck E. Nash" <flyboy@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jeff Garzik <jeff@...zik.org>, linux-ide@...r.kernel.org
Subject: Re: 2.6.21-rc7-mm1 BUG at kernel/sched-clock.c:175
init_sched_clock()
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 72c286e..a128717 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1369,10 +1369,14 @@ static unsigned int ahci_qc_issue(struct ata_queued_cmd *qc)
>
> static void ahci_freeze(struct ata_port *ap)
> {
> + void __iomem *mmio = ap->host->iomap[AHCI_PCI_BAR];
> void __iomem *port_mmio = ahci_port_base(ap);
>
> /* turn IRQ off */
> writel(0, port_mmio + PORT_IRQ_MASK);
> +
> + /* clear IRQ pending bit */
> + writel(1 << ap->port_no, mmio + HOST_IRQ_STAT);
> }
>
Actually now I think about it the problem is even worse. On older systems
IRQ delivery for SMP machines is asynchronous. So the following can occur
device raises IRQ line
IRQ request hits APIC bus
We write IRQ off
We clear IRQ pending
We read back to ensure the write took
IRQ arrives on CPU APIC
(and yes this happens on dual P3 boxes - NE2K has some fantastic bugs at
one point due to this)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists