From owner-freebsd-current Sat Nov 23 20:42: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEF7E37B401 for ; Sat, 23 Nov 2002 20:42:01 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4F1343E6E for ; Sat, 23 Nov 2002 20:42:00 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA03585; Sun, 24 Nov 2002 15:41:32 +1100 Date: Sun, 24 Nov 2002 15:54:52 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "M. Warner Losh" Cc: Maksim.Yevmenkin@cw.com, , , Subject: Re: Bluetooth questions In-Reply-To: <20021123.140223.15084544.imp@bsdimp.com> Message-ID: <20021124151956.S52130-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 23 Nov 2002, M. Warner Losh wrote: > In message: <20021123205433.J49198-100000@gamplex.bde.org> > Bruce Evans writes: > : 56k is a silly speed to use. Why not use the normal speed of 57600 > : bps or the faster speed of 115200 bps? I haven't got around to updating > : the 57600 in the example in /etc/rc.serial although this example became > : bad about 7 years ago just before 56k modems became normal. IIRC, I > : only had a 14400 bps modem when I wrote the example. > > I've used a 56k modem, which doesn't give a sustained speed higher > than about 56k :-). That's what I ment. Burst rates can be higher though. > : For the non-fast interrupt case, part of the problem is that the > : interrupt handler is not marked MPSAFE although it probably is MPFSAFE, > : so it has the same latency problems as most other interrupt handlers > : -- almost everything is blocked by Giant, and Giant can easily be held > : for 10 msec or so (e.g., in the mii tick code when it is run as a > : non-MPSAFE timeout). In RELENG_4, non-fast tty interrupts are only > : blocked by spltty(), so the latency problems are mostly isolated to > : a few low-quality drivers (e.g., syscons normally busy-waits for > : several msec in its tty interrupt handler to program LEDs). > > I'll have to try that. I use this, but haven't actually tested the non-fast case. In theory things should just work the locking requirements for fast interrupt handlers are stronger than Giant. Index: sio.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sio/sio.c,v retrieving revision 1.382 diff -u -2 -r1.382 sio.c --- sio.c 11 Oct 2002 20:22:20 -0000 1.382 +++ sio.c 17 Oct 2002 20:18:53 -0000 @@ -1117,5 +1146,6 @@ if (ret) { ret = BUS_SETUP_INTR(device_get_parent(dev), dev, - com->irqres, INTR_TYPE_TTY, + com->irqres, + INTR_TYPE_TTY | INTR_MPSAFE, siointr, com, &com->cookie); if (ret == 0) > : Does the hardware also do something funny with the input fifo size > : (which would make it non-16550 compatible)? Speeds faster than the > : nominal speed break things even if the interrupt handler can keep up, > : by generating more input than fits in buffers in upper layers. Fifos > : larger than the nominal size may break flow control in related ways. > : But silo overflows mean problems at the interrupt layer. > > Most of the 16650, 16750 and 16850 chips require special care to > enable the larget fifo, iirc, so that the compatibility problems don't > happen. They are enabled by driver flags which should only be used if they help since they driver doesn't really understand them and at least the original 16650 has broken-as-designed hardware flow control. T he driver doesn't understand its brokenness and enables it, unlike the Linux driver which at least used to ignore the possiblility of hardware flow control. The brokenness is that flow control is invoked when the input fifo trigger level is reached, so throughput is degraded if the sender actually notices the flow control in time, and the senders time is wasted by unnecessary interrupts for flow control. > You are right about the buffer sizes in the intermeidate > layers being sized for bursts of 16 bytes, not bursts of, say, 100 > bytes. Actually, they are sized for bursts related to hz without any knowledge of the burst size. Setting hz to a large value gives interrupt-level buffers of size 128 (it would be lower but is clamped to 128, which more or less corresponds to clamping the timeout period to 1/200 (not 1/hz)). 128 works OK if and only the driver's SWI isn't blocked (by Giant?) for too long and the burst length is significantly less than 128. Using the default hz gives interrupt-level buffer sizes of 512 at 115200 bps and 256 at 57600 bps so there is more slop for large fifos. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message