All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: ipw3945-devel@lists.sourceforge.net, linux-wireless@vger.kernel.org
Cc: Robin Holt <holt@sgi.com>
Subject: Re: System pauses with iwl3945 AP associate. RFKill unpauses.
Date: Thu, 2 Oct 2008 22:29:38 -0500	[thread overview]
Message-ID: <20081003032938.GX28581@sgi.com> (raw)
In-Reply-To: <20081003022554.GU28581@sgi.com>

On Thu, Oct 02, 2008 at 09:25:54PM -0500, Robin Holt wrote:
> OK.  I think I have convinced myself this is an issue with
> sta_info_debugfs_add_work().  I am going to turn off
> CONFIG_MAC80211_DEBUGFS and see if that makes things better.

Appear to be on the right track here.  With CONFIG_MAC80211_DEBUGFS=y, I
could only suspend/resume approx 4 times without iwl3945 hanging.  I had
worked around that by modprobe -r iwl3945 and waiting a while before
suspending.  Now with CONFIG_MAC80211_DEBUGFS=n, I have done 6 suspends
with the machine suspended for 5 minutes before resuming and it has not
hung.  That has not occurred before.  I will continue to test this for
the next few days.


Thanks,
Robin

> 
> Thanks,
> Robin
> 
> On Thu, Oct 02, 2008 at 08:47:50PM -0500, Robin Holt wrote:
> > On Thu, Oct 02, 2008 at 06:34:22PM -0500, Robin Holt wrote:
> > > I do have KDB installed as well and one other thing I noticed is we are
> > > adding work to a workqueue at the time of the hang.  Not sure if this
> > > is accurate and I forgot that I only have a VGA console so there is
> > > no record of the KDB output.
> > 
> > OK.  In KDB.  Here goes...
> > 
> > events/0 process is on cpu0 with the following stack.
> > 
> > _spin_unlock_irqrestore+0x10
> > [mac80211]sta_info_debugfs_add_work+0x82
> > run_workqueue+0xd4
> > worker_thread+0x88
> > kthread+0x42
> > 
> > 
> > I few times later, I got:
> > _cond_resched+0x10
> > [mac80211]sta_info_destroy+0x10
> > [mac80211]sta_info_debugfs_add_work+0xee
> > run_workqueue+0xd4
> > worker_thread+0x88
> > kthread+0x42
> > 
> > I am transposing these from screen to this email so I reserve the right
> > to be slightly off, but these appear to be the call traces.
> > 
> > It looks to me like this add_work loop is truly an infinite loop and
> > preventing interrupts from being processed on cpu0.
> > 
> > Thanks,
> > Robin

           reply	other threads:[~2008-10-03  3:29 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20081003022554.GU28581@sgi.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081003032938.GX28581@sgi.com \
    --to=holt@sgi.com \
    --cc=ipw3945-devel@lists.sourceforge.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.