Re: if_ath breaks s3 suspend/resume [Was: ACPI S3 wakeup problem (beeeeeeeeep)]

Alexander Leidinger wrote:
Quoting Louis Kowolowski <louisk@xxxxxxxxxxxxxxxxx> (Tue, 8 May 2007 23:38:51 -0700):

On Tue, May 08, 2007 at 09:04:49PM -0700, Sam Leffler wrote:
Harald Schmalzbauer wrote:
Am Dienstag, 8. Mai 2007 schrieb Harald Schmalzbauer:
Hello,

I found the sysctl "debug.acpi.resume_beep" and enabled it.
When I send my Vaio SRX41p sleeping with acpiconf -s3 it never waked up
again. Now with this sysctl enabled I hear a continuing beep, but the hard drive stays powered down, also the LCD keeps unlit.

Any hints how I can find out what's going wrong?
Tuning hw.acpi.reset_video doesn't change anything.
Again, the fabulous handbook gave me the hint to remove all devices from
the kernel and dynamically load them.
This revealse if_ath as the culprit. (the last I tried after usb, fwohci, pcm, ichsmb)

Could this be related to the interrupt strom problems with ath (I often get storm warnings, all drivers share IRQ9 on this laptop)?
Unclear but there's been an outstanding complaint against ath related to
suspend for a while. Specifically if you touch certain registers in the
h/w after the chip has been put to sleep you can hang the pci bus. I've
asked people that can reproduce the problem to narrow down the code path
by which the driver is entered but w/o luck.

I don't know for sure, but I think I might be seeing a similar issue with
atheros, but during bootup instead of suspend. It's not reproducable in a
reliable fashion, but sometimes I get a hang during bootup shortly after ath0 is brought up. I also see an interupt storm on irq11, which I believe is also shared by ichsmb (at least on my Thinkpad T60p).

AOL! Very hard hang. I have to remove the power supply and the battery
from my laptop then. I also get a message sometimes on the console (Sam
knows about it). The IRQ is also shared with something else, I think (I
have to look this up).

If there is more information I can make available, I'm more than willing. I'd like to provide a defined way to cause this, but it doesn't seem to happen in a "regular" way. If anyone has suggestions on this, please share.

I can reproduce the message very easy. I just have to boot and wait
some minutes. For the hang I'm not sure how to reproduce it. It happens
sometimes. It also happens sometimes in WinXP, so it may be a hardware
problem, not a driver problem (but I don't want to rule this out).

What's described above sounds very different from what I mentioned. The issue I referred to is that when you set many ath parts into sleep mode to conserve power all registers but those in the pci clock domain are unresponsivee over the bus (see the comment in ath_stop in the driver). Consequently any register access will hang. If this is with a cardbus card ejecting it will restore the system to normal use. For pci cards (e.g. minipci) power cycling works. I've never heard of anyone needing to remove a battery.

Sam
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages