- 07 Oct, 2009 2 commits
-
-
Ron Mercer authored
Check that we are not already polling firmware events before we queue the firmware event worker, then disable firmware interrupts. Otherwise we can queue the same event multiple times. Signed-off-by:
Ron Mercer <ron.mercer@qlogic.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ron Mercer authored
Signed-off-by:
-
- 06 Oct, 2009 1 commit
-
-
Stephen Boyd authored
Commit 7069331d (connector: Provide the sender's credentials to the callback, 2009-10-02) changed callbacks to take two arguments but missed this one. drivers/connector/cn_proc.c: In function ‘cn_proc_init’: drivers/connector/cn_proc.c:263: warning: passing argument 3 of ‘cn_add_callback’ from incompatible pointer type Signed-off-by:
Stephen Boyd <bebarino@gmail.com> Signed-off-by:
-
- 05 Oct, 2009 9 commits
-
-
Johannes Berg authored
A number of drivers (recently including cfg80211-based ones) assume that all wireless handlers, including statistics, can sleep and they often also implicitly assume that the rtnl is held around their invocation. This is almost always true now except when reading from sysfs: BUG: sleeping function called from invalid context at kernel/mutex.c:280 in_atomic(): 1, irqs_disabled(): 0, pid: 10450, name: head 2 locks held by head/10450: #0: (&buffer->mutex){+.+.+.}, at: [<c10ceb99>] sysfs_read_file+0x24/0xf4 #1: (dev_base_lock){++.?..}, at: [<c12844ee>] wireless_show+0x1a/0x4c Pid: 10450, comm: head Not tainted 2.6.32-rc3 #1 Call Trace: [<c102301c>] __might_sleep+0xf0/0xf7 [<c1324355>] mutex_lock_nested+0x1a/0x33 [<f8cea53b>] wdev_lock+0xd/0xf [cfg80211] [<f8cea58f>] cfg80211_wireless_stats+0x45/0x12d [cfg80211] [<c13118d6>] get_wireless_stats+0x16/0x1c [<c12844fe>] wireless_show+0x2a/0x4c Fix this by using the rtnl instead of dev_base_lock. Reported-by:Miles Lane <miles.lane@gmail.com> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Ajit Khaparde authored
This patch fixes a bug that got introduced in commit 76998bc7. During preparation of mcc wrb, req was being wrongly overwritten and the flash operation was failing. Signed-off-by:
Ajit Khaparde <ajitk@serverengines.com> Signed-off-by:
-
Ken Kawasaki authored
pcnet_cs,serial_cs: add cis of National Semicondoctor's lan&modem mulitifunction pcmcia card, NE2K, tamarack ethernet card, and some serial card(COMpad2, COMpad4). Signed-off-by:
Ken Kawasaki <ken_kawasaki@spring.nifty.jp> Signed-off-by:
-
Ben Hutchings authored
The following user-space program fails to compile: #include <linux/socket.h> #include <sys/socket.h> int main() { return 0; } The reason is that <linux/socket.h> tests __GLIBC__ to decide whether it should define various structures and macros that are now defined for user-space by <sys/socket.h>, but __GLIBC__ is not defined if no libc headers have yet been included. It seems safe to drop support for libc 5 now. Signed-off-by:Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Bastian Blank <waldi@debian.org> Signed-off-by:
-
Eric Dumazet authored
Commit fd29cf72 (pktgen: convert to use ktime_t) inadvertantly converted "delay" parameter from nanosec to microsec. Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Eric Dumazet authored
It is not currently possible to instruct pktgen to use one selected tx queue. When Robert added multiqueue support in commit 45b270f8, he added an interval (queue_map_min, queue_map_max), and his code doesnt take into account the case of min = max, to select one tx queue exactly. I suspect a high performance setup on a eight txqueue device wants to use exactly eight cpus, and assign one tx queue to each sender. This patchs makes pktgen select the right tx queue, not the first one. Also updates Documentation to reflect Robert changes. Signed-off-by:
Robert Olsson <robert.olsson@its.uu.se> Signed-off-by:
-
Alexander Duyck authored
There appears to have been a mixup in the max supported jumbo frame size between 82574 and 82583 which ended up disabling jumbo frames on the 82574 as a result. This patch swaps the two so that this issue is resolved. This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=14261Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Don Skidmore authored
This patch adds device support for the 82599 based X520 10GbE Dual Port KX4 Mezzanine card. Signed-off-by: Don Skidmore<donald.c.skidmore@intel.com> Acked-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
-
Don Skidmore authored
This patch will add support for the 82599 Dual port Backplane device (0x10f8). This device has the ability to link in serial (KR) and parallel (KX4/KX) modes, depending on what the switch capabilities are in the blade chassis. Signed-off-by:
Don Skidmore <donald.c.skidmore@intel.com> Acked-by:
-
- 02 Oct, 2009 12 commits
-
-
Michael Chan authored
This fixes the problem of not handling the NETDEV_UP event properly during hot-plug or modprobe of bnx2 after cnic. The handling was skipped by mistakenly using "else if" to check for the event. Also update version to 2.0.1. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
Benjamin Li <benli@broadcom.com> Signed-off-by:
-
Philipp Reisner authored
Signed-off-by:
Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by:
-
Philipp Reisner authored
Signed-off-by:
-
Philipp Reisner authored
Signed-off-by:
-
Philipp Reisner authored
Signed-off-by:
-
Philipp Reisner authored
Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Acked-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
Philipp Reisner authored
Signed-off-by:
-
Philipp Reisner authored
Signed-off-by:
-
Philipp Reisner authored
Signed-off-by:
-
Frans Pop authored
The only error returned by pci_{en,dis}able_pcie_error_reporting() is -EIO which simply means that Advanced Error Reporting is not supported. There is no need to report that, so remove the error check from e1000e, igb and ixgbe. Signed-off-by:Frans Pop <elendil@planet.nl> Signed-off-by:
-
Jean Delvare authored
Which is why I have always preferred sizeof(struct foo) over sizeof(var). Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Eric Dumazet authored
tcp_splice_read() doesnt take into account socket's O_NONBLOCK flag Before this patch : splice(socket,0,pipe,0,128*1024,SPLICE_F_MOVE); causes a random endless block (if pipe is full) and splice(socket,0,pipe,0,128*1024,SPLICE_F_MOVE | SPLICE_F_NONBLOCK); will return 0 immediately if the TCP buffer is empty. User application has no way to instruct splice() that socket should be in blocking mode but pipe in nonblock more. Many projects cannot use splice(tcp -> pipe) because of this flaw. http://git.samba.org/?p=samba.git;a=history;f=source3/lib/recvfile.c;h=ea0159642137390a0f7e57a123684e6e63e47581;hb=HEAD http://lkml.indiana.edu/hypermail/linux/kernel/0807.2/0687.html Linus introduced SPLICE_F_NONBLOCK in commit 29e35094 (splice: add SPLICE_F_NONBLOCK flag ) It doesn't make the splice itself necessarily nonblocking (because the actual file descriptors that are spliced from/to may block unless they have the O_NONBLOCK flag set), but it makes the splice pipe operations nonblocking. Linus intention was clear : let SPLICE_F_NONBLOCK control the splice pipe mode only This patch instruct tcp_splice_read() to use the underlying file O_NONBLOCK flag, as other socket operations do. Users will then call : splice(socket,0,pipe,0,128*1024,SPLICE_F_MOVE | SPLICE_F_NONBLOCK ); to block on data coming from socket (if file is in blocking mode), and not block on pipe output (to avoid deadlock) First version of this patch was submitted by Octavian Purdila Reported-by:
Volker Lendecke <vl@samba.org> Reported-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
Octavian Purdila <opurdila@ixiacom.com> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
- 01 Oct, 2009 16 commits
-
-
Atis Elsts authored
This patch against v2.6.31 adds support for route lookup using sk_mark in some more places. The benefits from this patch are the following. First, SO_MARK option now has effect on UDP sockets too. Second, ip_queue_xmit() and inet_sk_rebuild_header() could fail to do routing lookup correctly if TCP sockets with SO_MARK were used. Signed-off-by:
Atis Elsts <atis@mikrotik.com> Acked-by:
-
Stephen Hemminger authored
This is based on Michal Schmidt fix for skge. Most network drivers request their IRQ when the interface is activated. sky2 does it in ->probe() instead, because it can work with two-port cards where the two net_devices use the same IRQ. This works fine most of the time, except in some situations when the interface gets renamed. Consider this example: 1. modprobe sky2 The card is detected as eth0 and requests IRQ 17. Directory /proc/irq/17/eth0 is created. 2. There is an udev rule which says this interface should be called eth1, so udev renames eth0 -> eth1. 3. modprobe 8139too The Realtek card is detected as eth0. It will be using IRQ 17 too. 4. ip link set eth0 up Now 8139too requests IRQ 17. The result is: WARNING: at fs/proc/generic.c:590 proc_register ... proc_dir_entry '17/eth0' already registered The fix is for sky2 to name the irq based on the pci device, as is done by some other devices DRM, infiniband, ... ie. sky2@pci:0000:00:00 Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Reviewed-by:
Michal Schmidt <mschmidt@redhat.com> Signed-off-by:
-
Michal Schmidt authored
Most network drivers request their IRQ when the interface is activated. skge does it in ->probe() instead, because it can work with two-port cards where the two net_devices use the same IRQ. This works fine most of the time, except in some situations when the interface gets renamed. Consider this example: 1. modprobe skge The card is detected as eth0 and requests IRQ 17. Directory /proc/irq/17/eth0 is created. 2. There is an udev rule which says this interface should be called eth1, so udev renames eth0 -> eth1. 3. modprobe 8139too The Realtek card is detected as eth0. It will be using IRQ 17 too. 4. ip link set eth0 up Now 8139too requests IRQ 17. The result is: WARNING: at fs/proc/generic.c:590 proc_register ... proc_dir_entry '17/eth0' already registered ... And "ls /proc/irq/17" shows two subdirectories, both called eth0. Fix it by using a unique name for skge's IRQ, based on the PCI address. The naming from the example then looks like this: $ grep skge /proc/interrupts 17: 169 IO-APIC-fasteoi skge@pci:0000:00:0a.0, eth0 irqbalance daemon will have to be taught to recognize "skge@" as an Ethernet interrupt. This will be a one-liner addition in classify.c. I will send a patch to irqbalance if this change is accepted. Signed-off-by:
-
Ori Finkelman authored
Acknowledge TCP window scale support by inserting the proper option in SYN/ACK and SYN headers even if our window scale is zero. This fixes the following observed behavior: 1. Client sends a SYN with TCP window scaling option and non zero window scale value to a Linux box. 2. Linux box notes large receive window from client. 3. Linux decides on a zero value of window scale for its part. 4. Due to compare against requested window scale size option, Linux does not to send windows scale TCP option header on SYN/ACK at all. With the following result: Client box thinks TCP window scaling is not supported, since SYN/ACK had no TCP window scale option, while Linux thinks that TCP window scaling is supported (and scale might be non zero), since SYN had TCP window scale option and we have a mismatched idea between the client and server regarding window sizes. Probably it also fixes up the following bug (not observed in practice): 1. Linux box opens TCP connection to some server. 2. Linux decides on zero value of window scale. 3. Due to compare against computed window scale size option, Linux does not to set windows scale TCP option header on SYN. With the expected result that the server OS does not use window scale option due to not receiving such an option in the SYN headers, leading to suboptimal performance. Signed-off-by:
Gilad Ben-Yossef <gilad@codefidence.com> Signed-off-by:
Ori Finkelman <ori@comsleep.com> Acked-by:
-
Andrew Morton authored
net/ipv4/tcp.c: In function 'do_tcp_setsockopt': net/ipv4/tcp.c:2050: warning: comparison of distinct pointer types lacks a cast Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Ralf Baechle authored
Remove references to dead web site mosquitonet.Stanford.EDU. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Ralf Baechle authored
This typo was introduced by 5793f4be on October 14, 2005 ... Reported-by:
Matti Aarnio <matti.aarnio@zmailer.org> Signed-off-by:
-
Eric Dumazet authored
prev_vlan_tag field is not used. Patch saves 512*8 bytes per tx queue ring on 64bit arches. Signed-off-by:
Matthew Carlson <mcarlson@broadcom.com>
-
Uwe Kleine-König authored
The function virtnet_remove is used only wrapped by __devexit_p so define it using __devexit. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Cc: David S. Miller <davem@davemloft.net> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Alex Williamson <alex.williamson@hp.com> Cc: Mark McLoughlin <markmc@redhat.com> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Uwe Kleine-König authored
The function sgiseeq_remove is defined using __exit, so don't use __devexit_p but __exit_p to wrap it. Signed-off-by:
-
Uwe Kleine-König authored
The function meth_remove is defined using __exit, so don't use __devexit_p but __exit_p to wrap it. Signed-off-by:
-
Jiri Pirko authored
Primary module parameter passed to bonding is pernament. That means if you release the primary slave and enslave it again, it becomes the primary slave again. But if you set primary slave via sysfs, the primary slave is only set once and it's not remembered in bond->params structure. Therefore the setting is lost after releasing the primary slave. This simple one-liner fixes this. Signed-off-by:
Jiri Pirko <jpirko@redhat.com> Signed-off-by:
Jay Vosburgh <fubar@us.ibm.com> Signed-off-by:
-
-
Eric Dumazet authored
After last pktgen changes, delay handling is wrong. pktgen actually sends packets at full line speed. Fix is to update pkt_dev->next_tx even if spin() returns early, so that next spin() calls have a chance to see a positive delay. Signed-off-by:
-
Jiri Pirko authored
ccffad25 changed parameters for function ixgbe_update_uc_addr_list_generic but parameter description was not updated. This patch corrects it. Signed-off-by:
-
Ajit Khaparde authored
vtp bit in RX completion descriptor could be wrongly set in some skews of BladEngine. Ignore this bit if vtm is not set. Resending because the previous patch was against net-next tree. This patch is against the net-2.6 tree. Signed-off-by:
-
