On Tue, 2007-03-06 at 12:10 -0500, Dave Jones wrote:
> On Tue, Mar 06, 2007 at 03:58:01PM +0800, Zhao Forrest wrote:
> > On 3/6/07, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > On Tue, 6 Mar 2007 02:43:12 -0500 Dave Jones <davej@xxxxxxxxxx> wrote:
> > >
> > > > On Mon, Mar 05, 2007 at 11:30:37PM -0800, Andrew Morton wrote:
> > > > >
> > > > > I always get stuff like this coming out when I boot my x86_64 machine:
> > > > >
> > > > > asus_acpi: Unknown symbol backlight_device_unregister
> > > > > asus_acpi: Unknown symbol backlight_device_register
> > > > > ibm_acpi: Unknown symbol backlight_device_unregister
> > > > > ibm_acpi: Unknown symbol backlight_device_register
> > > > > toshiba_acpi: Unknown symbol backlight_device_unregister
> > > > > toshiba_acpi: Unknown symbol backlight_device_register
> > > > > video: Unknown symbol backlight_device_unregister
> > > > > video: Unknown symbol backlight_device_register
> > > > >
> > > > > This is a nocoma server, not a laptop. I'm not sure how those modules are
> > > > > even getting loaded. The distro is FC4, which might be doing something
> > > > > peculiar.
> > > >
> > > > I covered this on the list last week. There's no way to
> > > > have a module autoload based on dmi strings or the like,
> > > > (Which is the only sane way these modules can determine
> > > > if they need to run).
> > > >
> > > > Given the absense of mechanism, there's a pretty gross hack
> > > > in Fedora's rc.sysinit which loads every module in drivers/acpi/*/*
> > > > that it finds. Shameful I know.
> > >
> > > I thought it might be something like that. I'm a bit surprised that we
> > > can't get at the DMI stuff from userspace, or export it from the kernel.
> > > But whatever.
> >
> > I have a question: why can't we get at the DMI stuff from userspace
> > since "dmidecode" is a tool in userspace?
>
> We can, but we could do better.
> What's missing is an *event* that udev can see, so that it
> knows what to do.
>
> Imagine: asus_acpi gets a MODULE_DMI("ASUS") or whatever, and then
> at boottime, we register a sysfs modalias of the system DMI string.
> Suddenly we have two pieces of the puzzle, and udev will see the
> modalias and happily pull in any modules that match the alias.
>
> All without any changes to userspace at all.
I also saw asus_acpi module loaded on a server.
rmmodding it results in (sorry about escape chars):
BUG: at lib/kref.c:32 kref_get()
Call Trace:
[<ffffffff80232ed2>] kref_get+0x2f/0x34
[<ffffffff802501ed>] kobject_get+0x12/0x17
[<ffffffff80386422>] get_driver+0x14/0x1a
[<ffffffff80386439>] driver_remove_file+0x11/0x32
[<ffffffff803858e8>] bus_remove_driver+0x1c/0x90
[<ffffffff8038637e>] driver_unregister+0xd/0x16
[<ffffffff8829e79d>] :asus_acpi:asus_acpi_exit+0x21/0x35
Starting D-Bus d [<ffffffff802981ad>] sys_delete_module+0x1b1/0x1e0
aemonESC7ESC[?25l^MESC[ [<ffffffff80220069>] dma_alloc_coherent
+0x57/0x23f
80CESC[10DESC[1;32md [<ffffffff8025511e>] system_call+0x7e/0x83
oneESC[m^OESC8ESC[?25h^M
BUG: at lib/kref.c:32 kref_get()
Call Trace:
[<ffffffff80232ed2>] kref_get+0x2f/0x34
[<ffffffff802501ed>] kobject_get+0x12/0x17
Starting irqbala [<ffffffff80386422>] get_driver+0x14/0x1a
nce ESC7ESC[?25l^MESC[8 [<ffffffff803115bb>] kobject_release+0x0/0x9
0CESC[10DESC[1;32mdo [<ffffffff80386439>] driver_remove_file+0x11/0x32
neESC[m^OESC8ESC[?25h^M^M [<ffffffff803858f7>] bus_remove_driver
+0x2b/0x90
acpid: loading [<ffffffff8038637e>] driver_unregister+0xd/0x16
ACPI modules ( a [<ffffffff8829e79d>] :asus_acpi:asus_acpi_exit
+0x21/0x35
c battery button [<ffffffff802981ad>] sys_delete_module+0x1b1/0x1e0
) ESC7ESC[?25l^MESC[80 [<ffffffff80220069>] dma_alloc_coherent
+0x57/0x23f
CESC[10DESC[1;32mdon [<ffffffff8025511e>] system_call+0x7e/0x83
eESC[m^OESC8ESC[?25h^M
acpid: will not Unable to handle kernel NULL pointer dereference at
0000000000000020 RIP:
[<ffffffff803f8a02>] klist_del+0xa/0x46
PGD 21f3d0067 PUD 21efa9067 PMD 0
Oops: 0000 [1] SMP
CPU 0
This patch fixes it (Len, can you apply this?):
Do not load asus_acpi if no device has been found
Do not rely on acpi_bus_register_driver() return value which
is always zero, even no device has been found.
---
drivers/acpi/asus_acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21-rc3/drivers/acpi/asus_acpi.c
===================================================================
--- linux-2.6.21-rc3.orig/drivers/acpi/asus_acpi.c
+++ linux-2.6.21-rc3/drivers/acpi/asus_acpi.c
@@ -1398,7 +1398,7 @@ static int __init asus_acpi_init(void)
if (!asus_hotk_found) {
acpi_bus_unregister_driver(&asus_hotk_driver);
remove_proc_entry(PROC_ASUS, acpi_root_dir);
- return result;
+ return -ENODEV;
}
asus_backlight_device = backlight_device_register("asus",NULL,NULL,
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
