Just a thought..
I had a similar issue, but with totally different hardware. And the issue i had then was that udev was not started/completely started at the time the modules where loaded so some parts where 'cold-booted' and some where hotplugged. (running gentoo myself and gentoo do have udev issues) Just as a test, could you try and skip loading the modules during boot and manually load them when the system is up and see how that behaves? Or maybe you have already tried some version of this? /Patric Michael Thome wrote: > Sander Sweers wrote: > > On 7/10/07, Michael Thome <[EMAIL PROTECTED]> wrote: > > > >> My system has one pvr-150 and one pvr-500 (very sadly, one with samsung > >> tuners) - one of them (pvr-500, first tuner) is hooked to my cable box > >> for digital/premium content, the others direct to analog cable. I've > >> got udev rules to set up aliases according to physical location (pci > >> slot / pvr-500 unit) - the rules always test fine and never create the > >> wrong aliases, but they sometimes don't all fire, leaving me with one or > >> more tuners missing via the aliases I'm trying to set up. > >> > > > > The only thing I can think of is that another udev rule catches the > > event before yours (and I though processing stops at that point). > > > Doesn't seem to be the case: the udev logs don't show anything like that > happening. > > But I find it strange that the device naming is so unpredictable for > > you. For me it consistently creates the same device names. it only > > changes when I move the cards around or add a new video device. > > > Yah - very strange. It also really bugs me that the minor device numbers > aren't > stable - it blows my mind that the devices are being enumerated in a > non-deterministic way. I'm guessing that someone thought it would be cool to > multi-thread the hotplug system (I'm running on an dual-core machine). Hmmmm > - > LKML perusal suggests that multithreaded device probing was, indeed, patched > in > around a year ago - it looks like the PCI patch wasn't committed until 2.6.18 > (and I'm running 2.6.17). Maybe more udev logging would help. > > You can try to force ivtv to start counting from a specific minor by > > passing ivtv_first_minor=<number> to the module, maybe this helps? > > > > > Nope - the primary devices all get created correctly - the symlinks just > don't > work right. Perhaps the threaded probing is causing problems with the /dev > vfs > - maybe a simpler scheme like /dev/mpeg[01][ab] would help. As an aside, I > also > create parallel yuv, vbi, and pcm devices in the same /dev/pci/[01]/ trees - > it > is interesting that all the devices associated with a video unit appear or > disappear together, even though they are different rules for each type (e.g. > if > /dev/pci/1/mpeg1 is there, /dev/pci/1/pcm1 will always be there, too). > > Thanks for the suggestions. > > I suspect that when that when I have to do an upgrade everything will change > anyway, but it would be nice to understand what is going on. > > cheers! > > ------------------------------------------------------------------------ > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
