From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: 2.6.33-rc2 pata_macio fails to detect PMac G3 CD-drive Date: Mon, 11 Jan 2010 20:41:06 +1100 Message-ID: <1263202866.724.134.camel@pasglop> References: <19254.17766.674348.933702@pilspetsen.it.uu.se> <1263186759.724.132.camel@pasglop> <4B4ACCDD.8040803@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from gate.crashing.org ([63.228.1.57]:55342 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752590Ab0AKJnH (ORCPT ); Mon, 11 Jan 2010 04:43:07 -0500 In-Reply-To: <4B4ACCDD.8040803@kernel.org> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Tejun Heo Cc: Mikael Pettersson , linux-ide@vger.kernel.org On Mon, 2010-01-11 at 16:01 +0900, Tejun Heo wrote: > It would be best if the controller has an IRQ pending bit and IRQ can > be cleared as spurious on those bogus interrupts. The reason why SFF > IDE interface is so prone to IRQ storm is because there's no way the > driver can tell whether the controller is raising interrupt or not. > Does the controller have a way to clear IRQ other than reading the > status reg? Nope. Those old Apple controllers have neither a pending bit nor a clear, I think the disk interrupt is wired pretty much directly to the PIC. I can't tell for sure about Mikael's precise case because I can't reproduce it, but in the past, I've seen the CD drive act up similarily when touching NIEN on a wallstreet powerbook (same controller, though for some reason it doesn't act up for me right now) and reading the status reg wasn't clearing the IRQ neither. I suspect those guys have the IRQ in some kind of floating state after the HW reset and don't get it "right" until they get the first taskfile to kick them into some kind of shape... Cheers, Ben.