From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 15:05:39 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 4F8BD1065676 for ; Tue, 15 Dec 2009 15:05:39 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id EDF398FC1C for ; Tue, 15 Dec 2009 15:05:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id nBFF5bZ1038457 for ; Tue, 15 Dec 2009 09:05:39 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Tue Dec 15 09:05:38 2009 Message-ID: <4B27A539.808@denninger.net> Date: Tue, 15 Dec 2009 09:03:21 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Juergen Lock 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> In-Reply-To: <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------050309090106020203080501" X-Antivirus: avast! (VPS 091215-0, 12/15/2009), Outbound message X-Antivirus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: marcel@freebsd.org, freebsd-stable@freebsd.org, 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 15:05:39 -0000 This is a multi-part message in MIME format. --------------050309090106020203080501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen Lock wrote: > Hi! > > In article <4B150D60.5050200@denninger.net> you write: > >> -=-=-=-=-=- >> >> Jeremy Chadwick wrote: >> >>> On Sat, Nov 28, 2009 at 09:43:25PM -0600, Karl Denninger wrote: >>> >>> >>>> Karl Denninger wrote: >>>> >>>> >>>>> Jeremy Chadwick wrote: >>>>> >>>>> >>>>> >>>>>> On Fri, Nov 27, 2009 at 12:54:17PM -0600, Karl Denninger wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> For what its worth, USB-based serial adapters also fail in the same way, >>>>>>> but faster (they have NEVER been reliable in this regard, and this >>>>>>> hasn't improved) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> There must be a regression of some kind, given that some FreeBSD >>>>>> developers have stated in the past that FTDI-based USB serial adapters >>>>>> work great: >>>>>> >>>>>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041615.html >>>>>> >>>>>> Original thread: >>>>>> >>>>>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041610.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I don't know where "works great" has come from. Certainly not my >>>>> experience in "heavy" use. >>>>> >>>>> For non-modem-control heavy use, it works ok. I use an 8-port fanout on >>>>> 7.x to drive process control and it's stable. >>>>> >>>>> However, for heavy modem use (e.g. Hylafax) it has NEVER been stable - >>>>> although in 8.x it won't even manage to send ONE 10-page fax most of the >>>>> time, where under 7.x it would randomly fail in that use. Then again >>>>> the puc() driver based serial I/O was completely stable under 7.x and >>>>> now, with the "new architecture" it will get one or two jobs through it >>>>> before it blows up. >>>>> >>>>> -- Karl >>>>> >>>>> >>>>> >>>> FYI I downgraded back to 7.2-STABLE (it was a bit hairy but I got it to >>>> work after a small amount of screwing around) via sources >>>> and again the machine and those serial ports are 100% stable with the >>>> old driver infrastructure. >>>> >>>> The uart() infrastructure in 8.x has to be considered broken and >>>> unusable for modems at this point folks. I recognize that nobody >>>> flagged it until just before the release (I hadn't tried it until RC2, >>>> and thus didn't know) but this is a literal dagger in the heart of >>>> anyone who needs to put an actual modem on an 8.x box using the common >>>> cards out there, and I assume it will bite just as hard for things like >>>> a dial-in console as it will for a fax server. >>>> >>>> >>> Karl, >>> >>> I agree with you in this regard. However, I'm not sure what to >>> recommend to you with regards to getting this issue the proper attention >>> it needs. I fully agree with the Severity (serious) and Priority >>> (high) of the PR: >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/140947 >>> >>> Ed Schouten appears to be giving this attention, but I'd recommend that >>> Email communication include marcel@FreeBSD.org, "just in case" it turns >>> out that puc(4) needs some changes. I'm certain Ed will do his best to >>> assist tracking this one down. :-) >>> >>> >> Added the suggested forward address to the list..... just in case :) >> >> Yeah, this is pretty serious. It looks to me, at first blush, like an >> interrupt is being dropped on occasion and there is no watchdog timer in >> the driver code to catch it and unwedge the state machine. That's not >> supposed to be possible (dropped interrupts) on PCI (and PCI/Express) >> cards unless something is dramatically wrong in the code somewhere. >> > > It just occured to me that this might be related to a bug I fixed > in qemu's serial hw emulation, > http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=2d6ee8e7e17227d5eb8c6e9a054dd88d5b37c5ae > which also caused tx irqs to get lost and which the old sio(4) driver had > no problem with, only output on uart(4) then hung as a result. On that > occasion I also learned that there is a priority list for irqs, for example > rx irqs take precedence over tx ones, so maybe that explains why some irqs > can get lost during `heavy use'? (And which the old driver recovered from > I guess by checking status registers at least in the tx path too in > addition to just accounting for irqs.) > > HTH, > Juergen > This is now marked fixed and it appears (after limited testing thus far) that it indeed is. Thank you. -- Karl --------------050309090106020203080501--