- 15 Mar, 2010 31 commits
-
-
Stanislaw Gruszka authored
commit f09c2563 upstream. Patch prevents call set_wep_key() with zero key length. That fix long standing regression since commit c0380693 "airo: clean up WEP key operations". Additionally print call trace when someone will try to use improper parameters, and remove key.len = 0 assignment, because it is in not possible code path. Reported-by:
Chris Siebenmann <cks-rhbugzilla@cs.toronto.edu> Bisected-by:
Chris Siebenmann <cks@cs.toronto.edu> Cc: Dan Williams <dcbw@redhat.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Oliver Neukum authored
commit 858155fb upstream. Some devices do not react to a control request (seen on APC UPS's) resulting in a slow stream of messages, "generic-usb ... control queue full". Therefore request needs a timeout. Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
David Fries <david@fries.net> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Peter Hutterer authored
commit 9db630b4 upstream. These touchscreens are mounted onto HP TouchSmart and the Dell Studio One 19. Without a quirk they report a wrong button set and the x/y coordinates through ABS_Z/ABS_RX, confusing the higher levels (most notably X.Org's evdev driver). Device id 0x003 covers models 1900, 2150, and 2700 [1] though testing could only be performed on a model 1900. [1] http://www.nextwindow.com/nextwindow_support/latest_tech_info.htmlSigned-off-by:
Peter Hutterer <peter.hutterer@redhat.com> Signed-off-by:
-
Jiri Kosina authored
commit 4bb9508b upstream. There were multiple reports which indicate that vendor messed up horribly and the same VID/PID combination is used for completely different devices, some of them requiring the blacklist entry and other not. Remove the blacklist entry for this combination of VID/PID completely, and let the user decide and unbind the driver via sysfs eventually, if needed. Proper fix would be fixing the vendor. References: http://lkml.org/lkml/2009/2/10/434 http://bugzilla.kernel.org/show_bug.cgi?id=13411Signed-off-by:
-
Wu Fengguang authored
commit 0141450f upstream. This fixes inefficient page-by-page reads on POSIX_FADV_RANDOM. POSIX_FADV_RANDOM used to set ra_pages=0, which leads to poor performance: a 16K read will be carried out in 4 _sync_ 1-page reads. In other places, ra_pages==0 means - it's ramfs/tmpfs/hugetlbfs/sysfs/configfs - some IO error happened where multi-page read IO won't help or should be avoided. POSIX_FADV_RANDOM actually want a different semantics: to disable the *heuristic* readahead algorithm, and to use a dumb one which faithfully submit read IO for whatever application requests. So introduce a flag FMODE_RANDOM for POSIX_FADV_RANDOM. Note that the random hint is not likely to help random reads performance noticeably. And it may be too permissive on huge request size (its IO size is not limited by read_ahead_kb). In Quentin's report (http://lkml.org/lkml/2009/12/24/145), the overall (NFS read) performance of the application increased by 313%! Tested-by:
Quentin Barnes <qbarnes+nfs@yahoo-inc.com> Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Andi Kleen <andi@firstfloor.org> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Chuck Lever <chuck.lever@oracle.com> Cc: <qbarnes+nfs@yahoo-inc.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Wu Fengguang authored
commit 42e49608 upstream. We'll introduce FMODE_RANDOM which will be runtime modified. So protect all runtime modification to f_mode with f_lock to avoid races. Signed-off-by:
-
Theodore Kilgore authored
commit 70136081 upstream. If you read the mail to Oliver Neukum on the linux-usb list, then you know that I found a cure for the mysterious problem that the MR97310a CIF "type 1" cameras have been freezing up and refusing to stream if hooked up to a machine with a UHCI controller. Namely, the cure is that if the camera is an mr97310a CIF type 1 camera, you have to send it 0xa0, 0x00. Somehow, this is a timing reset command, or such. It un-blocks whatever was previously stopping the CIF type 1 cameras from working on the UHCI-based machines. Signed-off-by:
Theodore Kilgore <kilgota@auburn.edu> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Zhu Yi authored
commit 3dc1de0b upstream. Make addba_resp_timer aware the HT_AGG_STATE_REQ_STOP_BA_MSK mask so that when ___ieee80211_stop_tx_ba_session() is issued the timer will quit. Otherwise when suspend happens before the timer expired, the timer handler will be called immediately after resume and messes up driver status. Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Haicheng Li authored
commit f3186a9c upstream. Comparing with existing code, it's a simpler way to use kzalloc_node() to ensure that each unused alien cache entry is NULL. CC: Eric Dumazet <eric.dumazet@gmail.com> Acked-by:
Andi Kleen <ak@linux.intel.com> Acked-by:
Christoph Lameter <cl@linux-foundation.org> Acked-by:
Matt Mackall <mpm@selenic.com> Signed-off-by:
Haicheng Li <haicheng.li@linux.intel.com> Signed-off-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
-
Kashyap, Desai authored
commit d7384b28 upstream. The driver hangs when doing `rmmod mpt2sas` if there are any IR volumes present.The hang is due the scsi midlayer trying to access the IR volumes after the driver releases controller resources. Perhaps when scsi_remove_host is called,the scsi mid layer is sending some request. This doesn't occur for bare drives becuase the driver is already reporting those drives deleted prior to calling mpt2sas_base_detach. To solve this issue, we need to delete the volumes as well. Signed-off-by:
Kashyap Desai <kashyap.desai@lsi.com> Reviewed-by:
Eric Moore <eric.moore@lsi.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Pallipadi, Venkatesh authored
commit d306ebc2 upstream. ACPI deep C-state entry had a long standing bug/missing feature, wherein we were sending resched IPIs when an idle CPU is in mwait based deep C-state. Only mwait based C1 was using the write to the monitored address to wake up mwait'ing CPU. This patch changes the code to retain TS_POLLING bit if we are entering an mwait based deep C-state. The patch has been verified to reduce the number of resched IPIs in general and also improves the performance/power on workloads with low system utilization (i.e., when mwait based deep C-states are being used). Fixes "netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f6" http://marc.info/?l=linux-kernel&m=126441481427331&w=4Reported-by:
Lin Ming <ming.m.lin@intel.com> Tested-by:
Alex Shi <alex.shi@intel.com> Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Zhang Rui authored
commit 1379d2fe upstream. Wrong Lid state reported. Need to blacklist this machine for LVDS detection. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Roel Kluin authored
commit f04d5e01 upstream. sysfs_remove_group() removed the wrong attribute_group for thermal_read_mode TPEC_8, ACPI_TMP07 and ACPI_UPDT Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Acked-by:
Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br> Signed-off-by:
-
Len Brown authored
commit 49bf83a4 upstream. We broke "acpi=ht" in 2.6.32 by disabling MADT parsing for acpi=disabled. e5b8fc6a This also broke systems which invoked acpi=ht via DMI blacklist. acpi=ht is a really ugly hack, but restore it for those that still use it. http://bugzilla.kernel.org/show_bug.cgi?id=14886Signed-off-by:
-
Len Brown authored
commit 97c169d3 upstream. We realized when we broke acpi=ht http://bugzilla.kernel.org/show_bug.cgi?id=14886 that acpi=ht is not needed on this box and folks have been using acpi=force on it anyway. Signed-off-by:
-
Andrew Morton authored
commit ba02b242 upstream. check ioremap() return value. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Chandru authored
commit b0fc889c upstream. ibmphp driver currently maps only 1KB of ebda memory area into kernel address space during driver initialization. This causes kernel oops when the driver is modprobe'd and it accesses memory beyond 1KB within ebda segment. The first byte of ebda segment actually stores the length of the ebda region in Kilobytes. Hence make use of the length parameter and map the entire ebda region. Signed-off-by:
Chandru Siddalingappa <chandru@linux.vnet.ibm.com> Signed-off-by:
-
Robert Hancock authored
commit 453d3131 upstream. Mike Cui reported that his system with an NVIDIA MCP79 (aka MCP7A) chipset stopped working with 2.6.32. The problem appears to be that 2.6.32 now enables the FPDMA auto-activate optimization in the ahci driver. The drive works fine with this enabled on an Intel AHCI so this appears to be a chipset bug. Since MCP79 is a fairly recent NVIDIA chipset and we don't have any info on whether any other NVIDIA chipsets have this issue, disable FPDMA AA optimization on all NVIDIA AHCI controllers for now. Should address http://bugzilla.kernel.org/show_bug.cgi?id=14922Signed-off-by:
Robert Hancock <hancockrwd@gmail.com> While-we-investigate-issue-this-patch-looks-good-to-me-by:
Prajakta Gudadhe <pgudadhe@nvidia.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Joshua Roys authored
commit c36f74e6 upstream. This fixes corrupted CIPSO packets when SELinux categories greater than 127 are used. The bug occured on the second (and later) loops through the while; the inner for loop through the ebitmap->maps array used the same index as the NetLabel catmap->bitmap array, even though the NetLabel bitmap is twice as long as the SELinux bitmap. Signed-off-by:
Joshua Roys <joshua.roys@gtri.gatech.edu> Acked-by:
Paul Moore <paul.moore@hp.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit a120e912 upstream. Check the frame control for ieee80211_is_data_qos() is true before counting the number of tfds can be free, the tfds_in_queue only increment when ieee80211_is_data_qos() is true before transmit; so it should only decrement if the type match. Remove ieee80211_is_data_qos check for frame_ctrl in tx_resp to avoid invalid information pass from uCode. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Dan Halperin authored
commit 5e2f75b8 upstream. The HT extension channel settings require priv->staging_rxon.channel to be accurate. However, iwl_set_rxon_ht was being called before iwl_set_rxon_channel and thus HT40 could be broken unless another call to iwl_mac_config came in. This problem was recently introduced by "iwlwifi: Fix to set correct ht configuration" The particular setting in which I noticed this was monitor mode: iwconfig wlan0 mode monitor ifconfig wlan0 up ./iw wlan0 set channel 64 HT40- #./iw wlan0 set channel 64 HT40- tcpdump -i wlan0 -y IEEE802_11_RADIO would only catch HT40 packets if I issued the IW command twice. From visual inspection, iwl_set_rxon_channel does not depend on iwl_set_rxon_ht, so simply swapping them should be safe and fixes this problem. Signed-off-by:
Daniel Halperin <dhalperi@cs.washington.edu> Acked-by:
-
Wey-Yi Guy authored
commit a239a8b4 upstream. When receive reply_tx and ready to decrement the count for number of tfds in queue, do error checking to prevent error condition and tfds_in_queue become negative number. Signed-off-by:
-
Michael Neuling authored
commit a17e1879 upstream. 803bf5ec ("fs/exec.c: restrict initial stack space expansion to rlimit") attempts to limit the initial stack to 20*PAGE_SIZE. Unfortunately, in attempting ensure the stack is not reduced in size, we ended up not changing the stack at all. This size reduction check is not necessary as the expand_stack call does this already. This caused a regression in UML resulting in most guest processes being killed. Signed-off-by:
Michael Neuling <mikey@neuling.org> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by:
WANG Cong <xiyou.wangcong@gmail.com> Cc: Anton Blanchard <anton@samba.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: James Morris <jmorris@namei.org> Cc: Serge Hallyn <serue@us.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Jouni Malinen <j@w1.fi> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
commit 5a2d4196 upstream. Presently the oom-killer is memcg aware and it finds the worst process from processes under memcg(s) in oom. Then, it kills victim's child first. It may kill a child in another cgroup and may not be any help for recovery. And it will break the assumption users have. This patch fixes it. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Cc: Balbir Singh <balbir@linux.vnet.ibm.com> Reviewed-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
-
Ben Hutchings authored
commit fc4a7f93 upstream. cxusb uses the atbm8830 and lgs8gxx (not lgs8gl5) frontends and the max2165 tuner, so it needs to select them. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Jean Delvare authored
commit 24344664 upstream. Move I2C IR initialization from just after I2C bus setup to right before non-I2C IR initialization. This avoids the case where an I2C IR device is blocking audio support (at least the PV951 suffers from this). It is also more logical to group IR support together, regardless of the connectivity. This fixes bug #15184: http://bugzilla.kernel.org/show_bug.cgi?id=15184Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Martin Fuzzey authored
V4L/DVB: Video : pwc : Fix regression in pwc_set_shutter_speed caused by bad constant => sizeof conversion. commit 53f68607 upstream. Regression was caused by my commit 6b35ca0d which determined message size using sizeof rather than hardcoded constants. Unfortunately pwc_set_shutter_speed reuses a 2 byte buffer for a one byte message too so the sizeof was bogus in this case. All other uses of sizeof checked and are ok. Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Martin Fuzzey <mfuzzey@gmail.com> Signed-off-by:
-
Mike Frysinger authored
commit 3dae93ec upstream. Relying on overflow/wrap around isn't exact because if you wrap far enough, you get back to "valid" values. Reported-by:
Thorsten Pohlmann <pohlmann@tetronik.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Richard Guenther authored
commit c1db53b3 upstream. I'm trying to fix it on the GCC side (PR43007), but the module is quite stupid in using ULL constants to operate on u32 values: static int apply_frontend_param (struct dvb_frontend* fe, struct dvb_frontend_parameters *param) { ... static const u32 ppm = 8000; u32 spi_bias; ... spi_bias *= 1000ULL; spi_bias /= 1000ULL + ppm/1000; which causes current GCC 4.5 to emit calls to __udivdi3 for i?86 again. This patch fixes this issue. Signed-off-by:
Richard Guenther <rguenther@suse.de> Signed-off-by:
-
Guennadi Liakhovetski authored
commit b857df1a upstream. mod_timer() takes an absolute time and not a delay as its argument. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Al Viro authored
commit ac278a9c upstream. Make sure that automount "symlinks" are followed regardless of LOOKUP_FOLLOW; it should have no effect on them. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
- 23 Feb, 2010 9 commits
-
-
Greg Kroah-Hartman authored
-
Jonathan Brassow authored
commit ebfd32bb upstream. This patch fixes two bugs that revolve around the miscalculation and misuse of the variable 'overhead_size'. 'overhead_size' is the size of the various header structures used during communication. The first bug is the use of 'sizeof' with the pointer of a structure instead of the structure itself - resulting in the wrong size being computed. This is then used in a check to see if the payload (data_size) would be to large for the preallocated structure. Since the bug produces a smaller value for the overhead, it was possible for the structure to be breached. (Although the current users of the code do not currently send enough data to trigger this bug.) The second bug is that the 'overhead_size' value is used to compute how much of the preallocated space should be cleared before populating it with fresh data. This should have simply been 'sizeof(struct cn_msg)' not overhead_size. The fact that 'overhead_size' was computed incorrectly made this problem "less bad" - leaving only a pointer's worth of space at the end uncleared. Thus, this bug was never producing a bad result, but still needs to be fixed - especially now that the value is computed correctly. Signed-off-by:
Jonathan Brassow <jbrassow@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Nikanth Karthikesan authored
commit 781248c1 upstream. If a table containing zero as stripe count is passed into stripe_ctr the code attempts to divide by zero. This patch changes DM_TABLE_LOAD to return -EINVAL if the stripe count is zero. We now get the following error messages: device-mapper: table: 253:0: striped: Invalid stripe count device-mapper: ioctl: error adding target to table Signed-off-by:
Nikanth Karthikesan <knikanth@suse.de> Signed-off-by:
-
Wey-Yi Guy authored
commit 098dfded upstream. iwl_set_rxon_ht() only get called in iwl_post_associate(); which cause possible incorrect ht configuration. Adding the call in iwl_mac_config() if IEEE80211_CONF_CHANGE_CHANNEL flag is set to re-configure and send rxon command. Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2146Signed-off-by:
-
Benoit Papillault authored
commit 0da780c2 upstream. We only reply to probe request if either the requested SSID is the broadcast SSID or if the requested SSID matches our own SSID. This latter case was not properly handled since we were replying to different SSID with the same length as our own SSID. Signed-off-by:
Benoit Papillault <benoit.papillault@free.fr> Signed-off-by:
-
Sujith authored
commit 6c8afef5 upstream. Currently, PAE frames are not assigned proper sequence numbers. Since sending PAE frames as part of aggregates breaks crupto with several APs, they are sent as normal MPDUs. Fix the seqeuence number issue by updating the frame with the internal sequence number. Tested-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Sujith <Sujith.Manoharan@atheros.com> Signed-off-by:
-
Larry Finger authored
commit b6c3f5be upstream. Commit c7ab5ef9 entitled "b43: implement short slot and basic rate handling" reduced the transmit throughput for my BCM4311 device from 18 Mb/s to 0.7 Mb/s. The basic rate handling portion is OK, the problem is in the short slot handling. Prior to this change, the short slot enable/disable routines were never called. Experimentation showed that the critical part was changing the value at offset 0x0010 in the shared memory. This is supposed to contain the 802.11 Slot Time in usec, but if it is changed from its initial value of zero, performance is destroyed. On the other hand, changing the value in the MMIO register corresponding to the Interframe Slot Time increased performance from 18 to 22 Mb/s. A BCM4306/3 also shows dramatic improvement of the transmit rate from 5.3 to 19.0 Mb/s. Other changes in the patch include removal of the magic number for the MMIO register, and allowing the slot time to be set for any PHY operating in the 2.4 GHz band. Previously, the routine was executed only for G PHYs. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Tyler Hicks authored
commit f8f484d1 upstream. The i_blocks field of an eCryptfs inode cannot be trusted, but generic_fillattr() uses it to instantiate the blocks field of a stat() syscall when a filesystem doesn't implement its own getattr(). Users have noticed that the output of du is incorrect on newly created files. This patch creates ecryptfs_getattr() which calls into the lower filesystem's getattr() so that eCryptfs can use its kstat.blocks value after calling generic_fillattr(). It is important to note that the block count includes the eCryptfs metadata stored in the beginning of the lower file plus any padding used to fill an extent before encryption. https://bugs.launchpad.net/ecryptfs/+bug/390833Reported-by:
Dominic Sacré <dominic.sacre@gmx.de> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Cc: Tim Gardner <timg@tpi.com> Signed-off-by:
-
Chuck Lever authored
commit 65d26953 upstream. The cached read and write paths initialize fattr->time_start in their setup procedures. The value of fattr->time_start is propagated to read_cache_jiffies by nfs_update_inode(). Subsequent calls to nfs_attribute_timeout() will then use a good time stamp when computing the attribute cache timeout, and squelch unneeded GETATTR calls. Since the direct I/O paths erroneously leave the inode's fattr->time_start field set to zero, read_cache_jiffies for that inode is set to zero after any direct read or write operation. This triggers an otw GETATTR or ACCESS call to update the file's attribute and access caches properly, even when the NFS READ or WRITE replies have usable post-op attributes. Make sure the direct read and write setup code performs the same fattr initialization as the cached I/O paths to prevent unnecessary GETATTR calls. This was likely introduced by commit 0e574af1 in 2.6.15, which appears to add new nfs_fattr_init() call sites in the cached read and write paths, but not in the equivalent places in fs/nfs/direct.c. A subsequent commit in the same series, 33801147, introduces the fattr->time_start field. Interestingly, the direct write reschedule path already has a call to nfs_fattr_init() in the right place. Reported-by:
Quentin Barnes <qbarnes@yahoo-inc.com> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
