atom feed13 messages in org.freebsd.freebsd-qaRe: followup to problems with 4.3-RC1...
FromSent OnAttachments
John ReynoldsMar 28, 2001 5:50 pm 
John BaldwinMar 29, 2001 11:50 am 
Mike SmithMar 29, 2001 2:30 pm 
Warner LoshMar 29, 2001 11:52 pm 
Warner LoshMar 29, 2001 11:55 pm 
John BaldwinMar 30, 2001 3:00 pm 
Warner LoshMar 30, 2001 8:49 pm 
Alfred PerlsteinApr 2, 2001 10:43 am 
John BaldwinApr 2, 2001 11:36 am 
Alfred PerlsteinApr 2, 2001 12:20 pm 
John BaldwinApr 2, 2001 12:33 pm 
John BaldwinApr 2, 2001 4:16 pm 
Alfred PerlsteinApr 2, 2001 11:33 pm 
Subject:Re: followup to problems with 4.3-RC1 for laptops
From:Alfred Perlstein (bri@wintelcom.net)
Date:Apr 2, 2001 10:43:57 am
List:org.freebsd.freebsd-qa

* John Baldwin <jh@FreeBSD.ORG> [010402 10:37] wrote:

On 31-Mar-01 Warner Losh wrote:

In message <XFMa@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.

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