Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Apr 2001 10:44:19 -0700
From:      Alfred Perlstein <bright@wintelcom.net>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        Warner Losh <imp@harmony.village.org>, Mike Smith <msmith@FreeBSD.ORG>, John Reynolds <jjreynold@home.com>, mobile@FreeBSD.ORG, qa@FreeBSD.ORG
Subject:   Re: followup to problems with 4.3-RC1 for laptops
Message-ID:  <20010402104419.U813@fw.wintelcom.net>
In-Reply-To: <XFMail.010402103625.jhb@FreeBSD.org>; from jhb@FreeBSD.ORG on Mon, Apr 02, 2001 at 10:36:25AM -0800
References:  <200103310450.f2V4ofO08270@harmony.village.org> <XFMail.010402103625.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
* John Baldwin <jhb@FreeBSD.ORG> [010402 10:37] wrote:
> 
> On 31-Mar-01 Warner Losh wrote:
> > In message <XFMail.010330150116.jhb@FreeBSD.org> John Baldwin writes:
> >: That is easy enough to work around, just have the cardbus code mask out
> >: INTR_FAST in its bus_setup_intr and bus_teardown_intr and it will work fine.
> >: This will hurt sio(4) performance some however, but if fast interrupts are a
> >: problem for cardbus you can always turn them off.
> > 
> > The problem isn't FAST interrupts with cardbus.  The problem is that
> > fast interrupts can't be shared.  I don't think sio does anything that 
> > requires a fast interrupt, except for the latency issues for the 16550 
> > uarts.  They can't tolerate the latency we have in non-fast interrupts 
> > in current :-(.
> 
> I realize that fast interrupts can't be shared, so they are problematic in that
> regard, and you can still mask out INTR_FAST and INTR_EXCL if you wish in the
> bus layer so that the attaching device doesn't have to special case its code
> but can instead basically say what its desires are and let the bus decide if
> all of them can be satisified or not.

Shouldn't the device be able to specify an all-or-nothing request?

Perhaps something that needs fast interrupts will cause much hair
pulling if it doesn't get one becasue of latency issues messing up
the hardware.  If the bus didn't grant a fast interrupt it could then
declien to attach, perhaps spitting out a meaningful error message
at the same time.

My apologies if this has already been brought up.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010402104419.U813>