Date: Sun, 13 Dec 2009 17:46:44 +0100 (CET) From: Juergen Lock <nox@jelal.kn-bremen.de> To: karl@denninger.net 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 discussed previously) Message-ID: <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> In-Reply-To: <4B150D60.5050200@denninger.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912131646.nBDGkiPX010830>