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.
On Mon, 2010-11-08 at 22:13 -0500, Jon Masters wrote:
> 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:
Here's the log on the driver successfully re(loading):
[ 592.212928] brcm80211: module is from the staging directory, the
quality is unknown, you have been warned.
[ 592.252769] brcm80211 0000:02:00.0: PCI INT A -> GSI 17 (level, low)
-> IRQ 17
[ 592.252851] brcm80211 0000:02:00.0: setting latency timer to 64
[ 592.301703] Found chip type AI (0x13814313)
[ 592.307394] Changing max_res_mask to 0xffff
[ 592.307404] Changing min_res_mask to 0x200d
[ 592.313694] Applying 4313 WARs
[ 592.315470] wlc_bmac_attach:: deviceid 0x4727 nbands 1 board 0x2047
macaddr: 74:f0:6d:7e:ae:bc
[ 592.325680] ieee80211 phy0: Selected rate control algorithm
'minstrel_ht'
[ 592.347629] wl_set_hint: Sending country code US to MAC80211
[ 592.348371] wl0: Broadcom BCM43xx 802.11 MAC80211 Driver 5.75.11
(1.82.8.0) (Compiled in . at 19:32:54 on Nov 8 2010)
[ 592.350243] cfg80211: Calling CRDA for country: US
[ 592.440596] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 592.452998] cfg80211: Regulatory domain changed to country: US
[ 592.453126] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 592.453143] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi,
2700 mBm)
[ 592.453157] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi,
1700 mBm)
[ 592.453171] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 592.453186] (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 592.453209] (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 592.453231] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi,
3000 mBm)
[ 594.936591] wlan0: deauthenticating from X by local choice (reason=3)
[ 595.131413] wlan0: authenticate with X (try 1)
[ 595.332109] wlan0: authenticate with X (try 2)
[ 595.334992] wlan0: authenticated
[ 595.340928] wlan0: associate with X (try 1)
[ 595.348910] wlan0: RX AssocResp from X (capab=0x411 status=0 aid=4)
[ 595.348928] wlan0: associated
[ 595.357809] Associated: True
[ 595.376614] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 595.559868] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
374/256 dur 3498/1504
[ 596.740255] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
170/256 dur 1866/1504
[ 596.745966] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
170/256 dur 1866/1504
[ 596.748859] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
170/256 dur 1866/1504
[ 596.781364] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
163/256 dur 1810/1504
[ 596.790354] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
163/256 dur 1810/1504
[ 596.798995] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
163/256 dur 1810/1504
[ 602.093109] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
644/256 dur 5658/1504
[ 605.554079] wlan0: no IPv6 routers present
Jon.
On Mon, Nov 08, 2010 at 10:13:57PM -0500, Jon Masters wrote:
> 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:
<snip>
Did you copy the authors/developers on this bug report?
Please do that...
On Mon, 2010-11-08 at 19:24 -0800, Greg KH wrote:
> On Mon, Nov 08, 2010 at 10:13:57PM -0500, Jon Masters wrote:
> > 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:
>
> <snip>
>
> Did you copy the authors/developers on this bug report?
>
> Please do that...
I forwarded the mail to Brett right after I sent it because I had missed
them the original CC. Apologies for that. I didn't think it necessary to
send a followup but appreciate your mail - anyway, I think they got it.
Jon.
Hey Jon, thanks for the heads up. I can repro and am looking into it.
Brett
> -----Original Message-----
> From: [email protected] [mailto:devel-
> [email protected]] On Behalf Of Jon Masters
> Sent: Monday, November 08, 2010 7:14 PM
> To: devel
> Cc: Linux Kernel Mailing List
> 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.
>
>
> _______________________________________________
> devel mailing list
> [email protected]
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
On Tue, 2010-11-09 at 10:02 -0800, Brett Rudley wrote:
> Hey Jon, thanks for the heads up. I can repro and am looking into it.
Ok. Happy to test any experimental patches and get you a fast
turn-around on results. After working a lot of the weekend on the i915
regression I'm almost at the point where 2.6.37-rc1 works with all of
the devices I want to use in this netbook, except for WiFi suspend.
Jon.
On Tue, 2010-11-09 at 10:02 -0800, Brett Rudley wrote:
> Hey Jon, thanks for the heads up. I can repro and am looking into it.
Did you get chance to poke much yet?
Jon.
On Mon, 2010-11-15 at 23:04 -0500, Jon Masters wrote:
> On Tue, 2010-11-09 at 10:02 -0800, Brett Rudley wrote:
> > Hey Jon, thanks for the heads up. I can repro and am looking into it.
>
> Did you get chance to poke much yet?
This is still an issue in 2.6.37-rc5. Do you have any update on it?
Jon.
On Wed, 2010-12-08 at 02:03 -0500, Jon Masters wrote:
> On Mon, 2010-11-15 at 23:04 -0500, Jon Masters wrote:
> > On Tue, 2010-11-09 at 10:02 -0800, Brett Rudley wrote:
> > > Hey Jon, thanks for the heads up. I can repro and am looking into it.
> >
> > Did you get chance to poke much yet?
>
> This is still an issue in 2.6.37-rc5. Do you have any update on it?
In 2.6.37-rc2 I was unable to remove the module and reload it
successfully. In the latest RC I am at least able to reload it and have
it work again after doing so. Could you (for the moment) just add some
kind of big-hammer type reset in the unsuspend code path? :)
Jon.
On Mon, 2010-11-15 at 23:04 -0500, Jon Masters wrote:
> On Tue, 2010-11-09 at 10:02 -0800, Brett Rudley wrote:
> > Hey Jon, thanks for the heads up. I can repro and am looking into it.
>
> Did you get chance to poke much yet?
Any word on this?
Jon.
On Wed, 2011-01-19 at 12:51 -0500, Jon Masters wrote:
> On Wed, 2011-01-19 at 09:43 -0800, Arend Van Spriel wrote:
>
> > I tried to give you a heads up. I submitted the patch last friday to the
> > staging-2.6 repository. Not sure whether it has propagated to the 2.6.3[78]
> > kernels yet.
>
> Awesome. Sometime soon, I guess it will land and I'll test it for you :)
Latest upstream staging is working across suspend quite nicely. I did,
however, separately ping David Woodhouse to let him know that there is
some discrepancy between the firmware names you are looking for in the
brcm80211 driver and the firmware names in the linux-firmware rawhide
(Fedora) package such that one has to manually symlink stuff - can you
confirm that the current naming you're looking for is going to remain
consistent in the future if symlinks are fixed in linux-firmware?
Jon.