Skip to content

L
linux
Switch branch/tag
  1. 15 Jun, 2010 1 commit
  3. 14 Jun, 2010 5 commits
  5. 12 Jun, 2010 1 commit
    • Randy Dunlap's avatar
      enic: fix pci_alloc_consistent argument · d49aba84
      Randy Dunlap authored 
      Fix build warning on i386 (32-bit) with 32-bit dma_addr_t:

drivers/net/enic/vnic_dev.c: In function 'vnic_dev_init_prov':
drivers/net/enic/vnic_dev.c:716: warning: passing argument 3 of 'pci_alloc_consistent' from incompatible pointer type
include/asm-generic/pci-dma-compat.h:16: note: expected 'dma_addr_t *' but argument is of type 'u64 *'

Now builds without warnings on i386 and on x86_64.
Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
Cc:	Scott Feldman <scofeldm@cisco.com>
Cc:	Vasanthy Kolluri <vkolluri@cisco.com>
Cc:	Roopa Prabhu <roprabhu@cisco.com>
Acked-by: default avatarScott Feldman <scofeldm@cisco.com>
      d49aba84
  7. 11 Jun, 2010 6 commits
  9. 10 Jun, 2010 2 commits
  11. 09 Jun, 2010 7 commits
    • David S. Miller's avatar
      Merge branch 'num_rx_queues' of git://kernel.ubuntu.com/rtg/net-2.6 · ebedb22d
      David S. Miller authored
      ebedb22d
    • Anton Vorontsov's avatar
      gianfar: Revive the driver for eTSEC devices (disable timestamping) · 619baba1
      Anton Vorontsov authored 
      Since commit cc772ab7 ("gianfar: Add
hardware RX timestamping support"), the driver no longer works on
at least MPC8313ERDB and MPC8568EMDS boards (and possibly much more
boards as well).

That's how MPC8313 Reference Manual describes RCTRL_TS_ENABLE bit:

  Timestamp incoming packets as padding bytes. PAL field is set
  to 8 if the PAL field is programmed to less than 8. Must be set
  to zero if TMR_CTRL[TE]=0.

I see that the commit above sets this bit, but it doesn't handle
TMR_CTRL. Manfred probably had this bit set by the firmware for
his boards. But obviously this isn't true for all boards in the
wild.

Also, I recall that Freescale BSPs were explicitly disabling the
timestamping because of a performance drop.

For now, the best way to deal with this is just disable the
timestamping, and later we can discuss proper device tree bindings
and implement enabling this feature via some property.
Signed-off-by: default avatarAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      619baba1
    • Dan Carpenter's avatar
      caif: fix a couple range checks · aea34e7a
      Dan Carpenter authored 
      The extra ! character means that these conditions are always false.
Signed-off-by: default avatarDan Carpenter <error27@gmail.com>
Acked-by: default avatarSjur Braendeland <sjur.brandeland@stericsson.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aea34e7a
    • Richard Cochran's avatar
      phylib: Add support for the LXT973 phy. · e13647c1
      Richard Cochran authored 
      This patch implements a work around for Erratum 5, "3.3 V Fiber Speed
Selection." If the hardware wiring does not respect this erratum, then
fiber optic mode will not work properly.
Signed-off-by: default avatarRichard Cochran <richard.cochran@omicron.at>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e13647c1
    • Tim Gardner's avatar
      net: Print num_rx_queues imbalance warning only when there are allocated queues · 08c801f8
      Tim Gardner authored 
      BugLink: http://bugs.launchpad.net/bugs/591416

There are a number of network drivers (bridge, bonding, etc) that are not yet
receive multi-queue enabled and use alloc_netdev(), so don't print a
num_rx_queues imbalance warning in that case.

Also, only print the warning once for those drivers that _are_ multi-queue
enabled.
Signed-off-by: default avatarTim Gardner <tim.gardner@canonical.com>
Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      08c801f8
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 · 327723ed
      David S. Miller authored
      327723ed
    • Sven Wegener's avatar
      ipvs: Add missing locking during connection table hashing and unhashing · aea9d711
      Sven Wegener authored 
      The code that hashes and unhashes connections from the connection table
is missing locking of the connection being modified, which opens up a
race condition and results in memory corruption when this race condition
is hit.

Here is what happens in pretty verbose form:

CPU 0					CPU 1
------------				------------
An active connection is terminated and
we schedule ip_vs_conn_expire() on this
CPU to expire this connection.

					IRQ assignment is changed to this CPU,
					but the expire timer stays scheduled on
					the other CPU.

					New connection from same ip:port comes
					in right before the timer expires, we
					find the inactive connection in our
					connection table and get a reference to
					it. We proper lock the connection in
					tcp_state_transition() and read the
					connection flags in set_tcp_state().

ip_vs_conn_expire() gets called, we
unhash the connection from our
connection table and remove the hashed
flag in ip_vs_conn_unhash(), without
proper locking!

					While still holding proper locks we
					write the connection flags in
					set_tcp_state() and this sets the hashed
					flag again.

ip_vs_conn_expire() fails to expire the
connection, because the other CPU has
incremented the reference count. We try
to re-insert the connection into our
connection table, but this fails in
ip_vs_conn_hash(), because the hashed
flag has been set by the other CPU. We
re-schedule execution of
ip_vs_conn_expire(). Now this connection
has the hashed flag set, but isn't
actually hashed in our connection table
and has a dangling list_head.

					We drop the reference we held on the
					connection and schedule the expire timer
					for timeouting the connection on this
					CPU. Further packets won't be able to
					find this connection in our connection
					table.

					ip_vs_conn_expire() gets called again,
					we think it's already hashed, but the
					list_head is dangling and while removing
					the connection from our connection table
					we write to the memory location where
					this list_head points to.

The result will probably be a kernel oops at some other point in time.

This race condition is pretty subtle, but it can be triggered remotely.
It needs the IRQ assignment change or another circumstance where packets
coming from the same ip:port for the same service are being processed on
different CPUs. And it involves hitting the exact time at which
ip_vs_conn_expire() gets called. It can be avoided by making sure that
all packets from one connection are always processed on the same CPU and
can be made harder to exploit by changing the connection timeouts to
some custom values.
Signed-off-by: default avatarSven Wegener <sven.wegener@stealer.net>
Cc: stable@kernel.org
Acked-by: default avatarSimon Horman <horms@verge.net.au>
Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      aea9d711
  13. 08 Jun, 2010 2 commits
  15. 07 Jun, 2010 8 commits
  17. 06 Jun, 2010 6 commits
    • Timo Teräs's avatar
      r8169: fix random mdio_write failures · 024a07ba
      Timo Teräs authored 
      Some configurations need delay between the "write completed" indication
and new write to work reliably.

Realtek driver seems to use longer delay when polling the "write complete"
bit, so it waits long enough between writes with high probability (but
could probably break too). This patch adds a new udelay to make sure we
wait unconditionally some time after the write complete indication.

This caused a regression with XID 18000000 boards when the board specific
phy configuration writing many mdio registers was added in commit
2e955856 (r8169: phy init for the 8169scd). Some of the configration
mdio writes would almost always fail, and depending on failure might leave
the PHY in non-working state.
Signed-off-by: default avatarTimo Teräs <timo.teras@iki.fi>
Acked-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      024a07ba
    • Eric Dumazet's avatar
      ip6mr: fix a typo in ip6mr_for_each_table() · 8ffb335e
      Eric Dumazet authored 
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ffb335e
    • Emmanuel Grumbach's avatar
      iwlwifi: move sysfs_create_group to post request firmware · 7d47618a
      Emmanuel Grumbach authored 
      Move the sysfs_create_group to iwl_ucode_callback after we
have safely got the firmware.

The motivation to do this comes from a warning from lockdep which detected
that we request priv->mutex while holding s_active during a sysfs request
(show_statistics in the example copy pasted). The reverse order exists upon
request_firmware: request_firmware which is a sysfs operation
that requires s_active is run under priv->mutex.

This ensures that we don't get sysfs request before we finish to request
the firmware, avoiding this deadlock.

=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
cat/2595 is trying to acquire lock:
 (&priv->mutex){+.+.+.}, at: [<facfa598>] show_statistics+0x48/0x100 [iwlagn]

but task is already holding lock:
 (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (s_active){++++.+}:
       [<c0489b74>] __lock_acquire+0xc44/0x1230
       [<c048a1ed>] lock_acquire+0x8d/0x110
       [<c0581499>] sysfs_addrm_finish+0xe9/0x180
       [<c057f64a>] sysfs_hash_and_remove+0x4a/0x80
       [<c05829d4>] sysfs_remove_group+0x44/0xd0
       [<c0714b75>] dpm_sysfs_remove+0x15/0x20
       [<c070dac8>] device_del+0x38/0x170
       [<c070dc1e>] device_unregister+0x1e/0x60
       [<c071838d>] _request_firmware+0x29d/0x550
       [<c07186c7>] request_firmware+0x17/0x20
       [<fad01bf1>] iwl_mac_start+0xb1/0x1230 [iwlagn]
       [<fa46ba06>] ieee80211_open+0x436/0x6f0 [mac80211]
       [<c0808cd2>] dev_open+0x92/0xf0
       [<c0808b2b>] dev_change_flags+0x7b/0x190
       [<c08148e8>] do_setlink+0x178/0x3b0
       [<c0815169>] rtnl_setlink+0xf9/0x130
       [<c081453b>] rtnetlink_rcv_msg+0x1bb/0x1f0
       [<c0827ce6>] netlink_rcv_skb+0x86/0xa0
       [<c081436c>] rtnetlink_rcv+0x1c/0x30
       [<c08279c3>] netlink_unicast+0x263/0x290
       [<c0828768>] netlink_sendmsg+0x1c8/0x2a0
       [<c07f85fd>] sock_sendmsg+0xcd/0x100
       [<c07f964d>] sys_sendmsg+0x15d/0x290
       [<c07f9e6b>] sys_socketcall+0xeb/0x2a0
       [<c040ad9f>] sysenter_do_call+0x12/0x38

-> #0 (&priv->mutex){+.+.+.}:
       [<c0489f84>] __lock_acquire+0x1054/0x1230
       [<c048a1ed>] lock_acquire+0x8d/0x110
       [<c08bb358>] __mutex_lock_common+0x58/0x470
       [<c08bb84a>] mutex_lock_nested+0x3a/0x50
       [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
       [<c070d219>] dev_attr_show+0x29/0x50
       [<c057fecd>] sysfs_read_file+0xdd/0x190
       [<c052880f>] vfs_read+0x9f/0x190
       [<c0528d22>] sys_read+0x42/0x70
       [<c040ad9f>] sysenter_do_call+0x12/0x38

other info that might help us debug this:

3 locks held by cat/2595:
 #0:  (&buffer->mutex){+.+.+.}, at: [<c057fe25>] sysfs_read_file+0x35/0x190
 #1:  (s_active){++++.+}, at: [<c0580ecd>] sysfs_get_active_two+0x2d/0x50
 #2:  (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50

stack backtrace:
Pid: 2595, comm: cat Not tainted 2.6.33-tp-rc4 #2
Call Trace:
 [<c08b99ab>] ? printk+0x1d/0x22
 [<c0487752>] print_circular_bug+0xc2/0xd0
 [<c0489f84>] __lock_acquire+0x1054/0x1230
 [<c0478d81>] ? sched_clock_cpu+0x121/0x180
 [<c048a1ed>] lock_acquire+0x8d/0x110
 [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
 [<c08bb358>] __mutex_lock_common+0x58/0x470
 [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
 [<c08bb84a>] mutex_lock_nested+0x3a/0x50
 [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
 [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
 [<c0580cf9>] ? sysfs_get_active+0x69/0xb0
 [<facfa550>] ? show_statistics+0x0/0x100 [iwlagn]
 [<c070d219>] dev_attr_show+0x29/0x50
 [<c057fecd>] sysfs_read_file+0xdd/0x190
 [<c05ff314>] ? security_file_permission+0x14/0x20
 [<c0528242>] ? rw_verify_area+0x62/0xd0
 [<c052880f>] vfs_read+0x9f/0x190
 [<c047745b>] ? up_read+0x1b/0x30
 [<c057fdf0>] ? sysfs_read_file+0x0/0x190
 [<c04af3b4>] ? audit_syscall_entry+0x1f4/0x220
 [<c0528d22>] sys_read+0x42/0x70
 [<c040ad9f>] sysenter_do_call+0x12/0x38
Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      7d47618a
    • Wey-Yi Guy's avatar
      iwlwifi: add name to Maintainers list · 9edc71b7
      Wey-Yi Guy authored 
      Add "Wey-Yi Guy" to maintainers list for iwlwifi.
Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      9edc71b7
    • Abhijeet Kolekar's avatar
      iwl3945: fix internal scan · 14023641
      Abhijeet Kolekar authored 
      Port of internal scan to iwl3945 missed introduction
of iwl3945_get_single_channel_for_scan.

Fix the following bug by introducing the iwl3945_get_single_channel_for_scan
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208Signed-off-by: default avatarAbhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      14023641
    • Reinette Chatre's avatar
      iwl3945: enable stuck queue detection on 3945 · a6866ac9
      Reinette Chatre authored 
      We learn from
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and
https://bugzilla.redhat.com/show_bug.cgi?id=589777
that 3945 can also suffer from a stuck command queue. Enable stuck queue
detection for iwl3945 to enable recovery in this case.
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      a6866ac9
  19. 05 Jun, 2010 1 commit
  21. 04 Jun, 2010 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7