On 8/23/09, Karsten Jaeger <lists@xxxxxxxxx> wrote:
> Hi Alan!
>
> Alan Jenkins schrieb:
>> On 8/20/09, Karsten Jaeger <lists@xxxxxxxxx> 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.
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");
