linux-kernel - PROBLEM: brcm80211 unable to survive suspend/resume cycle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1289272437.3916.440.camel@constitution.bos.jonmasters.org>
Date:	Mon, 08 Nov 2010 22:13:57 -0500
From:	Jon Masters <jonathan@...masters.org>
To:	devel <devel@...uxdriverproject.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: PROBLEM: brcm80211 unable to survive suspend/resume cycle

Folks,

I reported this before, but let me open up a new thread for this now
that this driver has landed in 2.6.37-rc1 and been out for a while. I am
able to use this driver (more or less) for daily use on my netbook, but
it is unable survive a suspend/resume cycle without being unloaded and
then reloaded again on resume. That actually seems to work quite well.

I believe the problem is firmware related:

[  553.355497] wl0: wlc_coreinit: ucode did not self-suspend!
[  554.040495] wl0: wlc_suspend_mac_and_wait: waited 83000 uS and
MI_MACSSPNDD is still not on.
[  554.040517] wl0: psmdebug 0x000f8773, phydebug 0x00000000, psm_brc
0x0000
[  554.154625] wl0: wlc_suspend_mac_and_wait: waited 83000 uS and
MI_MACSSPNDD is still not on.
[  554.154647] wl0: psmdebug 0x000f8773, phydebug 0x00000000, psm_brc
0x0000
[  554.270438] wl0: wlc_suspend_mac_and_wait: waited 83000 uS and
MI_MACSSPNDD is still not on.
[  554.270459] wl0: psmdebug 0x000f8773, phydebug 0x00000000, psm_brc
0x0000
[  554.384569] wl0: wlc_suspend_mac_and_wait: waited 83000 uS and
MI_MACSSPNDD is still not on.

After the "ucode did not self-suspend", I then get the subsequent two
line warnings repeated forever until I reload the driver. Sure, it's
probably a firmware issue, but isn't there something the driver can do
to kick it into a full reset if it doesn't come back? It's able to do it
on module load initially...

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/