kern/109743: The sio(4) driver appears to be getting the serial
port speed multiplier bits wrong.
aphor at mac.com
Fri Mar 2 05:40:10 UTC 2007
>Synopsis: The sio(4) driver appears to be getting the serial port speed multiplier bits wrong.
>Arrival-Date: Fri Mar 02 05:40:04 GMT 2007
>Release: FreeBSD 6.2-STABLE i386
Vintage FIC SD11 Athlon Slot-A PC motherboard.
Serial port settings via sofware are not effective on the hardware device.
This *used* to work, but I can't remember when I had to change the batteries last...
probably 18-24 months ago. Ancient history, but my point is that the hardware hasn't changed.
The behavior is identical using puc(4) ports and built-in serial port at sio0, so it doesn't appear
to be puc(4) or shady cheap hardware at fault. Maybe it's ACPI bugs?
- dmesg -
puc0: NetMos NM9835 Dual UART and 1284 Printer port port 0xd400-0xd407,0xd000-0xd007,0xcc00-0xcc07,0xc800-0xc807,0xc400-0xc407,0xc000-0xc00f irq 10 at device 4.0 on pci0
sio4: NetMos NM9835 Dual UART and 1284 Printer port on puc0
sio4: type 16550A
sio4: unable to activate interrupt in fast mode - using normal mode
sio5: NetMos NM9835 Dual UART and 1284 Printer port> on puc0
sio5: type 16550A
sio5: unable to activate interrupt in fast mode - using normal mode
sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x30 on acpi0
sio0: type 16550A, console
I discovered this trying to get my puc(4) serial ports wired to my APC SmartUPS. I got frustrated
and broke out my null-modem cable. When I set up the serial port in /etc/ttys as root autologin,
I can get a shell via the serial port at 9600 baud despite the 2400 baud gettytab entry on the
/etc/ttys line for that port. When I type 'stty speed 9600' in that prompt across the serial
line, I get garbage until I switch to 38400 baud. When I stty to 600, I can communicate at 2400.
Get two PCs and hook up a serial debugger on one port and another null modem cable on the other.
Observe the bit-twiddling on the subject kernel's second serial port via debugger on the first port
as stty does its ioctl(2) magic. Marvel at the layers of abstraction that must be penetrated to
understand what went wrong. Read more code than you want to. Please?
>System: FreeBSD horizon.aphor.net 6.2-STABLE FreeBSD 6.2-STABLE #53: Tue Feb 27 22:37:03 CST 2007 root at horizon.aphor.net:/usr/obj/usr/src/sys/ATHLON i386
More information about the freebsd-bugs