From patchwork Fri Aug 28 14:25:47 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Jenkins X-Patchwork-Id: 44513 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n7SEPr14017837 for ; Fri, 28 Aug 2009 14:25:53 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750980AbZH1OZu (ORCPT ); Fri, 28 Aug 2009 10:25:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751191AbZH1OZu (ORCPT ); Fri, 28 Aug 2009 10:25:50 -0400 Received: from mail-fx0-f217.google.com ([209.85.220.217]:57400 "EHLO mail-fx0-f217.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750980AbZH1OZt (ORCPT ); Fri, 28 Aug 2009 10:25:49 -0400 Received: by fxm17 with SMTP id 17so1602837fxm.37 for ; Fri, 28 Aug 2009 07:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9+3iePtTHiSsAoL97eTb2KNwwW9NslHROUuK0v8n7B0=; b=QSbBIpk1RFK0FZynAMz0HnNcVtqAA/gYF9MrjWnY5gU9i3bBRc1UHtLGJMVgzvn/77 zWTv61VyK9mMG7s0z/fDXiBlaEoDQFkSGEdrWwgny5uUmBW1fcUHKPQlBFN8ilTXZYP/ gvUE9GtcSsyKadXrC0MLaTN0yPJ88rjv/mbaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LzAQsdDcwkcI2jBP25eEgUTzFq7BbGWlcxLTG+CjyKl/6KoTvEYqDUAeIMduMjh2c9 ++80bm5jy4yYXXsLB9IqibsU6GhEOznP90qr+jJ5Jxh4pdfaeYkrCzr16aJtMEKcG5eA 8tRU7X0HyOfXjlVZ2fvbTTD69nFYeq2DXD3wc= MIME-Version: 1.0 Received: by 10.204.34.20 with SMTP id j20mr1002085bkd.57.1251469547873; Fri, 28 Aug 2009 07:25:47 -0700 (PDT) In-Reply-To: <4A9104CC.90504@oss42.com> References: <4A8D32A8.8000702@oss42.com> <9b2b86520908200638y75c0c80cm4faf9a5c67b61397@mail.gmail.com> <4A9104CC.90504@oss42.com> Date: Fri, 28 Aug 2009 15:25:47 +0100 Message-ID: <9b2b86520908280725v383ed045m563385eb2a7c5461@mail.gmail.com> Subject: Re: [Debian-eeepc-devel] Problems with wlan on a 1005HA-M From: Alan Jenkins To: Karsten Jaeger Cc: debian-eeepc-devel@lists.alioth.debian.org, acpi4asus-user , ACPI Devel Maling List , Corentin Chary Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On 8/23/09, Karsten Jaeger wrote: > Hi Alan! > > Alan Jenkins schrieb: >> On 8/20/09, Karsten Jaeger wrote: >>> Last week I bought my EeePC 1005HA-M. It comes with Windows and Ubuntu >>> Installation, everything works fine. >>> Because my favorite OS is Debian I install it on the EeePC with >>> Standard-Lenny and kernel linux-image-2.6.31-rc5, updating it to sid and >>> everything worked fine. I updated it last sunday with latest sid and >>> kernel linux-image-2.6.31-rc6, put in in sleep mode (which worked fine >>> before) and want to restart it again on monday but nothing worked, I >>> have a black screen and it do not return from sleep. So I do an cold >>> reboot. >>> After that, my wlan said, it have an segmentation fault and also gives >>> the line back: >>> >>> SIOCSIFFLAGS: Unknown error 132 >>> Because I want to change some more, I do reinstalling it all, but since >>> than, I can't get wlan to work again. >> >> That looks like the new rfkill error code. Basically it means the >> wireless has been disabled. I guess the segmentation fault is a >> userspace bug, unless you also see a BUG message in dmesg. > > I do think about it before, but because it worked before upgrading, I am > not serios that this is the same. > >> You should definitely be able to re-enable the wireless using the BIOS >> setup screen... try these instructions: > > Yes, I can. > >> >> >> Are you able to confirm that this happens just by upgrading the >> kernel? If so, there's only one eeepc-laptop commit between -rc5 and >> -rc6, and I'm afraid it's mine. > > There also was an libc update. Not only the kernel-update. So I can't > really say, what exactly causes the problem. > >> I re-wrote it again for 2.6.32 in a slightly more sensible way. If >> we're lucky, your problem is fixed by the re-write and it can be >> expedited for 2.6.31. I've attached the relevant changes as a test >> patch; it should apply cleanly to 2.6.31-rc6. > > For now, I do an downgrade to 2.6.30 solve the WLAN-problem, it's more > needed as LAN. LAN doesn't work by now, but maybe in a few days after > the new 2.6.30 is uploaded. > > I give the test.patch a try on the weekend and get you informed. > > Thanks very much, > Karsten > > PS: Sorry Alan, I have to look more carefully on the TO-Header. ;-/ No worries, I've lost count how many times I did that myself. 2.6.31 is fast approaching and this is a bad regression. Please let me know if it's fixed by the test patch I sent you earlier. If that doesn't work, the safest approach is to revert my buggy code[1]. I've attached the reversions as a patch you can test. Thanks Alan [1] The change responsible was only intended to improve the case where you toggle the wireless half-way through hibernation. 2.6.31 can live without it. diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c index 222ffb8..5941c3f 100644 --- a/drivers/platform/x86/eeepc-laptop.c +++ b/drivers/platform/x86/eeepc-laptop.c @@ -143,7 +143,6 @@ struct eeepc_hotk { struct rfkill *bluetooth_rfkill; struct rfkill *wwan3g_rfkill; struct hotplug_slot *hotplug_slot; - struct work_struct hotplug_work; }; /* The actual device the driver binds to */ @@ -192,7 +191,6 @@ static struct key_entry eeepc_keymap[] = { */ static int eeepc_hotk_add(struct acpi_device *device); static int eeepc_hotk_remove(struct acpi_device *device, int type); -static int eeepc_hotk_resume(struct acpi_device *device); static void eeepc_hotk_notify(struct acpi_device *device, u32 event); static const struct acpi_device_id eeepc_device_ids[] = { @@ -209,7 +207,6 @@ static struct acpi_driver eeepc_hotk_driver = { .ops = { .add = eeepc_hotk_add, .remove = eeepc_hotk_remove, - .resume = eeepc_hotk_resume, .notify = eeepc_hotk_notify, }, }; @@ -661,12 +658,15 @@ static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot, return 0; } -static void eeepc_hotplug_work(struct work_struct *work) +static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data) { struct pci_dev *dev; struct pci_bus *bus = pci_find_bus(0, 1); bool blocked; + if (event != ACPI_NOTIFY_BUS_CHECK) + return; + if (!bus) { pr_warning("Unable to find PCI bus 1?\n"); return; @@ -697,14 +697,6 @@ static void eeepc_hotplug_work(struct work_struct *work) rfkill_set_sw_state(ehotk->wlan_rfkill, blocked); } -static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data) -{ - if (event != ACPI_NOTIFY_BUS_CHECK) - return; - - schedule_work(&ehotk->hotplug_work); -} - static void eeepc_hotk_notify(struct acpi_device *device, u32 event) { static struct key_entry *key; @@ -877,32 +869,6 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type) return 0; } -static int eeepc_hotk_resume(struct acpi_device *device) -{ - if (ehotk->wlan_rfkill) { - bool wlan; - - /* Workaround - it seems that _PTS disables the wireless - without notification or changing the value read by WLAN. - Normally this is fine because the correct value is restored - from the non-volatile storage on resume, but we need to do - it ourself if case suspend is aborted, or we lose wireless. - */ - wlan = get_acpi(CM_ASL_WLAN); - set_acpi(CM_ASL_WLAN, wlan); - - rfkill_set_sw_state(ehotk->wlan_rfkill, wlan != 1); - - schedule_work(&ehotk->hotplug_work); - } - - if (ehotk->bluetooth_rfkill) - rfkill_set_sw_state(ehotk->bluetooth_rfkill, - get_acpi(CM_ASL_BLUETOOTH) != 1); - - return 0; -} - /* * Hwmon */ @@ -1094,8 +1060,6 @@ static int eeepc_rfkill_init(struct device *dev) { int result = 0; - INIT_WORK(&ehotk->hotplug_work, eeepc_hotplug_work); - eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6"); eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");