lkml.org 
[lkml]   [2020]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [BUG] iwlwifi: card unusable after firmware crash
    Hi again, Emmanuel,

    On Wed, 9 Dec 2020 at 21:07, Emmanuel Grumbach <egrumbach@gmail.com> wrote:
    >
    > Indeed, the bit is reverse logic. So we can put that aside.
    > Frankly, I have no clue. You can try our backport tree to bisect,
    > should be easier..
    > What I see here is that your GP_CTRL value is 080003d8
    >
    > #define CSR_GP_CNTRL_REG_FLAG_HW_RF_KILL_SW (0x08000000)
    > which means sense since apparently, HW RF-Kill was asserted.
    > #define CSR_GP_CNTRL_REG_FLAG_GOING_TO_SLEEP (0x00000010)
    > Which means that the device is going to sleep... And that's the problem:
    >
    > iwl_trans_pcie_grab_nic_access:
    > ret = iwl_poll_bit(trans, CSR_GP_CNTRL,
    > CSR_GP_CNTRL_REG_VAL_MAC_ACCESS_EN,
    > (CSR_GP_CNTRL_REG_FLAG_MAC_CLOCK_READY |
    > CSR_GP_CNTRL_REG_FLAG_GOING_TO_SLEEP), 15000);
    > if (unlikely(ret < 0)) {
    > u32 cntrl = iwl_read32(trans, CSR_GP_CNTRL);
    >
    > WARN_ONCE(1,
    > "Timeout waiting for hardware access
    > (CSR_GP_CNTRL 0x%08x)\n",
    > cntrl);
    >
    > but I'd expect the splat in your log...
    > Or maybe you can't load the firmware?

    Well, my kernel doesn't have any modules, it's all built-in. The
    firmware is obviously loading fine, otherwise the card wouldn't work,
    but yeah, that WARN_ONCE hasn't triggered at all.

    > Can you try this:
    > diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
    > b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
    > index 2fffbbc8462f..748300752630 100644
    > --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
    > +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
    > @@ -2121,6 +2121,7 @@ static bool
    > iwl_trans_pcie_grab_nic_access(struct iwl_trans *trans,
    > * track nic_access anyway.
    > */
    > __release(&trans_pcie->reg_lock);
    > + mdelay(1);
    > return true;
    > }
    >
    > If that helps, then... I'd have no clue why it helps, but this
    > specific device caused us trouble like bad timing after
    > grab_nic_access..

    I'll give it a spin. Nasty hack, but if it works, it works. :)

    Thanks,
    Rui

    \
     
     \ /
      Last update: 2020-12-09 22:20    [W:3.675 / U:0.316 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site