From owner-freebsd-qa Mon Apr 2 11:34:56 2001 Delivered-To: freebsd-qa@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 6C74637B71F; Mon, 2 Apr 2001 11:34:38 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f32IYRG70883; Mon, 2 Apr 2001 11:34:27 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010402104419.U813@fw.wintelcom.net> Date: Mon, 02 Apr 2001 11:33:58 -0800 (PDT) From: John Baldwin To: Alfred Perlstein Subject: Re: followup to problems with 4.3-RC1 for laptops Cc: qa@FreeBSD.org, mobile@FreeBSD.org, John Reynolds , Mike Smith , Warner Losh Sender: owner-freebsd-qa@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 02-Apr-01 Alfred Perlstein wrote: > * John Baldwin [010402 10:37] wrote: >> >> On 31-Mar-01 Warner Losh wrote: >> > In message 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 -- 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