On 2010-06-04, at 20:47 , Garrett Cooper wrote: > On Fri, Jun 4, 2010 at 5:28 PM, Mayo Jordanov <m...@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 <m...@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 _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
