Juergen Lock wrote: > Hi! > > In article <4b150d60.5050...@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 mar...@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
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"