- 20 Apr, 2009 20 commits
-
-
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:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
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:
David S. Miller <davem@davemloft.net>
-
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:
-
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:
-
- 19 Apr, 2009 3 commits
-
-
Marcel Holtmann authored
The Broadcom chips with 2.1 firmware handle the fallback case to a SCO link wrongly when setting up eSCO connections. < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 11 voice setting 0x0060 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 1 bdaddr 00:1E:3A:xx:xx:xx type SCO encrypt 0x01 The Link Manager negotiates the fallback to SCO, but then sends out a Connect Complete event. This is wrong and the Link Manager should actually send a Synchronous Connection Complete event if the Setup Synchronous Connection has been used. Only the remote side is allowed to use Connect Complete to indicate the missing support for eSCO in the host stack. This patch adds a workaround for this which clearly should not be needed, but reality is that broken Broadcom devices are deployed. Based on a report by Ville Tervo <ville.tervo@nokia.com> Signed-off-by:Marcel Holtman <marcel@holtmann.org>
-
Marcel Holtmann authored
Some Bluetooth chips (like the ones from Texas Instruments) don't do proper eSCO negotiations inside the Link Manager. They just return an error code and in case of the Kyocera ED-8800 headset it is just a random error. < HCI Command: Setup Synchronous Connection 0x01|0x0028) plen 17 handle 1 voice setting 0x0060 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x1f handle 257 bdaddr 00:14:0A:xx:xx:xx type eSCO Error: Unspecified Error In these cases it is up to the host stack to fallback to a SCO setup and so retry with SCO parameters. Based on a report by Nick Pelly <npelly@google.com> Signed-off-by: -
Johan Hedberg authored
There is a missing call to rfcomm_dlc_clear_timer in the case that DEFER_SETUP is used and so the connection gets disconnected after the timeout even if it was successfully accepted previously. This patch adds a call to rfcomm_dlc_clear_timer to rfcomm_dlc_accept which will get called when the user accepts the connection by calling read() on the socket. Signed-off-by:
Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by:
-
- 17 Apr, 2009 17 commits
-
-
Patrick McHardy authored
Check whether the underlying device provides a set of ethtool ops before checking for individual handlers to avoid NULL pointer dereferences. Reported-by:
Art van Breemen <ard@telegraafnet.nl> Signed-off-by:
-
-
-
Christian Lamparter authored
Signed-off-by:
-
Johannes Berg authored
The TIM IE must not be shorter than 4 bytes, so verify that when parsing it. Signed-off-by:
-
Johannes Berg authored
Instead, allocate extra IE memory if necessary. Normally, this isn't even necessary since there's enough space. This is a better way of correcting the "held BSS can disappear" issue, but also a lot more code. It is also necessary for proper auth/assoc BSS handling in the future. Signed-off-by:
-
Johannes Berg authored
When we receive a probe response frame we can replace the BSS struct in our list -- but if that struct is held then we need to hold the new one as well. We really should fix this completely and not replace the struct, but this is a bandaid for now. Signed-off-by:
-
Johannes Berg authored
Using the scan_sdata variable here is terribly wrong, if there has never been a scan then we fail. However, we need a bandaid... Signed-off-by:
-
Pablo Neira Ayuso authored
With this patch, nfnetlink returns -ENOMEM instead of -EPERM if we fail to create the nfnetlink netlink socket during the module loading. This is exactly what rtnetlink does in this case. Ideally, it would be better if we propagate the error that has happened in netlink_kernel_create(), however, this function still does not implement this yet. Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Pablo Neira Ayuso authored
This patch fixes an inconsistency that results in no error reports to user-space listeners if we fail to allocate the event message. Signed-off-by:
-
Herbert Xu authored
After calling skb_gro_receive skb->len can no longer be relied on since if the skb was merged using frags, then its pages will have been removed and the length reduced. This caused tcp_gro_receive to prematurely end merging which resulted in suboptimal performance with ixgbe. The fix is to store skb->len on the stack. Reported-by:
Mark Wagner <mwagner@redhat.com> Signed-off-by:
-
Oliver Neukum authored
EPERM means that disconnect() is runnung. It should be treated like ENODEV Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Oliver Hartkopp authored
Since commit ead2ceb0 ("Network Drop Monitor: Adding kfree_skb_clean for non-drops and modifying end-of-line points for skbs") so called end-of-line points for skb's should use consume_skb() to free the socket buffer. In opposite to consume_skb() the function kfree_skb() is intended to be used for unexpected skb drops e.g. in error conditions that now can trigger the network drop monitor if enabled. This patch moves the skb end-of-line point in af_can.c to use consume_skb(). Signed-off-by:
Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by:
-
Erik Waling authored
Suppose that we receive lots of frames, start processing them, but exhaust our budget so that we return before we had a chance to look at all of them. Then, when the network layer calls us again, we will only continue processing the buffers if the REC bit was set in the mean time, which it might not be if there was a brief pause in the flow of packets. If this happens, we'll simply display a warning and call netif_rx_complete() with potentially lots of unprocessed packets in the RX ring... Fix this by scanning the ring no matter what flags are set in the interrupt status register. Signed-off-by:
Erik Waling <erik.waling@konftel.com> Signed-off-by:
Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Signed-off-by:
-
Erik Waling authored
When transfering large amounts of data we sometimes experienced that the Retry Limit Exceeded (RLE) bit got set in TSR during transmission attempts. When this happened the driver would stall in a state that prevented any more data from being sent. Signed-off-by:
-
PJ Waskiewicz authored
The thresholds for the DCB priority flow control are incorrect for 82599. This fixes the thresholds to be correct. 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:
-
PJ Waskiewicz authored
The traffic classes in hardware are not symmetrical for Rx and Tx. Rx is every 16 descriptor queues, Tx is not. It runs 32-32-16-16-8-8-8 when running with 8 traffic classes, and runs 64-32-16 when running with 4 traffic classes. This patch fixes the mapping. Signed-off-by:
-
