- 15 Mar, 2010 19 commits
-
-
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:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
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:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.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:
Linus Torvalds <torvalds@linux-foundation.org> 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:
Mauro Carvalho Chehab <mchehab@redhat.com> 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 21 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:
-
Dave Airlie authored
commit 01d45039 upstream. For usec delays use udelay instead of scheduling, this should allow reclocking to happen faster. This also was the cause of reported 33s delays at bootup on certain systems. fixes: freedesktop.org bug 25506 Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Arjan van de Ven authored
commit 370d5cd8 upstream. Since the rewrite of the CPU idle governor in 2.6.32, two laptops have surfaced where the BIOS advertises a C2 power state, but for some reason this state is not functioning (as verified in both cases by powertop before the patch in .32). The old governor had the accidental behavior that if a non-working state was chosen too many times, it would end up falling back to C1. The new governor works differently and this accidental behavior is no longer there; the result is a high temperature on these two machines. This patch adds these 2 machines to the DMI table for C state anomalies; by just not using C2 both these machines are better off (the TSC can be used instead of the pm timer, giving a performance boost for example). Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14742Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Reported-by: <akwatts@ymail.com> Signed-off-by:
-
Thomas Renninger authored
commit d2f6650a upstream. If acpi_bus_add does not return a device and it's passed to acpi_bus_start, bad things will happen: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff8128402d>] acpi_bus_start+0x14/0x24 ... [<ffffffffa008977a>] acpiphp_bus_add+0xba/0x130 [acpiphp] [<ffffffffa008aa72>] enable_device+0x132/0x2ff [acpiphp] [<ffffffffa0089b68>] acpiphp_enable_slot+0xb8/0x130 [acpiphp] [<ffffffffa0089df7>] handle_hotplug_event_func+0x87/0x190 [acpiphp] Next patch would make this NULL pointer check obsolete, but better having one more than one missing... Signed-off-by:
Thomas Renninger <trenn@suse.de> Acked-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
-
Jelle Martijn Kok authored
commit 174b2496 upstream. Add new RTL8187B device. Signed-off-by:
-
Linus Torvalds authored
commit ddeee0b2 upstream. I notice that the processcompl_compat() function seems to be leaking the 'struct async *as' in the error paths. I think that the calling convention is fundamentally buggered. The caller is the one that did the "reap_as()" to get the as thing, the caller should be the one to free it too. Freeing it in the caller also means that it very clearly always gets freed, and avoids the need for any "free in the error case too". From: Linus Torvalds <torvalds@linux-foundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Marcus Meissner <meissner@suse.de> Signed-off-by:
-
Greg KH authored
commit d4a4683c upstream. We need to only copy the data received by the device to userspace, not the whole kernel buffer, which can contain "stale" data. Thanks to Marcus Meissner for pointing this out and testing the fix. Reported-by:
Marcus Meissner <meissner@suse.de> Tested-by:
-
Laurent Pinchart authored
commit 18d19c96 upstream. Fix a memory leak by freeing the memory allocated in __class_register for the class private data. Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by:
-
Eric W. Biederman authored
commit 7c0ff870 upstream. There is currently a bug in sysfs_sd_setattr inherited from sysfs_setattr in 2.6.32 where the first time we set the attributes on a sysfs file we allocate backing store but do not set the backing store attributes. Resulting in overly restrictive permissions on sysfs files. The fix is to simply modify the code so that it always executes when we update the sysfs attributes, as we did in 2.6.31 and earlier. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Tested-by:
-
Dick Hollenbeck authored
commit bca47613 upstream. When controlling an industrial radio modem it can be necessary to manipulate the handshake lines in order to control the radio modem's transmitter, from userspace. The transmitter should not be turned off before all characters have been transmitted. serial8250_tx_empty() was reporting that all characters were transmitted before they actually were. === Discovered in parallel with more testing and analysis by Kees Schoenmakers as follows: I ran into an NetMos 9835 serial pci board which behaves a little different than the standard. This type of expansion board is very common. "Standard" 8250 compatible devices clear the 'UART_LST_TEMT" bit together with the "UART_LSR_THRE" bit when writing data to the device. The NetMos device does it slightly different I believe that the TEMT bit is coupled to the shift register. The problem is that after writing data to the device and very quickly after that one does call serial8250_tx_empty, it returns the wrong information. My patch makes the test more robust (and solves the problem) and it does not affect the already correct devices. Alan: We may yet need to quirk this but now we know which chips we have a way to do that should we find this breaks some other 8250 clone with dodgy THRE. Signed-off-by:
Dick Hollenbeck <dick@softplc.com> Signed-off-by:
Alan Cox <alan@linux.intel.com> Cc: Kees Schoenmakers <k.schoenmakers@sigmae.nl> Signed-off-by:
-
Takashi Iwai authored
commit 78b8d5d2 upstream. As the release of substreams may be done asynchronously from the disconnection, close callback needs to check the shutdown flag before actually accessing the usb interface. Reference: Novell bnc#505027 http://bugzilla.novell.com/show_bug.cgi?id=565027Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
George Kadianakis authored
commit df574b8e upstream. This patch fixes compilation problems that were caused by function naming conflicts between the rtl8187se driver and the mac80211 stack. Signed-off-by:
George Kadianakis <desnacked@gmail.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Yinghai Lu authored
commit 37ef2a30 upstream. When irq_desc is moved, we need to make sure to use the right cfg_new. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4B07A739.3030104@kernel.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
