From owner-aic7xxx Tue Aug 8 17:56: 9 2000 Delivered-To: aic7xxx@freebsd.org Received: from meer.meer.net (meer.meer.net [140.174.164.2]) by hub.freebsd.org (Postfix) with ESMTP id 5C65C37B5C6 for ; Tue, 8 Aug 2000 17:55:55 -0700 (PDT) (envelope-from andy@netfall.com) Received: from netfall.com (adsl-63-194-216-62.dsl.snfc21.pacbell.net [63.194.216.62]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id RAA251631; Tue, 8 Aug 2000 17:55:29 -0700 (PDT) Message-ID: <3990AC29.2C5C9D6C@netfall.com> Date: Tue, 08 Aug 2000 17:56:09 -0700 From: Andrew Sharp Organization: Sharp Programmers X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i686) X-Accept-Language: en MIME-Version: 1.0 To: Doug Ledford Cc: Rogier Wolff , Bob_Tracy , aic7xxx@FreeBSD.ORG, linux-kernel@vger.rutgers.edu Subject: Re: Adaptec 2930U2 problem followup References: <200008071818.UAA29163@cave.bitwizard.nl> <398F1659.5586BC@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a pretty common problem on Abit BP6 mobo's, which is anything but a rare motherboard , especially amongst DIY at-home Linuxerati and BSDers. I know that I have this problem every time I boot Linux on my BP6, and never had it on my Intel DK440FX motherboard. A lot of the time, if I go into the BIOS setup and tell it to update the ESCD information, then it will boot. But not always. Of course, WindowsNT has no problem, so I think it's something that Linux could handle if the developer or developers responsible for that code wanted to make it a priority. I know that there is a lot of disdain for this mobo expressed by certain kernel maintainers on the kernel list, possibly for this reason and that this is a bug in the BIOS of these boards, but it seems like a work around is possible if Windows never has a problem. Perhaps NT somehow "falls back" to not using the APIC if it detects a problem. I have noticed that NT takes a lot longer to boot on this motherboard than it does on any other that I have. Voodoo engineering, I know, but there you have it. For me, the problem is very inconsistent and flaky, but it virtually never works the first time I try to boot the system. It always happens when the kernel/aic7xxx is trying to identify the drives, and the number of drives that get identified before it starts the timing out business is never the same, although it usually gets at least one drive indentified. If it gets past identifying the drives, the system works fine for semi-infinite periods of time. Adaptec 2940 UW. a Doug Ledford wrote: > Rogier Wolff wrote: > > > > Doug Ledford wrote: > > > Bob_Tracy wrote: > > > > > > > > Been having problems with an Adaptec 2930U2 card in my machine at > > > > the house. Naturally, it works fine with Win95. The problem has > > > > been shown to be something peculiar to my motherboard after looking > > > > at many test scenarios over the past several days. Basically, > > > > there's no interrupt activity corresponding to the 2930U2 that > > > > either Linux or FreeBSD can see. This results in an infinite > > > > timeout/reset loop during driver initialization. > > > > > > This is usually only a problem on SMP motherboards. In that case, I tell > > > people to boot the kernel with the option noapic and see if it helps the > > > problem. In any case, linux isn't reading your IRQ routing information > > > properly either due to a linux bug or a buggy BIOS. You could bring this > > > problem up to Ingo Molnar if this is an SMP motherboard *and* noapic helps, or > > > bring it up to Martin Mares otherwise since it would likely be a PCI problem. > > > > Doug, > > > > If it's the IRQ routing stuff, then the symptoms would be consistent > > with: "But 2.0 worked just fine on this machine", right? > > > > I have a client with exaclty the same problem, and the "but 2.0 works" > > hint. (IBM machine by the way.) > > If it's IOAPIC related IRQ routing, then yes. If it's a PCI quirk on that > motherboard that we aren't working around then no. Both of these are IRQ > routing bits of code BTW, which is why I didn't answer your question as > yes/no. The IOAPIC code will rewrite the PCI IRQ entries based upon an SMP MP > table, and absent that the PCI code attempts to verify the IRQ routing of the > cards as well (although I don't think it actually modifies anything). In the > absence of an MP table and SMP, the likely culprit is a bad entry in the PCI > config space from the BIOS. It's possible then that going into the MB BIOS > and triggering the reset configuration space stuff *might* make a difference > on how IRQs are assigned by the BIOS and what gets placed into the PCI config > space of the card by the BIOS and might make linux work. > > Windows probably works on this machine because it has a special case handler > for whatever is going on (or else we have a genuine PCI bug here that we need > to fix and it's only triggered on certain rare MBs like this one). > > -- > > Doug Ledford http://people.redhat.com/dledford > Please check my web site for aic7xxx updates/answers before > e-mailing me about problems > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe aic7xxx" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message