freebsd stable - Nov 2009 - V8.x-PRE2 Serious PUC problem - Heads Up!

It appears that V8.x has changed some device names in the serial
subsystem, moving them to the "puc" naming (e.g. ttydxx moves to
ttyuxx)

There is a fairly serious issue with Hylafax under the new setup that I
have not (yet) been able to run down.  It manifests as ports that simply
stop working, where they were fine under 7.x, after some indeterminate
period of time.

I will update as I have more information - this is a serious issue for
anyone who needs working serial ports on multiport cards under FreeBSD
for things like a fax server..... this is not the sort of "surprise"
one
wants to see!

-- Karl Denninger

At 08:53 AM 11/19/2009, Karl Denninger wrote:
>I will update as I have more information - this is a serious issue for
>anyone who needs working serial ports on multiport cards under FreeBSD
>for things like a fax server..... this is not the sort of
"surprise" one
>wants to see!
Its not the puc per se as the transition from sio to uart

from /usr/src/UPDATING

20080713:
         The sio(4) driver has been removed from the i386 and amd64
         kernel configuration files. This means uart(4) is now the
         default serial port driver on those platforms as well.

         To prevent collisions with the sio(4) driver, the uart(4) driver
         uses different names for its device nodes. This means the
         onboard serial port will now most likely be called "ttyu0"
         instead of "ttyd0". You may need to reconfigure applications
to
         use the new device names.

         When using the serial port as a boot console, be sure to update
         /boot/device.hints and /etc/ttys before booting the new kernel.
         If you forget to do so, you can still manually specify the hints
         at the loader prompt:

                 set hint.uart.0.at="isa"
                 set hint.uart.0.port="0x3F8"
                 set hint.uart.0.flags="0x10"
                 set hint.uart.0.irq="4"
                 boot -s


>-- Karl Denninger
>
>_______________________________________________
>freebsd-stable@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

Mike Tancsa wrote:
> At 09:00 AM 11/19/2009, Karl Denninger wrote:
>> Well ok then the uart driver is BROKEN.
>>
>> It simply locks up on the port after some period of time, returning
>> nothing.  I have found no way to reset the port other than a reboot
>> either.  That's a "surprise" that people running fax
servers and other
>> similar things are going to be very unhappy about.
>
> Which serial card are you using ? I have a number of PCI cards (lava
> for example) that are working quite well with the puc and uart driver
> combo. Perhaps you could post some details about the hardware used
> thats having issues.
>
>         ---Mike
puc0: <Oxford Semiconductor OX16PCI954 UARTs> port
0x4060-0x407f,0x4040-0x405f mem
0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3
puc0: [FILTER]
uart2: <16550 or compatible> on puc0
uart2: [FILTER]
uart3: <16550 or compatible> on puc0
uart3: [FILTER]
uart4: <16550 or compatible> on puc0
uart4: [FILTER]
uart5: <16550 or compatible> on puc0
uart5: [FILTER]

It's a generic board with four ports sitting on the PCI bus.  Nothing
special, no smarts, just four 16550 uarts.  Port "0" is on the
motherboard and I am using that to talk to my NMEA clock (using PPS,
which is working).  I also am using one of the "troubled" ports to
talk
to an APC UPS, again, without problems.

Trivial and reasonably-trivial applications work fine on the uart/puc
combination.  Hylafax requires correct modem control that is FLAWLESS or
it WILL blow up.  This is an area where smart cards have in the past run
into driver trouble (going back years; I have lots of experience with
driver issues on so-called "smart" cards going back more than a decade
in this sort of application!) and now, it appears that sickness has
translated into the UART driver as well.

The system in question sends hundreds of faxes a day and any sort of
squirrelly driver problems in the serial subsystem show up almost
instantly  (I updated to RC2 on that machine last night and it took less
than an hour for the modems to wedge this morning.)

I tried to flip back to sio() as the driver in GENERIC and it appears
that can't be done, or I'm missing some interdependency somewhere (doing
so throws all sorts of errors related to the include files)

-- Karl