Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262354AbUKVUmk (ORCPT ); Mon, 22 Nov 2004 15:42:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262366AbUKVUlT (ORCPT ); Mon, 22 Nov 2004 15:41:19 -0500 Received: from fmr01.intel.com ([192.55.52.18]:42656 "EHLO hermes.fm.intel.com") by vger.kernel.org with ESMTP id S262354AbUKVUjT (ORCPT ); Mon, 22 Nov 2004 15:39:19 -0500 Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device) From: Len Brown To: Linus Torvalds Cc: Adrian Bunk , Chris Wright , Bjorn Helgaas , Kernel Mailing List , Andrew Morton In-Reply-To: References: <20041115152721.U14339@build.pdx.osdl.net> <1100819685.987.120.camel@d845pe> <20041118230948.W2357@build.pdx.osdl.net> <1100941324.987.238.camel@d845pe> <20041120124001.GA2829@stusta.de> <1101151780.20006.69.camel@d845pe> Content-Type: text/plain Organization: Message-Id: <1101155893.20007.125.camel@d845pe> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 22 Nov 2004 15:38:14 -0500 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1757 Lines: 50 On Mon, 2004-11-22 at 15:02, Linus Torvalds wrote: > > On Mon, 22 Nov 2004, Len Brown wrote: > > > > When we enable a link, we must set the ELCR. > > When we disable a link, we must clear the ELCR. > > We need to be able to enable and disable all links in the system. > > > > The bug was that while we were were setting the ELCR > > when we enabled a link, we were not clearing it when we disabled > one. > > Fair enough. ... > But feel free to send me a patch that doesn't just clear ELCR totally, > but clears the bits we are disabling. I just don't believe in the > "let's just clear everything" approach. Will do. > > > But if you're more comfortable with disabling the associated ELCR > bit> only when we disable links directed at that entry, we can do that > too. > > The complication with that approach is that links are many to one, > so > > clearing the bit without disabling all links directed to that entry > > would result in a failure. Also, the SCI uses the ELCR too, and it > > isn't described by links at all. > > Wouldn't it be nicer to take the _reverse_ approach: let's assume that > any PCI interrupts that we have already enabled are fine and should > not be disabled? Mark them in the ELCR, and _report_ when the ELCR > seems to be incorrect (let's make a wild guess here, and realize that > the screaming VIA interrupts you talk about are exactly because the > ELCR was wrong). I think the VIA case is more complicated than that, but I'll take another look at it. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/