- 26 Apr, 2010 40 commits
-
-
Dave Airlie authored
commit 79b9517a upstream. This is an M24/X600 chip. From RH# 581927 Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jerome Glisse authored
commit 30f69f3f upstream. Typo in in flush leaded to no flush of the RS600 tlb which ultimately leaded to massive system ram corruption, with this patch everythings seems to work properly. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 08d07511 upstream. On systems with the tv dac shared between DVI and TV, we can only use the dac for one of the connectors. However, when using a digital monitor on the DVI port, you can use the dac for the TV connector just fine. Check the use_digital status when resolving the conflict. Fixes fdo bug 27649, possibly others. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit d3a67a43 upstream. Switching between TV and VGA caused VGA to break on some systems since the TV encoder was left enabled when VGA was used. fixes fdo bug 25520. Signed-off-by:
-
Stefan Bader authored
commit 9875557e upstream. BugLink: http://bugs.launchpad.net/ubuntu/bugs/544671 This system claims to have a LVDS but has not. Signed-off-by:
Stephane Graber <stgraber@ubuntu.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Jean Delvare authored
commit c7a78d2c upstream. When CONFIG_REGULATOR isn't set, regulator_get_voltage() returns 0. Properly handle this case by not trusting the value. Reported-by:
Jerome Oufella <jerome.oufella@savoirfairelinux.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Jonathan Cameron <jic23@cam.ac.uk> Acked-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Jerome Oufella authored
commit 328a2c22 upstream. I discovered two issues. First the previous sht15_calc_temp() loop did not iterate through the temppoints array since the (data->supply_uV > temppoints[i - 1].vdd) test is always true in this direction. Also the two-points linear interpolation function was returning biased values due to a stray division by 1000 which shouldn't be there. [JD: Also change the default value for d1 from 0 to something saner.] Signed-off-by:
Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
-
Takashi Iwai authored
commit 29aac005 upstream. usb-midi causes sometimes Oops at snd_usbmidi_output_drain() after disconnection. This is due to the access to the endpoints which have been already released at disconnection while the files are still alive. This patch fixes the problem by checking disconnection state at snd_usbmidi_output_drain() and by releasing urbs but keeping the endpoint instances until really all freed. Tested-by:
Tvrtko Ursulin <tvrtko@ursulin.net> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Joerg Schirottke authored
commit d1501ea8 upstream. Added the matching model for Clevo laptop M570U. Signed-off-by:
Joerg Schirottke <master@kanotix.com> Tested-by:
Maximilian Gerhard <maxbox@directbox.com> Signed-off-by:
-
Trond Myklebust authored
commit 0df5dd4a upstream. Arnaud Giersch reports that NFSv4 locking is broken when we hold a delegation since commit 8e469ebd (NFSv4: Don't allow posix locking against servers that don't support it). According to Arnaud, the lock succeeds the first time he opens the file (since we cannot do a delegated open) but then fails after we start using delegated opens. The following patch fixes it by ensuring that locking behaviour is governed by a per-filesystem capability flag that is initially set, but gets cleared if the server ever returns an OPEN without the NFS4_OPEN_RESULT_LOCKTYPE_POSIX flag being set. Reported-by:
Arnaud Giersch <arnaud.giersch@iut-bm.univ-fcomte.fr> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit 80e60639 upstream. Signed-off-by:
-
Anton Blanchard authored
commit 84fba5ec upstream. taskset on 2.6.34-rc3 fails on one of my ppc64 test boxes with the following error: sched_getaffinity(0, 16, 0x10029650030) = -1 EINVAL (Invalid argument) This box has 128 threads and 16 bytes is enough to cover it. Commit cd3d8031 (sched: sched_getaffinity(): Allow less than NR_CPUS length) is comparing this 16 bytes agains nr_cpu_ids. Fix it by comparing nr_cpu_ids to the number of bits in the cpumask we pass in. Signed-off-by:
Anton Blanchard <anton@samba.org> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Sharyathi Nagesh <sharyath@in.ibm.com> Cc: Ulrich Drepper <drepper@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jack Steiner <steiner@sgi.com> Cc: Russ Anderson <rja@sgi.com> Cc: Mike Travis <travis@sgi.com> LKML-Reference: <20100406070218.GM5594@kryten> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
KOSAKI Motohiro authored
commit cd3d8031 upstream. [ Note, this commit changes the syscall ABI for > 1024 CPUs systems. ] Recently, some distro decided to use NR_CPUS=4096 for mysterious reasons. Unfortunately, glibc sched interface has the following definition: # define __CPU_SETSIZE 1024 # define __NCPUBITS (8 * sizeof (__cpu_mask)) typedef unsigned long int __cpu_mask; typedef struct { __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS]; } cpu_set_t; It mean, if NR_CPUS is bigger than 1024, cpu_set_t makes an ABI issue ... More recently, Sharyathi Nagesh reported following test program makes misterious syscall failure: ----------------------------------------------------------------------- #define _GNU_SOURCE #include<stdio.h> #include<errno.h> #include<sched.h> int main() { cpu_set_t set; if (sched_getaffinity(0, sizeof(cpu_set_t), &set) < 0) printf("\n Call is failing with:%d", errno); } ----------------------------------------------------------------------- Because the kernel assumes len argument of sched_getaffinity() is bigger than NR_CPUS. But now it is not correct. Now we are faced with the following annoying dilemma, due to the limitations of the glibc interface built in years ago: (1) if we change glibc's __CPU_SETSIZE definition, we lost binary compatibility of _all_ application. (2) if we don't change it, we also lost binary compatibility of Sharyathi's use case. Then, I would propse to change the rule of the len argument of sched_getaffinity(). Old: len should be bigger than NR_CPUS New: len should be bigger than maximum possible cpu id This creates the following behavior: (A) In the real 4096 cpus machine, the above test program still return -EINVAL. (B) NR_CPUS=4096 but the machine have less than 1024 cpus (almost all machines in the world), the above can run successfully. Fortunatelly, BIG SGI machine is mainly used for HPC use case. It means they can rebuild their programs. IOW we hope they are not annoyed by this issue ... Reported-by:
Sharyathi Nagesh <sharyath@in.ibm.com> Signed-off-by:
Ulrich Drepper <drepper@redhat.com> Acked-by:
Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jack Steiner <steiner@sgi.com> Cc: Russ Anderson <rja@sgi.com> Cc: Mike Travis <travis@sgi.com> LKML-Reference: <20100312161316.9520.A69D9226@jp.fujitsu.com> Signed-off-by:
-
Suresh Siddha authored
commit 472a474c upstream. Jan Grossmann reported kernel boot panic while booting SMP kernel on his system with a single core cpu. SMP kernels call enable_IR_x2apic() from native_smp_prepare_cpus() and on platforms where the kernel doesn't find SMP configuration we ended up again calling enable_IR_x2apic() from the APIC_init_uniprocessor() call in the smp_sanity_check(). Thus leading to kernel panic. Don't call enable_IR_x2apic() and default_setup_apic_routing() from APIC_init_uniprocessor() in CONFIG_SMP case. NOTE: this kind of non-idempotent and assymetric initialization sequence is rather fragile and unclean, we'll clean that up in v2.6.35. This is the minimal fix for v2.6.34. Reported-by: Jan.Grossmann@kielnet.net Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Cc: <jbarnes@virtuousgeek.org> Cc: <david.woodhouse@intel.com> Cc: <weidong.han@intel.com> Cc: <youquan.song@intel.com> Cc: <Jan.Grossmann@kielnet.net> LKML-Reference: <1270083887.7835.78.camel@sbs-t61.sc.intel.com> Signed-off-by:
-
Pallipadi, Venkatesh authored
commit 8da854cb upstream. On Wed, Feb 24, 2010 at 03:37:04PM -0800, Justin Piszcz wrote: > Hello, > > Again, on the Intel DP55KG board: > > # uname -a > Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux > > [ 1.237600] ------------[ cut here ]------------ > [ 1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80() > [ 1.238221] Hardware name: > [ 1.238504] hpet: compare register read back failed. > [ 1.238793] Modules linked in: > [ 1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1 > [ 1.239605] Call Trace: > [ 1.239886] <IRQ> [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0 > [ 1.240409] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0 > [ 1.240699] [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50 > [ 1.240992] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0 > [ 1.241281] [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80 > [ 1.241573] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0 > [ 1.241859] [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100 > [ 1.246533] [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30 > [ 1.246826] [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0 > [ 1.247118] [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160 > [ 1.247407] [<ffffffff81029f55>] ? handle_irq+0x15/0x20 > [ 1.247689] [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0 > [ 1.247976] [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa > [ 1.248262] <EOI> [<ffffffff8102f277>] ? mwait_idle+0x57/0x80 > [ 1.248796] [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0 > [ 1.249080] ---[ end trace db7f668fb6fef4e1 ]--- > > Is this something Intel has to fix or is it a bug in the kernel? This is a chipset erratum. Thomas: You mentioned we can retain this check only for known-buggy and hpet debug kind of options. But here is the simple workaround patch for this particular erratum. Some chipsets have a erratum due to which read immediately following a write of HPET comparator returns old comparator value instead of most recently written value. Erratum 15 in "Intel I/O Controller Hub 9 (ICH9) Family Specification Update" (http://www.intel.com/assets/pdf/specupdate/316973.pdf) Workaround for the errata is to read the comparator twice if the first one fails. Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> LKML-Reference: <20100225185348.GA9674@linux-os.sc.intel.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@gmail.com> Signed-off-by:
-
Thomas Gleixner authored
commit 18ed61da upstream. Andrew complained rightly that the WARN_ON in hpet_next_event() is confusing and the code comment not really helpful. Change it to WARN_ONCE and print the reason in clear text. Change the comment to explain what kind of hardware wreckage we deal with. Pointed-out-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Venki Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
-
Shaohua Li authored
commit 8ae06d22 upstream. Colin King reported a strange oops in S4 resume code path (see below). The test system has i5/i7 CPU. The kernel doesn't open PAE, so 4M page table is used. The oops always happen a virtual address 0xc03ff000, which is mapped to the last 4k of first 4M memory. Doing a global tlb flush fixes the issue. EIP: 0060:[<c0493a01>] EFLAGS: 00010086 CPU: 0 EIP is at copy_loop+0xe/0x15 EAX: 36aeb000 EBX: 00000000 ECX: 00000400 EDX: f55ad46c ESI: 0f800000 EDI: c03ff000 EBP: f67fbec4 ESP: f67fbea8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 ... ... CR2: 00000000c03ff000 Tested-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Shaohua Li <shaohua.li@intel.com> LKML-Reference: <20100305005932.GA22675@sli10-desk.sh.intel.com> Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Alex Deucher authored
commit 643acacf upstream. bad cast was overwriting the tvdac adj values Fixes fdo bug 27478 Signed-off-by:
-
Michel Dänzer authored
commit 57b54ea6 upstream. Gleaned from the Mesa code. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=27355 . Signed-off-by:
Michel Dänzer <daenzer@vmware.com> Signed-off-by:
-
Adam Jackson authored
commit ba1163de upstream. Claims 1280x1024 preferred, physically 1600x1200 cf. http://bugzilla.redhat.com/530399Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Rabin Vincent authored
commit d4d9959c upstream. 98e12b5a ("ARM: Fix decompressor's kernel size estimation for ROM=y") broke the Thumb-2 decompressor because it added an entry in the LC0 table but didn't adjust the offset the Thumb-2 code uses to load the SP from that table. Fix it. Signed-off-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Wey-Yi Guy authored
commit ece6444c upstream. For 4965, need to check it is valid qos frame before free, only valid QoS frame has the tid used to free the packets. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Steve French authored
commit a24e2d7d upstream. By doing this we always overwrite nbytes value that is being passed on to CIFSSMBWrite() and need not rely on the callers to initialize. CIFSSMBWrite2 is doing this already. Reviewed-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Reviewed-by:
Jeff Layton <jlayton@samba.org> Signed-off-by:
Suresh Jayaraman <sjayaraman@suse.de> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Suresh Jayaraman authored
commit 6513a81e upstream. While chasing a bug report involving a OS/2 server, I noticed the server sets pSMBr->CountHigh to a incorrect value even in case of normal writes. This results in 'nbytes' being computed wrongly and triggers a kernel BUG at mm/filemap.c. void iov_iter_advance(struct iov_iter *i, size_t bytes) { BUG_ON(i->count < bytes); <--- BUG here Why the server is setting 'CountHigh' is not clear but only does so after writing 64k bytes. Though this looks like the server bug, the client side crash may not be acceptable. The workaround is to mask off high 16 bits if the number of bytes written as returned by the server is greater than the bytes requested by the client as suggested by Jeff Layton. Reviewed-by:
-
Tejun Heo authored
commit 68b0ddb2 upstream. Crucial said, Thank you for contacting us. We know that with our M225 line of SSDs you sometimes need to disable NCQ (native command queuing) to avoid just the type of errors you're seeing. Our recommendation for the M225 is to add libata.force=noncq to your Linux kernel boot options, under the kernel ATA library option. I have sent your feedback to the engineers working on the C300, and asked them to please pass it on to the firmware team. I have been notified that they are in the process of testing and finalizing a new firmware version, that you can expect to see released around the end of April. We’ll keep you posted as to when it will be available for download. So, turn off NCQ on the drive w/ the current firmware revision. Reported in the following bug. https://bugzilla.kernel.org/show_bug.cgi?id=15573Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by: lethalwp@scarlet.be Reported-by:
Luke Macken <lmacken@redhat.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Alan Jenkins authored
commit ced69c59 upstream. The wireless hotplug code is not needed on this model, and it disables the wired ethernet card. (Like on the 1005HA and 1201N). References: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2010-February/003281.html> [bwh: Backported to 2.6.32] Signed-off-by:
Alan Jenkins <alan-jenkins@tuffmail.co.uk> Reported-by:
Ansgar Burchardt <ansgar@43-1.org> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Corentin Chary authored
commit 4194e2f5 upstream. [bwh: Backported to 2.6.32] Signed-off-by:
Corentin Chary <corentincj@iksaif.net> Signed-off-by:
Len Brown <len.brown@intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Corentin Chary authored
commit 322a1356 upstream. Some new models need to disable wireless hotplug. For the moment, we don't know excactly what models need that, except 1005HA. Users will be able to use that param as a workaround. [bwh: Backported to 2.6.32] Signed-off-by:
-
Corentin Chary authored
commit 10ae4b56 upstream. This is a short term workaround for Eeepc 1005HA. refs: <http://bugzilla.kernel.org/show_bug.cgi?id=14570> [bwh: Backported to 2.6.32] Signed-off-by:
-
Alan Jenkins authored
commit da8ba01d upstream. The EeePC 4G ("701") implements CFVS, but it is not supported by the pre-installed OS, and the original option to change it in the BIOS setup screen was removed in later versions. Judging by the lack of "Super Hybrid Engine" on Asus product pages, this applies to all "701" models (4G/4G Surf/2G Surf). So Asus made a deliberate decision not to support it on this model. We have several reports that using it can cause the system to hang [1]. That said, it does not happen all the time. Some users do not experience it at all (and apparently wish to continue "right-clocking"). Check for the EeePC 701 using DMI. If met, then disable writes to the "cpufv" sysfs attribute and log an explanatory message. Add a "cpufv_disabled" attribute which allow users to override this policy. Writing to this attribute will log a second message. The sysfs attribute is more useful than a module option, because it makes it easier for userspace scripts to provide consistent behaviour (according to user configuration), regardless of whether the kernel includes this change. [1] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578> [bwh: Backported to 2.6.32] Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit b525c06c upstream. Given the right combination of ThinkPad and X.org, just reading the video output control state is enough to hard-crash X.org. Until the day I somehow find out a model or BIOS cut date to not provide this feature to ThinkPads that can do video switching through X RandR, change permissions so that only processes with CAP_SYS_ADMIN can access any sort of video output control state. This bug could be considered a local DoS I suppose, as it allows any non-privledged local user to cause some versions of X.org to hard-crash some ThinkPads. Reported-by:
Jidanni <jidanni@jidanni.org> Signed-off-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by:
-
Alexey Dobriyan authored
commit 887965e6 upstream. (hmh@hmh.eng.br: Updated to apply to 2.6.32.y) Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit 5451a923 upstream. We already log the initial state of the hardware rfkill switch (WLSW), might as well log the state of the softswitches as well. Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit d89a727a upstream. Before we register the input device, sync the input layer EV_SW state through a call to input_report_switch(), to avoid issuing a gratuitous event for the initial state of these switches. This fixes some annoyances caused by the interaction with rfkill and EV_SW SW_RFKILL_ALL events. Reported-by:
Kevin Locke <kevin@kevinlocke.name> Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit 792979c8 upstream. Use input_set_capability() instead of set_bit. Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit 9ebd9e83 upstream. Log temperatures on any of the EC thermal alarms. It could be useful to help tracking down what is happening... Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit b09c7225 upstream. Export the normal (non-command) module paramenters as mode 0444, so that they will show up in sysfs. These parameters must not be changed at runtime as a rule, with very few exceptions. Reported-by:
Ferenc Wagner <wferi@niif.hu> Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit d112ef95 upstream. Properly init the parent field of the input device. Thanks to Alan Jenkins, who noted this problem in a different driver. Reported-by:
-
Henrique de Moraes Holschuh authored
commit 6b30eb7d upstream. Fix this bogus warning during module shutdown, when backlight event reporting is enabled: "thinkpad_acpi: required events 0x00018000 not enabled!" Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit 347a2686 upstream. Take advantage of the new events capabilities of the backlight class to notify userspace of backlight changes. This depends on "backlight: Allow drivers to update the core, and generate events on changes", by Matthew Garrett. Signed-off-by:
-
