Serial port: wrong UART

[BlueH2O]

My F9 machine is behaving strangely.. Every time it boots up it 'forgets' that ttyS0 is a 16550A UART, and it's set to "unknown", and the port does not work. I use setserial /dev/ttyS0 uart 16550A to fix it, but how do I make that a permanent change?

[PabloTwo]

Add the setserial command line to set the UART type to the end of the file: /etc/rc.d/rc.local

setserial /dev/ttyS0 uart 16550A

It will execute at bootup.

[BlueH2O]

Add the setserial command line to set the UART type to the end of the file: /etc/rc.d/rc.local

setserial /dev/ttyS0 uart 16550A

It will execute at bootup.

Yeah, I'm aware of that, but I find it strange I didn't need it before. Is there somewhere else these settings are defined?

[PabloTwo]

Is there somewhere else these settings are defined?
I don't know. I don't consider this a "fix" either, but a "work-a-round". I also consider it just another one of the seemingly endless broken things in F9. Welcome to "the bleeding edge".

[BlueH2O]

I don't know. I don't consider this a "fix" either, but a "work-a-round". I also consider it just another one of the seemingly endless broken things in F9. Welcome to "the bleeding edge".

:) :) :)

The system in question has been bleeding since core 3. Still looking for a tourniquet. :D

[BlueH2O]

If anyone cares, I found another, possibly better fix:

I added a new file /etc/udev/rules.d/99-serial.rules and put in it the following:
KERNEL=="ttyS0", RUN+="/bin/setserial /dev/%k uart 16550" OPTIONS+="last_rule"This accomplishes the same end result but also ensures that the port is ready before any other service starts that wants to use it.
Running udevtest /devices/platform/serial8250/tty/ttyS0 confirms the correct command being run:udevtest: run: '/bin/setserial /dev/ttyS0 uart 16550'

[PabloTwo]

Nice fix, and little above my present level of Linux expertise. But I noticed you dropped the "A" from "16550A". Perhaps inconsequential, or was that perhaps because a query of that serial port using setserial indicated that 16550 is the uart type? Just curious.

[BlueH2O]

Nice fix, and little above my present level of Linux expertise. But I noticed you dropped the "A" from "16550A". Perhaps inconsequential, or was that perhaps because a query of that serial port using setserial indicated that 16550 is the uart type? Just curious.
Because the kernel didn't agree with me that it was a 16550A.. turns out it's 16550.. my bad.
Using 16550A produced a kernel warning in the log: "LSR safety check engaged!"

[Update 6/13/08: my kernel LIED to me, this *IS* a 16550A..]

[BlueH2O]

Bummer- although the serial port seems to be ready, I am still not able to use it.-bash-3.2$ heyu on a8
RI serial line may be stuck.
Unable to send address bytesI remain baffled why my serial port has quit on me since updating to fedora 9.

[hyperspace]

Have you checked the log files for errors?

[BlueH2O]

Have you checked the log files for errors?Nothing useful.. All I have is "heyu_relay: relay setting up-" The process starts but I cannot get any signals out.

[hyperspace]

Where does this error show up? messages or ?

[BlueH2O]

Where does this error show up? messages or ?It's not an error, and yes, in messages.. there is also:
Jun 13 10:58:38 arturo kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

Ports look like this:
/dev/ttyS0, Line 0, UART: 16550, Port: 0x03f8, IRQ: 4
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test auto_irq
/dev/ttyS1, Line 1, UART: 16550, Port: 0x02f8, IRQ: 3
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test auto_irq
/dev/ttyS2, Line 2, UART: unknown, Port: 0x03e8, IRQ: 4
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test auto_irq
/dev/ttyS3, Line 3, UART: unknown, Port: 0x02e8, IRQ: 3
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal auto_irq

The machine has two physical ports.

[BlueH2O]

This is interesting.. These messages would seem to show the ports detected correctly up to June 5th... (And it appears they are, in fact 16550A.. strange the kernel doesn't like that)

anaconda.syslog:<6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
messages.1:Dec 5 19:44:41 arturo kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
messages.1:Dec 5 23:11:42 arturo kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
messages.1:Dec 6 03:45:51 arturo kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
messages.1:Dec 6 10:55:52 arturo kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
messages-20080518:May 15 20:47:33 arturo kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
messages-20080601:May 27 10:06:09 arturo kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
messages-20080608:Jun 1 20:37:37 arturo kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
messages-20080608:Jun 5 12:53:58 arturo kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

[hyperspace]

So, maybe an update has created this issue.

[BlueH2O]

So, maybe an update has created this issue.
I would agree, since that was the day I switched over from fedora 8 to 9! :mad:

[hyperspace]

Ouch! That sucks!

[BlueH2O]

I'm logging this in bugzilla.. we'll see what happens.

https://bugzilla.redhat.com/show_bug.cgi?id=451326