Felix Radensky [Sun, 24 Apr 2011 22:57:12 +0000 (01:57 +0300)]
mtd: mtdconcat: fix NAND OOB write
BugLink: http://bugs.launchpad.net/bugs/793702
commit
431e1ecabddcd7cbba237182ddf431771f98bb4c upstream.
Currently mtdconcat is broken for NAND. An attemtpt to create
JFFS2 filesystem on concatenation of several NAND devices fails
with OOB write errors. This patch fixes that problem.
Signed-off-by: Felix Radensky <felix@embedded-sol.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tejun Heo [Thu, 26 May 2011 19:06:50 +0000 (21:06 +0200)]
block: always allocate genhd->ev if check_events is implemented
BugLink: http://bugs.launchpad.net/bugs/793702
commit
75e3f3ee3c64968d42f4843ec49e579f84b5aa0c upstream.
9fd097b149 (block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe
drivers) removed DISK_EVENT_MEDIA_CHANGE from legacy/fringe block
drivers which have inadequate ->check_events(). Combined with earlier
change
7c88a168da (block: don't propagate unlisted DISK_EVENTs to
userland), this enables using ->check_events() for internal processing
while avoiding enabling in-kernel block event polling which can lead
to infinite event loop.
Unfortunately, this made many drivers including floppy without any bit
set in disk->events and ->async_events in which case disk_add_events()
simply skipped allocation of disk->ev, which disables whole event
handling. As ->check_events() is still used during open processing
for revalidation, this can lead to open failure.
This patch always allocates disk->ev if ->check_events is implemented.
In the long term, it would make sense to simply include the event
structure inline into genhd as it's now used by virtually all block
devices.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Ondrej Zary <linux@rainbow-software.org>
Reported-by: Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
James Bottomley [Wed, 18 May 2011 14:20:10 +0000 (16:20 +0200)]
block: add proper state guards to __elv_next_request
BugLink: http://bugs.launchpad.net/bugs/793702
commit
0a58e077eb600d1efd7e54ad9926a75a39d7f8ae upstream.
blk_cleanup_queue() calls elevator_exit() and after this, we can't
touch the elevator without oopsing. __elv_next_request() must check
for this state because in the refcounted queue model, we can still
call it after blk_cleanup_queue() has been called.
This was reported as causing an oops attributable to scsi.
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Martin K. Petersen [Wed, 18 May 2011 08:37:35 +0000 (10:37 +0200)]
block: Fix discard topology stacking and reporting
BugLink: http://bugs.launchpad.net/bugs/793702
commit
a934a00a69e940b126b9bdbf83e630ef5fe43523 upstream.
In some cases we would end up stacking discard_zeroes_data incorrectly.
Fix this by enabling the feature by default for stacking drivers and
clearing it for low-level drivers. Incorporating a device that does not
support dzd will then cause the feature to be disabled in the stacking
driver.
Also ensure that the maximum discard value does not overflow when
exported in sysfs and return 0 in the alignment and dzd fields for
devices that don't support discard.
Reported-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tejun Heo [Thu, 21 Apr 2011 18:54:46 +0000 (20:54 +0200)]
block: don't block events on excl write for non-optical devices
BugLink: http://bugs.launchpad.net/bugs/793702
commit
d4dc210f69bcb0b4bef5a83b1c323817be89bad1 upstream.
Disk event code automatically blocks events on excl write. This is
primarily to avoid issuing polling commands while burning is in
progress. This behavior doesn't fit other types of devices with
removeable media where polling commands don't have adverse side
effects and door locking usually doesn't exist.
This patch introduces new genhd flag which controls the auto-blocking
behavior and uses it to enable auto-blocking only on optical devices.
Note for stable: 2.6.38 and later only
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tejun Heo [Wed, 9 Mar 2011 18:54:27 +0000 (19:54 +0100)]
ide: Convert to bdops->check_events()
BugLink: http://bugs.launchpad.net/bugs/793702
commit
5b03a1b140e13a28ff6be1526892a9dc538ddef6 upstream.
Convert ->media_changed() to the new ->check_events() method. The
conversion is mostly mechanical. The only notable change is that
cdrom now doesn't generate any event if @slot_nr isn't CDSL_CURRENT.
It used to return -EINVAL which would be treated as media changed. As
media changer isn't supported anyway, this doesn't make any
difference.
This makes ide emit the standard disk events and allows kernel event
polling. Currently, only MEDIA_CHANGE event is implemented. Adding
support for EJECT_REQUEST shouldn't be difficult; however, given that
ide driver is already deprecated, it probably is best to leave it
alone.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-ide@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tejun Heo [Wed, 9 Mar 2011 18:54:28 +0000 (19:54 +0100)]
gdrom,viocd: Convert to bdops->check_events()
BugLink: http://bugs.launchpad.net/bugs/793702
commit
1c27030bd21e7e2c68ef5be9f28c63778cf4b27f upstream.
Convert gdrom and viocd from ->media_changed() to ->check_events().
It's unclear how the conditions are cleared and it's possible that it
may generate spurious events when polled.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tejun Heo [Wed, 9 Mar 2011 18:54:28 +0000 (19:54 +0100)]
paride: Convert to bdops->check_events()
BugLink: http://bugs.launchpad.net/bugs/793702
commit
b1b56b93f331bd61492fdb99e7986f7a528ca730 upstream.
Convert paride drivers from ->media_changed() to ->check_events().
pcd and pd buffer and clear events after reporting; however, pf
unconditionally reports MEDIA_CHANGE and will generate spurious events
when polled.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Tim Waugh <tim@cyberelk.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tejun Heo [Mon, 23 May 2011 11:26:07 +0000 (13:26 +0200)]
block: move bd_set_size() above rescan_partitions() in __blkdev_get()
BugLink: http://bugs.launchpad.net/bugs/793702
commit
7e69723fef8771a9d57bd27d36281d756130b4b5 upstream.
02e352287a4 (block: rescan partitions on invalidated devices on
-ENOMEDIA too) relocated partition rescan above explicit bd_set_size()
to simplify condition check. As rescan_partitions() does its own bdev
size setting, this doesn't break anything; however,
rescan_partitions() prints out the following messages when adjusting
bdev size, which can be confusing.
sda: detected capacity change from 0 to
146815737856
sdb: detected capacity change from 0 to
146815737856
This patch restores the original order and remove the warning
messages.
stable: Please apply together with
02e352287a4 (block: rescan
partitions on invalidated devices on -ENOMEDIA too).
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Tony Luck <tony.luck@gmail.com>
Tested-by: Tony Luck <tony.luck@gmail.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tejun Heo [Fri, 29 Apr 2011 08:15:20 +0000 (10:15 +0200)]
block: rescan partitions on invalidated devices on -ENOMEDIA too
BugLink: http://bugs.launchpad.net/bugs/793702
commit
02e352287a40bd456eb78df705bf888bc3161d3f upstream.
__blkdev_get() doesn't rescan partitions if disk->fops->open() fails,
which leads to ghost partition devices lingering after medimum removal
is known to both the kernel and userland. The behavior also creates a
subtle inconsistency where O_NONBLOCK open, which doesn't fail even if
there's no medium, clears the ghots partitions, which is exploited to
work around the problem from userland.
Fix it by updating __blkdev_get() to issue partition rescan after
-ENOMEDIA too.
This was reported in the following bz.
https://bugzilla.kernel.org/show_bug.cgi?id=13029
Stable: 2.6.38
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: David Zeuthen <zeuthen@gmail.com>
Reported-by: Martin Pitt <martin.pitt@ubuntu.com>
Reported-by: Kay Sievers <kay.sievers@vrfy.org>
Tested-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Johannes Berg [Fri, 6 May 2011 18:11:20 +0000 (11:11 -0700)]
iwlagn: fix iwl_is_any_associated
BugLink: http://bugs.launchpad.net/bugs/793702
commit
054ec924944912413e4ee927b8cf02f476d08783 upstream.
The function iwl_is_any_associated() was intended
to check both contexts, but due to an oversight
it only checks the BSS context. This leads to a
problem with scanning since the passive dwell
time isn't restricted appropriately and a scan
that includes passive channels will never finish
if only the PAN context is associated since the
default dwell time of 120ms won't fit into the
normal 100 TU DTIM interval.
Fix the function by using for_each_context() and
also reorganise the other functions a bit to take
advantage of each other making the code easier to
read.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Eric B Munson [Mon, 23 May 2011 04:22:40 +0000 (04:22 +0000)]
powerpc/oprofile: Handle events that raise an exception without overflowing
BugLink: http://bugs.launchpad.net/bugs/793702
commit
ad5d5292f16c6c1d7d3e257c4c7407594286b97e upstream.
Commit
0837e3242c73566fc1c0196b4ec61779c25ffc93 fixes a situation on POWER7
where events can roll back if a specualtive event doesn't actually complete.
This can raise a performance monitor exception. We need to catch this to ensure
that we reset the PMC. In all cases the PMC will be less than 256 cycles from
overflow.
This patch lifts Anton's fix for the problem in perf and applies it to oprofile
as well.
Signed-off-by: Eric B Munson <emunson@mgebm.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Ryan Grimm [Thu, 31 Mar 2011 19:33:02 +0000 (19:33 +0000)]
powerpc: Set nr_cpu_ids early and use it to free PACAs
BugLink: http://bugs.launchpad.net/bugs/793702
commit
c1854e00727f50f7ac99e98d26ece04c087ef785 upstream.
Without this, "holes" in the CPU numbering can cause us to
free too many PACAs
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Senthil Balasubramanian [Thu, 12 May 2011 10:54:28 +0000 (16:24 +0530)]
ath9k_hw: Fix STA connection issues with AR9380 (XB113).
BugLink: http://bugs.launchpad.net/bugs/793702
commit
be0e6aa5a0c487a2a0880dda8bc70f7f1860fc39 upstream.
XB113 (AR9380) 3x3 SB 5G only cards were failing to connect to APs
due to incorrect xpabiaslevel configuration. fix it.
Cc: Ray Li <ray.li@greenwavereality.com>
Cc: Kathy Giori <kathy.giori@atheros.com>
Cc: Aeolus Yang <aeolus.yang@atheros.com>
Cc: compat@orbit-lab.org
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Luis R. Rodriguez [Wed, 11 May 2011 21:57:26 +0000 (14:57 -0700)]
ath9k_hw: fix dual band assumption for XB113
BugLink: http://bugs.launchpad.net/bugs/793702
commit
9ba7f4f5eba5f4b44c7796bbad29f8ec3a7d5864 upstream.
The XB113 cards are single band, 5 GHz-only, but the
default settings were configured to assume it was dual
band. Users of these cards then would see 2.4 GHz channels
but you would never get any scan results from these channels
given that the radio is not present.
Cc: Fiona Cain <Fiona.Cain@atheros.com>
Cc: Ray Li <ray.li@greenwavereality.com>
Cc: Kathy Giori <kathy.giori@atheros.com>
Cc: Aeolus Yang <aeolus.yang@atheros.com>
Cc: Dan Friedman <dan.friedman@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Luis R. Rodriguez [Wed, 4 May 2011 21:01:26 +0000 (14:01 -0700)]
ath9k_hw: fix power for the HT40 duplicate frames
BugLink: http://bugs.launchpad.net/bugs/793702
commit
cf3a03b9c99a0b2715741d116f50f513f545bb2d upstream.
With AR9003 at about ~ 10 feet from an AP that uses RTS / CTS you
will be able to associate but not not get data through given that
the power for the rates used was set too low. This increases the
power and permits data connectivity at longer distances from
access points when connected with HT40. Without this you will not
get any data through when associated to APs configured in HT40
at about more than 10 feet away.
Cc: Fiona Cain <fcain@atheros.com>
Cc: Zhen Xie <Zhen.Xie@Atheros.com>
Cc: Kathy Giori <kathy.giori@atheros.com>
Cc: Neha Choksi <neha.choksi@atheros.com>
Cc: Wayne Daniel <wayne.daniel@atheros.com>
Cc: Gaurav Jauhar <gaurav.jauhar@atheros.com>
Cc: Samira Naraghi <samira.naraghi@atheros.com>
CC: Ashok Chennupati <ashok.chennupati@atheros.com>
Cc: Lance Zimmerman <lance.zimmerman@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Rajkumar Manoharan [Wed, 4 May 2011 14:07:17 +0000 (19:37 +0530)]
ath9k_hw: do noise floor calibration only on required chains
BugLink: http://bugs.launchpad.net/bugs/793702
commit
28ef6450f0182f95c4f50aaa0ab2043a09c72b0a upstream.
At present the noise floor calibration is processed in supported
control and extension chains rather than required chains.
Unnccesarily doing nfcal in all supported chains leads to
invalid nf readings on extn chains and these invalid values
got updated into history buffer. While loading those values
from history buffer is moving the chip to deaf state.
This issue was observed in AR9002/AR9003 chips while doing
associate/dissociate in HT40 mode and interface up/down
in iterative manner. After some iterations, the chip was moved
to deaf state. Somehow the pci devices are recovered by poll work
after chip reset. Raading the nf values in all supported extension chains
when the hw is not yet configured in HT40 mode results invalid values.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Fenghua Yu [Tue, 17 May 2011 19:33:26 +0000 (12:33 -0700)]
x86, cpufeature: Fix cpuid leaf 7 feature detection
BugLink: http://bugs.launchpad.net/bugs/793702
commit
2494b030ba9334c7dd7df9b9f7abe4eacc950ec5 upstream.
CPUID leaf 7, subleaf 0 returns the maximum subleaf in EAX, not the
number of subleaves. Since so far only subleaf 0 is defined (and only
the EBX bitfield) we do not need to qualify the test.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Link: http://lkml.kernel.org/r/
1305660806-17519-1-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Milton Miller [Tue, 10 May 2011 19:28:33 +0000 (19:28 +0000)]
powerpc/kexec: Fix memory corruption from unallocated slaves
BugLink: http://bugs.launchpad.net/bugs/793702
commit
3d2cea732d68aa270c360f55d8669820ebce188a upstream.
Commit
1fc711f7ffb01089efc58042cfdbac8573d1b59a (powerpc/kexec: Fix race
in kexec shutdown) moved the write to signal the cpu had exited the kernel
from before the transition to real mode in kexec_smp_wait to kexec_wait.
Unfornately it missed that kexec_wait is used both by cpus leaving the
kernel and by secondary slave cpus that were not allocated a paca for
what ever reason -- they could be beyond nr_cpus or not described in
the current device tree for whatever reason (for example, kexec-load
was not refreshed after a cpu hotplug operation). Cpus coming through
that path they will write to paca[NR_CPUS] which is beyond the space
allocated for the paca data and overwrite memory not allocated to pacas
but very likely still real mode accessable).
Move the write back to kexec_smp_wait, which is used only by cpus that
found their paca, but after the transition to real mode.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Milton Miller [Tue, 10 May 2011 19:28:41 +0000 (19:28 +0000)]
powerpc/kdump64: Don't reference freed memory as pacas
BugLink: http://bugs.launchpad.net/bugs/793702
commit
bd9e5eefecb3d69018bb95796298019d309cbec8 upstream.
Starting with
1426d5a3bd07589534286375998c0c8c6fdc5260 (powerpc:
Dynamically allocate pacas) the space for pacas beyond cpu_possible
is freed, but we failed to update the loop in crash.c.
Since
c1854e00727f50f7ac99e98d26ece04c087ef785 (powerpc: Set nr_cpu_ids
early and use it to free PACAs) the number of pacas allocated is
always nr_cpu_ids.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Arun Easi [Tue, 10 May 2011 18:18:17 +0000 (11:18 -0700)]
qla2xxx: Fix vport delete hang when logins are outstanding.
BugLink: http://bugs.launchpad.net/bugs/793702
commit
9f40682e2857a3c2ddb80a87b185af3c6a708346 upstream.
Timer is required to flush out entries that may be present in work queues.
Signed-off-by: Arun Easi <arun.easi@qlogic.com>
Signed-off-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Saurav Kashyap [Tue, 10 May 2011 18:18:18 +0000 (11:18 -0700)]
qla2xxx: Fix virtual port failing to login after chip reset.
BugLink: http://bugs.launchpad.net/bugs/793702
commit
cefcaba67ab97fb756b3a6af5139c94d861b660d upstream.
This patch ensures qla82xx_watchdog is not being run for the vport. It also
makes sure that beacon ON is not done for the vport, as it will lead to the
waking up of the dpc thread again and again.
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Arun Easi [Tue, 10 May 2011 18:18:16 +0000 (11:18 -0700)]
qla2xxx: Fix hang during driver unload when vport is active.
BugLink: http://bugs.launchpad.net/bugs/793702
commit
43ebf16d762b082663976b679b813e1b546548d1 upstream.
Bumping ref count during fc_vport_terminate() was the cause. vport
delete would wait for ref count to drop to zero and that would never
happen.
Signed-off-by: Arun Easi <arun.easi@qlogic.com>
Signed-off-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Steven Rostedt [Sat, 30 Apr 2011 02:35:33 +0000 (22:35 -0400)]
ftrace: Only update the function code on write to filter files
BugLink: http://bugs.launchpad.net/bugs/793702
commit
058e297d34a404caaa5ed277de15698d8dc43000 upstream.
If function tracing is enabled, a read of the filter files will
cause the call to stop_machine to update the function trace sites.
It should only call stop_machine on write.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Anton Blanchard [Tue, 17 May 2011 19:38:57 +0000 (15:38 -0400)]
net: recvmmsg: Strip MSG_WAITFORONE when calling recvmsg
BugLink: http://bugs.launchpad.net/bugs/793702
commit
b9eb8b8752804cecbacdb4d24b52e823cf07f107 upstream.
recvmmsg fails on a raw socket with EINVAL. The reason for this is
packet_recvmsg checks the incoming flags:
err = -EINVAL;
if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
goto out;
This patch strips out MSG_WAITFORONE when calling recvmmsg which
fixes the issue.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
steven finney [Mon, 2 May 2011 18:29:17 +0000 (11:29 -0700)]
Fix memory leak in cpufreq_stat
BugLink: http://bugs.launchpad.net/bugs/793702
commit
98586ed8b8878e10691203687e89a42fa3355300 upstream.
When a CPU is taken offline in an SMP system, cpufreq_remove_dev()
nulls out the per-cpu policy before cpufreq_stats_free_table() can
make use of it. cpufreq_stats_free_table() then skips the
call to sysfs_remove_group(), leaving about 100 bytes of sysfs-related
memory unclaimed each time a CPU-removal occurs. Break up
cpu_stats_free_table into sysfs and table portions, and
call the sysfs portion early.
Signed-off-by: Steven Finney <steven.finney@palm.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Shin [Wed, 27 Apr 2011 18:32:11 +0000 (13:32 -0500)]
CPU hotplug, re-create sysfs directory and symlinks
BugLink: http://bugs.launchpad.net/bugs/793702
commit
27ecddc2a9f99ce4ac9a59a0acd77f7100b6d034 upstream.
When we discover CPUs that are affected by each other's
frequency/voltage transitions, the first CPU gets a sysfs directory
created, and rest of the siblings get symlinks. Currently, when we
hotplug off only the first CPU, all of the symlinks and the sysfs
directory gets removed. Even though rest of the siblings are still
online and functional, they are orphaned, and no longer governed by
cpufreq.
This patch, given the above scenario, creates a sysfs directory for
the first sibling and symlinks for the rest of the siblings.
Please note the recursive call, it was rather too ugly to roll it
out. And the removal of redundant NULL setting (it is already taken
care of near the top of the function).
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Acked-by: Mark Langsdorf <mark.langsdorf@amd.com>
Reviewed-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Naga Chumbalkar [Tue, 26 Apr 2011 17:05:18 +0000 (17:05 +0000)]
Fix _OSC UUID in pcc-cpufreq
BugLink: http://bugs.launchpad.net/bugs/793702
commit
904cc1e637a00dba1b58e7752f485f90ebf2a568 upstream.
UUID needs to be written out the way it is described in
Sec 18.5.124 of ACPI 4.0a Specification.
Platform firmware's use of this UUID/_OSC is optional, which is
why we didn't notice this bug earlier.
Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Catalin Marinas [Thu, 19 May 2011 15:25:30 +0000 (16:25 +0100)]
kmemleak: Initialise kmemleak after debug_objects_mem_init()
BugLink: http://bugs.launchpad.net/bugs/793702
commit
9b090f2da85bd0df5e1a1ecfe4120b7b50358f48 upstream.
Kmemleak frees objects via RCU and when CONFIG_DEBUG_OBJECTS_RCU_HEAD
is enabled, the RCU callback triggers a call to free_object() in
lib/debugobjects.c. Since kmemleak is initialised before debug objects
initialisation, it may result in a kernel panic during booting. This
patch moves the kmemleak_init() call after debug_objects_mem_init().
Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Tested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Catalin Marinas [Wed, 27 Apr 2011 15:44:26 +0000 (16:44 +0100)]
kmemleak: Do not return a pointer to an object that kmemleak did not get
BugLink: http://bugs.launchpad.net/bugs/793702
commit
52c3ce4ec5601ee383a14f1485f6bac7b278896e upstream.
The kmemleak_seq_next() function tries to get an object (and increment
its use count) before returning it. If it could not get the last object
during list traversal (because it may have been freed), the function
should return NULL rather than a pointer to such object that it did not
get.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Acked-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Thu, 23 Jun 2011 14:55:53 +0000 (08:55 -0600)]
UBUNTU: [Config] Add grub-efi as a recommended bootloader for server and generic
BugLink: http://bugs.launchpad.net/bugs/800910
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Keng-Yu Lin [Wed, 22 Jun 2011 01:49:34 +0000 (09:49 +0800)]
drm/i915: disable PCH ports if needed when disabling a CRTC
BugLink: http://bugs.launchpad.net/bugs/791752
Disable any PCH ports associated with a pipe when disabling it. This
should prevent transcoder disable failures due to ports still being on.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: introduce *_PIPE_ENABLED() macro]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
backported from commit
47a05eca72991039e788b25232061f9c9df9ec23
Signed-off-by: Keng-Yu Lin <keng-yu.lin@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Rabin Vincent [Wed, 27 Apr 2011 15:37:28 +0000 (21:07 +0530)]
USB: ehci: remove structure packing from ehci_def
BugLink: http://bugs.launchpad.net/bugs/791552
As pointed out by Arnd Bergmann, in include/linux/usb/ehci_def.h, struct
ehci_caps is defined with __attribute__((packed)) for no good reason,
and this triggers undefined behaviour when using ARM's readl() on
pointers to elements of this structure:
http://lkml.kernel.org/r/
201102021700.20683.arnd@arndb.de
The same problem exists with the other two structures in ehci_def.h too,
so remove the __attribute__((packed)) from all of them.
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
139540170d9d9b7ead3caaf540f161756b356d56)
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Daniel J Blueman [Fri, 17 Jun 2011 18:32:19 +0000 (11:32 -0700)]
drm/i915: Fix gen6 (SNB) missed BLT ring interrupts.
BugLink: http://bugs.launchpad.net/bugs/761065
The failure appeared in dmesg as:
[drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt
ring idle [waiting on
35064155, at
35064155], missed IRQ?
This works around that problem on by making the blitter command
streamer write interrupt state to the Hardware Status Page when a
MI_USER_INTERRUPT command is decoded, which appears to force the seqno
out to memory before the interrupt happens.
v1->v2: Moved to prior interrupt handler installation and RMW flags as
per feedback.
v2->v3: Removed RMW of flags (by anholt)
Cc: stable@kernel.org
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> [v1]
Tested-by: Eric Anholt <eric@anholt.net> [v1,v3]
(incidence of the bug with a testcase went from avg 2/1000 to
0/12651 in the latest test run (plus more for v1))
Tested-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Tested-by: Robert Hooker <robert.hooker@canonical.com> [v1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33394
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
498e720b96379d8ee9c294950a01534a73defcf3)
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tero Kristo [Thu, 24 Feb 2011 15:19:23 +0000 (17:19 +0200)]
cpuidle: menu: fixed wrapping timers at 4.294 seconds
BugLink: http://bugs.launchpad.net/bugs/774947
Cpuidle menu governor is using u32 as a temporary datatype for storing
nanosecond values which wrap around at 4.294 seconds. This causes errors
in predicted sleep times resulting in higher than should be C state
selection and increased power consumption. This also breaks cpuidle
state residency statistics.
cc: stable@kernel.org # .32.x through .39.x
Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
Signed-off-by: Len Brown <len.brown@intel.com>
(cherry picked from commit
7467571f4480b273007517b26297c07154c73924)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Takashi Iwai [Tue, 26 Apr 2011 13:25:02 +0000 (15:25 +0200)]
ALSA: hda - Enable sync_write workaround for AMD generically
BugLink: http://bugs.launchpad.net/bugs/741825
Backport from
d507cd668a3f6d07b31e914722b453c454b03204.
The workaround for AMD chipset via sync_write flag seems needed for
machines with Realtek codecs. So, it's better to activate it
generically in hda_intel.c from the beginning.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Takashi Iwai [Tue, 17 May 2011 16:41:25 +0000 (18:41 +0200)]
ALSA: hda - Enable snoop bit for AMD controllers
BugLink: http://bugs.launchpad.net/bugs/741825
AMD Hudson controllers give noisy outputs when the buffer data is
rewritten on the fly as PulseAudio does. This seems fixed by the
snoop bit enabled just like ATI chipset.
Also, disable 64bit DMA as now, to be sure.
We can revisit this later.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit
20c304ed84e05a91b2acae36d428d621d3c1d1c6)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Takashi Iwai [Fri, 20 May 2011 14:29:09 +0000 (16:29 +0200)]
ALSA: hda - Use LPIB for ATI/AMD chipsets as default
BugLink: http://bugs.launchpad.net/bugs/741825
ATI and AMD chipsets seem not providing the proper position-buffer
information, and it also doesn't provide FIFO register required by
VIACOMBO fix. It's better to use LPIB for these.
Reported-by: David Henningsson <david.henningsson@canonical.com>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit
50e3bbf9898840eead86f90a43b3625a2b2f4112)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Johannes Weiner [Wed, 25 May 2011 00:11:09 +0000 (17:11 -0700)]
mm: vmscan: correct use of pgdat_balanced in sleeping_prematurely
BugLink: http://bugs.launchpad.net/bugs/755066
There are a few reports of people experiencing hangs when copying large
amounts of data with kswapd using a large amount of CPU which appear to be
due to recent reclaim changes. SLUB using high orders is the trigger but
not the root cause as SLUB has been using high orders for a while. The
root cause was bugs introduced into reclaim which are addressed by the
following two patches.
Patch 1 corrects logic introduced by commit
1741c877 ("mm: kswapd:
keep kswapd awake for high-order allocations until a percentage of
the node is balanced") to allow kswapd to go to sleep when
balanced for high orders.
Patch 2 notes that it is possible for kswapd to miss every
cond_resched() and updates shrink_slab() so it'll at least reach
that scheduling point.
Chris Wood reports that these two patches in isolation are sufficient to
prevent the system hanging. AFAIK, they should also resolve similar hangs
experienced by James Bottomley.
This patch:
Johannes Weiner poined out that the logic in commit
1741c877 ("mm: kswapd:
keep kswapd awake for high-order allocations until a percentage of the
node is balanced") is backwards. Instead of allowing kswapd to go to
sleep when balancing for high order allocations, it keeps it kswapd
running uselessly.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Wu Fengguang <fengguang.wu@intel.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Colin King <colin.king@canonical.com>
Cc: Raghavendra D Prabhu <raghu.prabhu13@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: Wu Fengguang <fengguang.wu@intel.com>
Cc: <stable@kernel.org> [2.6.38+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
afc7e326a3f5bafc41324d7926c324414e343ee5)
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Herton Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Minchan Kim [Wed, 25 May 2011 00:11:11 +0000 (17:11 -0700)]
mm: vmscan: correctly check if reclaimer should schedule during shrink_slab
BugLink: http://bugs.launchpad.net/bugs/755066
It has been reported on some laptops that kswapd is consuming large
amounts of CPU and not being scheduled when SLUB is enabled during large
amounts of file copying. It is expected that this is due to kswapd
missing every cond_resched() point because;
shrink_page_list() calls cond_resched() if inactive pages were isolated
which in turn may not happen if all_unreclaimable is set in
shrink_zones(). If for whatver reason, all_unreclaimable is
set on all zones, we can miss calling cond_resched().
balance_pgdat() only calls cond_resched if the zones are not
balanced. For a high-order allocation that is balanced, it
checks order-0 again. During that window, order-0 might have
become unbalanced so it loops again for order-0 and returns
that it was reclaiming for order-0 to kswapd(). It can then
find that a caller has rewoken kswapd for a high-order and
re-enters balance_pgdat() without ever calling cond_resched().
shrink_slab only calls cond_resched() if we are reclaiming slab
pages. If there are a large number of direct reclaimers, the
shrinker_rwsem can be contended and prevent kswapd calling
cond_resched().
This patch modifies the shrink_slab() case. If the semaphore is
contended, the caller will still check cond_resched(). After each
successful call into a shrinker, the check for cond_resched() remains in
case one shrinker is particularly slow.
[mgorman@suse.de: preserve call to cond_resched after each call into shrinker]
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Colin King <colin.king@canonical.com>
Cc: Raghavendra D Prabhu <raghu.prabhu13@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: <stable@kernel.org> [2.6.38+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
f06590bd718ed950c98828e30ef93204028f3210)
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Herton Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Nick Kossifidis [Fri, 17 Jun 2011 14:29:22 +0000 (09:29 -0500)]
ath5k: Disable fast channel switching by default
BugLink: http://bugs.launchpad.net/bugs/767192
Disable fast channel change by default on AR2413/AR5413 due to
some bug reports (it still works for me but it's better to be safe).
Add a module parameter "fastchanswitch" in case anyone wants to enable
it and play with it.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(backported from commit
a99168eece601d2a79ecfcb968ce226f2f30cf98 upstream)
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Herton Krzesinski <herton.krzesinski@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stefan Metzmacher [Wed, 1 Jun 2011 02:01:41 +0000 (02:01 +0000)]
usbnet/cdc_ncm: add missing .reset_resume hook
BugLink: http://bugs.launchpad.net/bugs/793892
This avoids messages like this after suspend:
cdc_ncm 2-1.4:1.6: no reset_resume for driver cdc_ncm?
cdc_ncm 2-1.4:1.7: no reset_resume for driver cdc_ncm?
cdc_ncm 2-1.4:1.6: usb0: unregister 'cdc_ncm' usb-0000:00:1d.0-1.4, CDC NCM
This is important for the Ericsson F5521gw GSM/UMTS modem.
Otherwise modemmanager looses the fact that the cdc_ncm and cdc_acm devices
belong together.
The cdc_ether module does the same.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
(backport from commit
85e3c65fa3a1d0542c181510a950a2be7733ff29 upstream)
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Timo Warns [Fri, 10 Jun 2011 10:05:59 +0000 (11:05 +0100)]
fs/partitions/efi.c: corrupted GUID partition tables can cause kernel oops
The kernel automatically evaluates partition tables of storage devices.
The code for evaluating GUID partitions (in fs/partitions/efi.c) contains
a bug that causes a kernel oops on certain corrupted GUID partition
tables.
This bug has security impacts, because it allows, for example, to
prepare a storage device that crashes a kernel subsystem upon connecting
the device (e.g., a "USB Stick of (Partial) Death").
crc = efi_crc32((const unsigned char *) (*gpt), le32_to_cpu((*gpt)->header_size));
computes a CRC32 checksum over gpt covering (*gpt)->header_size bytes.
There is no validation of (*gpt)->header_size before the efi_crc32 call.
A corrupted partition table may have large values for (*gpt)->header_size.
In this case, the CRC32 computation access memory beyond the memory
allocated for gpt, which may cause a kernel heap overflow.
Validate value of GUID partition table header size.
[akpm@linux-foundation.org: fix layout and indenting]
Signed-off-by: Timo Warns <warns@pre-sense.de>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Cc: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
3eb8e74ec72736b9b9d728bad30484ec89c91dde)
CVE-2011-1577
BugLink: http://bugs.launchpad.net/bugs/795418
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Phil Oester [Mon, 6 Jun 2011 10:35:23 +0000 (11:35 +0100)]
bonding: Incorrect TX queue offset, CVE-2011-1581
When packets come in from a device with >= 16 receive queues
headed out a bonding interface, syslog gets filled with this:
kernel: bond0 selects TX queue 16, but real number of TX queues is 16
because queue_mapping is offset by 1. Adjust return value
to account for the offset.
This is a revision of my earlier patch (which did not use the
skb_rx_queue_* helpers - thanks to Ben for the suggestion).
Andy submitted a similar patch which emits a pr_warning on
invalid queue selection, but I believe the log spew is
not useful. We can revisit that question in the future,
but in the interim I believe fixing the core problem is
worthwhile.
Signed-off-by: Phil Oester <kernel@linuxace.com>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit
fd0e435b0fe85622f167b84432552885a4856ac8)
CVE-2011-1581
BugLink: http://bugs.launchpad.net/bugs/792312
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Steve Conklin [Tue, 12 Jul 2011 20:00:27 +0000 (15:00 -0500)]
UBUNTU: Bump ABI
Ignore: yes
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Steve Conklin [Tue, 12 Jul 2011 19:58:42 +0000 (14:58 -0500)]
Fix up ABI directory
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Steve Conklin [Tue, 12 Jul 2011 19:57:59 +0000 (14:57 -0500)]
UBUNTU: Start new release
Ignore: yes
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Steve Conklin [Tue, 28 Jun 2011 13:38:06 +0000 (14:38 +0100)]
UBUNTU: Ubuntu-2.6.38-10.46
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Steve Conklin [Tue, 28 Jun 2011 13:33:14 +0000 (14:33 +0100)]
Revert "fix oops in scsi_run_queue()"
This reverts commit
57bd324dbd799b271cad945224df5a21b151297b.
This revert is being tracked in bug 802986
Steve Conklin [Tue, 28 Jun 2011 13:28:42 +0000 (14:28 +0100)]
Revert "put stricter guards on queue dead checks"
This reverts commit
39a0cfed63b656486fb2feee063aa033816a90e0.
This revert is being tracked in bug 802986
Steve Conklin [Tue, 28 Jun 2011 11:39:16 +0000 (12:39 +0100)]
UBUNTU: Start new release
Ignore: yes
Steve Conklin [Mon, 27 Jun 2011 14:05:24 +0000 (15:05 +0100)]
UBUNTU: Ubuntu-2.6.38-10.45
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Steve Conklin [Mon, 27 Jun 2011 14:02:07 +0000 (15:02 +0100)]
Revert "af_unix: Only allow recv on connected seqpacket sockets."
This reverts commit
4ce4a71e7f5bdd1d2bce71f1e798c76d3716630a.
This revert is being tracked in bug 802461
Steve Conklin [Mon, 27 Jun 2011 11:43:46 +0000 (12:43 +0100)]
UBUNTU: Start new release
Ignore: yes
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Steve Conklin [Thu, 2 Jun 2011 19:32:33 +0000 (14:32 -0500)]
UBUNTU: Ubuntu-2.6.38-10.44
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Steve Conklin [Wed, 1 Jun 2011 16:55:07 +0000 (11:55 -0500)]
Revert "USB: xhci - also free streams when resetting devices"
This reverts commit
fc4c57e02daa2699f54cf2ae92986484264880a3.
Due to a reported problem with USB3 after application of three patches
from upstream stable, these patches are being reverted until they can
be tested seperately and a determination made of whether there is a
problem and how bad it is. The reporter has not yet responded to a
request to test kernels with each of the most suspect patches reverted,
so all will be reverted. Testing will proceed using these patches and
hopefully they can be restored soon. The USB3 problem was reported
in LP bug number 769042
Steve Conklin [Wed, 1 Jun 2011 16:54:30 +0000 (11:54 -0500)]
Revert "USB: xhci - fix math in xhci_get_endpoint_interval()"
This reverts commit
fe3bf5f4be7d3a1a61225c77bd8a9b51baa3ac19.
Due to a reported problem with USB3 after application of three patches
from upstream stable, these patches are being reverted until they can
be tested seperately and a determination made of whether there is a
problem and how bad it is. The reporter has not yet responded to a
request to test kernels with each of the most suspect patches reverted,
so all will be reverted. Testing will proceed using these patches and
hopefully they can be restored soon. The USB3 problem was reported
in LP bug number 769042
Steve Conklin [Wed, 1 Jun 2011 16:42:58 +0000 (11:42 -0500)]
Revert "USB: xhci - fix unsafe macro definitions"
This reverts commit
923326deb96954b634b058f41bf6b482e503cb8f.
Due to a reported problem with USB3 after application of three patches
from upstream stable, these patches are being reverted until they can
be tested seperately and a determination made of whether there is a
problem and how bad it is. The reporter has not yet responded to a
request to test kernels with each of the most suspect patches reverted,
so all will be reverted. Testing will proceed using these patches and
hopefully they can be restored soon. The USB3 problem was reported
in LP bug number 769042
Chaoming Li [Sun, 10 Apr 2011 23:30:23 +0000 (18:30 -0500)]
rtlwifi: rtl8192ce: Fix LED initialization
Driver rtl8192ce does not initialize the LED correctly.
Signed-off-by: Chaoming Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
BugLink: http://bugs.launchpad.net/bugs/785975
[backport: renamed ledon to b_ledon]
(backported from commit
228bdfca9a09c1263c24509b4bc23a67be168e1a upstream)
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Herton Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Greg Kroah-Hartman [Sat, 21 May 2011 22:13:59 +0000 (15:13 -0700)]
Linux 2.6.38.7
BugLink: http://bugs.launchpad.net/bugs/788691
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Hugh Dickins [Fri, 20 May 2011 22:47:33 +0000 (15:47 -0700)]
tmpfs: fix highmem swapoff crash regression
BugLink: http://bugs.launchpad.net/bugs/788691
commit
e6c9366b2adb52cba64b359b3050200743c7568c upstream.
Commit
778dd893ae78 ("tmpfs: fix race between umount and swapoff")
forgot the new rules for strict atomic kmap nesting, causing
WARNING: at arch/x86/mm/highmem_32.c:81
from __kunmap_atomic(), then
BUG: unable to handle kernel paging request at
fffb9000
from shmem_swp_set() when shmem_unuse_inode() is handling swapoff with
highmem in use. My disgrace again.
See
https://bugzilla.kernel.org/show_bug.cgi?id=35352
Reported-by: Witold Baryluk <baryluk@smp.if.uj.edu.pl>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Stanislaw Gruszka [Sat, 7 May 2011 15:46:21 +0000 (17:46 +0200)]
iwlegacy: fix IBSS mode crashes
BugLink: http://bugs.launchpad.net/bugs/788691
commit
eb85de3f84868ca85703a23617b4079ce79a801e upstream.
We should not switch to non-IBSS channels when working in IBSS mode,
otherwise there are microcode errors, and after some time system
crashes.
This bug is only observable when software scan is used in IBSS mode,
so should be considered as regression after:
commit
0263aa45293838b514b8af674a03faf040991a90
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Tue Mar 29 11:24:21 2011 +0200
iwl3945: disable hw scan by default
However IBSS mode check, which this patch add again, was removed by
commit
b2f30e8bdd8ef5f3b5a7ef9146509585a15347d3
Author: Johannes Berg <johannes.berg@intel.com>
Date: Thu Jan 21 07:32:20 2010 -0800
iwlwifi: remove IBSS channel sanity check
That commit claim that mac80211 will not use non-IBSS channel in IBSS
mode, what definitely is not true. Bug probably should be fixed in
mac80211, but that will require more work, so better to apply that patch
temporally, and provide proper mac80211 fix latter.
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=34452
Reported-and-tested-by: Mikko Rapeli <mikko.rapeli@iki.fi>
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>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Jeff Layton [Tue, 17 May 2011 19:28:21 +0000 (15:28 -0400)]
cifs: fix cifsConvertToUCS() for the mapchars case
BugLink: http://bugs.launchpad.net/bugs/788691
commit
11379b5e33950048ad66825da7f462b0d0da9d73 upstream.
As Metze pointed out, commit
84cdf74e broke mapchars option:
Commit "cifs: fix unaligned accesses in cifsConvertToUCS"
(
84cdf74e8096a10dd6acbb870dd404b92f07a756) does multiple steps
in just one commit (moving the function and changing it without
testing).
put_unaligned_le16(temp, &target[j]); is never called for any
codepoint the goes via the 'default' switch statement. As a result
we put just zero (or maybe uninitialized) bytes into the target
buffer.
His proposed patch looks correct, but doesn't apply to the current head
of the tree. This patch should also fix it.
Reported-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Jeff Layton [Tue, 5 Apr 2011 19:02:37 +0000 (15:02 -0400)]
cifs: clean up various nits in unicode routines (try #2)
BugLink: http://bugs.launchpad.net/bugs/788691
commit
581ade4d1c025eb10421eda0d0c0a2f04447d7c5 upstream.
Minor revision to the original patch. Don't abuse the __le16 variable
on the stack by casting it to wchar_t and handing it off to char2uni.
Declare an actual wchar_t on the stack instead. This fixes a valid
sparse warning.
Fix the spelling of UNI_ASTERISK. Eliminate the unneeded len_remaining
variable in cifsConvertToUCS.
Also, as David Howells points out. We were better off making
cifsConvertToUCS *not* use put_unaligned_le16 since it means that we
can't optimize the mapped characters at compile time. Switch them
instead to use cpu_to_le16, and simply use put_unaligned to set them
in the string.
Reported-and-acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
James Bottomley [Wed, 23 Mar 2011 14:58:28 +0000 (09:58 -0500)]
Revert "[SCSI] Retrieve the Caching mode page"
BugLink: http://bugs.launchpad.net/bugs/788691
commit
3dea642afd9187728d119fce5c82a7ed9faa9b6a upstream.
This reverts commit
24d720b726c1a85f1962831ac30ad4d2ef8276b1.
Previously we thought there was little possibility that devices would
crash with this, but some have been found.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Thomas Jarosch [Mon, 16 May 2011 06:28:15 +0000 (06:28 +0000)]
vmxnet3: Fix inconsistent LRO state after initialization
BugLink: http://bugs.launchpad.net/bugs/788691
commit
ebde6f8acba92abfc203585198a54f47e83e2cd0 upstream.
During initialization of vmxnet3, the state of LRO
gets out of sync with netdev->features.
This leads to very poor TCP performance in a IP forwarding
setup and is hitting many VMware users.
Simplified call sequence:
1. vmxnet3_declare_features() initializes "adapter->lro" to true.
2. The kernel automatically disables LRO if IP forwarding is enabled,
so vmxnet3_set_flags() gets called. This also updates netdev->features.
3. Now vmxnet3_setup_driver_shared() is called. "adapter->lro" is still
set to true and LRO gets enabled again, even though
netdev->features shows it's disabled.
Fix it by updating "adapter->lro", too.
The private vmxnet3 adapter flags are scheduled for removal
in net-next, see commit
a0d2730c9571aeba793cb5d3009094ee1d8fda35
"net: vmxnet3: convert to hw_features".
Patch applies to 2.6.37 / 2.6.38 and 2.6.39-rc6.
Please CC: comments.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Tejun Heo [Fri, 29 Apr 2011 08:15:14 +0000 (10:15 +0200)]
cdrom: always check_disk_change() on open
BugLink: http://bugs.launchpad.net/bugs/788691
commit
bf2253a6f00e8fea5b026e471e9f0d0a1b3621f2 upstream.
cdrom_open() called check_disk_change() after the rest of open path
succeeded which leads to the following bizarre behavior.
* After media change, if the device opened without O_NONBLOCK,
open_for_data() naturally fails with -ENOMEDIA and
check_disk_change() is never called. The media is known to be gone
and the open failure makes it obvious to the userland but device
invalidation never happens.
* But if the device is opened with O_NONBLOCK, all the checks are
bypassed and cdrom_open() doesn't notice that the media is not there
and check_disk_change() is called and invalidation happens.
There's nothing to be gained by avoiding calling check_disk_change()
on open failure. Common cases end up calling check_disk_change()
anyway. All we get is inconsistent behavior.
Fix it by moving check_disk_change() invocation to the top of
cdrom_open() so that it always gets called regardless of how the rest
of open proceeds.
Stable: 2.6.38
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Amit Shah <amit.shah@redhat.com>
Tested-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Bjørn Mork [Wed, 19 Jan 2011 09:01:14 +0000 (10:01 +0100)]
megaraid_sas: Sanity check user supplied length before passing it to dma_alloc_coherent()
BugLink: http://bugs.launchpad.net/bugs/788691
commit
98cb7e4413d189cd2b54daf993a4667d9788c0bb upstream.
The ioc->sgl[i].iov_len value is supplied by the ioctl caller, and can be
zero in some cases. Assume that's valid and continue without error.
Fixes (multiple individual reports of the same problem for quite a while):
http://marc.info/?l=linux-ide&m=
128941801715301
http://bugs.debian.org/604627
http://www.mail-archive.com/linux-poweredge@dell.com/msg02575.html
megasas: Failed to alloc kernel SGL buffer for IOCTL
and
[ 69.162538] ------------[ cut here ]------------
[ 69.162806] kernel BUG at /build/buildd/linux-2.6.32/lib/swiotlb.c:368!
[ 69.163134] invalid opcode: 0000 [#1] SMP
[ 69.163570] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[ 69.163975] CPU 0
[ 69.164227] Modules linked in: fbcon tileblit font bitblit softcursor vga16fb vgastate ioatdma radeon ttm drm_kms_helper shpchp drm i2c_algo_bit lp parport floppy pata_jmicron megaraid_sas igb dca
[ 69.167419] Pid: 1206, comm: smartctl Tainted: G W 2.6.32-25-server #45-Ubuntu X8DTN
[ 69.167843] RIP: 0010:[<
ffffffff812c4dc5>] [<
ffffffff812c4dc5>] map_single+0x255/0x260
[ 69.168370] RSP: 0018:
ffff88081c0ebc58 EFLAGS:
00010246
[ 69.168655] RAX:
000000000003bffc RBX:
00000000ffffffff RCX:
0000000000000002
[ 69.169000] RDX:
0000000000000000 RSI:
0000000000000000 RDI:
ffff88001dffe000
[ 69.169346] RBP:
ffff88081c0ebcb8 R08:
0000000000000000 R09:
ffff880000030840
[ 69.169691] R10:
0000000000100000 R11:
0000000000000000 R12:
0000000000000000
[ 69.170036] R13:
00000000ffffffff R14:
0000000000000001 R15:
0000000000200000
[ 69.170382] FS:
00007fb8de189720(0000) GS:
ffff88001de00000(0000) knlGS:
0000000000000000
[ 69.170794] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 69.171094] CR2:
00007fb8dd59237c CR3:
000000081a790000 CR4:
00000000000006f0
[ 69.171439] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 69.171784] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[ 69.172130] Process smartctl (pid: 1206, threadinfo
ffff88081c0ea000, task
ffff88081a760000)
[ 69.194513] Stack:
[ 69.205788]
0000000000000034 00000002817e3390 0000000000000000 ffff88081c0ebe00
[ 69.217739] <0>
0000000000000000 000000000003bffc 0000000000000000 0000000000000000
[ 69.241250] <0>
0000000000000000 00000000ffffffff ffff88081c5b4080 ffff88081c0ebe00
[ 69.277310] Call Trace:
[ 69.289278] [<
ffffffff812c52ac>] swiotlb_alloc_coherent+0xec/0x130
[ 69.301118] [<
ffffffff81038b31>] x86_swiotlb_alloc_coherent+0x61/0x70
[ 69.313045] [<
ffffffffa002d0ce>] megasas_mgmt_fw_ioctl+0x1ae/0x690 [megaraid_sas]
[ 69.336399] [<
ffffffffa002d748>] megasas_mgmt_ioctl_fw+0x198/0x240 [megaraid_sas]
[ 69.359346] [<
ffffffffa002f695>] megasas_mgmt_ioctl+0x35/0x50 [megaraid_sas]
[ 69.370902] [<
ffffffff81153b12>] vfs_ioctl+0x22/0xa0
[ 69.382322] [<
ffffffff8115da2a>] ? alloc_fd+0x10a/0x150
[ 69.393622] [<
ffffffff81153cb1>] do_vfs_ioctl+0x81/0x410
[ 69.404696] [<
ffffffff8155cc13>] ? do_page_fault+0x153/0x3b0
[ 69.415761] [<
ffffffff811540c1>] sys_ioctl+0x81/0xa0
[ 69.426640] [<
ffffffff810121b2>] system_call_fastpath+0x16/0x1b
[ 69.437491] Code: fe ff ff 48 8b 3d 74 38 76 00 41 bf 00 00 20 00 e8 51 f5 d7 ff 83 e0 ff 48 05 ff 07 00 00 48 c1 e8 0b 48 89 45 c8 e9 13 fe ff ff <0f> 0b eb fe 0f 1f 80 00 00 00 00 55 48 89 e5 48 83 ec 20 4c 89
[ 69.478216] RIP [<
ffffffff812c4dc5>] map_single+0x255/0x260
[ 69.489668] RSP <
ffff88081c0ebc58>
[ 69.500975] ---[ end trace
6a2181b634e2abc7 ]---
Reported-by: Bokhan Artem <aptem@ngs.ru>
Reported by: Marc-Christian Petersen <m.c.p@gmx.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: Michael Benz <Michael.Benz@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Julia Lawall [Fri, 13 May 2011 13:52:09 +0000 (15:52 +0200)]
x86, mce, AMD: Fix leaving freed data in a list
BugLink: http://bugs.launchpad.net/bugs/788691
commit
d9a5ac9ef306eb5cc874f285185a15c303c50009 upstream.
b may be added to a list, but is not removed before being freed
in the case of an error. This is done in the corresponding
deallocation function, so the code here has been changed to
follow that.
The sematic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression E,E1,E2;
identifier l;
@@
*list_add(&E->l,E1);
... when != E1
when != list_del(&E->l)
when != list_del_init(&E->l)
when != E = E2
*kfree(E);// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Link: http://lkml.kernel.org/r/
1305294731-12127-1-git-send-email-julia@diku.dk
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Cliff Wickman [Tue, 10 May 2011 13:26:43 +0000 (08:26 -0500)]
x86: Fix UV BAU for non-consecutive nasids
BugLink: http://bugs.launchpad.net/bugs/788691
commit
77ed23f8d995a01cd8101d84351b567bf5177a30 upstream.
This is a fix for the SGI Altix-UV Broadcast Assist Unit code,
which is used for TLB flushing.
Certain hardware configurations (that customers are ordering)
cause nasids (numa address space id's) to be non-consecutive.
Specifically, once you have more than 4 blades in a IRU
(Individual Rack Unit - or 1/2 rack) but less than the maximum
of 16, the nasid numbering becomes non-consecutive. This
currently results in a 'catastrophic error' (CATERR) detected by
the firmware during OS boot. The BAU is generating an 'INTD'
request that is targeting a non-existent nasid value. Such
configurations may also occur when a blade is configured off
because of hardware errors. (There is one UV hub per blade.)
This patch is required to support such configurations.
The problem with the tlb_uv.c code is that is using the
consecutive hub numbers as indices to the BAU distribution bit
map. These are simply the ordinal position of the hub or blade
within its partition. It should be using physical node numbers
(pnodes), which correspond to the physical nasid values. Use of
the hub number only works as long as the nasids in the partition
are consecutive and increase with a stride of 1.
This patch changes the index to be the pnode number, thus
allowing nasids to be non-consecutive.
It also provides a table in local memory for each cpu to
translate target cpu number to target pnode and nasid.
And it improves naming to properly reflect 'node' and 'uvhub'
versus 'nasid'.
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Link: http://lkml.kernel.org/r/E1QJmxX-0002Mz-Fk@eag09.americas.sgi.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Laurent Pinchart [Sat, 30 Apr 2011 13:34:05 +0000 (10:34 -0300)]
v4l: Release module if subdev registration fails
BugLink: http://bugs.launchpad.net/bugs/788691
commit
b7534f002d3c81d18abfbf57179d07d3ec763bb5 upstream.
If v4l2_device_register_subdev() fails, the reference to the subdev
module taken by the function isn't released. Fix this.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Lawrence Rust [Fri, 8 Apr 2011 12:50:45 +0000 (09:50 -0300)]
Fix cx88 remote control input
BugLink: http://bugs.launchpad.net/bugs/788691
commit
2a164d02dd34c6b49a3f0995900e0f8af102b804 upstream.
In the IR interrupt handler of cx88-input.c there's a 32-bit multiply
overflow which causes IR pulse durations to be incorrectly calculated.
This is a regression caused by commit
2997137be8eba.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Youquan Song [Thu, 21 Apr 2011 16:22:43 +0000 (00:22 +0800)]
x86, apic: Fix spurious error interrupts triggering on all non-boot APs
BugLink: http://bugs.launchpad.net/bugs/788691
commit
e503f9e4b092e2349a9477a333543de8f3c7f5d9 upstream.
This patch fixes a bug reported by a customer, who found
that many unreasonable error interrupts reported on all
non-boot CPUs (APs) during the system boot stage.
According to Chapter 10 of Intel Software Developer Manual
Volume 3A, Local APIC may signal an illegal vector error when
an LVT entry is set as an illegal vector value (0~15) under
FIXED delivery mode (bits 8-11 is 0), regardless of whether
the mask bit is set or an interrupt actually happen. These
errors are seen as error interrupts.
The initial value of thermal LVT entries on all APs always reads
0x10000 because APs are woken up by BSP issuing INIT-SIPI-SIPI
sequence to them and LVT registers are reset to 0s except for
the mask bits which are set to 1s when APs receive INIT IPI.
When the BIOS takes over the thermal throttling interrupt,
the LVT thermal deliver mode should be SMI and it is required
from the kernel to keep AP's LVT thermal monitoring register
programmed as such as well.
This issue happens when BIOS does not take over thermal throttling
interrupt, AP's LVT thermal monitor register will be restored to
0x10000 which means vector 0 and fixed deliver mode, so all APs will
signal illegal vector error interrupts.
This patch check if interrupt delivery mode is not fixed mode before
restoring AP's LVT thermal monitor register.
Signed-off-by: Youquan Song <youquan.song@intel.com>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Yong Wang <yong.y.wang@intel.com>
Cc: hpa@linux.intel.com
Cc: joe@perches.com
Cc: jbaron@redhat.com
Cc: trenn@suse.de
Cc: kent.liu@intel.com
Cc: chaohong.guo@intel.com
Link: http://lkml.kernel.org/r/
1303402963-17738-1-git-send-email-youquan.song@intel.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Thomas Gleixner [Mon, 16 May 2011 09:07:48 +0000 (11:07 +0200)]
tick: Clear broadcast active bit when switching to oneshot
BugLink: http://bugs.launchpad.net/bugs/788691
commit
07f4beb0b5bbfaf36a64aa00d59e670ec578a95a upstream.
The first cpu which switches from periodic to oneshot mode switches
also the broadcast device into oneshot mode. The broadcast device
serves as a backup for per cpu timers which stop in deeper
C-states. To avoid starvation of the cpus which might be in idle and
depend on broadcast mode it marks the other cpus as broadcast active
and sets the brodcast expiry value of those cpus to the next tick.
The oneshot mode broadcast bit for the other cpus is sticky and gets
only cleared when those cpus exit idle. If a cpu was not idle while
the bit got set in consequence the bit prevents that the broadcast
device is armed on behalf of that cpu when it enters idle for the
first time after it switched to oneshot mode.
In most cases that goes unnoticed as one of the other cpus has usually
a timer pending which keeps the broadcast device armed with a short
timeout. Now if the only cpu which has a short timer active has the
bit set then the broadcast device will not be armed on behalf of that
cpu and will fire way after the expected timer expiry. In the case of
Christians bug report it took ~145 seconds which is about half of the
wrap around time of HPET (the limit for that device) due to the fact
that all other cpus had no timers armed which expired before the 145
seconds timeframe.
The solution is simply to clear the broadcast active bit
unconditionally when a cpu switches to oneshot mode after the first
cpu switched the broadcast device over. It's not idle at that point
otherwise it would not be executing that code.
[ I fundamentally hate that broadcast crap. Why the heck thought some
folks that when going into deep idle it's a brilliant concept to
switch off the last device which brings the cpu back from that
state? ]
Thanks to Christian for providing all the valuable debug information!
Reported-and-tested-by: Christian Hoffmann <email@christianhoffmann.info>
Cc: John Stultz <johnstul@us.ibm.com>
Link: http://lkml.kernel.org/r/%3Calpine.LFD.2.02.
1105161105170.3078%40ionos%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
john stultz [Thu, 5 May 2011 01:16:50 +0000 (18:16 -0700)]
clocksource: Install completely before selecting
BugLink: http://bugs.launchpad.net/bugs/788691
commit
e05b2efb82596905ebfe88e8612ee81dec9b6592 upstream.
Christian Hoffmann reported that the command line clocksource override
with acpi_pm timer fails:
Kernel command line: <SNIP> clocksource=acpi_pm
hpet clockevent registered
Switching to clocksource hpet
Override clocksource acpi_pm is not HRT compatible.
Cannot switch while in HRT/NOHZ mode.
The watchdog code is what enables CLOCK_SOURCE_VALID_FOR_HRES, but we
actually end up selecting the clocksource before we enqueue it into
the watchdog list, so that's why we see the warning and fail to switch
to acpi_pm timer as requested. That's particularly bad when we want to
debug timekeeping related problems in early boot.
Put the selection call last.
Reported-by: Christian Hoffmann <email@christianhoffmann.info>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Link: http://lkml.kernel.org/r/%
3C1304558210.2943.24.camel%40work-vm%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Borislav Petkov [Tue, 17 May 2011 12:55:19 +0000 (14:55 +0200)]
x86, AMD: Fix ARAT feature setting again
BugLink: http://bugs.launchpad.net/bugs/788691
commit
14fb57dccb6e1defe9f89a66f548fcb24c374c1d upstream.
Trying to enable the local APIC timer on early K8 revisions
uncovers a number of other issues with it, in conjunction with
the C1E enter path on AMD. Fixing those causes much more churn
and troubles than the benefit of using that timer brings so
don't enable it on K8 at all, falling back to the original
functionality the kernel had wrt to that.
Reported-and-bisected-by: Nick Bowler <nbowler@elliptictech.com>
Cc: Boris Ostrovsky <Boris.Ostrovsky@amd.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>
Cc: Nick Bowler <nbowler@elliptictech.com>
Cc: Joerg-Volker-Peetz <jvpeetz@web.de>
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Link: http://lkml.kernel.org/r/
1305636919-31165-3-git-send-email-bp@amd64.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Borislav Petkov [Tue, 17 May 2011 12:55:18 +0000 (14:55 +0200)]
Revert "x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors"
BugLink: http://bugs.launchpad.net/bugs/788691
commit
328935e6348c6a7cb34798a68c326f4b8372e68a upstream.
This reverts commit
e20a2d205c05cef6b5783df339a7d54adeb50962, as it crashes
certain boxes with specific AMD CPU models.
Moving the lower endpoint of the Erratum 400 check to accomodate
earlier K8 revisions (A-E) opens a can of worms which is simply
not worth to fix properly by tweaking the errata checking
framework:
* missing IntPenging MSR on revisions < CG cause #GP:
http://marc.info/?l=linux-kernel&m=
130541471818831
* makes earlier revisions use the LAPIC timer instead of the C1E
idle routine which switches to HPET, thus not waking up in
deeper C-states:
http://lkml.org/lkml/2011/4/24/20
Therefore, leave the original boundary starting with K8-revF.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Alexandre Bounine [Tue, 17 May 2011 22:44:08 +0000 (15:44 -0700)]
rapidio: fix default routing initialization
BugLink: http://bugs.launchpad.net/bugs/788691
commit
0bf2461fdd9008290cf429e50e4f362dafab4249 upstream.
Fix switch initialization to ensure that all switches have default routing
disabled. This guarantees that no unexpected RapidIO packets arrive to
the default port set by reset and there is no default routing destination
until it is properly configured by software.
This update also unifies handling of unmapped destinations by tsi57x, IDT
Gen1 and IDT Gen2 switches.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Jeff Layton [Tue, 17 May 2011 10:40:30 +0000 (06:40 -0400)]
cifs: add fallback in is_path_accessible for old servers
BugLink: http://bugs.launchpad.net/bugs/788691
commit
221d1d797202984cb874e3ed9f1388593d34ee22 upstream.
The is_path_accessible check uses a QPathInfo call, which isn't
supported by ancient win9x era servers. Fall back to an older
SMBQueryInfo call if it fails with the magic error codes.
Reported-and-Tested-by: Sandro Bonazzola <sandro.bonazzola@gmail.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Chris Ball [Mon, 16 May 2011 15:32:26 +0000 (11:32 -0400)]
Revert "mmc: fix a race between card-detect rescan and clock-gate work instances"
BugLink: http://bugs.launchpad.net/bugs/788691
commit
86f315bbb2374f1f077500ad131dd9b71856e697 upstream.
This reverts commit
26fc8775b51484d8c0a671198639c6d5ae60533e, which has
been reported to cause boot/resume-time crashes for some users:
https://bbs.archlinux.org/viewtopic.php?id=118751.
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Alex Deucher [Wed, 11 May 2011 18:02:07 +0000 (14:02 -0400)]
drm/radeon/kms: fix extended lvds info parsing
BugLink: http://bugs.launchpad.net/bugs/788691
commit
05fa7ea7d23980de0014417a0e0af2048a0f9fc1 upstream.
On rev <= 1.1 tables, the offset is absolute,
on newer tables, it's relative.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=700326
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Tejun Heo [Mon, 9 May 2011 14:04:11 +0000 (16:04 +0200)]
libata: fix oops when LPM is used with PMP
BugLink: http://bugs.launchpad.net/bugs/788691
commit
5f6f12ccf3aa42cfc0c5bde9228df0c843dd63f7 upstream.
ae01b2493c (libata: Implement ATA_FLAG_NO_DIPM and apply it to mcp65)
added ATA_FLAG_NO_DIPM and made ata_eh_set_lpm() check the flag.
However, @ap is NULL if @link points to a PMP link and thus the
unconditional @ap->flags dereference leads to the following oops.
BUG: unable to handle kernel NULL pointer dereference at
0000000000000018
IP: [<
ffffffff813f98e1>] ata_eh_recover+0x9a1/0x1510
...
Pid: 295, comm: scsi_eh_4 Tainted: P 2.6.38.5-core2 #1 System76, Inc. Serval Professional/Serval Professional
RIP: 0010:[<
ffffffff813f98e1>] [<
ffffffff813f98e1>] ata_eh_recover+0x9a1/0x1510
RSP: 0018:
ffff880132defbf0 EFLAGS:
00010246
RAX:
0000000000000000 RBX:
ffff880132f40000 RCX:
0000000000000000
RDX:
ffff88013377c000 RSI:
ffff880132f40000 RDI:
0000000000000000
RBP:
ffff880132defce0 R08:
ffff88013377dc58 R09:
ffff880132defd98
R10:
0000000000000000 R11:
00000000ffffffff R12:
0000000000000000
R13:
0000000000000000 R14:
ffff88013377c000 R15:
0000000000000000
FS:
0000000000000000(0000) GS:
ffff8800bf700000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000000000000018 CR3:
0000000001a03000 CR4:
00000000000406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process scsi_eh_4 (pid: 295, threadinfo
ffff880132dee000, task
ffff880133b416c0)
Stack:
0000000000000000 ffff880132defcc0 0000000000000000 ffff880132f42738
ffffffff813ee8f0 ffffffff813eefe0 ffff880132defd98 ffff88013377f190
ffffffffa00b3e30 ffffffff813ef030 0000000032defc60 ffff880100000000
Call Trace:
[<
ffffffff81400867>] sata_pmp_error_handler+0x607/0xc30
[<
ffffffffa00b273f>] ahci_error_handler+0x1f/0x70 [libahci]
[<
ffffffff813faade>] ata_scsi_error+0x5be/0x900
[<
ffffffff813cf724>] scsi_error_handler+0x124/0x650
[<
ffffffff810834b6>] kthread+0x96/0xa0
[<
ffffffff8100cd64>] kernel_thread_helper+0x4/0x10
Code: 8b 95 70 ff ff ff b8 00 00 00 00 48 3b 9a 10 2e 00 00 48 0f 44 c2 48 89 85 70 ff ff ff 48 8b 8d 70 ff ff ff f6 83 69 02 00 00 01 <48> 8b 41 18 0f 85 48 01 00 00 48 85 c9 74 12 48 8b 51 08 48 83
RIP [<
ffffffff813f98e1>] ata_eh_recover+0x9a1/0x1510
RSP <
ffff880132defbf0>
CR2:
0000000000000018
Fix it by testing @link->ap->flags instead.
stable: ATA_FLAG_NO_DIPM was added during 2.6.39 cycle but was
backported to 2.6.37 and 38. This is a fix for that and thus
also applicable to 2.6.37 and 38.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: "Nathan A. Mourey II" <nmoureyii@ne.rr.com>
LKML-Reference: <
1304555277.2059.2.camel@localhost.localdomain>
Cc: Connor H <cmdkhh@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Hugh Dickins [Wed, 11 May 2011 22:13:38 +0000 (15:13 -0700)]
tmpfs: fix spurious ENOSPC when racing with unswap
BugLink: http://bugs.launchpad.net/bugs/788691
commit
59a16ead572330deb38e5848151d30ed1af754bc upstream.
Testing the shmem_swaplist replacements for igrab() revealed another bug:
writes to /dev/loop0 on a tmpfs file which fills its filesystem were
sometimes failing with "Buffer I/O error"s.
These came from ENOSPC failures of shmem_getpage(), when racing with
swapoff: the same could happen when racing with another shmem_getpage(),
pulling the page in from swap in between our find_lock_page() and our
taking the info->lock (though not in the single-threaded loop case).
This is unacceptable, and surprising that I've not noticed it before:
it dates back many years, but (presumably) was made a lot easier to
reproduce in 2.6.36, which sited a page preallocation in the race window.
Fix it by rechecking the page cache before settling on an ENOSPC error.
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Hugh Dickins [Thu, 14 Apr 2011 22:22:07 +0000 (15:22 -0700)]
tmpfs: fix off-by-one in max_blocks checks
BugLink: http://bugs.launchpad.net/bugs/788691
commit
fc5da22ae35d4720be59af8787a8a6d5e4da9517 upstream.
If you fill up a tmpfs, df was showing
tmpfs 460800 - - - /tmp
because of an off-by-one in the max_blocks checks. Fix it so df shows
tmpfs 460800 460800 0 100% /tmp
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Hugh Dickins [Sat, 14 May 2011 19:06:42 +0000 (12:06 -0700)]
tmpfs: fix race between swapoff and writepage
BugLink: http://bugs.launchpad.net/bugs/788691
commit
05bf86b4ccfd0f197da61c67bd372111d15a6620 upstream.
Shame on me! Commit
b1dea800ac39 "tmpfs: fix race between umount and
writepage" fixed the advertized race, but introduced another: as even
its comment makes clear, we cannot safely rely on a peek at list_empty()
while holding no lock - until info->swapped is set, shmem_unuse_inode()
may delete any formerly-swapped inode from the shmem_swaplist, which
in this case would leave a swap area impossible to swapoff.
Although I don't relish taking the mutex every time, I don't care much
for the alternatives either; and at least the peek at list_empty() in
shmem_evict_inode() (a hotter path since most inodes would never have
been swapped) remains safe, because we already truncated the whole file.
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Hugh Dickins [Wed, 11 May 2011 22:13:36 +0000 (15:13 -0700)]
tmpfs: fix race between umount and writepage
BugLink: http://bugs.launchpad.net/bugs/788691
commit
b1dea800ac39599301d4bb8dcf2b1d29c2558211 upstream.
Konstanin Khlebnikov reports that a dangerous race between umount and
shmem_writepage can be reproduced by this script:
for i in {1..300} ; do
mkdir $i
while true ; do
mount -t tmpfs none $i
dd if=/dev/zero of=$i/test bs=1M count=$(($RANDOM % 100))
umount $i
done &
done
on a 6xCPU node with 8Gb RAM: kernel very unstable after this accident. =)
Kernel log:
VFS: Busy inodes after unmount of tmpfs.
Self-destruct in 5 seconds. Have a nice day...
WARNING: at lib/list_debug.c:53 __list_del_entry+0x8d/0x98()
list_del corruption. prev->next should be
ffff880222fdaac8, but was (null)
Pid: 11222, comm: mount.tmpfs Not tainted 2.6.39-rc2+ #4
Call Trace:
warn_slowpath_common+0x80/0x98
warn_slowpath_fmt+0x41/0x43
__list_del_entry+0x8d/0x98
evict+0x50/0x113
iput+0x138/0x141
...
BUG: unable to handle kernel paging request at
ffffffffffffffff
IP: shmem_free_blocks+0x18/0x4c
Pid: 10422, comm: dd Tainted: G W 2.6.39-rc2+ #4
Call Trace:
shmem_recalc_inode+0x61/0x66
shmem_writepage+0xba/0x1dc
pageout+0x13c/0x24c
shrink_page_list+0x28e/0x4be
shrink_inactive_list+0x21f/0x382
...
shmem_writepage() calls igrab() on the inode for the page which came from
page reclaim, to add it later into shmem_swaplist for swapoff operation.
This igrab() can race with super-block deactivating process:
shrink_inactive_list() deactivate_super()
pageout() tmpfs_fs_type->kill_sb()
shmem_writepage() kill_litter_super()
generic_shutdown_super()
evict_inodes()
igrab()
atomic_read(&inode->i_count)
skip-inode
iput()
if (!list_empty(&sb->s_inodes))
printk("VFS: Busy inodes after...
This igrap-iput pair was added in commit
1b1b32f2c6f6 "tmpfs: fix
shmem_swaplist races" based on incorrect assumptions: igrab() protects the
inode from concurrent eviction by deletion, but it does nothing to protect
it from concurrent unmounting, which goes ahead despite the raised
i_count.
So this use of igrab() was wrong all along, but the race made much worse
in 2.6.37 when commit
63997e98a3be "split invalidate_inodes()" replaced
two attempts at invalidate_inodes() by a single evict_inodes().
Konstantin posted a plausible patch, raising sb->s_active too: I'm unsure
whether it was correct or not; but burnt once by igrab(), I am sure that
we don't want to rely more deeply upon externals here.
Fix it by adding the inode to shmem_swaplist earlier, while the page lock
on page in page cache still secures the inode against eviction, without
artifically raising i_count. It was originally added later because
shmem_unuse_inode() is liable to remove an inode from the list while it's
unswapped; but we can guard against that by taking spinlock before
dropping mutex.
Reported-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Hugh Dickins <hughd@google.com>
Tested-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Geert Uytterhoeven [Thu, 12 May 2011 09:11:38 +0000 (09:11 +0000)]
zorro8390: Fix regression caused during net_device_ops conversion
BugLink: http://bugs.launchpad.net/bugs/788691
commit
cf7e032fc87d59c475df26c4d40bf45d401b2adb upstream.
Changeset
b6114794a1c394534659f4a17420e48cf23aa922 ("zorro8390: convert to
net_device_ops") broke zorro8390 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in zorro8390.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.
Fix based on commits
217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390:
fix regression caused during net_device_ops conversion") and
4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with
NET_POLL_CONTROLLER").
Reported-by: Christian T. Steigies <cts@debian.org>
Suggested-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Christian T. Steigies <cts@debian.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Paul Fox [Mon, 9 May 2011 09:40:42 +0000 (10:40 +0100)]
libertas: fix cmdpendingq locking
BugLink: http://bugs.launchpad.net/bugs/788691
commit
2ae1b8b35faba31a59b153cbad07f9c15de99740 upstream.
We occasionally see list corruption using libertas.
While we haven't been able to diagnose this precisely, we have spotted
a possible cause: cmdpendingq is generally modified with driver_lock
held. However, there are a couple of points where this is not the case.
Fix up those operations to execute under the lock, it seems like
the correct thing to do and will hopefully improve the situation.
Signed-off-by: Paul Fox <pgf@laptop.org>
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Anton Blanchard [Tue, 10 May 2011 16:17:10 +0000 (16:17 +0000)]
ehea: Fix memory hotplug oops
BugLink: http://bugs.launchpad.net/bugs/788691
commit
21ccc7936dac5ca9b3e2838bbc112a60f34e18b3 upstream.
The ehea driver oopses during memory hotplug if the ports are not
up. A simple testcase:
# ifconfig ethX down
# echo offline > /sys/devices/system/memory/memory32/state
Oops: Kernel access of bad area, sig: 11 [#1]
last sysfs file: /sys/devices/system/memory/memory32/state
REGS:
c000000709393110 TRAP: 0300 Not tainted (2.6.39-rc2-01385-g7ef73bc-dirty)
DAR:
0000000000000000, DSISR:
40000000
...
NIP [
c000000000067c98] .__wake_up_common+0x48/0xf0
LR [
c00000000006d034] .__wake_up+0x54/0x90
Call Trace:
[
c00000000006d034] .__wake_up+0x54/0x90
[
d000000006bb6270] .ehea_rereg_mrs+0x140/0x730 [ehea]
[
d000000006bb69c4] .ehea_mem_notifier+0x164/0x170 [ehea]
[
c0000000006fc8a8] .notifier_call_chain+0x78/0xf0
[
c0000000000b3d70] .__blocking_notifier_call_chain+0x70/0xb0
[
c000000000458d78] .memory_notify+0x28/0x40
[
c0000000001871d8] .remove_memory+0x208/0x6d0
[
c000000000458264] .memory_section_action+0x94/0x140
[
c0000000004583ec] .memory_block_change_state+0xdc/0x1d0
[
c0000000004585cc] .store_mem_state+0xec/0x160
[
c00000000044768c] .sysdev_store+0x3c/0x50
[
c00000000020b48c] .sysfs_write_file+0xec/0x1f0
[
c00000000018f86c] .vfs_write+0xec/0x1e0
[
c00000000018fa88] .SyS_write+0x58/0xd0
To fix this, initialise the waitqueues during port probe instead
of port open.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Geert Uytterhoeven [Thu, 12 May 2011 09:11:39 +0000 (09:11 +0000)]
hydra: Fix regression caused during net_device_ops conversion
BugLink: http://bugs.launchpad.net/bugs/788691
commit
0b25e0157dfa236a0629c16c8ad6f222f633f682 upstream.
Changeset
5618f0d1193d6b051da9b59b0e32ad24397f06a4 ("hydra: convert to
net_device_ops") broke hydra by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in hydra.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.
Fix based on commits
217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390:
fix regression caused during net_device_ops conversion") and
4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with
NET_POLL_CONTROLLER").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Geert Uytterhoeven [Thu, 12 May 2011 09:11:40 +0000 (09:11 +0000)]
ne-h8300: Fix regression caused during net_device_ops conversion
BugLink: http://bugs.launchpad.net/bugs/788691
commit
2592a7354092afd304a8c067319b15ab1e441e35 upstream.
Changeset
dcd39c90290297f6e6ed8a04bb20da7ac2b043c5 ("ne-h8300: convert to
net_device_ops") broke ne-h8300 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in ne-h8300.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.
Fix based on commits
217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390:
fix regression caused during net_device_ops conversion") and
4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with
NET_POLL_CONTROLLER").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Lars-Peter Clausen [Thu, 5 May 2011 14:59:16 +0000 (16:59 +0200)]
ASoC: SSM2602: Fix 'Mic Boost2' control
BugLink: http://bugs.launchpad.net/bugs/788691
commit
36c90ab33feabbd63da775bd92ad356e5bd5cf56 upstream.
The 'Mic Boost2' control's shift was off by one and thus was not working.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Marek Belisko [Tue, 3 May 2011 12:46:32 +0000 (14:46 +0200)]
ASoC: UDA134x: Remove POWER_OFF_ON_STANDBY define.
BugLink: http://bugs.launchpad.net/bugs/788691
commit
bf707de21fec7bb203dace2d0a2bbd124d1b36ca upstream.
Define POWER_OFF_ON_STANDBY cause trobles when trying to get some
sound from codec because code for bias setup was not compiled
(define wasn't defined). This define was removed in commit:
cc3202f5 but again introduced by commit:
f0fba2ad1 which then
completely break codec functionality so remove it again.
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Oliver Hartkopp [Tue, 10 May 2011 20:12:30 +0000 (13:12 -0700)]
slcan: fix ldisc->open retval
BugLink: http://bugs.launchpad.net/bugs/788691
commit
0d4420a90b51abdea71585f571bad6d789ff8eb7 upstream.
TTY layer expects 0 if the ldisc->open operation succeeded.
Reported-by: Matvejchikov Ilya <matvejchikov@gmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Eric Dumazet [Tue, 10 May 2011 19:26:06 +0000 (12:26 -0700)]
net: dev_close() should check IFF_UP
BugLink: http://bugs.launchpad.net/bugs/788691
commit
e14a599335427f81bbb0008963e59aa9c6449dce upstream.
Commit
443457242beb (factorize sync-rcu call in
unregister_netdevice_many) mistakenly removed one test from dev_close()
Following actions trigger a BUG :
modprobe bonding
modprobe dummy
ifconfig bond0 up
ifenslave bond0 dummy0
rmmod dummy
dev_close() must not close a non IFF_UP device.
With help from Frank Blaschka and Einar EL Lueck
Reported-by: Frank Blaschka <blaschka@linux.vnet.ibm.com>
Reported-by: Einar EL Lueck <ELELUECK@de.ibm.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Tomoya [Mon, 9 May 2011 01:19:37 +0000 (01:19 +0000)]
pch_gbe: support ML7223 IOH
BugLink: http://bugs.launchpad.net/bugs/788691
commit
b0e6baf5619a6fa3eaf43b55fdb4daa362c3c916 upstream.
Support new device OKI SEMICONDUCTOR ML7223 IOH(Input/Output Hub).
The ML7223 IOH is for MP(Media Phone) use.
The ML7223 is companion chip for Intel Atom E6xx series.
The ML7223 is completely compatible for Intel EG20T PCH.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Toshiharu Okada [Fri, 6 May 2011 02:53:56 +0000 (02:53 +0000)]
PCH_GbE : Fixed the issue of checksum judgment
BugLink: http://bugs.launchpad.net/bugs/788691
commit
5d05a04d283061b586e8dc819cfa6f4b8cfd5948 upstream.
The checksum judgment was mistaken.
Judgment result
0:Correct 1:Wrong
This patch fixes the issue.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Toshiharu Okada [Fri, 6 May 2011 02:53:51 +0000 (02:53 +0000)]
PCH_GbE : Fixed the issue of collision detection
BugLink: http://bugs.launchpad.net/bugs/788691
commit
ce3dad0f74e6b240f0b1dedbd8ea268a3f298d82 upstream.
The collision detection setting was invalid.
When collision occurred, because data was not resent,
there was an issue to which a transmitting throughput falls.
This patch enables the collision detection.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Matvejchikov Ilya [Fri, 6 May 2011 06:23:09 +0000 (06:23 +0000)]
NET: slip, fix ldisc->open retval
BugLink: http://bugs.launchpad.net/bugs/788691
commit
057bef938896e6266ae24ec4266d24792d27c29a upstream.
TTY layer expects 0 if the ldisc->open operation succeeded.
Signed-off-by : Matvejchikov Ilya <matvejchikov@gmail.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Kleber Sacilotto de Souza [Wed, 4 May 2011 13:05:11 +0000 (13:05 +0000)]
ehea: fix wrongly reported speed and port
BugLink: http://bugs.launchpad.net/bugs/788691
commit
dcbe14b91a920657ff3a9ba0efb7c5b5562f956a upstream.
Currently EHEA reports to ethtool as supporting 10M, 100M, 1G and
10G and connected to FIBRE independent of the hardware configuration.
However, when connected to FIBRE the only supported speed is 10G
full-duplex, and the other speeds and modes are only supported
when connected to twisted pair.
Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Acked-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>