- 27 Feb, 2009 12 commits
-
-
Stephen Hemminger authored
Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
- 25 Feb, 2009 24 commits
-
-
David S. Miller authored
Conflicts: drivers/net/wireless/orinoco/orinoco.c
-
-
Greg Kroah-Hartman authored
This patch adds two new device ids to the asix driver. One comes directly from the asix driver on their web site, the other was reported by Armani Liao as needed for the MSI X320 to get the driver to work properly for it. Reported-by:
Armani Liao <aliao@novell.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Ron Mercer authored
Currently there are two paths for filling rx buffer queues. One is used during initialization and the other during runtime. This patch removes ql_alloc_sbq_buffers() and ql_alloc_lbq_buffers() and replaces them with a call to the runtime functions ql_update_lbq() and ql_update_sbq(). Signed-off-by:
Ron Mercer <ron.mercer@qlogic.com> Signed-off-by:
-
Ron Mercer authored
RX Buffers are refilled in chunks of 16 at a time before notifying the hardware with a register write. This can cause several writes to take place in a given napi poll call. This change causes the write to take place only once at the end of the call. Signed-off-by:
-
Ron Mercer authored
Instead of taking/giving the hw semaphore repeatedly when iterating over several frame to queue route settings, we have the caller hold it until all are done. This reduces PCI bus chatter and possible waits. Signed-off-by:
-
Ron Mercer authored
Instead of taking/giving the semaphore repeatedly when iterating over several adderesses, we have the caller hold it until all are done. This reduces PCI bus chatter and possible waits. Signed-off-by:
-
Ron Mercer authored
Setting MAC addresses and routing frames to various queues will need to be done in response to firmware events as well as during initialization. This change encapsulates the facilities into a single call that can later me made from other places. Signed-off-by:
-
Wei Yongjun authored
The functions time_before is more robust for comparing jiffies against other values. Signed-off-by:
Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by:
-
Wei Yongjun authored
The functions time_before is more robust for comparing jiffies against other values. Signed-off-by:
-
Wei Yongjun authored
The functions time_before is more robust for comparing jiffies against other values. Signed-off-by:
-
Wei Yongjun authored
Remove some pointless conditionals before kfree_skb(). The semantic match that finds the problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression E; @@ - if (E) - kfree_skb(E); + kfree_skb(E); // </smpl> Signed-off-by:
-
Pablo Neira Ayuso authored
This patch changes the return value of nlmsg_notify() as follows: If NETLINK_BROADCAST_ERROR is set by any of the listeners and an error in the delivery happened, return the broadcast error; else if there are no listeners apart from the socket that requested a change with the echo flag, return the result of the unicast notification. Thus, with this patch, the unicast notification is handled in the same way of a broadcast listener that has set the NETLINK_BROADCAST_ERROR socket flag. This patch is useful in case that the caller of nlmsg_notify() wants to know the result of the delivery of a netlink notification (including the broadcast delivery) and take any action in case that the delivery failed. For example, ctnetlink can drop packets if the event delivery failed to provide reliable logging and state-synchronization at the cost of dropping packets. This patch also modifies the rtnetlink code to ignore the return value of rtnl_notify() in all callers. The function rtnl_notify() (before this patch) returned the error of the unicast notification which makes rtnl_set_sk_err() reports errors to all listeners. This is not of any help since the origin of the change (the socket that requested the echoing) notices the ENOBUFS error if the notification fails and should resync itself. Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Acked-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Lennert Buytenhek authored
A receive coalescing timeout of 250 usec appears to strike a good balance between allowing enough received frames to be aggregated for LRO to do its job and not allowing the connection to stall due to delaying ACKs to the remote end for too long. Signed-off-by:
Lennert Buytenhek <buytenh@marvell.com> Signed-off-by:
-
Lennert Buytenhek authored
Move the netif_carrier_off() call in ->open() to port probe, so that ethtool doesn't report the link as being up before we have up'd the interface. Move initialisation of the rx/tx coalescing timers from ->open() to port probe, so that we don't reset the coalescing timers every time the interface is up'd. Signed-off-by:
-
Lennert Buytenhek authored
Signed-off-by:
-
Lennert Buytenhek authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Dhananjay Phadke authored
Split pci probe function into smaller logical blocks. Signed-off-by:
Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by:
-
Dhananjay Phadke authored
Signed-off-by:
-
Dhananjay Phadke authored
Add ethtool wake on lan support. Signed-off-by:
-
Dhananjay Phadke authored
Signed-off-by:
-
Jesse Brandeburg authored
it was pointed out on the list that ixgbe was failing when using 64kB pages and large 16kB MTU. since with a 64kB PAGE_SIZE MAX_SKB_FRAGS = 3, the way the driver was configuring page usage was assuming 2kB is half a page, and was only ever dmaing that much data to a half page. (16kB - header size) / 2048 = 7 or 8 pages, which would far exceed 3 adjust the driver to account for these large pages, the hardware can support DMA to up to 16kB for each descriptor. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Shannon Nelson authored
From: Shannon Nelson <shannon.nelson@intel.com> The ring_feature member of ixgbe_adapter is statically allocated based on the supported features of the device. When a new feature is added, we need to manually update the static allocation. This patch makes the feature list an enum, eliminating the need for multiple updates to the code when adding a new feature. Signed-off-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
-
- 24 Feb, 2009 4 commits
-
-
-
Josef Drexler authored
Fix regression introduded by commit 079aa88f (netfilter: xt_recent: IPv6 support): From http://bugzilla.kernel.org/show_bug.cgi?id=12753: Problem Description: An uninitialized buffer causes IPv4 addresses added manually (via the +IP command to the proc interface) to never match any packets. Similarly, the -IP command fails to remove IPv4 addresses. Details: In the function recent_entry_lookup, the xt_recent module does comparisons of the entire nf_inet_addr union value, both for IPv4 and IPv6 addresses. For addresses initialized from actual packets the remaining 12 bytes not occupied by the IPv4 are zeroed so this works correctly. However when setting the nf_inet_addr addr variable in the recent_mt_proc_write function, only the IPv4 bytes are initialized and the remaining 12 bytes contain garbage. Hence addresses added in this way never match any packets, unless these uninitialized 12 bytes happened to be zero by coincidence. Similarly, addresses cannot consistently be removed using the proc interface due to mismatch of the garbage bytes (although it will sometimes work to remove an address that was added manually). Reading the /proc/net/xt_recent/ entries hides this problem because this only uses the first 4 bytes when displaying IPv4 addresses. Steps to reproduce: $ iptables -I INPUT -m recent --rcheck -j LOG $ echo +169.254.156.239 > /proc/net/xt_recent/DEFAULT $ cat /proc/net/xt_recent/DEFAULT src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910 [At this point no packets from 169.254.156.239 are being logged.] $ iptables -I INPUT -s 169.254.156.239 -m recent --set $ cat /proc/net/xt_recent/DEFAULT src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910 src=169.254.156.239 ttl: 255 last_seen: 126184 oldest_pkt: 4 125434, 125684, 125934, 126184 [At this point, adding the address via an iptables rule, packets are being logged correctly.] $ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT $ cat /proc/net/xt_recent/DEFAULT src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910 src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992 $ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT $ cat /proc/net/xt_recent/DEFAULT src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910 src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992 [Removing the address via /proc interface failed evidently.] Possible solutions: - initialize the addr variable in recent_mt_proc_write - compare only 4 bytes for IPv4 addresses in recent_entry_lookup Signed-off-by:
-
David S. Miller authored
-
David S. Miller authored
-
