Date: Mon, 12 Feb 2001 19:48:27 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Brian Somers <brian@Awfulhak.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, Chuck Paterson <cp@bsdi.com>, freebsd-arch@FreeBSD.ORG Subject: Re: usb, clists, spltty, splbio Message-ID: <Pine.BSF.4.21.0102121818570.3966-100000@besplex.bde.org> In-Reply-To: <200102091736.f19HaJN01324@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Feb 2001, Brian Somers wrote: > > On 09-Feb-01 Chuck Paterson wrote: > > > > > > I have been mucking with making moused talk to a usb joystick. > > > This all turned out pretty straight forward, all user land code in > > > moused talking to the hid device. The problem is that the kernel > > > crashes randomly, more often as the system get more loaded. A couple > > > of times I got a panic in the clist code, but it really didn't > > > show anything direct. Oh yah, this is with stable, not current. > > > > > > Reading through the code I found what looks like a problem. > > > The hid, and other usb code use clists. The various usb code is > > > protected by splusb which is a defined as splbio. The function > > > b_to_q() and all the other clist code use spltty. > > > > > > I changed the definition of spltty from > > > > > > GENSPL(spltty, |=, tty_imask, > > 14) > > > > > > to > > > > > > GENSPL(spltty, |=, tty_imask | bio_imask, > > 14) > > > > > > and the crashes appear to have gone away. I say appear, it has run > > > longer now than it has before, but it hasn't been up much more than > > > twice as long yet. > > > > > > I am not quite sure the best way to deal with this. The only > > > idea I have thought of that I like at all is to create a splclist() > > > which is the or of tty and bio and put that into the code that > > > mucks with clists, perhaps just the allocation/free routines. > > > > We have a similar problem with the slip and ppp devices, which have > > run code under botth spltty and splnet. The trick we use there is > > to actually change the imasks by doing something along the lines of: > > > > net_mask |= tty_imask; > > tty_imask = net_imask; > > > > So there is at least prior precedent for doing this sort of thing. > > Hmm. I would think that Chucks' idea has the advantage that it > doesn't adversely affect existing splnet/spltty code. Despite this > only mattering for a finite amount of time, I don't think the > precedent is good here :-/ It is more robust, but to be completely robust it would have to use (bio_imask | net_imask | tty_imask) for all of splbio(), splimp() and spltty(). This is a small step away from using splhigh() for everything. I sometimes feel that there should have been at at most 3 hardware spls: slpall(), splallbutclocks() and splnone(). Some machines can only support splall() and splnone(), so MI code shouldn't require more than 2 levels to operate properly, and optimizing for that case might be good for all cases (it essentially requires all hardware interrupt handlers to not take very long). I don't completely understand the uhid bug, but it seems to be a little different from the one with slip and ppp. Usb doesn't seem to use the hardware usb interrupt, and it only seems to use SWIs for netisrs, so I assume it uses timeouts for the relevant interrupt handlers. This makes it more like vpo than slip or ppp, so there should be no problem -- timeouts are certainly masked by spltty(), and we don't need splusb() to mask tty interrupts because non-usb tty drivers don't use usb code or data (*). The problem may be that usb is unwarrantedly chummy with the clist internals, but not chummy enough to use the correct spl for accessing them, e.g., in uhid_do_read(). However, I can't see how this would cause panics. (*) Part of the problem in slip and ppp is that the net and tty subsystems can get in each others way. This is handled in slip by setting set the imasks equal, and in ppp by setting the masks much more subtly and using a few extra spls. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0102121818570.3966-100000>