1. 04 2月, 2019 8 次提交
  2. 29 1月, 2019 5 次提交
  3. 26 1月, 2019 4 次提交
  4. 20 12月, 2018 2 次提交
  5. 14 12月, 2018 2 次提交
  6. 23 11月, 2018 5 次提交
  7. 11 11月, 2018 3 次提交
  8. 08 10月, 2018 1 次提交
    • S
      iwlwifi: dump debug data before stop device · 4244e7fc
      Shahar S Matityahu 提交于
      Debug data dump is not working in flows that stop the device is used
      in their error handling. During these flows the op mode mutex is
      locked until the device stops.  Because of that, any assert generated
      from the firmware can be handled only after the device already
      stopped.
      
      Since dumping cannot occour after stopping the device, split the the
      dump function to two parts, Part that handles locking, and the part
      that starts the actual dumping and call the second part in the op mode
      stop device function.
      Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      4244e7fc
  9. 06 10月, 2018 7 次提交
  10. 28 9月, 2018 3 次提交
    • E
      iwlwifi: dbg: don't crash if the firmware crashes in the middle of a debug dump · 79f25b10
      Emmanuel Grumbach 提交于
      We can dump data from the firmware either when it crashes,
      or when the firmware is alive.
      Not all the data is available if the firmware is running
      (like the Tx / Rx FIFOs which are available only when the
      firmware is halted), so we first check that the firmware
      is alive to compute the required size for the dump and then
      fill the buffer with the data.
      
      When we allocate the buffer, we test the STATUS_FW_ERROR
      bit to check if the firmware is alive or not. This bit
      can be changed during the course of the dump since it is
      modified in the interrupt handler.
      
      We hit a case where we allocate the buffer while the
      firmware is sill working, and while we start to fill the
      buffer, the firmware crashes. Then we test STATUS_FW_ERROR
      again and decide to fill the buffer with data like the
      FIFOs even if no room was allocated for this data in the
      buffer. This means that we overflow the buffer that was
      allocated leading to memory corruption.
      
      To fix this, test the STATUS_FW_ERROR bit only once and
      rely on local variables to check if we should dump fifos
      or other firmware components.
      
      Fixes: 04fd2c28 ("iwlwifi: mvm: add rxf and txf to dump data")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      79f25b10
    • S
      iwlwifi: debug flow cleanup · da752717
      Shahar S Matityahu 提交于
      Cleanup of the debug flow by moving several flows to separate
      functions to increase readability.  Three functions were created:
      
      1. iwl_fw_get_prph_len - returns the size needed for periphery dump.
      2. iwl_fw_dump_mem for - executes the memory dumping flow.
      3. iwl_trans_get_fw_monitor_len - returns the size needed for monitor dump.
      Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      da752717
    • S
      iwlwifi: fw: stop and start debugging using host command · 5cfe79c8
      Sara Sharon 提交于
      In new devices, access to periphery is forbidden. Send instead
      host command to start and stop debugging.
      
      Memory allocation is written in context info, but in case we
      need to update it there is a dedicated command. Add definitions,
      currently unused, of the new command.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      5cfe79c8