- 12 May, 2010 40 commits
-
-
Kamal Mostafa authored
commit ea5bc73f upstream. Add Dell Studio models (1558, 1557, 1555) to the 'set_sci_en_on_resume' list to fix hang on resume. BugLink: http://bugs.launchpad.net/bugs/553498Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Alex Chiang <achiang@canonical.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Carpenter authored
commit 18262714 upstream. acpi_device_class can only be 19 characters and a NULL terminator. The current code has a buffer overflow in acpi_power_meter_add(): strcpy(acpi_device_class(device), ACPI_POWER_METER_CLASS); Signed-off-by:
Dan Carpenter <error27@gmail.com> Cc: Len Brown <lenb@kernel.org> Cc: "Darrick J. Wong" <djwong@us.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Alex Chiang authored
commit 07bedca2 upstream. Multiple Lenovo ThinkPad models with Intel Core i5/i7 CPUs can successfully suspend/resume once, and then hang on the second s/r cycle. We got confirmation that this was due to a BIOS defect. The BIOS did not properly set SCI_EN coming out of S3. The BIOS guys hinted that The Other Leading OS ignores the fact that hardware owns the bit and sets it manually. In any case, an existing DMI table exists for machines where this defect is a known problem. Lenovo promise to fix their BIOS, but for folks who either won't or can't upgrade their BIOS, allow Linux to workaround the issue. https://bugzilla.kernel.org/show_bug.cgi?id=15407 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374 Confirmed by numerous testers in the launchpad bug that using acpi_sleep=sci_force_enable fixes the issue. We add the machines to acpisleep_dmi_table[] to automatically enable this workaround. Cc: Colin King <colin.king@canonical.com> Signed-off-by:
-
Bjørn Mork authored
commit 6f550dc0 upstream. Never call dvb_frontend_detach if we failed to attach a frontend. This fixes the following oops, which will be triggered by a missing stv090x module: [ 8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI) [ 8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29 [ 8.328665] Intel ICH 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 8.328753] Intel ICH 0000:00:1f.5: setting latency timer to 64 [ 8.562047] DVB: Unable to find symbol stv090x_attach() [ 8.562117] BUG: unable to handle kernel NULL pointer dereference at 000000ac [ 8.562239] IP: [<e08b04a3>] dvb_frontend_detach+0x4/0x67 [dvb_core] Ref http://bugs.debian.org/575207Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Gabriele A. Trombetti authored
commit 87aa6300 upstream. Fix: Raid-6 was not trying to correct a read-error when in singly-degraded state and was instead dropping one more device, going to doubly-degraded state. This patch fixes this behaviour. Tested-by:
Janos Haar <janos.haar@netcenter.hu> Signed-off-by:
Gabriele A. Trombetti <g.trombetti.lkrnl1213@logicschema.com> Reported-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Stijn Tintel authored
commit e2dbe06c upstream. Move initialization of the virtio framework before the initialization of mtd, so that block2mtd can be used on virtio-based block devices. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15644Signed-off-by:
Stijn Tintel <stijn@linux-ipv6.be> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
NeilBrown authored
commit 1176568d upstream. Some time ago we stopped the clean/active metadata updates from being written to a 'spare' device in most cases so that it could spin down and say spun down. Device failure/removal etc are still recorded on spares. However commit 51d5668c broke this 50% of the time, depending on whether the event count is even or odd. The change log entry said: This means that the alignment between 'odd/even' and 'clean/dirty' might take a little longer to attain, how ever the code makes no attempt to create that alignment, so it could take arbitrarily long. So when we find that clean/dirty is not aligned with odd/even, force a second metadata-update immediately. There are already cases where a second metadata-update is needed immediately (e.g. when a device fails during the metadata update). We just piggy-back on that. Reported-by:
Joe Bryant <tenminjoe@yahoo.com> Signed-off-by:
-
Dan Carpenter authored
commit b338cc82 upstream. There is a typo here. We should be testing "*dentry" instead of "dentry". If "*dentry" is an ERR_PTR, it gets dereferenced in either mkdir() or create() which would cause an OOPs. Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Jeff Mahoney authored
commit 86c38a31 upstream. GCC 4.5 introduces behavior that forces the alignment of structures to use the largest possible value. The default value is 32 bytes, so if some structures are defined with a 4-byte alignment and others aren't declared with an alignment constraint at all - it will align at 32-bytes. For things like the ftrace events, this results in a non-standard array. When initializing the ftrace subsystem, we traverse the _ftrace_events section and call the initialization callback for each event. When the structures are misaligned, we could be treating another part of the structure (or the zeroed out space between them) as a function pointer. This patch forces the alignment for all the ftrace_event_call structures to 4 bytes. Without this patch, the kernel fails to boot very early when built with gcc 4.5. It's trivial to check the alignment of the members of the array, so it might be worthwhile to add something to the build system to do that automatically. Unfortunately, that only covers this case. I've asked one of the gcc developers about adding a warning when this condition is seen. Cc: stable@kernel.org Signed-off-by:
Jeff Mahoney <jeffm@suse.com> LKML-Reference: <4B85770B.6010901@suse.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Andreas Radke <a.radke@arcor.de> Signed-off-by:
-
Michael Chan authored
commit c441b8d2 upstream. It has been reported that under certain heavy traffic conditions in MSI-X mode, the driver can lose an MSI-X vector causing all packets in the associated rx/tx ring pair to be dropped. The problem is caused by the chip dropping the write to unmask the MSI-X vector by the kernel (when migrating the IRQ for example). This can be prevented by increasing the GRC timeout value for these register read and write operations. Thanks to Dell for helping us debug this problem. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Lalit Chandivade authored
commit 0f00a206 upstream. Correct issues where the lower scsi-status would be improperly cleared, instead, allow the midlayer to process the status after the proper residual-count checks are performed. Finally, validate firmware status flags prior to assigning values from the FCP_RSP frame. Signed-off-by:
Lalit Chandivade <lalit.chandivade@qlogic.com> Signed-off-by:
Michael Hernandez <michael.hernandez@qlogic.com> Signed-off-by:
Ravi Anand <ravi.anand@qlogic.com> Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Carlos O'Donell authored
commit 5fd4514b upstream. Set the PCI CLS early in the boot process to prevent device failures. In pcibios_set_master use the new pci_cache_line_size instead of a hard-coded value. Signed-off-by:
Carlos O'Donell <carlos@codesourcery.com> Reviewed-by:
Grant Grundler <grundler@google.com> Signed-off-by:
Kyle McMartin <kyle@redhat.com> Signed-off-by:
-
Dave Chinner authored
commit 9bf729c0 upstream On low memory boxes or those with highmem, kernel can OOM before the background reclaims inodes via xfssyncd. Add a shrinker to run inode reclaim so that it inode reclaim is expedited when memory is low. This is more complex than it needs to be because the VM folk don't want a context added to the shrinker infrastructure. Hence we need to add a global list of XFS mount structures so the shrinker can traverse them. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Alex Elder <aelder@sgi.com> Signed-off-by:
-
Andre Detsch authored
commit dc8bf1b1 upstream. tg3: Fix INTx fallback when MSI fails MSI setup changes the value of irq_vec in struct tg3 *tp. This attribute must be taken into account and restored before we try to do a new request_irq for INTx fallback. In powerpc, the original code was leading to an EINVAL return within request_irq, because the driver was trying to use the disabled MSI virtual irq number instead of tp->pdev->irq. Signed-off-by:
Andre Detsch <adetsch@br.ibm.com> Acked-by:
-
Douglas Gilbert authored
commit e7efe593 upstream. Further to the lsml thread titled: "does scsi_io_completion need to dump sense data for ata pass through (ck_cond = 1) ?" This is a patch to skip logging when the sense data is associated with a SENSE_KEY of "RECOVERED_ERROR" and the additional sense code is "ATA PASS-THROUGH INFORMATION AVAILABLE". This only occurs with the SAT ATA PASS-THROUGH commands when CK_COND=1 (in the cdb). It indicates that the sense data contains ATA registers. Smartmontools uses such commands on ATA disks connected via SAT. Periodic checks such as those done by smartd cause nuisance entries into logs that are: - neither errors nor warnings - pointless unless the cdb that caused them are also logged Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Matthew Garrett authored
commit cc2893b6 upstream. If the firmware puts a device back into D0 state at resume time, we'll update its state in resume_noirq and thus skip the platform resume code. Calling that code twice should be safe and we ought to avoid getting to that point anyway, so remove the check and also allow the platform pci code to be called for D0. Fixes USB not being powered after resume on recent Lenovo machines. Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
françois romieu authored
commit 908ba2bf upstream. 78f1cd02 ("fix broken register writes") does not work for Al Viro's r8169 (XID 18000000). Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Francois Romieu authored
commit 78f1cd02 upstream. This is quite similar to b39fe41f though said registers are not even documented as 64-bit registers - as opposed to the initial TxDescStartAddress ones - but as single bytes which must be combined into 32 bits at the MMIO read/write level before being merged into a 64 bit logical entity. Credits go to Ben Hutchings <ben@decadent.org.uk> for the MAR registers (aka "multicast is broken for ages on ARM) and to Timo Teräs <timo.teras@iki.fi> for the MAC registers. Signed-off-by:
-
David Dillow authored
commit 4c020a96 upstream. r8169 needs certain writes to be visible to other CPUs or the NIC before touching the hardware, but was using smp_wmb() which is only required to order cacheable memory access. Switch to wmb() which is required to order both cacheable and non-cacheable memory. Noticed by Catalin Marinas and Paul Mackerras. Signed-off-by:
David Dillow <dave@thedillows.org> Signed-off-by:
-
Wufei authored
commit 56151e75 upstream. The bypassing of this test is a leftover from 2.4 vintage kernels, and is no longer appropriate, or even used by KGDB. Currently KGDB uses probe_kernel_write() for all access to memory via the KGDB core, so it can simply be deleted. This fixes CVE-2010-1446. CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Paul Mackerras <paulus@samba.org> CC: Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
Wufei <fei.wu@windriver.com> Signed-off-by:
Jason Wessel <jason.wessel@windriver.com> Signed-off-by:
-
Marcelo Tosatti authored
Commit 78ce64a3 in v2.6.32.12 introduced a warning due to unused load_segment_descriptor_to_kvm_desct helper, which has been opencoded by this commit. On upstream, the helper was removed as part of a different commit. Remove the now unused function. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Neil Horman authored
commit 38ff3e6b upstream. This was just recently reported to me. When built as modules, the dccp_probe module has a silent dependency on the dccp module. This stems from the fact that the module_init routine of dccp_probe registers a jprobe on the dccp_sendmsg symbol. Since the symbol is only referenced as a text string (the .symbol_name field in the jprobe struct) rather than the address of the symbol itself, depmod never picks this dependency up, and so if you load the dccp_probe module without the dccp module loaded, the register_jprobe call fails with an -EINVAL, and the whole module load fails. The fix is pretty easy, we can just wrap the register_jprobe call in a try_then_request_module call, which forces the dependency to get satisfied prior to the probe registration. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Darren Jenkins authored
commit 088ea189 upstream. fix off by one error in the queue size check of p54_tx_qos_accounting_alloc() Coverity CID: 13314 Signed-off-by:
Darren Jenkins <darrenrjenkins@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Christian Lamparter authored
commit f5300e04 upstream. A long time ago, a user reported several crashes due to data corruptions which are likely the result of a not-100%-supported, or faulty? PCI bridge. ( http://patchwork.kernel.org/patch/53004/ ) This patch fixes entry #1. "1. p54p_check_rx_ring - skb_over_panic: Under a ping flood or just left running for a bit would panic with a skb_over_panic." As described in the mail: The invalid frame length causes skb_put to bailout and trigger a crash. Note: Simply dropping the frame is problematic, because if its content contains a tx feedback we would lose some portion of the device memory space.... And the driver/mac80211 should handle all other invalid data. Reported-by:
Quintin Pitts <geek4linux@gmail.com> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Zhang Rui authored
commit d7f0eea9 upstream. Introduce kernel parameter acpi_sleep=sci_force_enable some laptop requires SCI_EN being set directly on resume, or else they hung somewhere in the resume code path. We already have a blacklist for these laptops but we still need this option, especially when debugging some suspend/resume problems, in case there are systems that need this workaround and are not yet in the blacklist. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Acked-by:
-
Bill Pemberton authored
commit 2b0b3951 upstream. Resizing the filesystem would result in an diAllocExt error in some instances because changes in bmp->db_agsize would not get noticed if goto extendBmap was called. Signed-off-by:
Bill Pemberton <wfp5p@virginia.edu> Signed-off-by:
Dave Kleikamp <shaggy@linux.vnet.ibm.com> Cc: jfs-discussion@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
David Howells authored
commit e134d200 upstream. creds_are_invalid() reads both cred->usage and cred->subscribers and then compares them to make sure the number of processes subscribed to a cred struct never exceeds the refcount of that cred struct. The problem is that this can cause a race with both copy_creds() and exit_creds() as the two counters, whilst they are of atomic_t type, are only atomic with respect to themselves, and not atomic with respect to each other. This means that if creds_are_invalid() can read the values on one CPU whilst they're being modified on another CPU, and so can observe an evolving state in which the subscribers count now is greater than the usage count a moment before. Switching the order in which the counts are read cannot help, so the thing to do is to remove that particular check. I had considered rechecking the values to see if they're in flux if the test fails, but I can't guarantee they won't appear the same, even if they've changed several times in the meantime. Note that this can only happen if CONFIG_DEBUG_CREDENTIALS is enabled. The problem is only likely to occur with multithreaded programs, and can be tested by the tst-eintr1 program from glibc's "make check". The symptoms look like: CRED: Invalid credentials CRED: At include/linux/cred.h:240 CRED: Specified credentials: ffff88003dda5878 [real][eff] CRED: ->magic=43736564, put_addr=(null) CRED: ->usage=766, subscr=766 CRED: ->*uid = { 0,0,0,0 } CRED: ->*gid = { 0,0,0,0 } CRED: ->security is ffff88003d72f538 CRED: ->security {359, 359} ------------[ cut here ]------------ kernel BUG at kernel/cred.c:850! ... RIP: 0010:[<ffffffff81049889>] [<ffffffff81049889>] __invalid_creds+0x4e/0x52 ... Call Trace: [<ffffffff8104a37b>] copy_creds+0x6b/0x23f Note the ->usage=766 and subscr=766. The values appear the same because they've been re-read since the check was made. Reported-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Daniel Vetter authored
commit c36a2a6d upstream. Current code is definitely crap: Largest pitch allowed spills into the TILING_Y bit of the fence registers ... :( I've rewritten the limits check under the assumption that 3rd gen hw has a 3d pitch limit of 8kb (like 2nd gen). This is supported by an otherwise totally misleading XXX comment. This bug mostly resulted in tiling-corrupted pixmaps because the kernel allowed too wide buffers to be tiled. Bug brought to the light by the xf86-video-intel 2.11 release because that unconditionally enabled tiling for pixmaps, relying on the kernel to check things. Tiling for the framebuffer was not affected because the ddx does some additional checks there ensure the buffer is within hw-limits. v2: Instead of computing the value that would be written into the hw fence registers and then checking the limits simply check whether the stride is above the 8kb limit. To better document the hw, add some WARN_ONs in i915_write_fence_reg like I've done for the i830 case (using the right limits). Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449Tested-by:
Alexander Lam <lambchop468@gmail.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Phillip Lougher authored
commit df37bd15 upstream. The unpack routine fails to handle the decompress_method() returning unrecognised decompressor (compress_name == NULL). This results in the routine looping eventually oopsing on an out of bounds memory access. Note this bug is usually hidden, only triggering on trailing junk after one or more correct compressed blocks. The case of the compressed archive being complete junk is (by accident?) caught by the if (state != Reset) check because state is initialised to Start, but not updated due to the decompressor not having been called. Obviously if the junk is trailing a correctly decompressed buffer, state == Reset from the previous call to the decompressor. Signed-off-by:
Phillip Lougher <phillip@lougher.demon.co.uk> Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
-
Leonard Michlmayr authored
commit aca92ff6 upstream. ext4_fiemap() rounds the length of the requested range down to blocksize, which is is not the true number of blocks that cover the requested region. This problem is especially impressive if the user requests only the first byte of a file: not a single extent will be reported. We fix this by calculating the last block of the region and then subtract to find the number of blocks in the extents. Signed-off-by:
Leonard Michlmayr <leonard.michlmayr@gmail.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Mark Lord authored
commit 45c4d015 upstream. Most drives from Seagate, Hitachi, and possibly other brands, do not allow LBA28 access to sector number 0x0fffffff (2^28 - 1). So instead use LBA48 for such accesses. This bug could bite a lot of systems, especially when the user has taken care to align partitions to 4KB boundaries. On misaligned systems, it is less likely to be encountered, since a 4KB read would end at 0x10000000 rather than at 0x0fffffff. Signed-off-by:
Mark Lord <mlord@pobox.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Daniel T Chen authored
commit c5366681 upstream. BugLink: https://launchpad.net/bugs/549267 The OR verified that using the olpc-xo-1_5 model quirk allows the headphones to be audible when inserted into the jack. Capture was also verified to work correctly. Reported-by: Richard Gagne Tested-by: Richard Gagne Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Daniel T Chen authored
commit 4442dd46 upstream. BugLink: https://launchpad.net/bugs/573284 The OR verified that using the olpc-xo-1_5 model quirk allows the headphones to be audible when inserted into the jack. Capture was also verified to work correctly. Reported-by:
Andy Couldrake <acouldrake@googlemail.com> Tested-by:
-
Daniel T Chen authored
commit 8f0f5ff6 upstream. BugLink: https://launchpad.net/bugs/541802 The OR's hardware distorts at PCM 100% because it does not correspond to 0 dB. Fix this in patch_cxt5045() for all Packard Bell models. Reported-by: Valombre Signed-off-by:
-
Daniel T Chen authored
commit 0b587fc4 upstream. BugLink: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4792 Cristian reported that these models have really bad sound above 6 dB and proposed the original patch. I've updated the comment to reflect this change. Signed-off-by:
-
Hans de Goede authored
commit 715aa675 upstream. Ignore spurious HV interrupts during suspend / resume, this avoids mistaking them for a mute button press. This is not very pretty but it seems the only way to fix the master volume control gets muted after suspend issue I'm seeing. Note that the es1968 driver is doing exactly the same. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
commit 7efbfd1a upstream. Without this quirk sound stops working after suspend resume. With this quirk, one still needs to manually unmute the master volume control after a suspend / / resume cycle. That is fixed in another patch in this set. Note that this patch was submitted to the alsa bug tracker a long time ago: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4319Signed-off-by:
-
Daniel T Chen authored
commit 3353541f upstream. BugLink: https://launchpad.net/bugs/567494 The OR has verified that the existing model quirk, ALC880_UNIWILL, is insufficient for audible playback and capture by default. Instead, the ALC880_F1734 model quirk needs to be used. This change is necessary for both 2.6.32.11 and 2.6.33.2. Reported-by:
Arnaud Malpeyre <amalpeyre@gmail.com> Tested-by:
-
Daniel T Chen authored
commit 5c1bccf6 upstream. BugLink: https://launchpad.net/bugs/568600 The OR has verified that the dell-m6 model quirk is necessary for audio to be audible by default on the Dell Studio XPS 1645. This change is necessary for 2.6.32.11 and 2.6.33.2 alike. Reported-by:
Andy Ross <andy@plausible.org> Tested-by:
-
Daniel T Chen authored
commit aac78daf upstream. BugLink: https://launchpad.net/bugs/553002 The OR has verified that the dell-m6 model quirk is necessary for audio to be audible by default on the Dell Studio XPS 1645. This change is necessary for 2.6.32.11 and 2.6.33.2 alike. Reported-by: Robert Chambers Tested-by: Robert Chambers Signed-off-by:
-
