Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 10月, 2009 15 次提交
  3. 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. 27 9月, 2009 13 次提交
  7. 26 9月, 2009 2 次提交
  9. 25 9月, 2009 2 次提交
    • A
      3c59x: Get rid of "Trying to free already-free IRQ" · 704cc92e
      由 Anton Vorontsov 提交于 
      Following trace pops up if we try to suspend with 3c59x ethernet NIC
brought down:

  root@b1:~# ifconfig eth16 down
  root@b1:~# echo mem > /sys/power/state
  ...
  3c59x 0000:00:10.0: suspend
  3c59x 0000:00:10.0: PME# disabled
  Trying to free already-free IRQ 48
  ------------[ cut here ]------------
  Badness at c00554e4 [verbose debug info unavailable]
  NIP: c00554e4 LR: c00554e4 CTR: c019a098
  REGS: c7975c60 TRAP: 0700   Not tainted  (2.6.31-rc4)
  MSR: 00021032 <ME,CE,IR,DR>  CR: 28242422  XER: 20000000
  TASK = c79cb0c0[1746] 'bash' THREAD: c7974000
  ...
  NIP [c00554e4] __free_irq+0x108/0x1b0
  LR [c00554e4] __free_irq+0x108/0x1b0
  Call Trace:
  [c7975d10] [c00554e4] __free_irq+0x108/0x1b0 (unreliable)
  [c7975d30] [c005559c] free_irq+0x10/0x24
  [c7975d40] [c01e21ec] vortex_suspend+0x70/0xc4
  [c7975d60] [c017e584] pci_legacy_suspend+0x58/0x100

This is because the driver manages interrupts without checking for
netif_running().

Though, there are few other issues with suspend/resume in this driver.
The intention of calling free_irq() in suspend() was to avoid any
possible spurious interrupts (see commit 5b039e68
"3c59x PM fixes"). But,

- On resume, the driver was requesting IRQ just after pci_set_master(),
  but before vortex_up() (which actually resets 3c59x chips).

- Issuing free_irq() on a shared IRQ doesn't guarantee that a buggy
  HW won't trigger spurious interrupts in another driver that
  requested the same interrupt. So, if we want to protect from
  unexpected interrupts, then on suspend we should issue disable_irq(),
  not free_irq().
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      704cc92e
    • S
      ems_pci: fix size of CAN controllers BAR mapping for CPC-PCI v2 · edf42a27
      由 Sebastian Haas 提交于 
      The driver mapped only 128 bytes of the CAN controller address space when a
CPC-PCI v2 was detected (incl. CPC-104P). This patch will fix it by always
mapping the whole address space (4096 bytes on all boards) of the
corresponding PCI BAR.
Signed-off-by: NSebastian Haas <haas@ems-wuensche.com>
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      edf42a27
  11. 24 9月, 2009 5 次提交
    • A
      sysctl: remove "struct file *" argument of ->proc_handler · 8d65af78
      由 Alexey Dobriyan 提交于 
      It's unused.

It isn't needed -- read or write flag is already passed and sysctl
shouldn't care about the rest.

It _was_ used in two places at arch/frv for some reason.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: James Morris <jmorris@namei.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d65af78
    • A
      virtio_net: Check for room in the vq before adding buffer · 0aea51c3
      由 Amit Shah 提交于 
      Saves us one cycle of alloc-add-free if the queue was full.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (modified)
      0aea51c3
    • R
      virtio_net: avoid (most) NETDEV_TX_BUSY by stopping queue early. · 48925e37
      由 Rusty Russell 提交于 
      Now we can tell the theoretical capacity remaining in the output
queue, virtio_net can waste entries by stopping the queue early.

It doesn't work in the case of indirect buffers and kmalloc failure,
but that's rare (we could drop the packet in that case, but other
drivers return TX_BUSY for similar reasons).

For the record, I think this patch reflects poorly on the linux
network API.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Dinesh Subhraveti <dineshs@us.ibm.com>
      48925e37
    • R
      virtio_net: formalize skb_vnet_hdr · b3f24698
      由 Rusty Russell 提交于 
      We put the virtio_net_hdr into the skb's cb region; turn this into a
union to clean up the code slightly and allow future expansion.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Mark McLoughlin <markmc@redhat.com>
Cc: Dinesh Subhraveti <dineshs@us.ibm.com>
      b3f24698
    • R
      virtio_net: don't free buffers in xmit ring · b0c39dbd
      由 Rusty Russell 提交于 
      The virtio_net driver is complicated by the two methods of freeing old
xmit buffers (in addition to freeing old ones at the start of the xmit
path).

The original code used a 1/10 second timer attached to xmit_free(),
reset on every xmit.  Before we orphaned skbs on xmit, the
transmitting userspace could block with a full socket until the timer
fired, the skb destructor was called, and they were re-woken.

So we added the VIRTIO_F_NOTIFY_ON_EMPTY feature: supporting devices
send an interrupt (even if normally suppressed) on an empty xmit ring
which makes us schedule xmit_tasklet().  This was a benchmark win.

Unfortunately, VIRTIO_F_NOTIFY_ON_EMPTY makes quite a lot of work: a
host which is faster than the guest will fire the interrupt every xmit
packet (slowing the guest down further).  Attempting mitigation in the
host adds overhead of userspace timers (possibly with the additional
pain of signals), and risks increasing latency anyway if you get it
wrong.

In practice, this effect was masked by benchmarks which take advantage
of GSO (with its inherent transmit batching), but it's still there.

Now we orphan xmitted skbs, the pressure is off: remove both paths and
no longer request VIRTIO_F_NOTIFY_ON_EMPTY.  Note that the current
QEMU will notify us even if we don't negotiate this feature (legal,
but suboptimal); a patch is outstanding to improve that.

Move the skb_orphan/nf_reset to after we've done the send and notified
the other end, for a slight optimization.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Mark McLoughlin <markmc@redhat.com>
      b0c39dbd