Fenghua Yu [Mon, 4 Jul 2011 08:36:16 +0000 (08:36 +0000)]
ACPICA: Do not repair _TSS return package if _PSS is present
commit
8f9c91273e36e5762c617c23e4fd48d5172e0dac upstream.
We can only sort the _TSS return package if there is no _PSS
in the same scope. This is because if _PSS is present, the ACPI
specification dictates that the _TSS Power Dissipation field is
to be ignored, and therefore some BIOSs leave garbage values in
the _TSS Power field(s). In this case, it is best to just return
the _TSS package as-is.
Reported-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joerg Roedel [Fri, 2 Sep 2011 12:10:32 +0000 (14:10 +0200)]
iommu/amd: Make sure iommu->need_sync contains correct value
commit
f1ca1512e765337a7c09eb875eedef8ea4e07654 upstream.
The value is only set to true but never set back to false,
which causes to many completion-wait commands to be sent to
hardware. Fix it with this patch.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joerg Roedel [Fri, 2 Sep 2011 12:19:50 +0000 (14:19 +0200)]
iommu/amd: Don't take domain->lock recursivly
commit
e33acde91140f1809952d1c135c36feb66a51887 upstream.
The domain_flush_devices() function takes the domain->lock.
But this function is only called from update_domain() which
itself is already called unter the domain->lock. This causes
a deadlock situation when the dma-address-space of a domain
grows larger than 1GB.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Randy Dunlap [Wed, 22 Jun 2011 03:32:53 +0000 (20:32 -0700)]
irda: fix smsc-ircc2 section mismatch warning
commit
f470e5ae34d68880a38aa79ee5c102ebc2a1aef6 upstream.
Fix section mismatch warning:
WARNING: drivers/net/irda/smsc-ircc2.o(.devinit.text+0x1a7): Section mismatch in reference from the function smsc_ircc_pnp_probe() to the function .init.text:smsc_ircc_open()
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Al Viro [Sat, 23 Jul 2011 06:28:13 +0000 (02:28 -0400)]
9p: close ACL leaks
commit
1ec95bf34d976b38897d1977b155a544d77b05e7 upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Venkateswararao Jujjuri (JV) [Thu, 30 Jun 2011 01:06:33 +0000 (18:06 -0700)]
net/9p: Fix the msize calculation.
commit
c9ffb05ca5b5098d6ea468c909dd384d90da7d54 upstream.
msize represents the maximum PDU size that includes P9_IOHDRSZ.
Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Aneesh Kumar K.V [Wed, 6 Jul 2011 11:02:31 +0000 (16:32 +0530)]
fs/9p: Always ask new inode in create
commit
ed80fcfac2565fa866d93ba14f0e75de17a8223e upstream.
This make sure we don't end up reusing the unlinked inode object.
The ideal way is to use inode i_generation. But i_generation is
not available in userspace always.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Prem Karat [Fri, 6 May 2011 12:54:18 +0000 (18:24 +0530)]
fs/9p: Fix invalid mount options/args
commit
a2dd43bb0d7b9ce28f8a39254c25840c0730498e upstream.
Without this fix, if any invalid mount options/args are passed while mouting
the 9p fs, no error (-EINVAL) is returned and default arg value is assigned.
This fix returns -EINVAL when an invalid arguement is found while parsing
mount options.
Signed-off-by: Prem Karat <prem.karat@linux.vnet.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Aneesh Kumar K.V [Mon, 11 Jul 2011 16:40:59 +0000 (16:40 +0000)]
fs/9p: When doing inode lookup compare qid details and inode mode bits.
commit
fd2421f54423f307ecd31bdebdca6bc317e0c492 upstream.
This make sure we don't use wrong inode from the inode hash. The inode number
of the file deleted is reused by the next file system object created
and if we only use inode number for inode hash lookup we could end up
with wrong struct inode.
Also compare inode generation number. Not all Linux file system provide
st_gen in userspace. So it could be 0;
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Aneesh Kumar K.V [Mon, 11 Jul 2011 16:40:58 +0000 (16:40 +0000)]
fs/9p: Fid is not valid after a failed clunk.
commit
5034990e28efb2d232ee82443a9edd62defd17ba upstream.
free the fid even in case of failed clunk.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
jvrao [Thu, 30 Jun 2011 23:18:41 +0000 (23:18 +0000)]
VirtIO can transfer VIRTQUEUE_NUM of pages.
commit
7f781679dd596c8abde8336b4d0d166d6a4aad04 upstream.
Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
jvrao [Thu, 30 Jun 2011 23:18:39 +0000 (23:18 +0000)]
Fix the size of receive buffer packing onto VirtIO ring.
commit
114e6f3a5ede73d5b56e145f04680c61c3dd67c4 upstream.
Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Van Hensbergen [Thu, 14 Jul 2011 00:12:18 +0000 (19:12 -0500)]
net/9p: fix client code to fail more gracefully on protocol error
commit
b85f7d92d7bd7e3298159e8b1eed8cb8cbbb0348 upstream.
There was a BUG_ON to protect against a bad id which could be dealt with
more gracefully.
Reported-by: Natalie Orlin <norlin@us.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Florian Mickler [Wed, 10 Aug 2011 10:05:20 +0000 (07:05 -0300)]
vp7045: fix buffer setup
commit
fc61ccd35fd59d5362d37c8bf9c0526c85086c84 upstream.
dvb_usb_device_init calls the frontend_attach method of this driver which
uses vp7045_usb_ob. In order to have a buffer ready in vp7045_usb_op, it has to
be allocated before that happens.
Luckily we can use the whole private data as the buffer as it gets separately
allocated on the heap via kzalloc in dvb_usb_device_init and is thus apt for
use via usb_control_msg.
This fixes a
BUG: unable to handle kernel paging request at
0000000000001e78
reported by Tino Keitel and diagnosed by Dan Carpenter.
Tested-by: Tino Keitel <tino.keitel@tikei.de>
Signed-off-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jarod Wilson [Mon, 8 Aug 2011 20:20:40 +0000 (17:20 -0300)]
nuvoton-cir: simplify raw IR sample handling
commit
de4ed0c111ed078b8729a5cc49c23197740f5bad upstream.
The nuvoton-cir driver was storing up consecutive pulse-pulse and
space-space samples internally, for no good reason, since
ir_raw_event_store_with_filter() already merges back to back like
samples types for us. This should also fix a regression introduced late
in 3.0 that related to a timeout change, which actually becomes correct
when coupled with this change. Tested with RC6 and RC5 on my own
nuvoton-cir hardware atop vanilla 3.0.0, after verifying quirky
behavior in 3.0 due to the timeout change.
Reported-by: Stephan Raue <sraue@openelec.tv>
CC: Stephan Raue <sraue@openelec.tv>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NeilBrown [Sat, 10 Sep 2011 07:21:28 +0000 (17:21 +1000)]
md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.
commit
27a7b260f71439c40546b43588448faac01adb93 upstream.
0.90 metadata uses an unsigned 32bit number to count the number of
kilobytes used from each device.
This should allow up to 4TB per device.
However we multiply this by 2 (to get sectors) before casting to a
larger type, so sizes above 2TB get truncated.
Also we allow rdev->sectors to be larger than 4TB, so it is possible
for the array to be resized larger than the metadata can handle.
So make sure rdev->sectors never exceeds 4TB when 0.90 metadata is in
used.
Also the sanity check at the end of super_90_load should include level
1 as it used ->size too. (RAID0 and Linear don't use ->size at all).
Reported-by: Pim Zandbergen <P.Zandbergen@macroscoop.nl>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NeilBrown [Sat, 10 Sep 2011 07:20:21 +0000 (17:20 +1000)]
Avoid dereferencing a 'request_queue' after last close.
commit
94007751bb02797ba87bac7aacee2731ac2039a3 upstream.
On the last close of an 'md' device which as been stopped, the device
is destroyed and in particular the request_queue is freed. The free
is done in a separate thread so it might happen a short time later.
__blkdev_put calls bdev_inode_switch_bdi *after* ->release has been
called.
Since commit
f758eeabeb96f878c860e8f110f94ec8820822a9
bdev_inode_switch_bdi will dereference the 'old' bdi, which lives
inside a request_queue, to get a spin lock. This causes the last
close on an md device to sometime take a spin_lock which lives in
freed memory - which results in an oops.
So move the called to bdev_inode_switch_bdi before the call to
->release.
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Acked-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marcin Slusarz [Mon, 22 Aug 2011 21:14:05 +0000 (23:14 +0200)]
drm/nouveau: properly handle allocation failure in nouveau_sgdma_populate
commit
17c8b960930da3599e47801a54ac0ea1070545d2 upstream.
Not cleaning after alloc failure would result in crash on destroy,
because nouveau_sgdma_clear assumes "ttm_alloced" to be not null when
"pages" is not null.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Walleij [Tue, 2 Aug 2011 15:48:38 +0000 (17:48 +0200)]
ARM: davinci: fix cache flush build error
commit
897a6a1a14837d6d582bfd1fd7aba00be44b6469 upstream.
The TNET variant of DaVinci compiles some code that it shares
with other DaVinci variants, however it has a V6 CPU rather than
an ARM926T, thus the hardcoded call to arm926_flush_kern_cache_all()
in sleep.S will obviously fail, and we need to build with the
v6_flush_kern_cache_all() call instead. This was triggered by
manually altering the DaVinci config to build the TNET version.
Cc: Dave Martin <dave.martin@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sudhakar Rajashekhara [Tue, 12 Jul 2011 10:28:53 +0000 (15:58 +0530)]
ARM: davinci: da850 EVM: read mac address from SPI flash
commit
810198bc9c109489dfadc57131c5183ce6ad2d7d upstream.
DA850/OMAP-L138 EMAC driver uses random mac address instead of
a fixed one because the mac address is not stuffed into EMAC
platform data.
This patch provides a function which reads the mac address
stored in SPI flash (registered as MTD device) and populates the
EMAC platform data. The function which reads the mac address is
registered as a callback which gets called upon addition of MTD
device.
NOTE: In case the MAC address stored in SPI flash is erased, follow
the instructions at [1] to restore it.
[1] http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash
Modifications in v2:
Guarded registering the mtd_notifier only when MTD is enabled.
Earlier this was handled using mtd_has_partitions() call, but
this has been removed in Linux v3.0.
Modifications in v3:
a. Guarded da850_evm_m25p80_notify_add() function and
da850evm_spi_notifier structure with CONFIG_MTD macros.
b. Renamed da850_evm_register_mtd_user() function to
da850_evm_setup_mac_addr() and removed the struct mtd_notifier
argument to this function.
c. Passed the da850evm_spi_notifier structure to register_mtd_user()
function.
Modifications in v4:
Moved the da850_evm_setup_mac_addr() function within the first
CONFIG_MTD ifdef construct.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Walleij [Tue, 6 Sep 2011 07:08:13 +0000 (08:08 +0100)]
ARM: 7081/1: mach-integrator: fix the clocksource
commit
bb9ea77846620ed2b37e74c852d72c7a476b248c upstream.
I was intrigued by the fact that the clock stood still on
the Integrator, but it wasn't strange at all, because the
timer was set up all wrong and probably has been for a
while. With this patch the clock starts ticking again:
make the timer periodic (reload), |= on the divisor bit
and load the timer before starting it.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Guenter Roeck [Sun, 28 Aug 2011 20:01:49 +0000 (13:01 -0700)]
hwmon: (max16065) Fix current calculation
commit
ff71c182f461da5ae9d2d65f8a63f5a9193b9be1 upstream.
Current calculation is completely wrong. Add missing brackets to fix it.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Konrad Rzeszutek Wilk [Thu, 1 Sep 2011 13:48:27 +0000 (09:48 -0400)]
xen/smp: Warn user why they keel over - nosmp or noapic and what to use instead.
commit
ed467e69f16e6b480e2face7bc5963834d025f91 upstream.
We have hit a couple of customer bugs where they would like to
use those parameters to run an UP kernel - but both of those
options turn of important sources of interrupt information so
we end up not being able to boot. The correct way is to
pass in 'dom0_max_vcpus=1' on the Xen hypervisor line and
the kernel will patch itself to be a UP kernel.
Fixes bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637308
Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Igor Mammedov [Thu, 1 Sep 2011 11:46:55 +0000 (13:46 +0200)]
xen: x86_32: do not enable iterrupts when returning from exception in interrupt context
commit
d198d499148a0c64a41b3aba9e7dd43772832b91 upstream.
If vmalloc page_fault happens inside of interrupt handler with interrupts
disabled then on exit path from exception handler when there is no pending
interrupts, the following code (arch/x86/xen/xen-asm_32.S:112):
cmpw $0x0001, XEN_vcpu_info_pending(%eax)
sete XEN_vcpu_info_mask(%eax)
will enable interrupts even if they has been previously disabled according to
eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99)
testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp)
setz XEN_vcpu_info_mask(%eax)
Solution is in setting XEN_vcpu_info_mask only when it should be set
according to
cmpw $0x0001, XEN_vcpu_info_pending(%eax)
but not clearing it if there isn't any pending events.
Reproducer for bug is attached to RHBZ 707552
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Girish K S [Fri, 26 Aug 2011 09:28:18 +0000 (14:58 +0530)]
mmc: sdhci-s3c: Fix mmc card I/O problem
commit
49bb1e619568ec84785ceb366f07db2a6f0b64cc upstream.
This patch fixes the problem in sdhci-s3c host driver for Samsung Soc's.
During the card identification stage the mmc core driver enumerates for
the best bus width in combination with the highest available data rate.
It starts enumerating from the highest bus width (8) to lowest width (1).
In case of few MMC cards the 4-bit bus enumeration fails and tries
the 1-bit bus enumeration. When switched to 1-bit bus mode the host driver
has to clear the previous bus width setting and apply the new setting.
The current patch will clear the previous bus mode and apply the new
mode setting.
Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mika Westerberg [Thu, 18 Aug 2011 12:23:49 +0000 (15:23 +0300)]
mmc: core: use non-reentrant workqueue for clock gating
commit
50a50f9248497484c678631a9c1a719f1aaeab79 upstream.
The default multithread workqueue can cause the same work to be executed
concurrently on a different CPUs. This isn't really suitable for clock
gating as it might already gated the clock and gating it twice results both
host->clk_old and host->ios.clock to be set to 0.
To prevent this from happening we use system_nrt_wq instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mika Westerberg [Thu, 18 Aug 2011 12:23:48 +0000 (15:23 +0300)]
mmc: core: prevent aggressive clock gating racing with ios updates
commit
778e277cb82411c9002ca28ccbd216c4d9eb9158 upstream.
We have seen at least two different races when clock gating kicks in in a
middle of ios structure update.
First one happens when ios->clock is changed outside of aggressive clock
gating framework, for example via mmc_set_clock(). The race might happen
when we run following code:
mmc_set_ios():
...
if (ios->clock > 0)
mmc_set_ungated(host);
Now if gating kicks in right after the condition check we end up setting
host->clk_gated to false even though we have just gated the clock. Next
time a request is started we try to ungate and restore the clock in
mmc_host_clk_hold(). However since we have host->clk_gated set to false the
original clock is not restored.
This eventually will cause the host controller to hang since its clock is
disabled while we are trying to issue a request. For example on Intel
Medfield platform we see:
[ 13.818610] mmc2: Timeout waiting for hardware interrupt.
[ 13.818698] sdhci: =========== REGISTER DUMP (mmc2)===========
[ 13.818753] sdhci: Sys addr: 0x00000000 | Version: 0x00008901
[ 13.818804] sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
[ 13.818853] sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[ 13.818903] sdhci: Present: 0x1fff0000 | Host ctl: 0x00000001
[ 13.818951] sdhci: Power: 0x0000000d | Blk gap: 0x00000000
[ 13.819000] sdhci: Wake-up: 0x00000000 | Clock: 0x00000000
[ 13.819049] sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
[ 13.819098] sdhci: Int enab: 0x00ff00c3 | Sig enab: 0x00ff00c3
[ 13.819147] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[ 13.819196] sdhci: Caps: 0x6bee32b2 | Caps_1: 0x00000000
[ 13.819245] sdhci: Cmd: 0x00000000 | Max curr: 0x00000000
[ 13.819292] sdhci: Host ctl2: 0x00000000
[ 13.819331] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
[ 13.819377] sdhci: ===========================================
[ 13.919605] mmc2: Reset 0x2 never completed.
and it never recovers.
Second race might happen while running mmc_power_off():
static void mmc_power_off(struct mmc_host *host)
{
host->ios.clock = 0;
host->ios.vdd = 0;
[ clock gating kicks in here ]
/*
* Reset ocr mask to be the highest possible voltage supported for
* this mmc host. This value will be used at next power up.
*/
host->ocr = 1 << (fls(host->ocr_avail) - 1);
if (!mmc_host_is_spi(host)) {
host->ios.bus_mode = MMC_BUSMODE_OPENDRAIN;
host->ios.chip_select = MMC_CS_DONTCARE;
}
host->ios.power_mode = MMC_POWER_OFF;
host->ios.bus_width = MMC_BUS_WIDTH_1;
host->ios.timing = MMC_TIMING_LEGACY;
mmc_set_ios(host);
}
If the clock gating worker kicks in while we are only partially updated the
ios structure the host controller gets incomplete ios and might not work as
supposed. Again on Intel Medfield platform we get:
[ 4.185349] kernel BUG at drivers/mmc/host/sdhci.c:1155!
[ 4.185422] invalid opcode: 0000 [#1] PREEMPT SMP
[ 4.185509] Modules linked in:
[ 4.185565]
[ 4.185608] Pid: 4, comm: kworker/0:0 Not tainted 3.0.0+ #240 Intel Corporation Medfield/iCDKA
[ 4.185742] EIP: 0060:[<
c136364e>] EFLAGS:
00010083 CPU: 0
[ 4.185827] EIP is at sdhci_set_power+0x3e/0xd0
[ 4.185891] EAX:
f5ff98e0 EBX:
f5ff98e0 ECX:
00000000 EDX:
00000001
[ 4.185970] ESI:
f5ff977c EDI:
f5ff9904 EBP:
f644fe98 ESP:
f644fe94
[ 4.186049] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 4.186125] Process kworker/0:0 (pid: 4, ti=
f644e000 task=
f644c0e0 task.ti=
f644e000)
[ 4.186219] Stack:
[ 4.186257]
f5ff98e0 f644feb0 c1365173 00000282 f5ff9460 f5ff96e0 f5ff96e0 f644feec
[ 4.186418]
c1355bd8 f644c0e0 c1499c3d f5ff96e0 f644fed4 00000006 f5ff96e0 00000286
[ 4.186579]
f644fedc c107922b f644feec 00000286 f5ff9460 f5ff9700 f644ff10 c135839e
[ 4.186739] Call Trace:
[ 4.186802] [<
c1365173>] sdhci_set_ios+0x1c3/0x340
[ 4.186883] [<
c1355bd8>] mmc_gate_clock+0x68/0x120
[ 4.186963] [<
c1499c3d>] ? _raw_spin_unlock_irqrestore+0x4d/0x60
[ 4.187052] [<
c107922b>] ? trace_hardirqs_on+0xb/0x10
[ 4.187134] [<
c135839e>] mmc_host_clk_gate_delayed+0xbe/0x130
[ 4.187219] [<
c105ec09>] ? process_one_work+0xf9/0x5b0
[ 4.187300] [<
c135841d>] mmc_host_clk_gate_work+0xd/0x10
[ 4.187379] [<
c105ec82>] process_one_work+0x172/0x5b0
[ 4.187457] [<
c105ec09>] ? process_one_work+0xf9/0x5b0
[ 4.187538] [<
c1358410>] ? mmc_host_clk_gate_delayed+0x130/0x130
[ 4.187625] [<
c105f3c8>] worker_thread+0x118/0x330
[ 4.187700] [<
c1496cee>] ? preempt_schedule+0x2e/0x50
[ 4.187779] [<
c105f2b0>] ? rescuer_thread+0x1f0/0x1f0
[ 4.187857] [<
c1062cf4>] kthread+0x74/0x80
[ 4.187931] [<
c1062c80>] ? __init_kthread_worker+0x60/0x60
[ 4.188015] [<
c149acfa>] kernel_thread_helper+0x6/0xd
[ 4.188079] Code: 81 fa 00 00 04 00 0f 84 a7 00 00 00 7f 21 81 fa 80 00 00 00 0f 84 92 00 00 00 81 fa 00 00 0
[ 4.188780] EIP: [<
c136364e>] sdhci_set_power+0x3e/0xd0 SS:ESP 0068:
f644fe94
[ 4.188898] ---[ end trace
a7b23eecc71777e4 ]---
This BUG() comes from the fact that ios.power_mode was still in previous
value (MMC_POWER_ON) and ios.vdd was set to zero.
We prevent these by inhibiting the clock gating while we update the ios
structure.
Both problems can be reproduced by simply running the device in a reboot
loop.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mika Westerberg [Thu, 18 Aug 2011 12:23:47 +0000 (15:23 +0300)]
mmc: rename mmc_host_clk_{ungate|gate} to mmc_host_clk_{hold|release}
commit
08c14071fda4e69abb9d5b1566651cd092b158d3 upstream.
As per suggestion by Linus Walleij:
> If you think the names of the functions are confusing then
> you may rename them, say like this:
>
> mmc_host_clk_ungate() -> mmc_host_clk_hold()
> mmc_host_clk_gate() -> mmc_host_clk_release()
>
> Which would make the usecases more clear
(This is CC'd to stable@ because the next two patches, which fix
observable races, depend on it.)
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrey Vagin [Tue, 30 Aug 2011 08:32:36 +0000 (12:32 +0400)]
x86, perf: Check that current->mm is alive before getting user callchain
commit
20afc60f892d285fde179ead4b24e6a7938c2f1b upstream.
An event may occur when an mm is already released.
I added an event in dequeue_entity() and caught a panic with
the following backtrace:
[ 434.421110] BUG: unable to handle kernel NULL pointer dereference at
0000000000000050
[ 434.421258] IP: [<
ffffffff810464ac>] __get_user_pages_fast+0x9c/0x120
...
[ 434.421258] Call Trace:
[ 434.421258] [<
ffffffff8101ae81>] copy_from_user_nmi+0x51/0xf0
[ 434.421258] [<
ffffffff8109a0d5>] ? sched_clock_local+0x25/0x90
[ 434.421258] [<
ffffffff8101b048>] perf_callchain_user+0x128/0x170
[ 434.421258] [<
ffffffff811154cd>] ? __perf_event_header__init_id+0xed/0x100
[ 434.421258] [<
ffffffff81116690>] perf_prepare_sample+0x200/0x280
[ 434.421258] [<
ffffffff81118da8>] __perf_event_overflow+0x1b8/0x290
[ 434.421258] [<
ffffffff81065240>] ? tg_shares_up+0x0/0x670
[ 434.421258] [<
ffffffff8104fe1a>] ? walk_tg_tree+0x6a/0xb0
[ 434.421258] [<
ffffffff81118f44>] perf_swevent_overflow+0xc4/0xf0
[ 434.421258] [<
ffffffff81119150>] do_perf_sw_event+0x1e0/0x250
[ 434.421258] [<
ffffffff81119204>] perf_tp_event+0x44/0x70
[ 434.421258] [<
ffffffff8105701f>] ftrace_profile_sched_block+0xdf/0x110
[ 434.421258] [<
ffffffff8106121d>] dequeue_entity+0x2ad/0x2d0
[ 434.421258] [<
ffffffff810614ec>] dequeue_task_fair+0x1c/0x60
[ 434.421258] [<
ffffffff8105818a>] dequeue_task+0x9a/0xb0
[ 434.421258] [<
ffffffff810581e2>] deactivate_task+0x42/0xe0
[ 434.421258] [<
ffffffff814bc019>] thread_return+0x191/0x808
[ 434.421258] [<
ffffffff81098a44>] ? switch_task_namespaces+0x24/0x60
[ 434.421258] [<
ffffffff8106f4c4>] do_exit+0x464/0x910
[ 434.421258] [<
ffffffff8106f9c8>] do_group_exit+0x58/0xd0
[ 434.421258] [<
ffffffff8106fa57>] sys_exit_group+0x17/0x20
[ 434.421258] [<
ffffffff8100b202>] system_call_fastpath+0x16/0x1b
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1314693156-24131-1-git-send-email-avagin@openvz.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
WANG Cong [Thu, 18 Aug 2011 12:36:57 +0000 (20:36 +0800)]
sched: Fix a memory leak in __sdt_free()
commit
feff8fa0075bdfd43c841e9d689ed81adda988d6 upstream.
This patch fixes the following memory leak:
unreferenced object 0xffff880107266800 (size 512):
comm "sched-powersave", pid 3718, jiffies
4323097853 (age 27495.450s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
ffffffff81133940>] create_object+0x187/0x28b
[<
ffffffff814ac103>] kmemleak_alloc+0x73/0x98
[<
ffffffff811232ba>] __kmalloc_node+0x104/0x159
[<
ffffffff81044b98>] kzalloc_node.clone.97+0x15/0x17
[<
ffffffff8104cb90>] build_sched_domains+0xb7/0x7f3
[<
ffffffff8104d4df>] partition_sched_domains+0x1db/0x24a
[<
ffffffff8109ee4a>] do_rebuild_sched_domains+0x3b/0x47
[<
ffffffff810a00c7>] rebuild_sched_domains+0x10/0x12
[<
ffffffff8104d5ba>] sched_power_savings_store+0x6c/0x7b
[<
ffffffff8104d5df>] sched_mc_power_savings_store+0x16/0x18
[<
ffffffff8131322c>] sysdev_class_store+0x20/0x22
[<
ffffffff81193876>] sysfs_write_file+0x108/0x144
[<
ffffffff81135b10>] vfs_write+0xaf/0x102
[<
ffffffff81135d23>] sys_write+0x4d/0x74
[<
ffffffff814c8a42>] system_call_fastpath+0x16/0x1b
[<
ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: WANG Cong <amwang@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1313671017-4112-1-git-send-email-amwang@redhat.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Wed, 22 Jun 2011 17:47:01 +0000 (19:47 +0200)]
sched: Move blk_schedule_flush_plug() out of __schedule()
commit
9c40cef2b799f9b5e7fa5de4d2ad3a0168ba118c upstream.
There is no real reason to run blk_schedule_flush_plug() with
interrupts and preemption disabled.
Move it into schedule() and call it when the task is going voluntarily
to sleep. There might be false positives when the task is woken
between that call and actually scheduling, but that's not really
different from being woken immediately after switching away.
This fixes a deadlock in the scheduler where the
blk_schedule_flush_plug() callchain enables interrupts and thereby
allows a wakeup to happen of the task that's going to sleep.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/n/tip-dwfxtra7yg1b5r65m32ywtct@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Wed, 22 Jun 2011 17:47:00 +0000 (19:47 +0200)]
sched: Separate the scheduler entry for preemption
commit
c259e01a1ec90063042f758e409cd26b2a0963c8 upstream.
Block-IO and workqueues call into notifier functions from the
scheduler core code with interrupts and preemption disabled. These
calls should be made before entering the scheduler core.
To simplify this, separate the scheduler core code into
__schedule(). __schedule() is directly called from the places which
set PREEMPT_ACTIVE and from schedule(). This allows us to add the work
checks into schedule(), so they are only called when a task voluntary
goes to sleep.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20110622174918.813258321@linutronix.de
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
John Stultz [Fri, 22 Jul 2011 09:12:51 +0000 (09:12 +0000)]
rtc: Fix RTC PIE frequency limit
commit
938f97bcf1bdd1b681d5d14d1d7117a2e22d4434 upstream.
Thomas earlier submitted a fix to limit the RTC PIE freq, but
picked 5000Hz out of the air. Willy noticed that we should
instead use the 8192Hz max from the rtc man documentation.
Cc: Willy Tarreau <w@1wt.eu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
John Stultz [Wed, 10 Aug 2011 17:26:09 +0000 (10:26 -0700)]
alarmtimers: Avoid possible denial of service with high freq periodic timers
commit
6af7e471e5a7746b8024d70b4363d3dfe41d36b8 upstream.
Its possible to jam up the alarm timers by setting very small interval
timers, which will cause the alarmtimer subsystem to spend all of its time
firing and restarting timers. This can effectivly lock up a box.
A deeper fix is needed, closely mimicking the hrtimer code, but for now
just cap the interval to 100us to avoid userland hanging the system.
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
John Stultz [Thu, 4 Aug 2011 14:51:56 +0000 (07:51 -0700)]
alarmtimers: Memset itimerspec passed into alarm_timer_get
commit
ea7802f630d356acaf66b3c0b28c00a945fc35dc upstream.
Following common_timer_get, zero out the itimerspec passed in.
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
John Stultz [Thu, 4 Aug 2011 14:25:35 +0000 (07:25 -0700)]
alarmtimers: Avoid possible null pointer traversal
commit
971c90bfa2f0b4fe52d6d9002178d547706f1343 upstream.
We don't check if old_setting is non null before assigning it, so
correct this.
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Troy Kisky [Fri, 24 Jun 2011 17:52:56 +0000 (10:52 -0700)]
MXC: iomux-v3: correct NO_PAD_CTRL definition
commit
425933b30b0ccfac58065bca6c853ea627443cdf upstream.
iomux-v3.c uses NO_PAD_CTRL as a 32 bit value
so it should not be shifted left by MUX_PAD_CTRL_SHIFT(41)
Previously, anything requesting NO_PAD_CTRL would get
their pad control register set to 0.
Since it is a pad control mask, place it with the other mask values.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Acked-by: Lothar Waßmann <LW@KARO-electronics.de>
Tested-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Carolyn Wyborny [Thu, 7 Jul 2011 00:24:56 +0000 (00:24 +0000)]
igb: fix WOL on second port of i350 device
commit
6d337dce664b6872ddf1655f6b1fcab76ce35b08 upstream.
This patch fixes a problem where WOL would fail on second port of i350
device.
Reported-by: Martin Wilck <martin.wilck@ts.fujitsu.com>
Reported-by: Stefan Assmann<sassmann@redhat.com>
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mel Gorman [Tue, 26 Jul 2011 00:12:30 +0000 (17:12 -0700)]
mm: page allocator: reconsider zones for allocation after direct reclaim
commit
76d3fbf8fbf6cc78ceb63549e0e0c5bc8a88f838 upstream.
With zone_reclaim_mode enabled, it's possible for zones to be considered
full in the zonelist_cache so they are skipped in the future. If the
process enters direct reclaim, the ZLC may still consider zones to be full
even after reclaiming pages. Reconsider all zones for allocation if
direct reclaim returns successfully.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Stefan Priebe <s.priebe@profihost.ag>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mel Gorman [Tue, 26 Jul 2011 00:12:29 +0000 (17:12 -0700)]
mm: page allocator: initialise ZLC for first zone eligible for zone_reclaim
commit
cd38b115d5ad79b0100ac6daa103c4fe2c50a913 upstream.
There have been a small number of complaints about significant stalls
while copying large amounts of data on NUMA machines reported on a
distribution bugzilla. In these cases, zone_reclaim was enabled by
default due to large NUMA distances. In general, the complaints have not
been about the workload itself unless it was a file server (in which case
the recommendation was disable zone_reclaim).
The stalls are mostly due to significant amounts of time spent scanning
the preferred zone for pages to free. After a failure, it might fallback
to another node (as zonelists are often node-ordered rather than
zone-ordered) but stall quickly again when the next allocation attempt
occurs. In bad cases, each page allocated results in a full scan of the
preferred zone.
Patch 1 checks the preferred zone for recent allocation failure
which is particularly important if zone_reclaim has failed
recently. This avoids rescanning the zone in the near future and
instead falling back to another node. This may hurt node locality
in some cases but a failure to zone_reclaim is more expensive than
a remote access.
Patch 2 clears the zlc information after direct reclaim.
Otherwise, zone_reclaim can mark zones full, direct reclaim can
reclaim enough pages but the zone is still not considered for
allocation.
This was tested on a 24-thread 2-node x86_64 machine. The tests were
focused on large amounts of IO. All tests were bound to the CPUs on
node-0 to avoid disturbances due to processes being scheduled on different
nodes. The kernels tested are
3.0-rc6-vanilla Vanilla 3.0-rc6
zlcfirst Patch 1 applied
zlcreconsider Patches 1+2 applied
FS-Mark
./fs_mark -d /tmp/fsmark-10813 -D 100 -N 5000 -n 208 -L 35 -t 24 -S0 -s 524288
fsmark-3.0-rc6 3.0-rc6 3.0-rc6
vanilla zlcfirs zlcreconsider
Files/s min 54.90 ( 0.00%) 49.80 (-10.24%) 49.10 (-11.81%)
Files/s mean 100.11 ( 0.00%) 135.17 (25.94%) 146.93 (31.87%)
Files/s stddev 57.51 ( 0.00%) 138.97 (58.62%) 158.69 (63.76%)
Files/s max 361.10 ( 0.00%) 834.40 (56.72%) 802.40 (55.00%)
Overhead min 76704.00 ( 0.00%) 76501.00 ( 0.27%) 77784.00 (-1.39%)
Overhead mean
1485356.51 ( 0.00%)
1035797.83 (43.40%)
1594680.26 (-6.86%)
Overhead stddev
1848122.53 ( 0.00%) 881489.88 (109.66%)
1772354.90 ( 4.27%)
Overhead max
7989060.00 ( 0.00%)
3369118.00 (137.13%)
10135324.00 (-21.18%)
MMTests Statistics: duration
User/Sys Time Running Test (seconds) 501.49 493.91 499.93
Total Elapsed Time (seconds) 2451.57 2257.48 2215.92
MMTests Statistics: vmstat
Page Ins 46268 63840 66008
Page Outs
90821596 90671128 88043732
Swap Ins 0 0 0
Swap Outs 0 0 0
Direct pages scanned
13091697 8966863 8971790
Kswapd pages scanned 0
1830011 1831116
Kswapd pages reclaimed 0
1829068 1829930
Direct pages reclaimed
13037777 8956828 8648314
Kswapd efficiency 100% 99% 99%
Kswapd velocity 0.000 810.643 826.346
Direct efficiency 99% 99% 96%
Direct velocity 5340.128 3972.068 4048.788
Percentage direct scans 100% 83% 83%
Page writes by reclaim 0 3 0
Slabs scanned 796672 720640 720256
Direct inode steals
7422667 7160012 7088638
Kswapd inode steals 0
1736840 2021238
Test completes far faster with a large increase in the number of files
created per second. Standard deviation is high as a small number of
iterations were much higher than the mean. The number of pages scanned by
zone_reclaim is reduced and kswapd is used for more work.
LARGE DD
3.0-rc6 3.0-rc6 3.0-rc6
vanilla zlcfirst zlcreconsider
download tar 59 ( 0.00%) 59 ( 0.00%) 55 ( 7.27%)
dd source files 527 ( 0.00%) 296 (78.04%) 320 (64.69%)
delete source 36 ( 0.00%) 19 (89.47%) 20 (80.00%)
MMTests Statistics: duration
User/Sys Time Running Test (seconds) 125.03 118.98 122.01
Total Elapsed Time (seconds) 624.56 375.02 398.06
MMTests Statistics: vmstat
Page Ins
3594216 439368 407032
Page Outs
23380832 23380488 23377444
Swap Ins 0 0 0
Swap Outs 0 436 287
Direct pages scanned
17482342 69315973 82864918
Kswapd pages scanned 0 519123 575425
Kswapd pages reclaimed 0 466501 522487
Direct pages reclaimed
5858054 2732949 2712547
Kswapd efficiency 100% 89% 90%
Kswapd velocity 0.000 1384.254 1445.574
Direct efficiency 33% 3% 3%
Direct velocity 27991.453 184832.737 208171.929
Percentage direct scans 100% 99% 99%
Page writes by reclaim 0 5082 13917
Slabs scanned 17280 29952 35328
Direct inode steals 115257
1431122 332201
Kswapd inode steals 0 0 979532
This test downloads a large tarfile and copies it with dd a number of
times - similar to the most recent bug report I've dealt with. Time to
completion is reduced. The number of pages scanned directly is still
disturbingly high with a low efficiency but this is likely due to the
number of dirty pages encountered. The figures could probably be improved
with more work around how kswapd is used and how dirty pages are handled
but that is separate work and this result is significant on its own.
Streaming Mapped Writer
MMTests Statistics: duration
User/Sys Time Running Test (seconds) 124.47 111.67 112.64
Total Elapsed Time (seconds) 2138.14 1816.30 1867.56
MMTests Statistics: vmstat
Page Ins 90760 89124 89516
Page Outs
121028340 120199524 120736696
Swap Ins 0 86 55
Swap Outs 0 0 0
Direct pages scanned
114989363 96461439 96330619
Kswapd pages scanned
56430948 56965763 57075875
Kswapd pages reclaimed
27743219 27752044 27766606
Direct pages reclaimed 49777 46884 36655
Kswapd efficiency 49% 48% 48%
Kswapd velocity 26392.541 31363.631 30561.736
Direct efficiency 0% 0% 0%
Direct velocity 53780.091 53108.759 51581.004
Percentage direct scans 67% 62% 62%
Page writes by reclaim 385 122 1513
Slabs scanned 43008 39040 42112
Direct inode steals 0 10 8
Kswapd inode steals 733 534 477
This test just creates a large file mapping and writes to it linearly.
Time to completion is again reduced.
The gains are mostly down to two things. In many cases, there is less
scanning as zone_reclaim simply gives up faster due to recent failures.
The second reason is that memory is used more efficiently. Instead of
scanning the preferred zone every time, the allocator falls back to
another zone and uses it instead improving overall memory utilisation.
This patch: initialise ZLC for first zone eligible for zone_reclaim.
The zonelist cache (ZLC) is used among other things to record if
zone_reclaim() failed for a particular zone recently. The intention is to
avoid a high cost scanning extremely long zonelists or scanning within the
zone uselessly.
Currently the zonelist cache is setup only after the first zone has been
considered and zone_reclaim() has been called. The objective was to avoid
a costly setup but zone_reclaim is itself quite expensive. If it is
failing regularly such as the first eligible zone having mostly mapped
pages, the cost in scanning and allocation stalls is far higher than the
ZLC initialisation step.
This patch initialises ZLC before the first eligible zone calls
zone_reclaim(). Once initialised, it is checked whether the zone failed
zone_reclaim recently. If it has, the zone is skipped. As the first zone
is now being checked, additional care has to be taken about zones marked
full. A zone can be marked "full" because it should not have enough
unmapped pages for zone_reclaim but this is excessive as direct reclaim or
kswapd may succeed where zone_reclaim fails. Only mark zones "full" after
zone_reclaim fails if it failed to reclaim enough pages after scanning.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Stefan Priebe <s.priebe@profihost.ag>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Thu, 1 Sep 2011 17:46:15 +0000 (17:46 +0000)]
drm/radeon/kms: make sure pci max read request size is valid on evergreen+ (v2)
commit
d054ac16eeb658bccadb06b12c39cee22243b10f upstream.
If the bios or OS sets the pci max read request size to 0 or an
invalid value (6,7), it can result in a hang or slowdown. Check
and set it to something sane if it's invalid.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=42162
v2: use pci reg defines from include/linux/pci_regs.h
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Airlie [Tue, 30 Aug 2011 19:22:04 +0000 (20:22 +0100)]
drm/radeon/kms: set a default max_pixel_clock
commit
9adceaa5b3d2480e2252c4a7f9c4bd7d66b8c4a2 upstream.
On some Power rv100 cards, we have no ATY OF table, but we have
no combios table either, and hence we refuse all modes on VGA-0
since we end up with a 0 max pixel clock.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NeilBrown [Thu, 25 Aug 2011 04:43:53 +0000 (14:43 +1000)]
md/linear: avoid corrupting structure while waiting for rcu_free to complete.
commit
1b6afa17581027218088a18a9ceda600e0ddba7a upstream.
I don't know what I was thinking putting 'rcu' after a dynamically
sized array! The array could still be in use when we call rcu_free()
(That is the point) so we mustn't corrupt it.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Srinivas Kandagatla [Mon, 15 Aug 2011 09:43:44 +0000 (10:43 +0100)]
ARM: 7014/1: cache-l2x0: Fix L2 Cache size calculation.
commit
43c734be5571a4daad9f0a3e0b3229a1c0049917 upstream.
This patch fixes L2 Cache size calculations for L2C-210, L2C-310 and
PL310, by changing the L2X0_AUX_CTRL_WAY_SIZE_MASK from 2 bits to 3
bits.
The Auxiliary Control Register for L2C-210, L2C-310 and PL310 has 3bits
[19:17] for Way size, however the existing code only uses 2 bits to
get this value. This results in incorrect cachesize calculations.
It also results in performing operations on the whole cache when we
erroneously decide that the range is big enough (due to l2x0_size being
too small) and also prints incorrect cachesize.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jerome Glisse [Wed, 24 Aug 2011 20:00:17 +0000 (20:00 +0000)]
drm/radeon/kms: evergreen & ni reset SPI block on CP resume
commit
a49a50dad48586d42ebac1a6730c3a3cd5603421 upstream.
For some reason SPI block is in broken state after module
unloading. This lead to broken rendering after reloading
module. Fix this by reseting SPI block in CP resume function
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Mon, 29 Aug 2011 14:55:25 +0000 (14:55 +0000)]
drm/radeon/kms: add s/r quirk for Compaq Presario V5245EU
commit
302a8e8b06d312dcb3b718dfeb42aa912b5f426b upstream.
Fixes resume on Compaq Presario V5245EU.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=41642
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 30 Aug 2011 04:14:29 +0000 (21:14 -0700)]
sparc64: Only Panther cheetah+ chips have POPC.
commit
1a8e0da5937a6c87807083baa318cf8f98dac9aa upstream.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Axel Lin [Sun, 10 Jul 2011 13:44:09 +0000 (21:44 +0800)]
regulator: tps65910: Add missing breaks in switch/case
commit
d04156bca629740a661fd0738cd69ba1f08b2b20 upstream.
Also add a default case in tps65910_list_voltage_dcdc to silence
'volt' may be used uninitialized in this function warning.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kjetil Oftedal [Sun, 28 Aug 2011 22:16:28 +0000 (00:16 +0200)]
sparc32,sun4d: Change IPI IRQ level to prevent collision between IPI and timer interrupt
commit
38f7f8f05e8239e9871f7e1c4b0a842080e85315 upstream.
On Sun4d systems running in SMP mode, IRQ 14 is used for timer interrupts
and has a specialized interrupt handler. IPI is currently set to use IRQ 14
as well, which causes it to trigger the timer interrupt handler, and not the
IPI interrupt handler.
The IPI interrupt is therefore changed to IRQ 13, which is the highest
normally handled interrupt. This IRQ is also used for SBUS interrupts,
however there is nothing in the IPI/SBUS interrupt handlers that indicate
that they will not handle sharing the interrupt.
(IRQ 13 is indicated as audio interrupt, which is unlikely to be found in a
sun4d system)
Signed-off-by: Kjetil Oftedal <oftedal@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ian Campbell [Wed, 17 Aug 2011 22:14:57 +0000 (22:14 +0000)]
sparc: fix array bounds error setting up PCIC NMI trap
commit
4a0342ca8e8150bd47e7118a76e300692a1b6b7b upstream.
CC arch/sparc/kernel/pcic.o
arch/sparc/kernel/pcic.c: In function 'pcic_probe':
arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds]
cc1: all warnings being treated as errors
I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via
the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear
to be 4 instructions long and I presume from the usage that instructions are
int sized.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Mon, 15 Aug 2011 21:45:17 +0000 (14:45 -0700)]
sparc64: Set HAVE_C_RECORDMCOUNT
[ Upstream commit
178a29600340bef5b13cd4157053679debe35351 ]
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Sun, 21 Aug 2011 00:14:54 +0000 (17:14 -0700)]
sparc: Allow handling signals when stack is corrupted.
commit
5598473a5b40c47a8c5349dd2c2630797169cf1a upstream.
If we can't push the pending register windows onto the user's stack,
we disallow signal delivery even if the signal would be delivered on a
valid seperate signal stack.
Add a register window save area in the signal frame, and store any
unsavable windows there.
On sigreturn, if any windows are still queued up in the signal frame,
try to push them back onto the stack and if that fails we kill the
process immediately.
This allows the debug/tst-longjmp_chk2 glibc test case to pass.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mikael Pettersson [Mon, 15 Aug 2011 10:11:50 +0000 (10:11 +0000)]
sparc32: unbreak arch_write_unlock()
commit
3f6aa0b113846a8628baa649af422cfc6fb1d786 upstream.
The sparc32 version of arch_write_unlock() is just a plain assignment.
Unfortunately this allows the compiler to schedule side-effects in a
protected region to occur after the HW-level unlock, which is broken.
E.g., the following trivial test case gets miscompiled:
#include <linux/spinlock.h>
rwlock_t lock;
int counter;
void foo(void) { write_lock(&lock); ++counter; write_unlock(&lock); }
Fixed by adding a compiler memory barrier to arch_write_unlock(). The
sparc64 version combines the barrier and assignment into a single asm(),
and implements the operation as a static inline, so that's what I did too.
Compile-tested with sparc32_defconfig + CONFIG_SMP=y.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mikael Pettersson [Mon, 15 Aug 2011 10:10:31 +0000 (10:10 +0000)]
sparc64: remove unnecessary macros from spinlock_64.h
commit
a0fba3eb059e73fed2d376a901f8117734c12f1f upstream.
The sparc64 spinlock_64.h contains a number of operations defined
first as static inline functions, and then as macros with the same
names and parameters as the functions. Maybe this was needed at
some point in the past, but now nothing seems to depend on these
macros (checked with a recursive grep looking for ifdefs on these
names). Other archs don't define these identity-macros.
So this patch deletes these unnecessary macros.
Compile-tested with sparc64_defconfig.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Thu, 25 Aug 2011 15:14:26 +0000 (17:14 +0200)]
rt2x00: fix crash in rt2800usb_get_txwi
commit
674db1344443204b6ce3293f2df8fd1b7665deea upstream.
Patch should fix this oops:
BUG: unable to handle kernel NULL pointer dereference at
000000a0
IP: [<
f81b30c9>] rt2800usb_get_txwi+0x19/0x70 [rt2800usb]
*pdpt =
0000000000000000 *pde =
f000ff53f000ff53
Oops: 0000 [#1] SMP
Pid: 198, comm: kworker/u:3 Tainted: G W 3.0.0-wl+ #9 LENOVO 6369CTO/6369CTO
EIP: 0060:[<
f81b30c9>] EFLAGS:
00010283 CPU: 1
EIP is at rt2800usb_get_txwi+0x19/0x70 [rt2800usb]
EAX:
00000000 EBX:
f465e140 ECX:
f4494960 EDX:
ef24c5f8
ESI:
810f21f5 EDI:
f1da9960 EBP:
f4581e80 ESP:
f4581e70
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process kworker/u:3 (pid: 198, ti=
f4580000 task=
f4494960 task.ti=
f4580000)
Call Trace:
[<
f804790f>] rt2800_txdone_entry+0x2f/0xf0 [rt2800lib]
[<
c045110d>] ? warn_slowpath_common+0x7d/0xa0
[<
f81b3a38>] ? rt2800usb_work_txdone+0x288/0x360 [rt2800usb]
[<
f81b3a38>] ? rt2800usb_work_txdone+0x288/0x360 [rt2800usb]
[<
f81b3a13>] rt2800usb_work_txdone+0x263/0x360 [rt2800usb]
[<
c046a8d6>] process_one_work+0x186/0x440
[<
c046a85a>] ? process_one_work+0x10a/0x440
[<
f81b37b0>] ? rt2800usb_probe_hw+0x120/0x120 [rt2800usb]
[<
c046c283>] worker_thread+0x133/0x310
[<
c04885db>] ? trace_hardirqs_on+0xb/0x10
[<
c046c150>] ? manage_workers+0x1e0/0x1e0
[<
c047054c>] kthread+0x7c/0x90
[<
c04704d0>] ? __init_kthread_worker+0x60/0x60
[<
c0826b42>] kernel_thread_helper+0x6/0x1
Oops might happen because we check rt2x00queue_empty(queue) twice,
but this condition can change and we can process entry in
rt2800_txdone_entry(), which was already processed by
rt2800usb_txdone_entry_check() -> rt2x00lib_txdone_noinfo() and
has nullify entry->skb .
Reported-by: Justin Piszcz <jpiszcz@lucidpixels.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Thu, 25 Aug 2011 15:14:24 +0000 (17:14 +0200)]
rt2x00: fix crash in rt2800usb_write_tx_desc
commit
4b1bfb7d2d125af6653d6c2305356b2677f79dc6 upstream.
Patch should fix this oops:
BUG: unable to handle kernel NULL pointer dereference at
000000a0
IP: [<
f8e06078>] rt2800usb_write_tx_desc+0x18/0xc0 [rt2800usb]
*pdpt =
000000002408c001 *pde =
0000000024079067 *pte =
0000000000000000
Oops: 0000 [#1] SMP
EIP: 0060:[<
f8e06078>] EFLAGS:
00010282 CPU: 0
EIP is at rt2800usb_write_tx_desc+0x18/0xc0 [rt2800usb]
EAX:
00000035 EBX:
ef2bef10 ECX:
00000000 EDX:
d40958a0
ESI:
ef1865f8 EDI:
ef1865f8 EBP:
d4095878 ESP:
d409585c
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Call Trace:
[<
f8da5e85>] rt2x00queue_write_tx_frame+0x155/0x300 [rt2x00lib]
[<
f8da424c>] rt2x00mac_tx+0x7c/0x370 [rt2x00lib]
[<
c04882b2>] ? mark_held_locks+0x62/0x90
[<
c081f645>] ? _raw_spin_unlock_irqrestore+0x35/0x60
[<
c04884ba>] ? trace_hardirqs_on_caller+0x5a/0x170
[<
c04885db>] ? trace_hardirqs_on+0xb/0x10
[<
f8d618ac>] __ieee80211_tx+0x5c/0x1e0 [mac80211]
[<
f8d631fc>] ieee80211_tx+0xbc/0xe0 [mac80211]
[<
f8d63163>] ? ieee80211_tx+0x23/0xe0 [mac80211]
[<
f8d632e1>] ieee80211_xmit+0xc1/0x200 [mac80211]
[<
f8d63220>] ? ieee80211_tx+0xe0/0xe0 [mac80211]
[<
c0487d45>] ? lock_release_holdtime+0x35/0x1b0
[<
f8d63986>] ? ieee80211_subif_start_xmit+0x446/0x5f0 [mac80211]
[<
f8d637dd>] ieee80211_subif_start_xmit+0x29d/0x5f0 [mac80211]
[<
f8d63924>] ? ieee80211_subif_start_xmit+0x3e4/0x5f0 [mac80211]
[<
c0760188>] ? sock_setsockopt+0x6a8/0x6f0
[<
c0760000>] ? sock_setsockopt+0x520/0x6f0
[<
c076daef>] dev_hard_start_xmit+0x2ef/0x650
Oops might happen because we perform parallel putting new entries in a
queue (rt2x00queue_write_tx_frame()) and removing entries after
finishing transmitting (rt2800usb_work_txdone()). There are cases when
_txdone may process an entry that was not fully send and nullify
entry->skb .
To fix check in _txdone if entry has flags that indicate pending
transmission and wait until flags get cleared.
Reported-by: Justin Piszcz <jpiszcz@lucidpixels.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Schwierzeck [Fri, 19 Aug 2011 12:04:20 +0000 (12:04 +0000)]
atm: br2684: Fix oops due to skb->dev being NULL
commit
fbe5e29ec1886967255e76946aaf537b8cc9b81e upstream.
This oops have been already fixed with commit
27141666b69f535a4d63d7bc6d9e84ee5032f82a
atm: [br2684] Fix oops due to skb->dev being NULL
It happens that if a packet arrives in a VC between the call to open it on
the hardware and the call to change the backend to br2684, br2684_regvcc
processes the packet and oopses dereferencing skb->dev because it is
NULL before the call to br2684_push().
but have been introduced again with commit
b6211ae7f2e56837c6a4849316396d1535606e90
atm: Use SKB queue and list helpers instead of doing it by-hand.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Thu, 4 Aug 2011 09:15:07 +0000 (11:15 +0200)]
pata_via: disable ATAPI DMA on AVERATEC 3200
commit
6d0e194d2eefcaab6dbdca1f639748660144acb5 upstream.
On AVERATEC 3200, pata_via causes memory corruption with ATAPI DMA,
which often leads to random kernel oops. The cause of the problem is
not well understood yet and only small subset of machines using the
controller seem affected. Blacklist ATAPI DMA on the machine.
Signed-off-by: Tejun Heo <tj@kernel.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=11426
Reported-and-tested-by: Jim Bray <jimsantelmo@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
John Stanley [Thu, 4 Aug 2011 00:41:00 +0000 (20:41 -0400)]
savagedb: Fix typo causing regression in savage4 series video chip detection
commit
4b00e4b3940eabb38adeec0823751820fe2d6fda upstream.
Two additional savage4 variants were added, but the S3_SAVAGE4_SERIES
macro was incompletely modified, resulting in a false positive detection
of a savage4 card regardless of which savage card is actually present.
For non-savage4 series cards, such as a Savage/IX-MV card, this results
in garbled video and/or a hard-hang at boot time. Fix this by changing
an '||' to an '&&' in the S3_SAVAGE4_SERIES macro.
Signed-off-by: John P. Stanley <jpsinthemix@verizon.net>
Reviewed-by: Tormod Volden <debian.tormod@gmail.com>
[ The macros have incomplete parenthesis too, but whatever .. -Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Fri, 12 Aug 2011 12:02:04 +0000 (14:02 +0200)]
rt2x00: do not drop usb dev reference counter on suspend
commit
543cc38c8fe86deba4169977c61eb88491036837 upstream.
When hibernating ->resume may not be called by usb core, but disconnect
and probe instead, so we do not increase the counter after decreasing
it in ->supend. As a result we free memory early, and get crash when
unplugging usb dongle.
BUG: unable to handle kernel paging request at
6b6b6b9f
IP: [<
c06909b0>] driver_sysfs_remove+0x10/0x30
*pdpt =
0000000034f21001 *pde =
0000000000000000
Pid: 20, comm: khubd Not tainted 3.1.0-rc1-wl+ #20 LENOVO 6369CTO/6369CTO
EIP: 0060:[<
c06909b0>] EFLAGS:
00010202 CPU: 1
EIP is at driver_sysfs_remove+0x10/0x30
EAX:
6b6b6b6b EBX:
f52bba34 ECX:
00000000 EDX:
6b6b6b6b
ESI:
6b6b6b6b EDI:
c0a0ea20 EBP:
f61c9e68 ESP:
f61c9e64
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process khubd (pid: 20, ti=
f61c8000 task=
f6138270 task.ti=
f61c8000)
Call Trace:
[<
c06909ef>] __device_release_driver+0x1f/0xa0
[<
c0690b20>] device_release_driver+0x20/0x40
[<
c068fd64>] bus_remove_device+0x84/0xe0
[<
c068e12a>] ? device_remove_attrs+0x2a/0x80
[<
c068e267>] device_del+0xe7/0x170
[<
c06d93d4>] usb_disconnect+0xd4/0x180
[<
c06d9d61>] hub_thread+0x691/0x1600
[<
c0473260>] ? wake_up_bit+0x30/0x30
[<
c0442a39>] ? complete+0x49/0x60
[<
c06d96d0>] ? hub_disconnect+0xd0/0xd0
[<
c06d96d0>] ? hub_disconnect+0xd0/0xd0
[<
c0472eb4>] kthread+0x74/0x80
[<
c0472e40>] ? kthread_worker_fn+0x150/0x150
[<
c0809b3e>] kernel_thread_helper+0x6/0x10
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Senthil Balasubramanian [Fri, 19 Aug 2011 13:13:06 +0000 (18:43 +0530)]
ath9k_hw: Fix STA (AR9485) bringup issue due to incorrect MAC address
commit
b503c7a273c0a3018ad11ea8c513c639120afbf4 upstream.
Due to some recent optimization done in the way the mac address
bytes are written into the OTP memory, some AR9485 chipsets were
forced to use the first byte from the eeprom template and the
remaining bytes are read from OTP.
AR9485 happens to use generic eeprom template which has 0x1 as
the first byte causes issues in bringing up the card.
So fixed the eeprom template accordingly to address the issue.
Cc: Paul Stewart <pstew@google.com>
Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexey Khoroshilov [Tue, 23 Aug 2011 20:44:32 +0000 (00:44 +0400)]
carl9170: Fix mismatch in carl9170_op_set_key mutex lock-unlock
commit
66cb54bd24086b2d871a03035de9b0e79b2b725e upstream.
If is_main_vif(ar, vif) reports that we have to fall back
to software encryption, we goto err_softw; before locking ar->mutex.
As a result, we have unprotected call to carl9170_set_operating_mode
and unmatched mutex_unlock.
The patch fix the issue by adding mutex_lock before goto.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Acked-By: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Anton Blanchard [Thu, 25 Aug 2011 00:56:15 +0000 (17:56 -0700)]
ibmveth: Fix leak when recycling skb and hypervisor returns error
commit
c6f59d13e24187ff95427a9f4a5a7e14fb8faf5a upstream.
If h_add_logical_lan_buffer returns an error we need to free
the skb.
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>
Mohammed Shafi Shajakhan [Wed, 24 Aug 2011 16:08:07 +0000 (21:38 +0530)]
ath9k: Fix PS wrappers in ath9k_set_coverage_class
commit
8b2a3827bb12430d932cd479b22d906baf08c212 upstream.
this callback is called during suspend/resume and also via iw command.
it configures parameters like sifs, slottime, acktimeout in
ath9k_hw_init_global_settings where few REG_READ, REG_RMW are also done
and hence the need for PS wrappers
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mathieu Desnoyers [Thu, 25 Aug 2011 02:45:03 +0000 (19:45 -0700)]
sendmmsg/sendmsg: fix unsafe user pointer access
commit
bc909d9ddbf7778371e36a651d6e4194b1cc7d4c upstream.
Dereferencing a user pointer directly from kernel-space without going
through the copy_from_user family of functions is a bad idea. Two of
such usages can be found in the sendmsg code path called from sendmmsg,
added by
commit
c71d8ebe7a4496fb7231151cb70a6baa0cb56f9a upstream.
commit
5b47b8038f183b44d2d8ff1c7d11a5c1be706b34 in the 3.0-stable tree.
Usages are performed through memcmp() and memcpy() directly. Fix those
by using the already copied msg_sys structure instead of the __user *msg
structure. Note that msg_sys can be set to NULL by verify_compat_iovec()
or verify_iovec(), which requires additional NULL pointer checks.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
CC: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
CC: Anton Blanchard <anton@samba.org>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Fri, 12 Aug 2011 17:23:01 +0000 (10:23 -0700)]
xhci: Handle zero-length isochronous packets.
commit
48df4a6fd8c40c0bbcbca2044f5f2bc75dcf6db1 upstream.
For a long time, the xHCI driver has had this note:
/* FIXME: Ignoring zero-length packets, can those happen? */
It turns out that, yes, there are drivers that need to queue zero-length
transfers for isochronous OUT transfers. Without this patch, users will
see kernel hang messages when a driver attempts to enqueue an isochronous
URB with a zero length transfer (because count_isoc_trbs_needed will return
zero for that TD, xhci_td->last_trb will never be set, and updating the
dequeue pointer will cause an infinite loop).
Matěj ran into this issue when using an NI Audio4DJ USB soundcard
with the snd-usb-caiaq driver. See
https://bugzilla.kernel.org/show_bug.cgi?id=40702
Fix count_isoc_trbs_needed() to return 1 for zero-length transfers (thanks
Alan on the math help). Update the various TRB field calculations to deal
with zero-length transfers. We're still transferring one packet with a
zero-length data payload, so the total_packet_count should be 1. The
Transfer Burst Count (TBC) and Transfer Last Burst Packet Count (TLBPC)
fields should be set to zero.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Matěj Laitl <matej@laitl.cz>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Tue, 2 Aug 2011 22:43:40 +0000 (15:43 -0700)]
xhci: Remove TDs from TD lists when URBs are canceled.
commit
585df1d90cb07a02ca6c7a7d339e56e46d50dafb upstream.
When a driver tries to cancel an URB, and the host controller is dying,
xhci_urb_dequeue will giveback the URB without removing the xhci_tds
that comprise that URB from the td_list or the cancelled_td_list. This
can cause a race condition between the driver calling URB dequeue and
the stop endpoint command watchdog timer.
If the timer fires on a dying host, and a driver attempts to resubmit
while the watchdog timer has dropped the xhci->lock to giveback a
cancelled URB, URBs may be given back by the xhci_urb_dequeue() function.
At that point, the URB's priv pointer will be freed and set to NULL, but
the TDs will remain on the td_list. This will cause an oops in
xhci_giveback_urb_in_irq() when the watchdog timer attempts to loop
through the endpoints' td_lists, giving back killed URBs.
Make sure that xhci_urb_dequeue() removes TDs from the TD lists and
canceled TD lists before it gives back the URB.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Fri, 29 Jul 2011 19:44:32 +0000 (12:44 -0700)]
xhci: Fix failed enqueue in the middle of isoch TD.
commit
522989a27c7badb608155b1f1dea3487ed431f74 upstream.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Fri, 22 Jul 2011 21:34:34 +0000 (14:34 -0700)]
xhci: Fix memory leak during failed enqueue.
commit
d13565c12828ce0cd2a3862bf6260164a0653352 upstream.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andiry Xu [Wed, 3 Aug 2011 08:46:49 +0000 (16:46 +0800)]
xHCI: report USB2 port in resuming as suspend
commit
8a8ff2f9399b23b968901f585ccb5a70a537c5ae upstream.
When a USB2 port initiate a remote wakeup, software shall ensure that
resume is signaled for at least 20ms, and then write '0' to the PLS field.
According to this, xhci driver do the following things:
1. When receive a remote wakeup event in irq_handler, set the resume_done
value as jiffies + 20ms, and modify rh_timer to poll root hub status at
that time;
2. When receive a GetPortStatus request, if the jiffies is after the
resume_done value, clear the resume signal and resume_done.
However, if usb_port_resume() is called before the rh_timer triggered, it
will indicate the port as Suspend Cleared and skip the clear resume signal
part. The device will fail the usb_get_status request in finish_port_resume(),
and usbcore will try a reset-resume instead. Device will work OK after
reset-resume, but resume_done value is not cleared in this case, and
xhci_bus_suspend() will fail because when it finds a non-zero resume_done
value, it will regard the port as resuming and return -EBUSY.
This causes issue on some platforms that the system fail to suspend
after remote wakeup from suspend by USB2 devices connected to xHCI port.
To fix this issue, report the port status as suspend if the resume is
signaling less that 20ms, and usb_port_resume() will wait 25ms and check
port status again, so xHCI driver can clear the resume signaling and
resume_done value.
This should be backported to kernels as old as 2.6.37.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andiry Xu [Wed, 3 Aug 2011 08:46:48 +0000 (16:46 +0800)]
xHCI: fix port U3 status check condition
commit
5ac04bf190e6f8b17238aef179ebd7f2bdfec919 upstream.
Fix the port U3 status check when Clear PORT_SUSPEND Feature.
The port status should be masked with PORT_PLS_MASK to check if it's in
U3 state.
This should be backported to kernels as old as 2.6.37.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wang Zhi [Wed, 17 Aug 2011 02:39:31 +0000 (10:39 +0800)]
USB: EHCI: Do not rely on PORT_SUSPEND to stop USB resuming in ehci_bus_resume().
commit
d0f2fb2500b1c5fe4967eb45d8c9bc758d7aef80 upstream.
From EHCI Spec p.28 HC should clear PORT_SUSPEND when SW clears
PORT_RESUME. In Intel Oaktrail platform, MPH (Multi-Port Host
Controller) core clears PORT_SUSPEND directly when SW sets PORT_RESUME
bit. If we rely on PORT_SUSPEND bit to stop USB resume, we will miss
the action of clearing PORT_RESUME. This will cause unexpected long
resume signal on USB bus.
Signed-off-by: Wang Zhi <zhi.wang@windriver.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Per Forlin [Wed, 3 Aug 2011 13:39:15 +0000 (15:39 +0200)]
usb: musb: cppi: fix build errors due to DBG and missing musb variable
commit
f847a79ab3c1faca3022061045cd22e4678c1b1c upstream.
Replace DBG with dev_dbg and fix invalid access of musb->controller.
With this patch cppi_dma builds successfully.
Signed-off-by: Per Forlin <per.forlin@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Bird [Tue, 16 Aug 2011 23:20:03 +0000 (00:20 +0100)]
USB option driver K3765/K4505 avoid CDC_DATA interface
commit
6118514e8749105334f46ccec6faf9a439be6cf9 upstream.
Currently the Option driver avoids binding interface 1 on Huawei K3765
and K4505 broadband modems as it should be handled by the cdc_ether
driver instead. This patch ensures we don't bind the interface 2
on those devices as that is CDC_DATA.
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gavin.zhu [Mon, 22 Aug 2011 20:51:53 +0000 (13:51 -0700)]
USB: option: add YUGA device id to driver
commit
c6eb2d75ffcdfafa37ff010bf467de20d468ef79 upstream.
Signed-off-by: Gavin.zhu <gavin.kx@qq.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Bird [Tue, 16 Aug 2011 19:58:21 +0000 (13:58 -0600)]
USB option driver add PID of Huawei Vodafone K4605
commit
7e1805844da18a37e6d251d286f93c94b52d791e upstream.
This patch adds the product ID of Huawei's Vodafone K4605 mobile broadband
modem to option.c. This is necessary so that the driver gets loaded on
demand without the intervention of usb_modeswitch. This has the benefit of
it becoming available faster and also ensures that the option driver is not
bound to a network interface that should be claimed by suitable network
driver.
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Signed-off-by: Alex Chiang <achiang@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Bird [Tue, 16 Aug 2011 19:57:14 +0000 (13:57 -0600)]
USB option driver add PID of Huawei Vodafone K3806
commit
0e69d75ccb2f091757b38d4d6a2ed739e06b615e upstream.
This patch adds the product ID of Huawei's Vodafone K3806 mobile broadband
modem to option.c. This is necessary so that the driver gets loaded on
demand without the intervention of usb_modeswitch. This has the benefit of
it becoming available faster and also ensures that the option driver is not
bound to a network interface that should be claimed by cdc_ether.
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Signed-off-by: Alex Chiang <achiang@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Yulgon Kim [Thu, 18 Aug 2011 05:02:45 +0000 (14:02 +0900)]
usb: s5p-ehci: fix a NULL pointer deference
commit
e5d3d4463fb30998385f9e78ab3c7f63b5813000 upstream.
This patch fixes a NULL pointer deference. A NULL pointer
dereference happens since s5p_ehci->hcd field is not initialized
yet in probe function.
[jg1.han@samsung.com: edit commit message]
Signed-off-by: Yulgon Kim <yulgon.kim@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean-Christophe PLAGNIOL-VILLARD [Thu, 25 Aug 2011 09:46:58 +0000 (11:46 +0200)]
USB: ftdi_sio: add Calao reference board support
commit
c96fbdd0ab97235f930ebf24b38fa42a2e3458cf upstream.
Calao use on there dev kits a FT2232 where the port 0 is used for the JTAG and
port 1 for the UART
They use the same VID and PID as FTDI Chip but they program the manufacturer
name in the eeprom
So use this information to detect it
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Gregory Hermant <gregory.hermant@calao-systems.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiri Slaby [Wed, 10 Aug 2011 12:59:28 +0000 (14:59 +0200)]
TTY: pty, fix pty counting
commit
24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24 upstream.
tty_operations->remove is normally called like:
queue_release_one_tty
->tty_shutdown
->tty_driver_remove_tty
->tty_operations->remove
However tty_shutdown() is called from queue_release_one_tty() only if
tty_operations->shutdown is NULL. But for pty, it is not.
pty_unix98_shutdown() is used there as ->shutdown.
So tty_operations->remove of pty (i.e. pty_unix98_remove()) is never
called. This results in invalid pty_count. I.e. what can be seen in
/proc/sys/kernel/pty/nr.
I see this was already reported at:
https://lkml.org/lkml/2009/11/5/370
But it was not fixed since then.
This patch is kind of a hackish way. The problem lies in ->install. We
allocate there another tty (so-called tty->link). So ->install is
called once, but ->remove twice, for both tty and tty->link. The fix
here is to count both tty and tty->link and divide the count by 2 for
user.
And to have ->remove called, let's make tty_driver_remove_tty() global
and call that from pty_unix98_shutdown() (tty_operations->shutdown).
While at it, let's document that when ->shutdown is defined,
tty_shutdown() is not called.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Axel Lin [Mon, 1 Aug 2011 13:20:10 +0000 (21:20 +0800)]
tty: Add "spi:" prefix for spi modalias
commit
8c4074cd2254606aeb788d518ccc27c9f97129e1 upstream.
Since commit
e0626e38 (spi: prefix modalias with "spi:"),
the spi modalias is prefixed with "spi:".
This patch adds "spi:" prefix and removes "-spi" suffix in the modalias.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Al Cooper [Mon, 25 Jul 2011 20:19:52 +0000 (16:19 -0400)]
8250: Fix race condition in serial8250_backup_timeout().
commit
dbb3b1ca5609d1f3848cd387d06cc60aaacf7f98 upstream.
This is to fix an issue where output will suddenly become very slow.
The problem occurs on 8250 UARTS with the hardware bug UART_BUG_THRE.
BACKGROUND
For normal UARTs (without UART_BUG_THRE): When the serial core layer
gets new transmit data and the transmitter is idle, it buffers the
data and calls the 8250s' serial8250_start_tx() routine which will
simply enable the TX interrupt in the IER register and return. This
should immediately fire a THRE interrupt and begin transmitting the
data.
For buggy UARTs (with UART_BUG_THRE): merely enabling the TX interrupt
in IER does not necessarily generate a new THRE interrupt.
Therefore, a background timer periodically checks to see if there is
pending data, and starts transmission if that is the case.
The bug happens on SMP systems when the system has nothing to transmit,
the transmit interrupt is disabled and the following sequence occurs:
- CPU0: The background timer routine serial8250_backup_timeout()
starts and saves the state of the interrupt enable register (IER)
and then disables all interrupts in IER. NOTE: The transmit interrupt
(TI) bit is saved as disabled.
- CPU1: The serial core gets data to transmit, grabs the port lock and
calls serial8250_start_tx() which enables the TI in IER.
- CPU0: serial8250_backup_timeout() waits for the port lock.
- CPU1: finishes (with TI enabled) and releases the port lock.
- CPU0: serial8250_backup_timeout() calls the interrupt routine which
will transmit the next fifo's worth of data and then restores the
IER from the previously saved value (TI disabled).
At this point, as long as the serial core has more transmit data
buffered, it will not call serial8250_start_tx() again and the
background timer routine will slowly transmit the data.
The fix is to have serial8250_start_tx() get the port lock before
it saves the IER state and release it after restoring IER. This will
prevent serial8250_start_tx() from running in parallel.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Smith [Tue, 12 Jul 2011 04:53:13 +0000 (22:53 -0600)]
8250_pci: add support for Rosewill RC-305 4x serial port card
commit
44178176ecc55ad370b837dd2c4b4b8bed1e3823 upstream.
This patch adds support for the Rosewill RC-305 four-port PCI serial
card, and probably any other four-port serial cards based on the
Moschip MCS9865 chip, assuming that the EEPROM on the card was
programmed in accordance with Table 6 of the MCS9865 EEPROM
Application Note version 0.3 dated 16-May-2008, available from the
Moschip web site (registration required).
This patch is based on an earlier patch [1] for the SYBA 6x serial
port card by Ira W. Snyder.
[1]: http://www.gossamer-threads.com/lists/linux/kernel/
1162435
Signed-off-by: Eric Smith <eric@brouhaha.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bjorn Helgaas [Tue, 16 Aug 2011 18:02:28 +0000 (12:02 -0600)]
serial: 8250_pnp: add Intermec CV60 touchscreen device
commit
ab8ba3a2d2cba6a658ef596cd5b2e0905b6c8a9f upstream.
It would have been nice if Intermec had supplied a PNP0501 _CID for the
COM3 device, but they didn't, so we have to recognize it explicitly.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=40612
CC: Jeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nick Pelly [Fri, 15 Jul 2011 20:53:08 +0000 (13:53 -0700)]
omap-serial: Allow IXON and IXOFF to be disabled.
commit
b280a97d1caf6fe1d38b51ebb31219391f5ad1a0 upstream.
Fixes logic bug that software flow control cannot be disabled, because
serial_omap_configure_xonxoff() is not called if both IXON and IXOFF bits
are cleared.
Signed-off-by: Nick Pelly <npelly@google.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Tested-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Scott Jiang [Fri, 12 Aug 2011 22:04:11 +0000 (18:04 -0400)]
ASoC: ad193x: fix dac word len setting
commit
95c93d8525ebce1024bda7316f602ae45c36cd6f upstream.
dac word len value should left shift before setting
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Acked-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Scott Jiang [Fri, 12 Aug 2011 22:04:10 +0000 (18:04 -0400)]
ASoC: ad193x: fix registers definition
commit
bf545ed72f2eeac664695a8ea2199d9ddaef6020 upstream.
fix dac word len mask and adc tdm fmt shift value
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Axel Lin [Sat, 13 Aug 2011 11:15:01 +0000 (19:15 +0800)]
ASoC: soc-jack: Fix checking return value of request_any_context_irq
commit
d2b4c7bd7eabfaa2e3e5b8107d5eeb56ac879813 upstream.
request_any_context_irq() returns a negative value on failure.
On success, it returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Liu Gang-B34182 [Thu, 25 Aug 2011 22:59:25 +0000 (15:59 -0700)]
arch/powerpc/sysdev/fsl_rio.c: correct IECSR register clear value
commit
671ee7f0ce62e4b991b47fcf1c161c3f710dabbc upstream.
This bug causes the IECSR register clear failure. In this case, the RETE
(retry error threshold exceeded) interrupt will be generated and cannot be
cleared. So the related ISR may be called persistently.
The RETE bit in IECSR is cleared by writing a 1 to it.
Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kumar Gala <galak@kernel.crashing.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>
Alexandre Bounine [Thu, 25 Aug 2011 22:59:13 +0000 (15:59 -0700)]
rapidio: fix use of non-compatible registers
commit
284fb68d00c56e971ed01e0b4bac5ddd4d1b74ab upstream.
Replace/remove use of RIO v.1.2 registers/bits that are not
forward-compatible with newer versions of RapidIO specification.
RapidIO specification v.1.3 removed Write Port CSR, Doorbell CSR,
Mailbox CSR and Mailbox and Doorbell bits of the PEF CAR.
Use of removed (since RIO v.1.3) register bits affects users of
currently available 1.3 and 2.x compliant devices who may use not so
recent kernel versions.
Removing checks for unsupported bits makes corresponding routines
compatible with all versions of RapidIO specification. Therefore,
backporting makes stable kernel versions compliant with RIO v.1.3 and
later as well.
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>
Cc: Chul Kim <chul.kim@idt.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>
Nishanth Aravamudan [Thu, 25 Aug 2011 22:59:11 +0000 (15:59 -0700)]
kernel/printk: do not turn off bootconsole in printk_late_init() if keep_bootcon
commit
4c30c6f566c0989ddaee3407da44751e340a63ed upstream.
It seems that
7bf693951a8e ("console: allow to retain boot console via
boot option keep_bootcon") doesn't always achieve what it aims, as when
printk_late_init() runs it unconditionally turns off all boot consoles.
With this patch, I am able to see more messages on the boot console in
KVM guests than I can without, when keep_bootcon is specified.
I think it is appropriate for the relevant -stable trees. However, it's
more of an annoyance than a serious bug (ideally you don't need to keep
the boot console around as console handover should be working -- I was
encountering a situation where the console handover wasn't working and
not having the boot console available meant I couldn't see why).
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <gregkh@suse.de>
Acked-by: Fabio M. Di Nitto <fdinitto@redhat.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>
Greg Kroah-Hartman [Mon, 29 Aug 2011 20:56:30 +0000 (13:56 -0700)]
Linux 3.0.4
Andi Kleen [Fri, 19 Aug 2011 23:15:10 +0000 (16:15 -0700)]
Add a personality to report 2.6.x version numbers
commit
be27425dcc516fd08245b047ea57f83b8f6f0903 upstream.
I ran into a couple of programs which broke with the new Linux 3.0
version. Some of those were binary only. I tried to use LD_PRELOAD to
work around it, but it was quite difficult and in one case impossible
because of a mix of 32bit and 64bit executables.
For example, all kind of management software from HP doesnt work, unless
we pretend to run a 2.6 kernel.
$ uname -a
Linux svivoipvnx001
3.0.0-08107-g97cd98f #1062 SMP Fri Aug 12 18:11:45 CEST 2011 i686 i686 i386 GNU/Linux
$ hpacucli ctrl all show
Error: No controllers detected.
$ rpm -qf /usr/sbin/hpacucli
hpacucli-8.75-12.0
Another notable case is that Python now reports "linux3" from
sys.platform(); which in turn can break things that were checking
sys.platform() == "linux2":
https://bugzilla.mozilla.org/show_bug.cgi?id=664564
It seems pretty clear to me though it's a bug in the apps that are using
'==' instead of .startswith(), but this allows us to unbreak broken
programs.
This patch adds a UNAME26 personality that makes the kernel report a
2.6.40+x version number instead. The x is the x in 3.x.
I know this is somewhat ugly, but I didn't find a better workaround, and
compatibility to existing programs is important.
Some programs also read /proc/sys/kernel/osrelease. This can be worked
around in user space with mount --bind (and a mount namespace)
To use:
wget ftp://ftp.kernel.org/pub/linux/kernel/people/ak/uname26/uname26.c
gcc -o uname26 uname26.c
./uname26 program
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Carolyn Wyborny [Sat, 25 Jun 2011 13:18:12 +0000 (13:18 +0000)]
igb: Fix lack of flush after register write and before delay
commit
064b43304ed8ede8e13ff7b4338d09fd37bcffb1 upstream.
Register writes followed by a delay are required to have a flush
before the delay in order to commit the values to the register. Without
the flush, the code following the delay may not function correctly.
Reported-by: Tong Ho <tong.ho@ericsson.com>
Reported-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Aaron Lu [Mon, 11 Jul 2011 05:27:11 +0000 (13:27 +0800)]
mmc: sdhci: fix retuning timer wrongly deleted in sdhci_tasklet_finish
commit
78869618a886d33d8cdfcb78cf9b245b5250e465 upstream.
Currently, the retuning timer for retuning mode 1 will be deleted in
function sdhci_tasklet_finish after a mmc request done, which will make
retuning timing never trigger again. This patch fixed this problem.
Signed-off-by: Aaron Lu <Aaron.Lu@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Wed, 10 Aug 2011 13:32:23 +0000 (15:32 +0200)]
rt2x00: fix order of entry flags modification
commit
df71c9cfceea801e7e26e2c74241758ef9c042e5 upstream.
In rt2800usb_work_txdone we check flags in order:
- ENTRY_OWNER_DEVICE_DATA
- ENTRY_DATA_STATUS_PENDING
- ENTRY_DATA_IO_FAILED
Modify flags in separate order in rt2x00usb_interrupt_txdone, to avoid
processing entries in _txdone with wrong flags or skip processing
ready entries.
Reported-by: Justin Piszcz <jpiszcz@lucidpixels.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Miklos Szeredi [Wed, 24 Aug 2011 08:20:17 +0000 (10:20 +0200)]
fuse: check size of FUSE_NOTIFY_INVAL_ENTRY message
commit
c2183d1e9b3f313dd8ba2b1b0197c8d9fb86a7ae upstream.
FUSE_NOTIFY_INVAL_ENTRY didn't check the length of the write so the
message processing could overrun and result in a "kernel BUG at
fs/fuse/dev.c:629!"
Reported-by: Han-Wen Nienhuys <hanwenn@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Reim [Wed, 17 Aug 2011 09:03:32 +0000 (09:03 +0000)]
drm/radeon: Extended DDC Probing for Toshiba L300D Radeon Mobility X1100 HDMI-A Connector
commit
f2b60717e692550bf753a5d64a5b69ea430fc832 upstream.
Toshiba Satellite L300D with ATI Mobility Radeon X1100 sends data
to i2c bus for a HDMI connector that is not implemented/existent
on the notebook's board.
Fix by applying extented DDC probing for this connector.
Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
with Improperly Wired DDC Lines
Tested for kernel 2.6.38 on Toshiba Satellite L300D notebook
BugLink: http://bugs.launchpad.net/bugs/826677
Signed-off-by: Thomas Reim <reimth@gmail.com>
Acked-by: Chris Routh <routhy@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marcin Slusarz [Mon, 22 Aug 2011 21:17:57 +0000 (21:17 +0000)]
drm/ttm: fix ttm_bo_add_ttm(user) failure path
commit
7c4c3960dff109bc5db4c35da481c212dadb5eb5 upstream.
ttm_tt_destroy kfrees passed object, so we need to nullify
a reference to it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jack Steiner [Fri, 5 Aug 2011 14:09:00 +0000 (09:09 -0500)]
x86, UV: Remove UV delay in starting slave cpus
commit
05e33fc20ea5e493a2a1e7f1d04f43cdf89f83ed upstream.
Delete the 10 msec delay between the INIT and SIPI when starting
slave cpus. I can find no requirement for this delay. BIOS also
has similar code sequences without the delay.
Removing the delay reduces boot time by 40 sec. Every bit helps.
Signed-off-by: Jack Steiner <steiner@sgi.com>
Link: http://lkml.kernel.org/r/20110805140900.GA6774@sgi.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>