Date: Tue, 15 Dec 2009 12:01:42 -0600 From: Karl Denninger <karl@denninger.net> To: Marcel Moolenaar <xcllnt@mac.com> Cc: freebsd-stable@freebsd.org, Juergen Lock <nox@jelal.kn-bremen.de>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously) Message-ID: <4B27CF06.7070900@denninger.net> In-Reply-To: <E3C14EC6-4F90-4438-84E6-0C1AA031454A@mac.com> References: <4B100262.6000900@denninger.net> <4B102059.6040003@denninger.net> <20091127190319.GA12437@icarus.home.lan> <4B102C41.6040205@denninger.net> <4B11EDDD.8060108@denninger.net> <20091129205814.GB77530@icarus.home.lan> <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> <4B27A539.808@denninger.net> <E3C14EC6-4F90-4438-84E6-0C1AA031454A@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------060106000505060601040802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Marcel Moolenaar wrote: > On Dec 15, 2009, at 7:03 AM, Karl Denninger wrote: > > >> This is now marked fixed and it appears (after limited testing thus far) >> that it indeed is. >> > > The bug existed in 7 as well. It's not a regression introduced in 8. > The reason why this didn't come up in the 7 time frame is that sio(4) > was still the default. Jeremy has been an early adopter of uart(4) > and if I'm not mistaken, he always loaded the driver(s) as modules. > This, due to a "lucky" bug, avoided the problem for him. > > In depth: > > With uart(4) I created the serdev I/F. This is an interface that > allows umbrella drivers like puc(4) and scc(4) to obtain pending > interrupt status and invoke interrupt source specific handlers. > This puts the umbrella driver in control over what gets handled > in what order *across* multiple interfaces. As such, with puc(4), > you can service all receive interrupts for all ports before you > service, say, the transmit interrupt across the ports. > > When a serial device does not implement the serdev I/F, then > puc(4) won't be involved in interrupt handling at all. This is > why puc(4)+sio(4) had no problem. Since uart(4) does implement > the serdev I/F, the interrupt handler of puc(4) would be in > control and since it was this interrupt handler that was broken, > exhibit the stalls. > But, when puc(4) and/or uart(4) were loaded as modules, puc(4) > would not see uart(4) as implementing the serdev I/F. This is > to do with linker sets, etc. Consequently, uart(4) would handle > its own interrupts and puc(4) would not be involved (just as > with the sio(4) setup). In that scenario puc(4)+uart(4) also > just worked. > > In any case: puc(4) has been fixed and I'll deal with the linker > set bug later. For best results: compile puc(4) and uart(4) into > the kernel and don't load them as modules for now... > > FYI, > uart(4) is defined in the GENERIC file; I am compiling in puc(4) at present in my kernel. -- Karl --------------060106000505060601040802--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B27CF06.7070900>