wpi and suspend/resume

[Frank Staals]

Hey everyone,

Is anyone running a system with a wireless card using the wpi driver
that can successfully suspend/resume ? I have a Dell Latitude D630
running FreeBSD 8-STABLE on amd64, the system suspends and resumes fine
( acpiconf -s3 ). However after bringing it back up wpi0 refuses to
reconnect to a network:

frank@Rena# uname -a
FreeBSD Rena.FStaals.LAN 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Dec 10
21:06:05 CET 2009
fr...@Rena.FStaals.LAN:/home/obj/usr/src/sys/RENAKERNEL amd64

When I resume the system the following error message is printed to dmesg:

Dec 18 21:34:29 Rena kernel: wpi0: fatal firmware error
Dec 18 21:34:29 Rena kernel: wpi0: timeout resetting Rx ring

I tried bringing the interface down and up again (ifconfig wpi0 down up
) and reassociate with wpa_cli. Unfortunately after resuming wpi simply
won't reconnect again. It is very nice that my system actually
successfully suspends and resumes for the rest, but without networking
connectivity ( if_bge is also dead after a suspend ) uses are rather
limited. So is anyone successfully resuming with a system using the wpi
driver ?

--

- Frankn

[Lars Engels]

Quoting Frank Staals <fr...@fstaals.net>:

You could try to unload the module before you go to standby and reload
it after resuming.

[Frank Staals]

On 12/23/09 11:50, Lars Engels wrote:
> <snip>

>
> You could try to unload the module before you go to standby and reload
> it after resuming.

Ah I forgot to mention that: I actually also tried that unfortunately
that resulted in wpi completely hanging my system when I try to reload
it after resuming. It again gives a bunch of 'wpi0: could not lock
memory' errors. Then something what I believe to be
initializing/scanning? channels and then:

wpi0: SKU does support 802.11a
panic: ieee8021_get_ratetable: no rate table for channel: freq 0 flags 0x0

--

- Frank

[Alexey]

Try
/etc/rc.d/netif restart

[Paul B Mahol]

This is bug, it doesnt exits nicely if attach fail ...

You could try, when unloading wpi module to unload another pci driver and load
same one again while using

hw.pci.do_power_nodriver="3"
hw.pci.do_power_resume="0"

in loader.conf, maybe device doesnt get to D3 state in 'right way'.

--
Paul B Mahol

[Sam Leffler]

This sounds like wpi didn't read data properly from the eeprom on
resume. The panic is because no channels were registered by the driver.
There look to be debug msgs in the driver that can help track that
issue down.

Sam

[Frank Staals]

On 12/24/09 11:33, Paul B Mahol wrote:
> <snip>

> This is bug, it doesnt exits nicely if attach fail ...
>
> You could try, when unloading wpi module to unload another pci driver and load
> same one again while using
>
> hw.pci.do_power_nodriver="3"
> hw.pci.do_power_resume="0"
>
> in loader.conf, maybe device doesnt get to D3 state in 'right way'.
>

I'm not sure I understand what you meant by that. First I added the
both hw.pci lines to /boot/loader.conf and rebooted. Then I tried the
following two scenarios:

1: kldunload if_wpi
2: kldunload snd_hda
3: acpiconf -s3
4: resume
5: kldload snd_hda
6: kldload if_wpi

However when I load if_wpi in step 6 it will not recognize the hardware.

The other scenario:

1: kldunload if_wpi
2: kldunload snd_hda
3: kldload snd_hda
4: acpiconf -s3
5: kldload if_wpi

This scenario again results in a panic when loading if_wpi in step 5.
When loading if_wpi again the following message popped up in particular:

wpi0: chip is in D3 power mode -- setting to d0

Allthough when I checked the second scenario again without the hw.pci
lines in /boot/loader.conf the this message also appears when
re-enabling wpi.

Is one of these scenarios what you had in mind ? Or can/should I try
something else ?

Thanks for the help so far

--

- Frank

[Paul B Mahol]

I'm out of ideas :(

--
Paul B Mahol