PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously)

Karl Denninger karl at denninger.net
Tue Dec 1 12:36:39 UTC 2009


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 at 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.

-- Karl


More information about the freebsd-stable mailing list