[Debian-eeepc-devel] Problems with wlan on a 1005HA-M

Commit Message

Alan Jenkins Aug. 28, 2009, 2:25 p.m. UTC

On 8/23/09, Karsten Jaeger <[e-mail]> wrote:
> Hi Alan!
>
> Alan Jenkins schrieb:
>> On 8/20/09, Karsten Jaeger <[e-mail]> 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.
>
>> <http://www.1-script.com/forums/wireless-card-and-camera-no-longer-work-or-show-in-hardware-article46509--25.htm>
>>
>> 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.

Patch

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");