In the driver pci-bus and slot are hard coded, but on 1005ha is ethernet card there. I think there are a kernel-freez-problem too (as in http://bugzilla.kernel.org/show_bug.cgi?id=13390): there are a dead lock. The handler try to remove the wlan-card from pci-bus (it is not any more in lspci, until the pci-bus rescan). The call come from rfkill-device, which is to the wlan-card attached (also locked) and pci_remove_bus_device try to remove all attached to the wlan-card devices.
dmesg: Nov 9 16:29:21 eeekiste kernel: SysRq : Show Blocked State Nov 9 16:29:21 eeekiste kernel: task PC stack pid father Nov 9 16:29:21 eeekiste kernel: events/0 D 00000046 0 9 2 0x00000000 Nov 9 16:29:21 eeekiste kernel: c1d40b00 00000046 c1547890 00000046 00000046 00000000 c102df96 f784df80 Nov 9 16:29:21 eeekiste kernel: f784e10c c15a1b00 c159df64 c159c000 f784e10c c1d40b00 f7872000 f784df80 Nov 9 16:29:21 eeekiste kernel: f7872000 c1547890 00000000 c1547880 c154007b c10b007b f55600d8 00000000 Nov 9 16:29:21 eeekiste kernel: Call Trace: Nov 9 16:29:21 eeekiste kernel: [<c102df96>] ? irq_exit+0x2c/0x58 Nov 9 16:29:21 eeekiste kernel: [<c10b007b>] ? load_elf_binary+0x130a/0x15bf Nov 9 16:29:21 eeekiste kernel: [<c1020815>] ? mutex_spin_on_owner+0x61/0x76 Nov 9 16:29:21 eeekiste kernel: [<c13b19c3>] ? __mutex_lock_slowpath+0xb4/0x10a Nov 9 16:29:21 eeekiste kernel: [<c13b1cf9>] ? mutex_lock+0x17/0x2e Nov 9 16:29:21 eeekiste kernel: [<c13a0dc1>] ? rfkill_unregister+0x4b/0x91 Nov 9 16:29:21 eeekiste kernel: [<c137cb6f>] ? wiphy_unregister+0x17/0x7a Nov 9 16:29:21 eeekiste kernel: [<c138996d>] ? ieee80211_unregister_hw+0x94/0xd1 Nov 9 16:29:21 eeekiste kernel: [<c1257bbf>] ? ath_detach+0x8b/0x178 Nov 9 16:29:21 eeekiste kernel: [<c1257cb4>] ? ath_cleanup+0x8/0x30 Nov 9 16:29:21 eeekiste kernel: [<c117005d>] ? pci_device_remove+0x16/0x36 Nov 9 16:29:21 eeekiste kernel: [<c1214330>] ? __device_release_driver+0x3b/0x7c Nov 9 16:29:21 eeekiste kernel: [<c12143ff>] ? device_release_driver+0x15/0x1e Nov 9 16:29:21 eeekiste kernel: [<c1213bbf>] ? bus_remove_device+0x6d/0x89 Nov 9 16:29:21 eeekiste kernel: [<c121256b>] ? device_del+0xe9/0x141 Nov 9 16:29:21 eeekiste kernel: [<c12125cb>] ? device_unregister+0x8/0x10 Nov 9 16:29:21 eeekiste kernel: [<c116bf38>] ? pci_stop_bus_device+0x5c/0x71 Nov 9 16:29:21 eeekiste kernel: [<c116bfbb>] ? pci_remove_bus_device+0xa/0x9c Nov 9 16:29:21 eeekiste kernel: [<f88319fe>] ? eeepc_rfkill_hotplug+0x14c/0x151 [eeepc_laptop] Nov 9 16:29:21 eeekiste kernel: [<f8831ae1>] ? eeepc_rfkill_set+0x20/0x3a [eeepc_laptop] Nov 9 16:29:21 eeekiste kernel: [<c13a069a>] ? rfkill_set_block+0x65/0xc6 Nov 9 16:29:21 eeekiste kernel: [<c13a085e>] ? __rfkill_switch_all+0x5c/0x68 Nov 9 16:29:21 eeekiste kernel: [<c13a12f0>] ? rfkill_op_handler+0x0/0x13d Nov 9 16:29:21 eeekiste kernel: [<c13a08e8>] ? rfkill_switch_all+0x3d/0x49 Nov 9 16:29:21 eeekiste kernel: [<c13a1355>] ? rfkill_op_handler+0x65/0x13d Nov 9 16:29:21 eeekiste kernel: [<c1036f0c>] ? worker_thread+0xdd/0x197 Nov 9 16:29:21 eeekiste kernel: [<c103a1bc>] ? autoremove_wake_function+0x0/0x33 Nov 9 16:29:21 eeekiste kernel: [<c1036e2f>] ? worker_thread+0x0/0x197 Nov 9 16:29:21 eeekiste kernel: [<c1039f5e>] ? kthread+0x71/0x75 Nov 9 16:29:21 eeekiste kernel: [<c1039eed>] ? kthread+0x0/0x75 Nov 9 16:29:21 eeekiste kernel: [<c100369f>] ? kernel_thread_helper+0x7/0x18
last comment after small patch, which choose the right device (also wlan instend of lan, as in mainline)
Created attachment 23716 [details] remove rfkill from eeepc-laptop rfkill in eeepc-laptop is not very good implemented and cause problems
Created attachment 23779 [details] rewrite rfkill Patch for 2.6.31.6. I have rewritten the rfkill-code. There no more use of hotplug subsystem (it's not needed and cause problems). Kernel toggle the eeepc-wlan rfkill on wlan-key not any more, it should be done in userspace (it is more flexible).
Created attachment 23781 [details] rfkill rewrite patch for 2.6.32.rc7 last patch for 2.6.32.rc7
Created attachment 23784 [details] rfkill rewrite for patch 2.6.32.rc7 I added in this patch thaw and restore functions (which i have removed in past patches)
Created attachment 23790 [details] make hotplug in eeepc-laptop optional This patch is for eeepc-laptop upstream from git://git.iksaif.net/acpi4asus.git
Created attachment 23897 [details] make hotplug optional for 2.6.31.6
Created attachment 23898 [details] make hotplug optional for 2.6.32-rc8
re-assign the bug to Corentin
Created attachment 24063 [details] eeepc-laptop patch make hotplug optional Make use of hotplug subsystem optional and add module parameter, which turn of the use of hotplug subsystem. hotplug paramete: 0 = disable hotplug use of hotplug subsystem 1 = default (use hotplug subsystem) 2 >=force use of hotplug subsystem TODO: disable use of hotplug subsystem for blacklisted systems (such as 1005ha). This patch contain the patch from git://git.iksaif.net/acpi4asus.git: acpi/blacklist: enable OSI(Linux) on newer eeepc is needed for eeepc-latop on 2.6.32 (at least for 1005ha)
The acpi/blacklist patch won't be merged, and will be reverted in my tree. A module parameter don't solve the problem. The only real solution is: - Create a new driver to support the wmi interface - Disable hotplug at runtime in eeepc-laptop if hotplug should not be used. But I don't know how the driver could find if it should use or not hotplug (without any kind of blacklist if possible). I would love to make a driver for the wmi interface, but I don't have a eeepc 1005ha :/.
Created attachment 24071 [details] make use of hotplug subsystem optional and blacklist it for 1005ha In this patch the use of hotplug-subsystem is blacklisted for 1005ha.
(In reply to comment #12) > The acpi/blacklist patch won't be merged, and will be reverted in my tree. > A module parameter don't solve the problem. > The only real solution is: > - Create a new driver to support the wmi interface > - Disable hotplug at runtime in eeepc-laptop if hotplug should not be used. > But > I don't know how the driver could find if it should use or not hotplug > (without > any kind of blacklist if possible). whatever, the vanilla driver is not usable for me :P and there no other solution at the moment. > > I would love to make a driver for the wmi interface, but I don't have a eeepc > 1005ha :/. i have it and i will help you, if you say me, how i can help.
(In reply to comment #14) > (In reply to comment #12) > > The acpi/blacklist patch won't be merged, and will be reverted in my tree. > > A module parameter don't solve the problem. > > The only real solution is: > > - Create a new driver to support the wmi interface > > - Disable hotplug at runtime in eeepc-laptop if hotplug should not be used. > But > > I don't know how the driver could find if it should use or not hotplug > (without > > any kind of blacklist if possible). > > whatever, the vanilla driver is not usable for me :P and there no other > solution at the moment. Maybe we could disable hotplug if we fail to register any rfkill notifier, we should discuss that with Alan and Matthew > > > > I would love to make a driver for the wmi interface, but I don't have a > eeepc > > 1005ha :/. > > i have it and i will help you, if you say me, how i can help. By writting such a driver ? :p Honestly, I could write, then give it to you to test, but writting driver without having the hardware is not that fun, and I won't do it. You can also make a donation to the acpi4asus project so I can buy hardware. Else, we will have to wait that someone else write it.
(In reply to comment #15) > (In reply to comment #14) > Maybe we could disable hotplug if we fail to register any rfkill notifier, we > should discuss that with Alan and Matthew it's not the problem, the problem is, that the eeepc-laptop turn off my LAN! Hard coded slot to turn off is not good idea.
> it's not the problem, the problem is, that the eeepc-laptop turn off my LAN! > Hard coded slot to turn off is not good idea. besides the eeepc-laptop won't work on 2.6.32 without acpi/blacklist: enable OSI(Linux) on newer eeepc patch from git://git.iksaif.net/acpi4asus.git. The use of hotplug-subsystem in eeepc-laptop is not needed for my EEE PC. The rfkill work fine for me without use of hotplug subsystem.
(In reply to comment #17) > > it's not the problem, the problem is, that the eeepc-laptop turn off my > LAN! > > Hard coded slot to turn off is not good idea. > > besides the eeepc-laptop won't work on 2.6.32 without > acpi/blacklist: enable OSI(Linux) on newer eeepc > patch from git://git.iksaif.net/acpi4asus.git. There is a thread about that on linux-acpi, and as I said before, we won't merge it, the real solution it to write a new driver. > The use of hotplug-subsystem in eeepc-laptop is not needed for my EEE PC. > The rfkill work fine for me without use of hotplug subsystem. I understand, it's why we should find a way to disable it at runtime, without any Kconfig option or module parameter.
(In reply to comment #18) > I understand, it's why we should find a way to disable it at runtime, without > any Kconfig option or module parameter. see my last patch: i have added a module parameter hotplug and the blacklisting. In my patch is only 1005ha blacklisted (i haven't tested it on other hardware).
Could you test that patch ? http://patchwork.kernel.org/patch/67046/
Ping Andrej...
pong. It would not work. All Notifiers are there. :( Why not my last patch? My test patch for 2.6.32: diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c index 4226e53..a68eaf9 100644 --- a/drivers/platform/x86/eeepc-laptop.c +++ b/drivers/platform/x86/eeepc-laptop.c @@ -750,6 +750,8 @@ static int eeepc_register_rfkill_notifier(char *node) acpi_status status = AE_OK; acpi_handle handle; + pr_info("try to register rfkill notifier (node: %s)", node); + status = acpi_get_handle(NULL, node, &handle); if (ACPI_SUCCESS(status)) { @@ -759,8 +761,12 @@ static int eeepc_register_rfkill_notifier(char *node) NULL); if (ACPI_FAILURE(status)) pr_warning("Failed to register notify on %s\n", node); + pr_info("enable hotplug"); } else + { + pr_info("not enable hotplug"); return -ENODEV; + } return 0; } log: Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: Eee PC Hotkey Driver Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: Hotkey init flags 0x41 Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: TYPE (2000000) not reported by BIOS, enabling anyway Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: PANELPOWER (4000000) not reported by BIOS, enabling anyway Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: TPD (8000000) not reported by BIOS, enabling anyway Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: Get control methods supported: 0xe101711 Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: Backlight controlled by ACPI video driver Dec 22 23:16:54 eeekiste kernel: input: Asus EeePC extra buttons as /devices/platform/eeepc/input/input8 Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: try to register rfkill notifier (node: \_SB.PCI0.P0P5) Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: enable hotplug Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: try to register rfkill notifier (node: \_SB.PCI0.P0P6) Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: enable hotplug Dec 22 23:16:54 eeekiste kernel: eeepc_laptop: try to registe
Because I want something that work without any configuration, and because all we will do in eeepc-laptop will only be a workaround. Mathew is working on a real solution at the pci level, don't know when this will be merged. If we really find no good solution, we can add a dmi blacklist before the end of 2.6.32. Do you know the exact list of models affected ?
My last patch is workaround. Have you looked at it? I am not sure, if you need that solution, it work absolutely fine for me without any pci-black-woodoo.
Ho, I didn't see the dmi check in your last patch, I'll rework that one and send it to you for testing. But it may take some time, I won't have an internet connection for the next two weeks.
(In reply to comment #24) > My last patch is workaround. Have you looked at it? > I am not sure, if you need that solution, it work absolutely fine for me > without any pci-black-woodoo. The patch for that is comming soon, could you give me your dsdt ? It will also help me to solve #14865
Could you try eeepc-laptop.c from acpi4asus git tree ? Patch "eeepc-laptop: dmi blacklist to disable pci hotplug code" should fix the issue. http://git.iksaif.net/?p=acpi4asus.git;a=shortlog;h=refs/heads/eeepc-laptop
it's work, but at least module parameter to force not to use or use the hotplug-code would be nice.
Is that one ok ? http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=c61a195c7cdf77199a55b30fc8c241f50e48cd1a
yes, it's ok. I hope, you can get it in 2.6.33 kernel.
commit 10ae4b5663ff3092553bfbd867e7bd474ce6c553 Author: Corentin Chary <corentincj@iksaif.net> Date: Wed Jan 6 22:07:38 2010 +0100 eeepc-laptop: dmi blacklist to disable pci hotplug code shipped in linux-2.6.33-rc5 closed
I believe this also affects the Asus 1001P (https://bugs.launchpad.net/linux/+bug/527361). If so, it looks like there is still a tiny little bit of work to be done.
Could you try that patch: http://git.iksaif.net/?p=acpi4asus.git;a=commit;h=830324097a364704a3975864830e2a2f1aa696ca ? Thanks.