First off, about the buffer issue, I'm not sure why but I couldn't
reproduce it. :/ Rebooted a few times, with the default buffer, and
mdevd-netlink never complained.
I still have the old messages in my logs, it happened every single
reboot, and not once this time.... don't know. Maybe I'll try again
later, maybe it's the weather... :D
(I even tried rebooting w/out strace/tee in case, same thing. Damn, I
don't get it, why do things work? uh?... :p)
On Tue, 09 Jan 2018 13:36:48 +0000
"Laurent Bercot" <ska-skaw...@skarnet.org> wrote:
> >By that I mean, currently if I don't do anything else, some things
> >aren't processed. For instance, my audio card isn't there, neither
> >are a few input devices, such as my (usb) mouse.
> I can't reproduce the problem on my system: mdevd-coldplug detects
> all the USB devices. But it's a small system with no fancy hardware.
Not sure I have fancy hardware, but who knows :p
% uname -a
Linux arch.local 4.14.11-1-ARCH #1 SMP PREEMPT Wed Jan 3 07:02:42 UTC
2018 x86_64 GNU/Linux
Not an old kernel, and no firmware involved. What I found out is that,
there are no symlinks in /sys/dev at first no. I'll use my audio card as
So upon boot, nothing in /sys/dev points to it. But if I write "add"
to /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/uevent then magic
happens, uevents are triggered, modules loaded, and now my audio card is
there. Also symlinks of related devices do appear in /sys/dev/char:
ls -lR /sys/dev/char|grep 01:00.1
lrwxrwxrwx 1 root root 0 Jan 9 19:58 116:2
lrwxrwxrwx 1 root root 0 Jan 9 19:58 116:3
lrwxrwxrwx 1 root root 0 Jan 9 19:58 116:4
lrwxrwxrwx 1 root root 0 Jan 9 19:58 13:67
Thing is, before writing to that uevent, there was nothing of the sort
% cat uevent
% ls -l subsystem
lrwxrwxrwx 1 root root 0 Jan 9 20:07 subsystem -> ../../../../bus/pci
I see similar results for e.g. my mouse, not there (or in /dev/input)
until I write "add"
or the pc speaker, not there until I write "add"
to /sys/devices/platform/pcspkr/uevent, only then does /sys/dev/char/13:66
to ../../devices/platform/pcspkr/input/input2/event2) appear.
If that's any consolation, `mdev -s` doesn't do any better than
mdevd-coldplug, so maybe it works as expected, and I do have fancy
hardware after all.
(I can't remember if I had tried it before or not, but maybe that was
why I didn't use it, and used my own trigger-uevents service instead.)
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...