Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Apr 2001 11:33:58 -0800 (PDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        qa@FreeBSD.org, mobile@FreeBSD.org, John Reynolds <jjreynold@home.com>, Mike Smith <msmith@FreeBSD.org>, Warner Losh <imp@harmony.village.org>
Subject:   Re: followup to problems with 4.3-RC1 for laptops
Message-ID:  <XFMail.010402113358.jhb@FreeBSD.org>
In-Reply-To: <20010402104419.U813@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On 02-Apr-01 Alfred Perlstein wrote:
> * 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.

True, no need for an error message, but I suppose one could do something like
this then:

if (BUS_SETUP_INTR(..., INTR_FOO | INTR_FAST, ...) != 0) {
   error = BUS_SETUP_INTR(..., INTR_FOO, ...);
   if (error)
       return (error);
}

> My apologies if this has already been brought up.

No, it was also something kicking around in my head, but I didn't mention it. 
Wasn't sure if that was an implied condition of bus_setup_intr().

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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




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