Red Hat Bugzilla – Bug 486427
haldaemon crashes if /dev/ttyS* does not exist
Last modified: 2010-03-30 04:32:48 EDT
Created attachment 332595 [details]
extra checks during detection of ttyS-devices
Description of problem:
The haldaemon crashes if /sys/class/tty/ttyS* exists but /dev/ttyS* has been removed/modified.
Version-Release number of selected component (if applicable):
hal-0.5.3.8-35.el5 (as released unmodified with CentOS-5.2)
Steps to Reproduce:
1. rm -f /dev/ttyS* (or only one of the ttyS-nodes)
2. service haldaemon restart
Starting HAL daemon: [FAILED]
Starting HAL daemon: [ OK ]
Removing/modifying /dev/ttyS* devices is a common advice (i.e. http://lkml.org/lkml/2009/1/29/133) for users with lots of serial-ports. Some PCI-boards with serial-ports provide more than the actual physical ports. A board with support for 4-ports can actually have only 2-ports. If two or more of these PCI-boards are used, the numbering of the ttyS-devices makes no sense for common users.
PCI-board #1 provides:
ttyS4 - labeled COM5 on the hardware
ttyS5 - labeled COM6 on the hardware
ttyS6 - not available
ttyS7 - not available
PCI-board #2 provides:
ttyS8 - labeled COM7 on the hardware
ttyS9 - labeled COM8 on the hardware
ttyS10 - not available
ttyS11 - not available
With a custom script the serial-ports of these two PCI-boards are removed and created (mknod) again so that the label on the hardware matches the /dev/ttyS* node. /sys/class/tty still contains a complete reference to all the ttyS-devices. hald seems to get confused if devices are listed under /sys/class/tty but are missing under /dev.
Could you please provide a backtrace (with debuginfo for hal) when this happens please.
Created attachment 335496 [details]
backtrace with gdb on the crash
gdb and haldeamon started with following command:
script -f hald-gdb.log -c "gdb --args hald --daemon=no --verbose"
Niels, if I built a test package, would you be able to install it and test a patch? It's a bit tricky to test on my local machine. If it's okay with you, I'll just spin a set of test rpms.
(In reply to comment #3)
> Niels, if I built a test package, would you be able to install it and test a
> patch? It's a bit tricky to test on my local machine. If it's okay with you,
> I'll just spin a set of test rpms.
Yes, that's fine.
Note that I'm testing on CentOS-5.2, so please no incompatible 5.3 RPMs.
Just a note that the same bug is still there on 5.3 - hal-0.5.8.1-38.el5.
Are there any RPMs for testing already? CentOS-5.3 is out, so I'll be able to test any current release.
Uhm... the statements above are not really correct any more. As you'll notice my emailaddress changed and now I'm able to run tests on RHEL :)
A tiny check to see if hal_device_property_get_string (d, "linux.device_file") is NULL would fix this. It would be a trivial two line patch.
Built as http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2106624
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.