I have a custom kernel which has some additional acpi modules compiled: asus_acpi and toschiba_acpi. The current code tries to load this modules even though this is a sony laptop. Causing unneeded modules to be loaded respectively errors during boot. Hence I suggest something like: --- rc.sysinit.save 2003-10-15 21:00:16.000000000 +0200 +++ rc.sysinit 2003-10-15 21:06:32.000000000 +0200 @@ -171,8 +171,11 @@ # Initialiaze ACPI bits if [ -d /proc/acpi ]; then - for module in /lib/modules/`uname -r`/kernel/drivers/acpi/* ; do - insmod $module + ACPIMODULES="ac battery button fan processor thermal" + [ -f /etc/sysconfig/acpi ] && . /etc/sysconfig/acpi + modulesdir=/lib/modules/`uname -r`/kernel/drivers/acpi + for module in $ACPIMODULES ; do + [ -f $modulesdir/$module.o ] && modprobe $module done fi
I'd rather not have to keep a list of what new modules may end up being 'required' and then have to change initscripts whenever the kernel changes.
How about this? --- rc.sysinit.orig 2003-11-07 21:38:40.000000000 -0600 +++ rc.sysinit 2003-11-07 21:45:05.000000000 -0600 @@ -171,9 +171,16 @@ # Initialiaze ACPI bits if [ -d /proc/acpi ]; then - for module in /lib/modules/`uname -r`/kernel/drivers/acpi/* ; do - insmod $module - done + if [ -f /etc/sysconfig/acpi ]; then + . /etc/sysconfig/acpi + for module in $ACPIMODULES ; do + modprobe $module + done + else + for module in /lib/modules/`uname -r`/kernel/drivers/acpi/* ; do + insmod $module + done + fi fi # Initialize USB controller and HID devices
Seconded.
Yes, the message about toshiba_acpi failure is really annoying. Users think there is a error here - while actually it is not.
*** Bug 109940 has been marked as a duplicate of this bug. ***
*** Bug 115680 has been marked as a duplicate of this bug. ***
I'm not sure exactly how things are in this area. I'd link to think that modules will load on the hardware that they support and nothing else. In this case meaning that if the toshiba_acpi.ko can't be loaded it must be because it won't work on the target machine. If this is all true - Why can't we handle this simply by redirecting insmod output to /dev/null and perhaps doing some checks in /proc to see if things look okay?
*** Bug 116689 has been marked as a duplicate of this bug. ***
*** Bug 116785 has been marked as a duplicate of this bug. ***
This message has been cleaned up.