> > > > I get another complaint with hid.o and a missing mousedev module > > > > (which makes sense because moudev.o is only for PS/2 mice, I believe; > > > > however, before init starts there's a log "mice: PS/2 mouse device > > > > common for all mice"). > > > > > > Which doesn't sound like it's only for PS/2 mice, does it? :) > > > > Actually, I find the log confusing. But perhaps that's because the > > mousedev module is not currently built for Debian PPC kernels, > > It's built in, isn't it? > > grep MOUSEDEV= /boot/config-`uname -r` > > > and I'm looking for some reason that it's getting modprobed. > > mousedev is loaded and in use here, I guess it's the driver behind > /dev/input/mice and friends. My guess is /sbin/hotplug tries to load it > when the kernel generates a hotplug event for the mouse (or trackpad?).
I hadn't thought about that possibility. But you're right; it's built-in here as well. > > > The input related module(s) could be loaded by something like hotplug. > > > > The /etc/init.d/hotplug script hasn't been run at this point. Though I > > think that the kernel might call /sbin/hotplug when it gets a hotplug > > event, > > Indeed, it does. So, I've figured out what's going on. Because I have a USB mouse plugged in when I boot, /sbin/hotplug is called asynchronously by the kernel (2.4.20) before init is started. /etc/hotplug/usb.agent checks the magic code of the USB device against the list of built modules in /lib/modules/2.4.20-powerpc/modules.usbmap. After that, it looks in /etc/hotplug/usb.handmap for a (short) list of problematic modules that might match the magic code. My USB mouse matches the mousedev entry there, so hotplug tries to modprobe mousedev and fails (because there's no mousedev module). A workaround to not see this (cosemetic) error message is to add a line "mousedev" to /etc/hotplug/blacklist which will cause hotplug to delete mousedev from the list. I think the real fix is for hotplug to only add modules from usb.handmap if there is actually a module by that name on the system. (In the modules.usbmap, that can be assumed.) > > though it only loads hid at this point, not all the unix.o module (I'd > > guess). > > My only idea for the unix module is that something tries to access a > UNIX socket, and the kernel autoloads it. > > Maybe all the problems are caused by or at least related to the /proc > weirdness? For mousedev, no. It's hotplug. However, I think you might be right about /proc and unix.o. I've also noticed that on shutdown some script complains about /proc already being mounted. Now that I have a setup for reproducing these early things, that can be my next project. :) (Although looking at the subject of this thread, that was my current project!) Thanks for you help on this. Your comments helped me think about what was really going on. Frank
