I wrote:
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.
...
I will work around this path_id bug by making the input devices children
of the fw-host devices.
PS:
I don't know if the hierarchy depth is really the cause of the bug.
I only know that the workaround prevents the bug.
Example of a desired but unsafe path, without workaround:
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:03.0/fw-host0/0012870036002bd7/0012870036002bd7-0/input/input14
Example of a safe path, i.e. with workaround:
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:03.0/fw-host0/input/input21
At the currently posted patchlevel (no "real" parent device provided to
the input subsystem), the path looks like this, which is safe too:
/devices/virtual/input/input12
At the same time, the following devices aren't a problem for path_id:
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:03.0/fw-host0/0012870036002bd7/0012870036002bd7-0/dvb/
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:03.0/fw-host0/0012870036002bd7/0012870036002bd7-0/dvb/dvb0.demux0/
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:03.0/fw-host0/0012870036002bd7/0012870036002bd7-0/dvb/dvb0.dvr0/
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:03.0/fw-host0/0012870036002bd7/0012870036002bd7-0/dvb/dvb0.frontend0/
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:03.0/fw-host0/0012870036002bd7/0012870036002bd7-0/dvb/dvb0.net0/
--
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
