- 21 Apr, 2009 9 commits
-
-
Peter Holik authored
because of using the same function get_ethernet_addr as cdc_ether.c i export usbnet_get_ethernet_addr from usbnet and fixed cdc_ether (suggested by Oliver Neukum). Signed-off-by:
Peter Holik <peter@holik.at> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Matt Carlson authored
This patch updates the tg3 version to 3.99. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
Matt Carlson authored
After a shutdown reset, the LAA needs to be restored before posting the post-reset signature in shared memory. If the LAA is not restored before then, the bootcode will assume the factory default MAC address and WOL will not work with the LAA. Signed-off-by:
-
Matt Carlson authored
This patch restricts the CLKREQ bugfix to the A0 and A1 revisions of 57780 ASIC rev chips. Signed-off-by:
-
Matt Carlson authored
The 5761 WOL and LED fixes used the PCI device ID to as the activation key. The 5761S requires the same process. Signed-off-by:
-
Matt Carlson authored
On rare occasions, send BD corruptions can occur. This patch fixes the problem by increasing the L1 entry threshold to 4 milliseconds. Signed-off-by:
-
Matt Carlson authored
Some 57780 ASIC revision parts do not have NVRAM. Code the driver so that it is tolerant of this configuration. Signed-off-by:
-
Matt Carlson authored
The tg3 driver's ISR is coded to accept interrupts as its own if the status block tag does not equal the last tag the driver has seen. The last_tag field is updated from tg3_poll. In a screaming interrupt situation from another device sharing tg3's IRQ, tg3_poll does not get a chance to be called, so the last_tag will always be out of sync with the status block tag. Consequently, the driver will continually declare the screaming interrupts as its own, thus thwarting the screaming interrupt detection logic. This patch solves the problem by creating a new last_irq_tag member and recording the status block tag in the ISR. The ISR then checks the last_irq_tag for interrupt ownership. Many thanks to John Marvin for the detailed bug report and analysis and Michael Chan for the bugfix. Signed-off-by:
John Marvin <jsm@fc.hp.com> Signed-off-by:
-
David S. Miller authored
Conflicts: net/core/dev.c
-
- 20 Apr, 2009 31 commits
-
-
-
Matt Carlson authored
The recent NVRAM patches sanitized how the driver deals with NVRAM data, but they failed to bring the SEEPROM interfaces inline with the new strategy. This patch brings the SEEPROM interfaces up to date. This patch also reverts commit 0d489ffb ("tg3: fix big endian MAC address collection failure"). Signed-off-by:
Robin Holt <holt@sgi.com> Tested-by:
James Bottomley <james.bottomley@HansenPartnership.com> Signed-off-by:
-
Johannes Berg authored
"mac80211: fix basic rates setting from association response" introduced a copy/paste error. Unfortunately, this not just leads to wrong data being passed to the driver but is remotely exploitable for some hardware or driver combinations. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Cc: stable@kernel.org [2.6.29] Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Kalle Valo authored
Currently beacon loss detection triggers after a scan. A probe request is sent and a message like this is printed to the log: wlan0: beacon loss from AP 00:12:17:e7:98:de - sending probe request But in fact there is no beacon loss, the beacons are just not received because of the ongoing scan. Fix it by updating last_beacon after the scan has finished. Reported-by:
Jaswinder Singh Rajput <jaswinder@kernel.org> Signed-off-by:
Kalle Valo <kalle.valo@iki.fi> Acked-by:
-
Jouni Malinen authored
One of the code paths sending deauth/disassoc events ends up calling this function with rcu_read_lock held, so we must use GFP_ATOMIC in allocation routines. Reported-by:
Jouni Malinen <j@w1.fi> Signed-off-by:
-
Christian Lamparter authored
This patch fixes a hang on resume when the filesystem is not available and request_firmware blocks. However, the device does not accept the firmware on resume. and it will exit with: > firmware part 1 upload failed (-71). > device is in a bad state. please reconnect it! Reported-by:
Christian Lamparter <chunkeey@web.de> Signed-off-by:
-
Robert P. J. Day authored
Remove this unused Kconfig variable, which Intel apparently once promised to make use of but never did. Signed-off-by:
Robert P. J. Day <rpjday@crashcourse.ca> Acked-by:
-
Joerg Albert authored
swap mwl8k_remove and mwl8k_shutdown functions to allow "rmmod mwl8k; modprobe mwl8k" Signed-off-by:
Joerg Albert <jal2@gmx.de> Signed-off-by:
-
Christian Lamparter authored
This patch deactivates powersave in station mode. It does not work correctly yet, so the code does more harm than good. Reported-by:
-
Joe Perches authored
"not" is not printed without a space after %pM Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Ivo van Doorn authored
After suspend & resume the rt2x00 devices won't wakeup anymore due to a broken register information setup. The most important problem is the release of the EEPROM buffer which is completely cleared and never read again after the suspend. Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Herbert Xu authored
As the sk_sleep wait queue actually lives in tfile, which may be detached from the tun device, bad things will happen when we use sk_sleep after detaching. Since the tun device is the persistent data structure here (when requested by the user), it makes much more sense to have the wait queue live there. There is no reason to have it in tfile at all since the only time we can wait is if we have a tun attached. In fact we already have a wait queue in tun_struct, so we might as well use it. Reported-by:
Eric W. Biederman <ebiederm@xmission.com> Tested-by:
Christian Borntraeger <borntraeger@de.ibm.com> Tested-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Herbert Xu authored
The commit c70f1829 ("tun: Fix races between tun_net_close and free_netdev") fixed a race where an asynchronous deletion of a tun device can hose a poll(2) on a tun fd attached to that device. However, this came at the cost of moving the tun wait queue into the tun file data structure. The problem with this is that it imposes restrictions on when and where the tun device can access the wait queue since the tun file may change at any time due to detaching and reattaching. In particular, now that we need to use the wait queue on the receive path it becomes difficult to properly synchronise this with the detachment of the tun device. This patch solves the original race in a different way. Since the race is only because the underlying memory gets freed, we can prevent it simply by ensuring that we don't do that until all tun descriptors ever attached to the device (even if they have since be detached because they may still be sitting in poll) have been closed. This is done by using reference counting the attached tun file descriptors. The refcount in tun->sk has been reappropriated for this purpose since it was already being used for that, albeit from the opposite angle. Note that we no longer zero tfile->tun since tun_get will return NULL anyway after the refcount on tfile hits zero. Instead it represents whether this device has ever been attached to a device. Signed-off-by:
-
Florian Westphal authored
last_synq_overflow eats 4 or 8 bytes in struct tcp_sock, even though it is only used when a listening sockets syn queue is full. We can (ab)use rx_opt.ts_recent_stamp to store the same information; it is not used otherwise as long as a socket is in listen state. Move linger2 around to avoid splitting struct mtu_probe across cacheline boundary on 32 bit arches. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Eric Dumazet authored
We can in some situations drop packets in netif_rx() loopback driver does not report these (unlikely) drops to its stats, and incorrectly change packets/bytes counts. After this patch applied, "ifconfig lo" can reports these drops as in : # ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:692562900 errors:3228 dropped:3228 overruns:0 frame:0 TX packets:692562900 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2865674174 (2.6 GiB) TX bytes:2865674174 (2.6 GiB) I initialy chose to reflect those errors only in tx_dropped/tx_errors, but David convinced me that it was really RX errors, as loopback_xmit() really starts a RX process. (calling eth_type_trans() for example, that itself pulls the ethernet header) These errors are accounted in rx_dropped/rx_errors. Signed-off-by:Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
Ben Hutchings authored
This loop over fragments in napi_fraginfo_skb() was "interesting". Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
-
-
Marcin Slusarz authored
Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by:
-
Ilpo Järvinen authored
Just noticed while doing some new work that the recent mid-wq adjustment logic will misbehave when FACK is not in use (happens either due sysctl'ed off or auto-detected reordering) because I forgot the relevant TCPCB tagbit. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Jarek Poplawski authored
Alex Sidorenko reported: "while experimenting with 'netem' we have found some strange behaviour. It seemed that ingress delay as measured by 'ping' command shows up on some hosts but not on others. After some investigation I have found that the problem is that skbuff->tstamp field value depends on whether there are any packet sniffers enabled. That is: - if any ptype_all handler is registered, the tstamp field is as expected - if there are no ptype_all handlers, the tstamp field does not show the delay" This patch prevents unnecessary update of tstamp in dev_queue_xmit_nit() on ingress path (with act_mirred) adding a check, so minimal overhead on the fast path, but only when sniffers etc. are active. Since netem at ingress seems to logically emulate a network before a host, tstamp is zeroed to trigger the update and pretend delays are from the outside. Reported-by:
Alex Sidorenko <alexandre.sidorenko@hp.com> Tested-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
-
Alan Cox authored
This has been broken for a while. I happened to catch it testing because one app "knew" that the top line of the calls data was the policy line and got confused. Put the header back. Signed-off-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Divy Le Ray authored
EEH attempts to recover up 6 times. The last attempt leaves all the ports and adapter down.hen The driver is then unloaded, bringing the adapter down again unconditionally. The unload will hang. Check if the adapter is already down before trying to bring it down again. Signed-off-by:
Divy Le Ray <divy@chelsio.com> Signed-off-by:
-
Divy Le Ray authored
Release vectors when a MSI-X allocation fails. Signed-off-by:
-
Divy Le Ray authored
The fatal error task can be scheduled while processing an offload packet in NAPI context when the connection handle is bogus. this can race with the ports being brought down and the cxgb3 workqueue being flushed. Stop napi processing before flushing the work queue. The ULP drivers (iSCSI, iWARP) might also schedule a task on keventd_wk while releasing a connection handle (cxgb3_offload.c::cxgb3_queue_tid_release()). The driver however does not flush any work on keventd_wq while being unloaded. This patch also fixes this. Also call cancel_delayed_work_sync in place of the the deprecated cancel_rearming_delayed_workqueue. Signed-off-by:
-
Divy Le Ray authored
Use the existing periodic task to handle link faults. The link fault interrupt handler is also called in work queue context, which is wrong and might cause potential deadlocks. Signed-off-by:
-
Jesse Brandeburg authored
As reported by Andrew Lutomirski <amluto@gmail.com> All the intel wired ethernet drivers were calling netif_carrier_off and netif_stop_queue (or variants) before calling register_netdevice This is incorrect behavior as was pointed out by davem, and causes ifconfig and friends to report a strange state before first link after the driver was loaded. This apparently confused *some* versions of networkmanager. Andy tested this for e1000e and confirmed it was working for him. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Reported-by:
Andrew Lutomirski <amluto@gmail.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Jesse Brandeburg authored
As reported by Andrew Lutomirski <amluto@gmail.com> All the intel wired ethernet drivers were calling netif_carrier_off and netif_stop_queue (or variants) before calling register_netdevice This is incorrect behavior as was pointed out by davem, and causes ifconfig and friends to report a strange state before first link after the driver was loaded, since without a netif_carrier_off, the stack assumes carrier_on, but before register_netdev, netlink messages are not sent out telling link state. This apparently confused *some* versions of networkmanager. Andy tested this for e1000e and confirmed it was working for him. see thread: http://marc.info/?l=linux-netdev&m=123946479705636&w=2Signed-off-by:
-
Jesse Brandeburg authored
As reported by Andrew Lutomirski <amluto@gmail.com> All the intel wired ethernet drivers were calling netif_carrier_off and netif_stop_queue (or variants) before calling register_netdevice This is incorrect behavior as was pointed out by davem, and causes ifconfig and friends to report a strange state before first link after the driver was loaded, since without a netif_carrier_off, the stack assumes carrier_on, but before register_netdev, netlink messages are not sent out telling link state. This apparently confused *some* versions of networkmanager. Signed-off-by:
-
Jesse Brandeburg authored
As reported by Andrew Lutomirski <amluto@gmail.com> All the intel wired ethernet drivers were calling netif_carrier_off and netif_stop_queue (or variants) before calling register_netdevice This is incorrect behavior as was pointed out by davem, and causes ifconfig and friends to report a strange state before first link after the driver was loaded, since without a netif_carrier_off, the stack assumes carrier_on, but before register_netdev, netlink messages are not sent out telling link state. This apparently confused *some* versions of networkmanager. in addition this driver appeared to need a netif_start_queue at the end of open. Signed-off-by:
-
Jesse Brandeburg authored
As reported by Andrew Lutomirski <amluto@gmail.com> All the intel wired ethernet drivers were calling netif_carrier_off and netif_stop_queue (or variants) before calling register_netdevice This is incorrect behavior as was pointed out by davem, and causes ifconfig and friends to report a strange state before first link after the driver was loaded, since without a netif_carrier_off, the stack assumes carrier_on, but before register_netdev, netlink messages are not sent out telling link state. This apparently confused *some* versions of networkmanager. Signed-off-by:
-
Alexander Beregalov authored
Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by:
-
