Hi,
the path_id script was apparently written with the assumption that the
hierarchy of IEEE1394 device representation begins with fw-host devices
and ends with children (node entry devices) or grandchildren (unit
directory devices) of them.
If there are more levels of descendant devices than that, i.e. if there
are children of unit directory devices, then path_id may get stuck with
100% CPU utilization.
This is not a problem with current mainline drivers. But there is a new
driver to be added soon which adds input devices which would naturally
be children of unit directory devices. (It's the firedtv driver for
FireDTV DVB devices which feature a remote control. See
http://ieee1394.wiki.kernel.org/index.php/Out-of-tree_Kernel_Drivers and
http://user.in-berlin.de/~s5r6/linux1394/firedtv/.)
I will work around this path_id bug by making the input devices children
of the fw-host devices. The drawback is that some useful information
from the unit directory device and node entry device (like model,
vendor, and unique ID) will be unavailable that way.
Strangely, path_id does not hang due to the dvb child and dvb/*
grandchildren of the node entry device.
(I tested with Gentoo's udev-124-r1.)
I hope that I won't need that workaround when I port firedtv from the
ieee1394 stack to the firewire stack. The firewire stack does not have
fw-host devices (only node entry devices and unit directory devices,
with different names and attributes than in the ieee1394 stack), hence
path_id's ieee1394 heuristics will not be triggered if the firewire
stack is running.
Just FYI.
--
Stefan Richter
-=====-==--- =--= ===-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
