| From | Sent On | Attachments |
|---|---|---|
| John Reynolds | Mar 28, 2001 5:50 pm | |
| John Baldwin | Mar 29, 2001 11:50 am | |
| Mike Smith | Mar 29, 2001 2:30 pm | |
| Warner Losh | Mar 29, 2001 11:52 pm | |
| Warner Losh | Mar 29, 2001 11:55 pm | |
| John Baldwin | Mar 30, 2001 3:00 pm | |
| Warner Losh | Mar 30, 2001 8:49 pm | |
| Alfred Perlstein | Apr 2, 2001 10:43 am | |
| John Baldwin | Apr 2, 2001 11:36 am | |
| Alfred Perlstein | Apr 2, 2001 12:20 pm | |
| John Baldwin | Apr 2, 2001 12:33 pm | |
| John Baldwin | Apr 2, 2001 4:16 pm | |
| Alfred Perlstein | Apr 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.
-- -Alfred Perlstein - [bri...@wintelcom.net|alf...@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 majo...@FreeBSD.org with "unsubscribe freebsd-qa" in the body of the message





