linux-toradex.git/drivers, branch v2.6.33.4

SCSI: Retry commands with UNIT_ATTENTION sense codes to fix ext3/ext4 I/O error

2010-05-12T22:03:16+00:00

commit 77a4229719e511a0d38d9c355317ae1469adeb54 upstream.

There's nastyness in the way we currently handle barriers (and
discards): They're effectively filesystem commands, but they get
processed as BLOCK_PC commands.  Unfortunately BLOCK_PC commands are
taken by SCSI to be SG_IO commands and the issuer expects to see and
handle any returned errors, however trivial.  This leads to a huge
problem, because the block layer doesn't expect this to happen and any
trivially retryable error on a barrier causes an immediate I/O error
to the filesystem.

The only real way to hack around this is to take the usual class of
offending errors (unit attentions) and make them all retryable in the
case of a REQ_HARDBARRIER.  A correct fix would involve a rework of
the entire block and SCSI submit system, and so is out of scope for a
quick fix.

Cc: Hannes Reinecke 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

Enable retries for SYNCRONIZE_CACHE commands to fix I/O error

2010-05-12T22:03:13+00:00

commit c213e1407be6b04b144794399a91472e0ef92aec upstream.

Some arrays are giving I/O errors with ext3 filesystems when
SYNCHRONIZE_CACHE gets a UNIT_ATTENTION.  What is happening is that
these commands have no retries, so the UNIT_ATTENTION causes the
barrier to fail.  We should be enable retries here to clear any
transient error and allow the barrier to succeed.

Signed-off-by: Hannes Reinecke 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

scsi_debug: virtual_gb ignores sector_size

2010-05-12T22:03:12+00:00

commit 5447ed6c968e7270b656afa273c2b79d15d82edd upstream.

In the scsi_debug driver, the virtual_gb option ignores the
sector_size, implicitly assuming that is 512 bytes.  So if
'virtual_gb=1 sector_size=4096' the result is an 8 GB (virtual) disk.

Signed-off-by: Douglas Gilbert 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: libiscsi: regression: fix header digest errors

2010-05-12T22:03:12+00:00

commit 96b1f96dcab87756c0a1e7ba76bc5dc2add82b88 upstream.

This fixes a regression introduced with this commit:

commit d3305f3407fa3e9452079ec6cc8379067456e4aa
Author: Mike Christie 
Date:   Thu Aug 20 15:10:58 2009 -0500

    [SCSI] libiscsi: don't increment cmdsn if cmd is not sent

in 2.6.32.

When I moved the hdr->cmdsn after init_task, I added
a bug when header digests are used. The problem is
that the LLD may calculate the header digest in init_task,
so if we then set the cmdsn after the init_task call we
change what the digest will be calculated by the target.

Signed-off-by: Mike Christie 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: fix locking around blk_abort_request()

2010-05-12T22:03:11+00:00

commit 70b25f890ce9f0520c64075ce9225a5b020a513e upstream.

blk_abort_request() expects queue lock to be held by the caller.
Grab it before calling the function.

Lack of this synchronization led to infinite loop on corrupt
q->timeout_list.

Signed-off-by: Tejun Heo 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

cpuidle: Fix incorrect optimization

2010-05-12T22:03:10+00:00

commit 1c6fe0364fa7bf28248488753ee0afb6b759cd04 upstream.

commit 672917dcc78 ("cpuidle: menu governor: reduce latency on exit")
added an optimization, where the analysis on the past idle period moved
from the end of idle, to the beginning of the new idle.

Unfortunately, this optimization had a bug where it zeroed one key
variable for new use, that is needed for the analysis.  The fix is
simple, zero the variable after doing the work from the previous idle.

During the audit of the code that found this issue, another issue was
also found; the ->measured_us data structure member is never set, a
local variable is always used instead.

Signed-off-by: Arjan van de Ven 
Cc: Corrado Zoccolo 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ACPI: sleep: init_set_sci_en_on_resume for Dell Studio 155x

2010-05-12T22:03:10+00:00

commit ea5bc73f4f56449b2d450068d492bcd17a675d7a 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/553498

Signed-off-by: Kamal Mostafa 
Acked-by: Alex Chiang 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

power_meter: acpi_device_class "power_meter_resource" too long

2010-05-12T22:03:09+00:00

commit 18262714ca0fb65c290b8ea1807b2b02bb52d0e3 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 
Cc: Len Brown 
Cc: "Darrick J. Wong" 
Signed-off-by: Andrew Morton 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: DMI init_set_sci_en_on_resume for multiple Lenovo ThinkPads

2010-05-12T22:03:09+00:00

commit 07bedca29b0973f36a6b6db36936deed367164ed 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 
Signed-off-by: Alex Chiang 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference"

2010-05-12T22:03:08+00:00

commit 6f550dc08369ee0bc6402963c377e65f0f2e3b71 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: [] dvb_frontend_detach+0x4/0x67 [dvb_core]

Ref http://bugs.debian.org/575207

Signed-off-by: Bjørn Mork 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman