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

[Juergen Lock]

Hi!

In article <4B150D60.5050200 at 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 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.

 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