From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Renninger Subject: Re: backlight mystery Date: Thu, 08 Mar 2007 17:57:31 +0100 Message-ID: <1173373051.5863.70.camel@queen.suse.de> References: <20070305233037.0c5727e7.akpm@linux-foundation.org> <20070306074312.GC23955@redhat.com> <20070305234812.d8b2b08d.akpm@linux-foundation.org> <20070306171050.GE26813@redhat.com> Reply-To: trenn@suse.de Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mail.suse.de ([195.135.220.2]:37193 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752558AbXCHQ5h (ORCPT ); Thu, 8 Mar 2007 11:57:37 -0500 In-Reply-To: <20070306171050.GE26813@redhat.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org Cc: Zhao Forrest , Andrew Morton , Richard Purdie , linux-acpi@vger.kernel.org, Dave Jones 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 wrote: > > > On Tue, 6 Mar 2007 02:43:12 -0500 Dave Jones 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: [] kref_get+0x2f/0x34 [] kobject_get+0x12/0x17 [] get_driver+0x14/0x1a [] driver_remove_file+0x11/0x32 [] bus_remove_driver+0x1c/0x90 [] driver_unregister+0xd/0x16 [] :asus_acpi:asus_acpi_exit+0x21/0x35 Starting D-Bus d [] sys_delete_module+0x1b1/0x1e0 aemonESC7ESC[?25l^MESC[ [] dma_alloc_coherent +0x57/0x23f 80CESC[10DESC[1;32md [] system_call+0x7e/0x83 oneESC[m^OESC8ESC[?25h^M BUG: at lib/kref.c:32 kref_get() Call Trace: [] kref_get+0x2f/0x34 [] kobject_get+0x12/0x17 Starting irqbala [] get_driver+0x14/0x1a nce ESC7ESC[?25l^MESC[8 [] kobject_release+0x0/0x9 0CESC[10DESC[1;32mdo [] driver_remove_file+0x11/0x32 neESC[m^OESC8ESC[?25h^M^M [] bus_remove_driver +0x2b/0x90 acpid: loading [] driver_unregister+0xd/0x16 ACPI modules ( a [] :asus_acpi:asus_acpi_exit +0x21/0x35 c battery button [] sys_delete_module+0x1b1/0x1e0 ) ESC7ESC[?25l^MESC[80 [] dma_alloc_coherent +0x57/0x23f CESC[10DESC[1;32mdon [] system_call+0x7e/0x83 eESC[m^OESC8ESC[?25h^M acpid: will not Unable to handle kernel NULL pointer dereference at 0000000000000020 RIP: [] 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,