kern/147082: [uart] Serial ports unusable

[Mayo Jordanov]

On 2010-06-04, at 20:47 , Garrett Cooper wrote:

> On Fri, Jun 4, 2010 at 5:28 PM, Mayo Jordanov <mayo at oyam.ca> wrote:
>> Hi Andy,
>> 
>> Thanks for the suggestion. I have all my ports mapped directly as you have, and I also tried setting the bios to reserve the IRQs so nothing else gets to use them.
>> 
>> Thank you for the suggestions and keeping an eye on this.
>> mayo
>> 
>> On 2010-06-04, at 16:43 , Andy Farkas wrote:
>> 
>>> On Sat, Jun 5, 2010 at 5:00 AM, Mayo Jordanov <mayo at oyam.ca> wrote:
>>>> 
>>>>  One more report, I loaded FreeBSD 6.4 on this machine, and the serial =
>>>>  ports work without any problems.=
>>>> 
>>> 
>>> Hi Mayo,
>>> 
>>> You might remember that I was having this problem as well, no output on
>>> serial ports, on my HP ProLiant ML 100 box.
>>> 
>>> I solved it by going into BIOS and explicitly setting the COM ports to
>>> 3F8/4 and 2F8/3. They were set to AUTO before. As a side note, when set
>>> to AUTO, COM2 did not show up in dmesg.
>>> 
>>> What are your BIOS settings?
> 
> Was this an upgrade or a fresh install? If it was an upgrade, what
> version of FreeBSD did you upgrade from? Can you please provide your
> device.hints file?
> Thanks,
> -Garrett

Hi Garrett,

I started looking at the code a bit. I'm not very experienced with inner workings of serial or kernel drivers, but here are a few observations I made:

With the uart in current state and terminal application on each end (using cuau3 atm), the FreeBSD side gets DTR, RTS On and CD, DST, CTS, RI are off. If I change device.hints and set flags for the port and add 0x100 to it (UART_FLAGS_FCR_RX_LOW) followed by a reboot and repeat the setup, I get: DST, CTS, DTR, RTS on and CD, RI off. 

The odd thing there is even at this point if I connect two terminal applications and turn off flow control, I can't get them to send stuff back and forth. So, the signals on port are detected, but there is still something that prevents data to be sent/received. I see the data arrive on the pins when I scope them, so the data must be lost somewhere in software.

I've noticed this when I compared the 6.4 sio driver with 7.3's sio driver. 6.4 uses FIFO_RX_LOW, whereas 7 switched to using FIFO_RX_HIGH. In 7.x the driver doesn't work and reports silo overflows. Changing the FIFO_RX_HIGH to FIFO_RX_LOW (sio.c line 976 -- "sio_setreg(com, com_fifo, FIFO_ENABLE | FIFO_RX_HIGH);" ) fixes things in 7.x and then works same as in 6.4.w

Similarly, there are quite a few differences in how some of the other registers are setup in _attach, _probe and other functions. There are definitely more DELAY calls in the old driver. Like I said, I'm not very familiar with lower levels of serial comms or I'm not sure what exactly this means for the driver, but may give you some ideas. Also, opening /dev/cuau* devices is quick, but closing them always times out in ttyclos() (when exiting kermit, etc).

Thanks,
mayo