Thing is, before writing to that uevent, there was nothing of the sort
in /sys/dev.

 What it looks like is the kernel not assigning a major and a minor
to the device before you manually trigger the "add". I suspect it's
just that the relevant module is not loaded, but why would that be
different from any other hardware managing to make mdevd autoload the
appropriate module? It's weird, and my kernel knowledge is insufficient
to understand this. If someone's more familiar with the internals of
the Linux kernel, especially module loading and hardware detection,
please stand up.

 Question that may help:
 - does your /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1 directory
contain a "dev" file: before you manually trigger the add? afterwards?

Note that I don't mind just using my trigger-uevents service instead,
it's what I used to do anyway; I just figured, as I switched to mdevd,
since there's a coldplug thing might as well give it a try...

 Well I certainly don't want people to need to write their own
trigger-uevents service, so I'll make sure your hardware is properly
found by mdevd-coldplug. I'd just like to understand what is happening
and add the proper fix rather than take a big hammer and scan all of
/sys/devices just to be sure.


Reply via email to