Difference between revisions of "Common Problem: namespace race conditions"
m (→The Problem: Clear statement of the "problem" itself.) |
m (→The Problem: Grammatical and syntax rewrites) |
||
| Line 8: | Line 8: | ||
==The Problem== | ==The Problem== | ||
| − | An old problem that originally occurred when udev/HAL were first being deployed has come back to haunt you. | + | An old problem that originally occurred when udev/HAL were first being deployed has come back to haunt you. |
| + | |||
| + | Prior to the developments of udev/HAL, if you had two of the same piece of hardware in your machine, it was up to you to find a way to be certain that either they couldn't swap places between reboots or that it didn't matter if it did. At that time, the kernel searched for these devices in a specific order which avoided many potential problems. | ||
| + | |||
| + | The change to having udev enumerate (in short, identify them, load their respective driver, and give them their /dev node if applicable) devices on USB and PCI buses brought this problem back with a vengeance. Initially udev loaded driver modules based on whichever devices on the bus identified themselves ''first'', but this is not ''guaranteed'' to happen in the same order very time. The changes to udev to ensure that devices are enumerated consistently in the same order applies to each individual bus and under certain circumstances ''may still fail to do what you expect'' if these devices are on different buses. This may be the case if you have both PCI and USB tuner devices. | ||
==The Solution== | ==The Solution== | ||
Revision as of 04:26, 24 January 2010
The Symptom
If you're here it's because you're experiencing a problem where your various tuners don't always seem to wind up with the same device name each time the machine boots and it's causing your backend to fail to use the correct tuner (or any tuner at all) to record with.
This is most likely to occur if you have multiple tuner devices on separate buses (meaning one or more USB devices and/or one or more PCI devices), although it can potentially happen under rarer circumstances like the cards being moved around inside the machine, or the USB devices being plugged into a different hub or different ports.
Solving this problem can be done semi-permanently with little risk to the rest of your configuration but will require a small amount a reading, a few shell commands, and the ability to cut and paste short strings without making mistakes.
The Problem
An old problem that originally occurred when udev/HAL were first being deployed has come back to haunt you.
Prior to the developments of udev/HAL, if you had two of the same piece of hardware in your machine, it was up to you to find a way to be certain that either they couldn't swap places between reboots or that it didn't matter if it did. At that time, the kernel searched for these devices in a specific order which avoided many potential problems.
The change to having udev enumerate (in short, identify them, load their respective driver, and give them their /dev node if applicable) devices on USB and PCI buses brought this problem back with a vengeance. Initially udev loaded driver modules based on whichever devices on the bus identified themselves first, but this is not guaranteed to happen in the same order very time. The changes to udev to ensure that devices are enumerated consistently in the same order applies to each individual bus and under certain circumstances may still fail to do what you expect if these devices are on different buses. This may be the case if you have both PCI and USB tuner devices.
