Date: Tue, 15 Dec 2009 09:03:21 -0600 From: Karl Denninger <karl@denninger.net> To: Juergen Lock <nox@jelal.kn-bremen.de> Cc: marcel@freebsd.org, freebsd-stable@freebsd.org, 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: <4B27A539.808@denninger.net> In-Reply-To: <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B27A539.808>