- 07 Feb, 2009 20 commits
-
-
Alexander Duyck authored
Instead of pulling the mac address from EEPROM it is easier to pull it from the RAL/RAH registers and then just copy it into the address structures. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
This patch makes dev_spec a union and simplifies it so that it does not require dynamic allocation and freeing in the driver. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
Add a link check function to contain all activities related to verifying that the link is present. The current approach is a bit cludgy and needs to be cleaned up. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
Since igb supports only pci-e nics and there is no plan to support any legacy pci parts in the driver there isn't really much need for checking to see if an io port is needed. In the unlikely event that we do begin supporting legacy pci parts then we can see about adding this code back to the driver. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
This patch moves the initialization of the number of queues into set_interrupt_capability. This allows the number of queues to increase in the unlikely event that the system initially fails to allocate enough msi-x interrupts, does a suspend/resume, and then can allocate enough interrupts on resume. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
buffsz is being repeatedly set when allocaing buffers. Since this value should only need to be set once in the function I am moving it out of the looped portion of the path. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
While cleaning up the skb_over panic with small frames I found there was room for improvement in the ordering of operations within the rx receive flow. These changes will place the prefetch for the next descriptor to a point earlier in the rx path. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Peter P Waskiewicz Jr authored
Now that our set_num_queues() routines for each feature are re-entrant, and can be called at any point, they shouldn't zero out the feature's indices or mask bits. Subsequent calls into those routines for those features can result in zero Rx and Tx queues being assigned, causing a panic later in driver reinitialization. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ayaz Abdulla authored
This patch bumps the version up to 63 Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ayaz Abdulla authored
This patch adds another type of recoverable error to the driver. It also modifies the sequence for recovery to include a mac reset and clearing of interrupts. Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ayaz Abdulla authored
This patch fixes the ethtool tx csum "set" command. A recent patch was submitted to remove HW_CSUM and use IP_CSUM instead. Therefore, the corresponding ethtool command should also be modified. Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ayaz Abdulla authored
This patch fixes an issue with the suspend/resume cycle with msi interrupts. See bugzilla number 10487 for more details. The fix is to re-setup a private msi pci config offset field. Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ayaz Abdulla authored
This patch updates the logic used to communicate with the mgmt unit. It also adds a version check for a newer mgmt unit firmware. * Fixed udelay to schedule_timeout_uninterruptible Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
$ diff-funcs xs_udp_write_space net/sunrpc/xprtsock.c net/sunrpc/xprtsock.c xs_tcp_write_space --- net/sunrpc/xprtsock.c:xs_udp_write_space() +++ net/sunrpc/xprtsock.c:xs_tcp_write_space() @@ -1,4 +1,4 @@ - * xs_udp_write_space - callback invoked when socket buffer space + * xs_tcp_write_space - callback invoked when socket buffer space * becomes available * @sk: socket whose state has changed * @@ -7,12 +7,12 @@ * progress, otherwise we'll waste resources thrashing kernel_sendmsg * with a bunch of small requests. */ -static void xs_udp_write_space(struct sock *sk) +static void xs_tcp_write_space(struct sock *sk) { read_lock(&sk->sk_callback_lock); - /* from net/core/sock.c:sock_def_write_space */ - if (sock_writeable(sk)) { + /* from net/core/stream.c:sk_stream_write_space */ + if (sk_stream_wspace(sk) >= sk_stream_min_wspace(sk)) { struct socket *sock; struct rpc_xprt *xprt; $ codiff net/sunrpc/xprtsock.o net/sunrpc/xprtsock.o.new net/sunrpc/xprtsock.c: xs_tcp_write_space | -163 xs_udp_write_space | -163 2 functions changed, 326 bytes removed net/sunrpc/xprtsock.c: xs_write_space | +179 1 function changed, 179 bytes added net/sunrpc/xprtsock.o.new: 3 functions changed, 179 bytes added, 326 bytes removed, diff: -147 Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
$ codiff net/ipv6/addrconf.o net/ipv6/addrconf.o.new net/ipv6/addrconf.c: addrconf_notify | -267 1 function changed, 267 bytes removed net/ipv6/addrconf.c: add_addr | +86 1 function changed, 86 bytes added net/ipv6/addrconf.o.new: 2 functions changed, 86 bytes added, 267 bytes removed, diff: -181 Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Peter P Waskiewicz Jr authored
Tx Head writeback is causing multi-microsecond stalls on PCIe chipsets, due to partial cacheline writebacks. Removing this feature removes these issues. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Peter P Waskiewicz Jr authored
The flow control handling is overly complicated and difficult to maintain. This patch cleans up the flow control handling and makes it much more explicit. It also adds 1G flow control autonegotiation, for 1G copper links, 1G KX links, and 1G fiber links. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 06 Feb, 2009 13 commits
-
-
Yinghai Lu authored
Impact: change default msix and napic can work again Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yinghai Lu authored
Impact: cleanup so get less irq. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yinghai Lu authored
Impact: clean up schedule it later after disable it. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yinghai Lu authored
Impact: fix bug for msix, we still need that flag to enable irq respectively Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yinghai Lu authored
Impact: make /proc/interrupts could show more info which irq is rx or other for msi-x add three name fields for rx, tx, other Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pablo Neira Ayuso authored
Currently, netlink_broadcast() reports errors to the caller if no messages at all were delivered: 1) If, at least, one message has been delivered correctly, returns 0. 2) Otherwise, if no messages at all were delivered due to skb_clone() failure, return -ENOBUFS. 3) Otherwise, if there are no listeners, return -ESRCH. With this patch, the caller knows if the delivery of any of the messages to the listeners have failed: 1) If it fails to deliver any message (for whatever reason), return -ENOBUFS. 2) Otherwise, if all messages were delivered OK, returns 0. 3) Otherwise, if no listeners, return -ESRCH. In the current ctnetlink code and in Netfilter in general, we can add reliable logging and connection tracking event delivery by dropping the packets whose events were not successfully delivered over Netlink. Of course, this option would be settable via /proc as this approach reduces performance (in terms of filtered connections per seconds by a stateful firewall) but providing reliable logging and event delivery (for conntrackd) in return. This patch also changes some clients of netlink_broadcast() that may report ENOBUFS errors via printk. This error handling is not of any help. Instead, the userspace daemons that are listening to those netlink messages should resync themselves with the kernel-side if they hit ENOBUFS. BTW, netlink_broadcast() clients include those that call cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they internally call netlink_broadcast() and return its error value. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alex Chiang authored
Cosmetic change to use struct e1000_mac_info.serdes_has_link consistently as the 'bool' that it's declared as. No functional change. Signed-off-by: Alex Chiang <achiang@hp.com> Acked-by: Jeff Kirsher <Jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Peter P Waskiewicz Jr authored
Currently ixgbe does not display the EEPROM version in ethtool -i, where other drivers do. The EEPROM version is located at offset 0x29. This patch adds support to display it. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Peter P Waskiewicz Jr authored
The current code has some flaws in it when performing autonegotiation, especially on KX/KX4 links. This patch updates the code to better handle the autonegotiation states on link setup. The patch also removes a redundant link configuration call on driver load, and moves link configuration to the ->open() path. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Peter P Waskiewicz Jr authored
The current code to determine the number of queues the device will want on driver initialization is ugly and difficult to maintain. It also doesn't allow for easy expansion for future features or future hardware. This patch refactors these routines, and make them easier to deal with. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
The previous fix ad0f9904 (gro: Fix handling of imprecisely split packets) only fixed the case of frags merging, frag_list merging in the same circumstances were still broken. In particular, the packet headers end up in the data stream. This patch fixes this plus another issue where an imprecisely split packet header may be read incorrectly (this is mostly harmless since it'll simply cause the packet to not match and be rejected for GRO). Thanks to Emil Tantilov and Jeff Kirsher for helping to track this down. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Graf Yang authored
Signed-off-by: Graf Yang <graf.yang@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
Unlike a normal socket path, the tuntap device send path does not have any accounting. This means that the user-space sender may be able to pin down arbitrary amounts of kernel memory by continuing to send data to an end-point that is congested. Even when this isn't an issue because of limited queueing at most end points, this can also be a problem because its only response to congestion is packet loss. That is, when those local queues at the end-point fills up, the tuntap device will start wasting system time because it will continue to send data there which simply gets dropped straight away. Of course one could argue that everybody should do congestion control end-to-end, unfortunately there are people in this world still hooked on UDP, and they don't appear to be going away anywhere fast. In fact, we've always helped them by performing accounting in our UDP code, the sole purpose of which is to provide congestion feedback other than through packet loss. This patch attempts to apply the same bandaid to the tuntap device. It creates a pseudo-socket object which is used to account our packets just as a normal socket does for UDP. Of course things are a little complex because we're actually reinjecting traffic back into the stack rather than out of the stack. The stack complexities however should have been resolved by preceding patches. So this one can simply start using skb_set_owner_w. For now the accounting is essentially disabled by default for backwards compatibility. In particular, we set the cap to INT_MAX. This is so that existing applications don't get confused by the sudden arrival EAGAIN errors. In future we may wish (or be forced to) do this by default. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 05 Feb, 2009 7 commits
-
-
Herbert Xu authored
The function sock_alloc_send_pskb is completely useless if not exported since most of the code in it won't be used as is. In fact, this code has already been duplicated in the tun driver. Now that we need accounting in the tun driver, we can in fact use this function as is. So this patch marks it for export again. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
As it currently stands, skb destructors are forbidden on the receive path because the protocol end-points will overwrite any existing destructor with their own. This is the reason why we have to call skb_orphan in the loopback driver before we reinject the packet back into the stack, thus creating a period during which loopback traffic isn't charged to any socket. With virtualisation, we have a similar problem in that traffic is reinjected into the stack without being associated with any socket entity, thus providing no natural congestion push-back for those poor folks still stuck with UDP. Now had we been consistent in telling them that UDP simply has no congestion feedback, I could just fob them off. Unfortunately, we appear to have gone to some length in catering for this on the standard UDP path, with skb/socket accounting so that has created a very unhealthy dependency. Alas habits are difficult to break out of, so we may just have to allow skb destructors on the receive path. It turns out that making skb destructors useable on the receive path isn't as easy as it seems. For instance, simply adding skb_orphan to skb_set_owner_r isn't enough. This is because we assume all over the IP stack that skb->sk is an IP socket if present. The new transparent proxy code goes one step further and assumes that skb->sk is the receiving socket if present. Now all of this can be dealt with by adding simple checks such as only treating skb->sk as an IP socket if skb->sk->sk_family matches. However, it turns out that for bridging at least we don't need to do all of this work. This is of interest because most virtualisation setups use bridging so we don't actually go through the IP stack on the host (with the exception of our old nemesis the bridge netfilter, but that's easily taken care of). So this patch simply adds skb_orphan to the point just before we enter the IP stack, but after we've gone through the bridge on the receive path. It also adds an skb_orphan to the one place in netfilter that touches skb->sk/skb->destructor, that is, tproxy. One word of caution, because of the internal code structure, anyone wishing to deploy this must use skb_set_owner_w as opposed to skb_set_owner_r since many functions that create a new skb from an existing one will invoke skb_set_owner_w on the new skb. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
-
David S. Miller authored
-
Andy Fleming authored
Stashing is only supported on the 85xx (e500-based) SoCs. The 83xx and 86xx chips don't have a proper cache for this. U-Boot has been updated to add stashing properties to the device tree nodes of gianfar devices on 85xx. So now we modify Linux to keep stashing off unless those properties are there. Signed-off-by: Andy Fleming <afleming@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andy Fleming authored
Signed-off-by: Andy Fleming <afleming@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andy Fleming authored
The MDIO bus drivers for the UCC and gianfar ethernet controllers are essentially the same. There's no reason to duplicate that much code. Signed-off-by: Andy Fleming <afleming@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-