1. 08 10月, 2009 4 次提交
  2. 02 10月, 2009 1 次提交
  3. 30 9月, 2009 4 次提交
  4. 29 9月, 2009 3 次提交
    • R
      iwlwifi: fix 3945 ucode info retrieval after failure · b7a79404
      Reinette Chatre 提交于
      When hardware or uCode problem occurs driver captures significant
      information from device to enable debugging. The format of this information
      is different between 3945 and 4965 and later devices, yet currently the
      3945 uses the 4965 and later format. Fix this by adding a new library call
      that is initialized to the correct formatting routine based on device.
      
      This moves the iwlagn event and error log handling back to iwl-agn.c to
      make it part of iwlagn module.
      
      Also remove the 3945 sysfs file that triggers dump of event log - there is
      already a debugfs file that can do it for all drivers.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b7a79404
    • R
      iwlwifi: fix memory leak in command queue handling · 28142986
      Reinette Chatre 提交于
      Also free the array of command pointers and meta data of each
      command buffer when command queue is freed.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      28142986
    • R
      iwlwifi: fix debugfs buffer handling · 2fac9717
      Reinette Chatre 提交于
      We keep track of where to write into a buffer by keeping a count of how
      much has been written so far. When writing to the buffer we thus take the
      buffer pointer and adding the count of what has been written so far.
      Keeping track of what has been written so far is done by incrementing
      this number every time something is written to the buffer with how much has
      been written at that time.
      
      Currently this number is incremented incorrectly when using the
      "hex_dump_to_buffer" call to add data to the buffer. Fix this by only
      adding what has been added to the buffer in that call instead of what has
      been added since beginning of buffer.
      
      Issue was discovered and discussed during testing of
      https://bugzilla.redhat.com/show_bug.cgi?id=464598 .
      
      When a user views any of these files they will see something like:
      
      [  179.355202] ------------[ cut here ]------------
      [  179.355209] WARNING: at ../lib/vsprintf.c:989 vsnprintf+0x5ec/0x5f0()
      [  179.355212] Hardware name: VGN-Z540N
      [  179.355213] Modules linked in: i915 drm i2c_algo_bit i2c_core ipv6 acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative cpufreq_stats freq_table container sbs sbshc arc4 ecb iwlagn iwlcore joydev led_class mac80211 af_packet pcmcia psmouse sony_laptop cfg80211 iTCO_wdt iTCO_vendor_support pcspkr serio_raw rfkill intel_agp video output tpm_infineon tpm tpm_bios button battery yenta_socket rsrc_nonstatic pcmcia_core processor ac evdev ext3 jbd mbcache sr_mod sg cdrom sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore thermal fan thermal_sys
      [  179.355262] Pid: 5449, comm: cat Not tainted 2.6.31-wl-54419-ge881071 #62
      [  179.355264] Call Trace:
      [  179.355267]  [<ffffffff811ad14c>] ? vsnprintf+0x5ec/0x5f0
      [  179.355271]  [<ffffffff81041348>] warn_slowpath_common+0x78/0xd0
      [  179.355275]  [<ffffffff810413af>] warn_slowpath_null+0xf/0x20
      [  179.355277]  [<ffffffff811ad14c>] vsnprintf+0x5ec/0x5f0
      [  179.355280]  [<ffffffff811ad23d>] ? scnprintf+0x5d/0x80
      [  179.355283]  [<ffffffff811ad23d>] scnprintf+0x5d/0x80
      [  179.355286]  [<ffffffff811aed29>] ? hex_dump_to_buffer+0x189/0x340
      [  179.355290]  [<ffffffff810e91d7>] ? __kmalloc+0x207/0x260
      [  179.355303]  [<ffffffffa02a02f8>] iwl_dbgfs_nvm_read+0xe8/0x220 [iwlcore]
      [  179.355306]  [<ffffffff811a9b62>] ? __up_read+0x92/0xb0
      [  179.355310]  [<ffffffff810f0988>] vfs_read+0xc8/0x1a0
      [  179.355313]  [<ffffffff810f0b50>] sys_read+0x50/0x90
      [  179.355316]  [<ffffffff8100bd6b>] system_call_fastpath+0x16/0x1b
      [  179.355319] ---[ end trace 2383d0d5e0752ca0 ]---
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2fac9717
  5. 24 9月, 2009 1 次提交
  6. 23 9月, 2009 27 次提交