Taking a suggestion from the discussion regarding the aforementioned bug I altered /boot/grub/grub.conf and added this entry:
title CentOS (2.6.18-53.1.4.el5xen-com1) root (hd0,0) kernel /xen.gz-2.6.18-53.1.4.el5 com1=38400,8n1 module /vmlinuz-2.6.18-53.1.4.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet xencons=xvc console=xvc module /initrd-2.6.18-53.1.4.el5xen.img
Which explicitly sets the console for the xen root to com1 and bypasses the module altogether. This works as can be seen by:
# setserial -g /dev/ttyS* /dev/ttyS0, UART: unknown, Port: 0x03f8, IRQ: 4 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 /dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4 /dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
However, since this fix will get clobbered on the very next kernel update the recommended method seems to be to add these rules to udev:
ACTION=="add", SUBSYSTEM=="pnp", RUN+="/bin/sh -c 'while read id; \ do /sbin/modprobe pnp:d$$id ; done < /sys/$devpath/id'"
Can somebody tell me how to do that? Where do I do this. I have very little experience with this sort of thing. As this bug is reported upstream and is more than a year old I have some difficulty understanding how it persists in CentOS-5.
Regards,