seems 2.6.32-rc7 is a good kernel.. but bisecting craps out with an error(and is painfully slow todo), I'll keep trying on this until I get the commit causing this..

This would be:

         if (WARN_ON(sc->vif != vif))
                goto unlock;

Can you add printk()s to ath5k_add_interface, ath5k_remove_interface, and ath5k_bss_info_changed to see what the ptr value of sc->vif and vif are?

Doesn't seem to be a recent regression if 2.6.32 is the most recent good kernel.  It was most recently modified when config_interface and bss_info_changed were unified back in April.

I can try adding the printk to these...(might need a little help), in the meantime im bisecting this right now(going to take some time, due to this machine having a small processor(but since I no schedule I've plenty O time to go through this)

Ok well, you can try picking a commit before and after:

commit 2d0ddec5b2b859f06116f631fc0ffe94fbceb556
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Thu Apr 23 16:13:26 2009 +0200

    mac80211: unify config_interface and bss_info_changed

Since that added the warning to bss_info_changed where it didn't exist previously.  If that is it we'll have to figure out what the order of the function calls is supposed to be, which the printks will help.

o.k. I ended up doing the bisect to see if it pointed to what you had posted(and also because I was half way done, and figured might as well finish)..


here is what the bisect resulted with:

 git bisect good
88b060d6c03fcb9e4d2018b4349954c4242a5c7f is the first bad commit
commit 88b060d6c03fcb9e4d2018b4349954c4242a5c7f
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Sat Jan 2 14:14:23 2010 +0100

    pcmcia: improve check for same card in slot after resume

    During a suspend/resume cycle, an user may change the card in the
    PCMCIA/CardBus slot. The pcmcia_core can at least look at the
    socket state to check whether it is the same.

    For PCMCIA devices, move the detection and handling of such a
    change to ds.c.

    For CardBus devices, the PCI hotplug interface doesn't offer a "rescan"
    facility which also _removes_ devices no longer to be found behind a
    bridge. Therefore, remove and re-add all devices unconditionally.

    CC: Jesse Barnes <jbarnes@virtuousgeek.org>
    CC: Linus Torvalds <torvalds@linux-foundation.org>
    Tested-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>

:040000 040000 9d17c47c3f30a637556efbe33fb4601f2657b4a3
594301366ddeef3b3c904d42613e5099aaa93db3 M	drivers
:040000 040000 e6c8dd889196c9669e79de6ab1d490f086217ca1
abe7d22fb059bec6ffb182d2892059432f717965 M	include
justin@linux-kk9p:/home/kernel/2.6.35>



I have not reverted this yet due to git revert crapping out telling me there is too many files etc...(so I'll have to manually revert this to see if it is the correct offending commit)...

Justin, did you get a chance to do that manual revert of "pcmcia: improve check for same card in slot after resume"?  Did it change the situation for you?

working on it today..(hopefully it doesnt turn into a mess, and hopefully I can narrow it down to a line or so).
I'll keep you updated!!

o.k. ended up doing a git reset to the commit before this bisect commit, built, rebooted and everything is good. Then manually adding in the bisect commit I get the warning message. Looking at the message I see something in there with socket_late_resume but am unsure if this is where the cause is. Im going to play around with this to see what function is doing this...

alright so in socket_late_resume the warning message is generated..
keep in mind this one is kind of out of whack i.e. with 2.6.33-rc4 one function of socket_late_resume was causing this warning, but with the current mainline it's another function in socket_late_resume..

this is the troubled spot for 2.6.33-rc4:

@@ static int socket_late_resume(struct pcmcia_socket *skt)

    if (skt->suspended_state != skt->state) {
                 dev_dbg(&skt->dev,
                         "suspend state 0x%x != resume state 0x%x\n",
                         skt->suspended_state, skt->state);

                 socket_shutdown(skt);
                 return socket_insert(skt);
         }

(from what I remember changing return socket_insert(skt); to return 0;
and got a good suspend)


and with the current mainline this is the troubled spot:

@@static int socket_late_resume(struct pcmcia_socket *skt)

#ifdef CONFIG_CARDBUS
         if (skt->state & SOCKET_CARDBUS) {
                 /* We can't be sure the CardBus card is the same
                  * as the one previously inserted. Therefore, remove
                  * and re-add... */
                 cb_free(skt);
                 cb_alloc(skt);
                 return 0;
         }
#endif


right now I just commented out this and everything works good on the current mainline kernel.

let me know if you have anything for me to test...

On Sunday, October 17, 2010, Justin P. Mattock wrote:
> On 10/17/2010 01:21 PM, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.35.  Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> >
> >
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=19392
> > Subject             : WARNING: at
> drivers/net/wireless/ath/ath5k/base.c:3475 ath5k_bss_info_changed+0x44/0x168
> [ath5k]()
> > Submitter   : Justin Mattock<justinmattock@gmail.com>
> > Date                : 2010-09-28 22:30 (20 days old)
> 
> 
> yeah it's still here...(I can try and play with this, but who knows..)

Created attachment 37622 [details]
dmesg of current Mainline

still shows up with the current Mainline kernel

On Friday, November 19, 2010, Justin P. Mattock wrote:
> On 11/18/2010 03:53 PM, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.35 and 2.6.36.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.35 and 2.6.36.  Please verify if it still should
> > be listed and let the tracking team know (either way).
> >
> >
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=19392
> > Subject             : WARNING: at
> drivers/net/wireless/ath/ath5k/base.c:3475 ath5k_bss_info_changed+0x44/0x168
> [ath5k]()
> > Submitter   : Justin Mattock<justinmattock@gmail.com>
> > Date                : 2010-09-28 22:30 (52 days old)
> > Message-ID  :<AANLkTim5WCGKPvEkOkO_YnMF9pg8mvLfQoFBNUFpfa_k@mail.gmail.com>
> > References  : http://marc.info/?l=linux-kernel&m=128571307018635&w=2
> 
> yep still there..

At least in w-t (since multi-vif work) this warning no longer exists.  I think it was probably an errant warning, something like mac80211 resume calling config_interface when ath5k wasn't expecting it but without a pcmcia card or some tracing data I can't say for sure.

On Monday, December 06, 2010, Justin Mattock wrote:
> On Sun, Dec 5, 2010 at 12:34 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.35 and 2.6.36.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.35 and 2.6.36.  Please verify if it still should
> > be listed and let the tracking team know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=19392
> > Subject         : WARNING: at drivers/net/wireless/ath/ath5k/base.c:3475
> ath5k_bss_info_changed+0x44/0x168 [ath5k]()
> > Submitter       : Justin Mattock <justinmattock@gmail.com>
> > Date            : 2010-09-28 22:30 (69 days old)
> 
> still here with the latest Mainline..

On Monday, December 20, 2010, Justin Mattock wrote:
> On Sun, Dec 19, 2010 at 4:50 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.35 and 2.6.36.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.35 and 2.6.36.  Please verify if it still should
> > be listed and let the tracking team know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=19392
> > Subject         : WARNING: at drivers/net/wireless/ath/ath5k/base.c:3475
> ath5k_bss_info_changed+0x44/0x168 [ath5k]()
> > Submitter       : Justin Mattock <justinmattock@gmail.com>
> > Date            : 2010-09-28 22:30 (83 days old)
> 
> yep.. still here with the latest Mainline

Is it still a problem with 2.6.37?

On Jan 16, 2011, at 3:01 PM, bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=19392
>
>
> Rafael J. Wysocki <rjw@sisk.pl> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|NEW                         |NEEDINFO
>
>
>
>
> --- Comment #16 from Rafael J. Wysocki <rjw@sisk.pl>  2011-01-16  
> 23:01:58 ---
> Is it still a problem with 2.6.37?
>
> -- 
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.


not sure... right now just pulled the latest, and all I see is white  
lines flashing, then  a black screen..
(can do a bisect, but given I dont have the time to do so somebody  
else probably should)

OK, thanks for checking.

Justin, did you ever get your "white lines flashing" issue resolved?  Does the ath5k issue remain afterwards?

I have not pulled for that machine since then.. over the weekend I should look at this.(I will let you know)

well I finally got around to this, and pulled to the current Mainline.. seems the above message is not present anymore, but the wireless is still not working upon wakeup.(unfortunately the intel graphics is broken so waking up is broken, but I was able to get dmesg)

full dmesg here:

 http://fpaste.org/HYVU/

Please open a new bug for the "ath5k phy2: failed to wakeup the MAC Chip" error.

On 03/21/2011 06:39 AM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=19392
>
>
> John W. Linville<linville@tuxdriver.com>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|NEEDINFO                    |CLOSED
>           Resolution|                            |CODE_FIX
>
>
>
>
> --- Comment #22 from John W. Linville<linville@tuxdriver.com>   2011-03-21
> 13:39:18 ---
> Please open a new bug for the "ath5k phy2: failed to wakeup the MAC Chip"
> error.
>

alright!!