On Tue, 2012-02-07 at 09:01 +0100, Stanislaw Gruszka wrote:
> On Mon, Feb 06, 2012 at 08:08:16AM -0800, wwguy wrote:
> > On Mon, 2012-02-06 at 17:09 +0100, Stanislaw Gruszka wrote:
> > > Print dump stack when the device is not responding. This should give
> > > some more clue about the reason of failure. Also change the message we
> > > print, since "MAC in deep sleep" is kinda confusing.
> > >
> > > On the way add unlikely(), as fail to gain NIC access is hmm ...
> > > unlikely.
> > >
> > > Signed-off-by: Stanislaw Gruszka <sgruszka@xxxxxxxxxx>
> > > ---
> > > drivers/net/wireless/iwlwifi/iwl-io.c | 6 +++---
> > > 1 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/iwlwifi/iwl-io.c b/drivers/net/wireless/iwlwifi/iwl-io.c
> > > index 83fdff3..ce6d9c1 100644
> > > --- a/drivers/net/wireless/iwlwifi/iwl-io.c
> > > +++ b/drivers/net/wireless/iwlwifi/iwl-io.c
> > > @@ -120,10 +120,10 @@ int iwl_grab_nic_access_silent(struct iwl_bus *bus)
> > > int iwl_grab_nic_access(struct iwl_bus *bus)
> > > {
> > > int ret = iwl_grab_nic_access_silent(bus);
> > > - if (ret) {
> > > + if (unlikely(ret)) {
> > > u32 val = iwl_read32(bus, CSR_GP_CNTRL);
> > > - IWL_ERR(bus,
> > > - "MAC is in deep sleep!. CSR_GP_CNTRL = 0x%08X\n", val);
> > > + WARN_ONCE(1, "Timeout waiting for ucode processor access "
> > > + "(CSR_GP_CNTRL 0x%08x)\n", val);
> > > }
> > >
> > I agree the message and check make sense, but not sure what new clue we
> > got by doing this?
>
> Calltrace with very first grab nic access failure.
>
Good point, we have this "PCI bus disappear" problem on all of our
devices and very difficult to debug.
btw, do you have any system can reproduce this problem? we have nothing.
Thanks
Wey
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
