[<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
 
