PUC Serial I/O problem - copy of gnats-filed bug report (as [SB
QUAR: Sun Dec 13 10:50:06 2009] discussed previously)
Karl Denninger
karl at denninger.net
Tue Dec 15 15:05:39 UTC 2009
Juergen Lock wrote:
> 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
>
This is now marked fixed and it appears (after limited testing thus far)
that it indeed is.
Thank you.
-- Karl
More information about the freebsd-stable
mailing list