Hi Clemens,
please try this in case it helps anything
to debug the issue.
this should avoid dead beef and the interrupt when we access MAC
registers when the MAC is asleep. also i did not see MAC irq being not
triggerred in your case(AR_INTR_ASYNC_CAUSE should be 0x2) or may be
its not an interrupt triggered by the chip itself. thanks
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 93fbe6f..51b7c54 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -770,6 +770,7 @@ irqreturn_t ath_isr(int irq, void *dev)
enum ath9k_int status;
bool sched = false;
+ ath9k_ps_wakeup(sc);
/*
* The hardware is not ready/present, don't
* touch anything. Note this can happen early
On Wed, Oct 5, 2011 at 6:32 PM, Adrian Chadd <adrian@xxxxxxxxxxx> wrote:
> On 5 October 2011 14:28, Clemens Buchacher <drizzd@xxxxxx> wrote:
>> For the record, instead of going to full sleep, I can reproduce the
>> issue with
>>
>> echo devices >/sys/power/pm_test
>> echo mem >/sys/power/state
>>
>> but not with
>>
>> echo freezer >/sys/power/pm_test
>> echo mem >/sys/power/state
>>
>> So it could still be a different device that's causing the issue? I
>> can try unloading all kinds of modules. Or is there an option to
>> suspend just one device?
>
> Right. So its likely something (more) odd. Yes, see if that's the case
> :) At this point I'm going to punt this to the power management/ACPI
> people .:)
>
> Good luck!
>
>
> Adrian
>
--
shafi
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
