+++ This bug was initially created as a clone of Bug #204825 +++

Description of problem:
In kernel-xen0, CONFIG_SERIAL_8250 is set to "m" instead of "y" as in non-Xen
kernels. Consequently, serial ports cannot be accessed unless "modprobe 8250" is
run first.

One package this impacts is "nut" (Network UPS Tools). When booting using a xen0
kernel, the daemon fails to start with this error message:

"Can't connect to UPS [ups] (apcsmart-ttyS0): No such file or directory"

Version-Release number of selected component (if applicable):
kernel-xen0-2.6.17-1.2174_FC5

How reproducible:
Always

Steps to Reproduce:
1. Set up "nut" on a non-Xen kernel with a UPS attached to ttyS0.
2. Reboot and observe that "nut" starts successfully.
3. Add "xencons=off" to your Xen kernel's command line in /boot/grub/grub.conf.
(This step is necessary to prevent Xen from trying to attach a console to a
serial port.)
4. Boot into the Xen kernel.
  
Actual results:
Because 8250 is compiled as a module, "nut" fails to start with the message:

"Can't connect to UPS [ups] (apcsmart-ttyS0): No such file or directory"

Expected results:
"nut" should start with no errors.

-- Additional comment from russell.au on 2006-10-30 03:35 EST --
"modprobe 8250" doesn't work with kernel 2.6.18-1.2200.fc5xen for me on a P3 
system.

-- Additional comment from sct on 2006-10-30 07:30 EST --
Does it work on FC6?


-- Additional comment from jr-redhatbugs on 2006-10-30 14:38 EST --
It's still a problem in FC6.

# grep CONFIG_SERIAL_8250= config-2.6.18-1.2798.fc6*
config-2.6.18-1.2798.fc6PAE:CONFIG_SERIAL_8250=y
config-2.6.18-1.2798.fc6xen:CONFIG_SERIAL_8250=m   <----

-- Additional comment from sct on 2006-11-02 18:29 EST --
Question was not whether it was modular, but whether the module works (comment
#1).  We know it is modular, and it needs to stay that way, I'm afraid.

The problem is that the kernel is not the only driver of the serial ports: the
hypervisor has the ability to log to serial too, so there's handshaking between
the kernel and Xen for serial console.  That does not use the normal kernel
serial driver, hence that driver gets loaded as a separate module.

Arguably, though udev or kudzu should be loading the module in this case.

-- Additional comment from notting on 2006-11-03 12:23 EST --
ACTION=="add", SUBSYSTEM=="pnp", RUN+="/bin/sh -c 'while read id; do
/sbin/modprobe pnp:d$$id ; done < /sys/$devpath/id'"

in udev rules will load the 8250_pnp driver for most modern PCs with PNP BIOSes
(tested on both x86 and x86_64.) Not sure there's much else we can do to
automatically detect it. PCI serial ports should already be picked up.

-- Additional comment from sct on 2006-11-15 16:55 EST --
Need feedback --- does that udev rule help?


-- Additional comment from jr-redhatbugs on 2006-11-20 14:18 EST --
No. I saved the above line to /etc/udev/rules.d/TEST.rules and rebooted. dmesg
shows that it's attempting to load the 8250 driver:

Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

But then:

8250_pnp: Unknown symbol serial8250_unregister_port
8250_pnp: Unknown symbol serial8250_register_port

If I try to start "nut" after that, it can't find ttyS0.

(This is on a fully-updated system. kernel-xen-2.6.18-1.2849.fc6, udev-095-14)

-- Additional comment from jr-redhatbugs on 2006-11-20 14:26 EST --
And running "modprobe 8250" manually doesn't work anymore in the latest xen kernel:

FATAL: Error inserting 8250
(/lib/modules/2.6.18-1.2849.fc6xen/kernel/drivers/serial/8250.ko): Device or
resource busy

even if I remove the udev rule and reboot. I guess these problems are related?

-- Additional comment from jr-redhatbugs on 2006-11-20 14:34 EST --
OOPS! Please disregard my last two comments. I had forgotten to include
"xencons=off" in my kernel command line...

Yes, the udev rule works. nut now starts successfully on boot.

-- Additional comment from sct on 2006-11-20 16:19 EST --
Bill, is this something we can set in the udev rules by default, or would that
cause problems on non-xen kernels?

-- Additional comment from notting on 2006-11-20 16:28 EST --
Not-the-udev-maintainer, but it shouldn't cause any issues. It doesn't fully
support all PnP devices, but works for things like serial or parallel ports.