From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 17:58:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA2AE106566B for ; Tue, 15 Dec 2009 17:58:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 916D68FC16 for ; Tue, 15 Dec 2009 17:58:09 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUP00H7MGKNSS50@asmtp027.mac.com> for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 09:58:01 -0800 (PST) From: Marcel Moolenaar In-reply-to: <4B27A539.808@denninger.net> Date: Tue, 15 Dec 2009 09:57:59 -0800 Message-id: 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> To: Karl Denninger X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org, Juergen Lock , Jeremy Chadwick 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) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 17:58:09 -0000 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, -- Marcel Moolenaar xcllnt@mac.com