Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 07 Aug 2000 16:04:41 -0400
From:      Doug Ledford <dledford@redhat.com>
To:        Rogier Wolff <R.E.Wolff@BitWizard.nl>
Cc:        Bob_Tracy <rct@gherkin.sa.wlk.com>, aic7xxx@FreeBSD.ORG, linux-kernel@vger.rutgers.edu
Subject:   Re: Adaptec 2930U2 problem followup
Message-ID:  <398F1659.5586BC@redhat.com>
References:  <200008071818.UAA29163@cave.bitwizard.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <dledford@redhat.com>  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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?398F1659.5586BC>