From owner-freebsd-mobile  Mon Nov  3 08:28:46 1997
Return-Path: <owner-freebsd-mobile>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA12038
          for mobile-outgoing; Mon, 3 Nov 1997 08:28:46 -0800 (PST)
          (envelope-from owner-freebsd-mobile)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA12021
          for <freebsd-mobile@freebsd.org>; Mon, 3 Nov 1997 08:28:43 -0800 (PST)
          (envelope-from nate@rocky.mt.sri.com)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id JAA17166;
	Mon, 3 Nov 1997 09:28:35 -0700 (MST)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA07134; Mon, 3 Nov 1997 09:28:33 -0700 (MST)
Date: Mon, 3 Nov 1997 09:28:33 -0700 (MST)
Message-Id: <199711031628.JAA07134@rocky.mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Mike Smith <mike@smith.net.au>
Cc: Nate Williams <nate@mt.sri.com>, freebsd-mobile@freebsd.org
Subject: Re: problems after PAO -> 2.2.5 stable 
In-Reply-To: <199711030534.QAA01689@word.smith.net.au>
References: <199711030520.WAA05479@rocky.mt.sri.com>
	<199711030534.QAA01689@word.smith.net.au>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-mobile@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > > Which component "doesn't work"?  The card has no idea which IRQ it's 
> > > triggering, and AFAIK the pcic doesn't interpret the CIS, nor does the
> > > kernel, so I can't see anything other than pccardd that's at fault 
> > > here...
> > 
> > Don't know.  If I try to use the first free irq for my ethernet card it
> > doesn't work (I can't remember which one it is, but it is free).
> > However, if it's one of the 'accepted' IRQ's, it does work.  I have no
> > good explanation of why this is the way it is, other than what I stated
> > already.
> 
> Well, it sounds like my logic above is screwed.  Let's be Sherlock:
> 
>  - pccardd doesn't do it (I checked)

As did I.

>  - the kernel doesn't do it (I checked)

It never did.

>  - the card _can't_ do it (it has no idea what IRQ is actually being
>    generated)

Is that true?  How do you know that it doesn't know which IRQ is being
used via the driver?

> So once the impossible has been eliminated, I can only conclude that 
> the pcic *does* interpret the CIS.

But it doesn't, I checked. :)


Nate