No ethernet interface found after suspend-resume

[Sriram V]

Hi,

Thank you for your responses.  I now understand things better.

I tried the following:

1) Back-Port the "Powered" Sdio card stuff to .29 kernel.
    I see that the mmc_sdio_suspend return -ENOSYS since the card function
    does not have a pm suspend.

    I think probably libertas drivers need to have suspend-resume somewhere
    which does not exist at the moment.

   Hence I tried to reset the wlan chip during suspend-resume  before
the mmc/sdio suspend resume gets called.
   Probably the easiest way to implement suspend-resume and
   it does matter to the user-space if the suspend period is long enough

Upon resume i see that the Wifi module has successfully being detected
and the firmware gets downloaded (because i have built the firmware into the
kernel).

What happens next is when i try to reconnect to a AP.  It fails.

I get lots of errors like:

mmc2:0001: error -110 reading SDIO_CCCR_INTx
mmc2:0001: error -110 reading SDIO_CCCR_INTx
mmc2:0001: error -110 reading SDIO_CCCR_INTx
mmc2:0001: error -110 reading SDIO_CCCR_INTx
mmc2:0001: error -110 reading SDIO_CCCR_INTx

libertas: command 0x0028 timed out
libertas: requeueing command 0x0028 due to timeout (#1)

Sometimes i get errors like:

libertas: command 0x0010 timed out

Am i resetting the wlan chip at the wrong place?

I am not sure what could be wrong? I guess i need to call some
libertas functions
before i reset the wlan chip. am not sure what it could be.


Thank you,


Regards,
sriram






On Mon, May 3, 2010 at 2:46 AM, Dan Williams <dcbw at redhat.com> wrote:
> On Fri, 2010-04-30 at 21:54 +0530, Sriram V wrote:
>> On Fri, Apr 30, 2010 at 9:40 PM, Chris Ball <cjb at laptop.org> wrote:
>> > Hi,
>> >
>> >   > How can i reset the card? I use a gpio - If i do a reset - The
>> >   > firmware again gets downloaded. I need to again configure my
>> >   > ethernet interface and get an IP address. which i dont think is
>> >   > the right way to do.
>> >
>> > Yes, that's what has to happen if the card loses power.  (And the card
>> > losing power is what has to happen on vanilla 2.6.29.)
>> >
>> >   > Can you elaborate on this? I cant upgrade to .33. I would like to
>> >   > back port to .29.
>> >
>> > Let me just check what you're trying to do -- you want the card to
>> > retain power while the CPU's in suspend, and you want it to stay
>> > associated during suspend.  Do you also want packets sent to the card
>> > during suspend to wake up the system?
>>
>> I think the connection should stay associated after comming back from
>> suspend-resume. Becaue that was the state before going to suspend.
>
> Remember that saying connected to the AP (by keeping the 8686 powered
> and associated) while the host CPU is suspended only works reliably with
> WEP and unencrypted modes.  When you're using WPA/WPA2 or Dynamic WEP,
> you need to run the WPA supplicant process (for rekeying and other
> things) which of course requires the host CPU.  This is not specific to
> the 8686; all cards work this way.  Rekeying is a core feature of WPA
> that greatly increases security.
>
> You can probably get away with a short host suspend (like the OLPC does)
> but anything more than 10 or 20 seconds and you're likely to get dropped
> by the AP.  You can get dropped even if you're suspended for a single
> second because the WPA rekey is triggered by two things: (a) time, and
> (b) packet count.  If during suspend the rekey packet count threshold is
> reached and your host CPU running the supplicant isn't awake to handle
> the rekey, you'll get dropped by the AP when you come out of suspend.
>
> So just because the state of the device was associated before you
> suspend, don't expect that state to be the same when you exit suspend.
>
>> I dont want the system to be woken up during suspend - i can live without it.
>>
>>
>>  Or is it just the extra time
>> > that it takes to bring the interface back up after suspend that you're
>> > trying to get rid of?
>>
>>
>> Do all - have to bring the interface backup after
>> suspend-resume. Is this taken care by the user-space. But how does the
>> user space know that the interface is back up and query for an IP everytime
>> the device comes back from suspend and associate with an AP.
>
> How the reassociation is handled on resume depends on what kind of
> userspace you're running.  Any system needs something to configure the
> network, whether that's scripts or ifplugd or NetworkManager or
> whatever.  That thing also needs to handle the resume case, or really it
> needs to handle any case where the card is disconnected from the AP,
> which includes being dropped by the AP while suspended.
>
>> Is this normal behaviour elsewhere?
>
> Yes.  Normal laptop/desktop cards these days are "softmac" which means
> that the card's firmware is very small and most operations are done  on
> the host CPU.  THus if the machine goes to sleep, there's nothing to
> handle the normal 802.11 management traffic (which the 8686's more
> capable firmware will do for you) and clearly you're going to get
> dropped by the AP while suspended with these types of cards.
>
>> Not really sure this the default behaviour.
>
> Yes, reconfiguring the interface on resume is the default behavior
> because devices are almost always unpowered across suspend/resume.
> There are some prominent exceptions here though, mostly in the embedded
> space and of course OLPC.
>
>> Besides, My device is externally powered and i just specify the ocr's
>> ranges to the mmc drivers.
>> So probably the state machine within libertas does not expect CMD5,
>> CMD8 and so on....
>
> Since the kernel just recently got the handling code for
> powered-during-suspend MMC stuff, that's fairly necessary so that the
> MMC bus (on which the libertas driver is based) knows about this
> condition and doesn't try to re-initialize a powered card on resume.
>
> Dan
>
>
>