14 Feb, 2012
40 commits
-
commit df754e6af2f237a6c020c0daff55a1a609338e31 upstream.
It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false
lockdep messages, so do not disable lockdep in that case.
We still want to keep lockdep disabled in the
TAINT_OOT_MODULE case:- bin-only modules can cause various instabilities in
their and in unrelated kernel code- they are impossible to debug for kernel developers
- they also typically do not have the copyright license
permission to link to the GPL-ed lockdep code.Suggested-by: Ben Hutchings
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-xopopjjens57r0i13qnyh2yo@git.kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 9f1065032ceb7e86c7c9f16bb86518857e88a172 upstream.
An error was existing in the saving of CONTRAST_CTR register
across suspend/resume.Signed-off-by: Hubert Feurstein
Signed-off-by: Nicolas Ferre
Acked-by: Jean-Christophe PLAGNIOL-VILLARD
Signed-off-by: Florian Tobias Schandinat
Signed-off-by: Greg Kroah-Hartman -
commit de47a4176c532ef5961b8a46a2d541a3517412d3 upstream.
For null user mounts, do not invoke string length function
during session setup.Reported-and-Tested-by: Chris Clayton
Acked-by: Jeff Layton
Signed-off-by: Shirish Pargaonkar
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 585c0fd8216e0c9f98e2434092af7ec0f999522d upstream.
NCT6776F can select fan input pins for fans 3 to 5 with a secondary set of
chip register bits. Check that second set of bits in addition to the first set
to detect if fans 3..5 are monitored.Signed-off-by: Guenter Roeck
Acked-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman -
commit 684a3ff7e69acc7c678d1a1394fe9e757993fd34 upstream.
ecryptfs_write() can enter an infinite loop when truncating a file to a
size larger than 4G. This only happens on architectures where size_t is
represented by 32 bits.This was caused by a size_t overflow due to it incorrectly being used to
store the result of a calculation which uses potentially large values of
type loff_t.[tyhicks@canonical.com: rewrite subject and commit message]
Signed-off-by: Li Wang
Signed-off-by: Yunchuan Wen
Reviewed-by: Cong Wang
Signed-off-by: Tyler Hicks
Signed-off-by: Greg Kroah-Hartman -
commit 9f1f46a45a681d357d1ceedecec3671a5ae957f4 upstream.
The problem this patch solves is that the forcewake accounting
necessary for register reads is protected by dev->struct_mutex. But the
hangcheck and error_capture code need to access registers without
grabbing this mutex because we hold it while waiting for the gpu.
So a new lock is required. Because currently the error_state capture
is called from the error irq handler and the hangcheck code runs from
a timer, it needs to be an irqsafe spinlock (note that the registers
used by the irq handler (neglecting the error handling part) only uses
registers that don't need the forcewake dance).We could tune this down to a normal spinlock when we rework the
error_state capture and hangcheck code to run from a workqueue. But
we don't have any read in a fastpath that needs forcewake, so I've
decided to not care much about overhead.This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
snb on recent kernels - something must have slightly changed the
timings. On previous kernels it only trigger a WARN about the broken
locking.v2: Drop the previous patch for the register writes.
v3: Improve the commit message per Chris Wilson's suggestions.
Signed-Off-by: Daniel Vetter
Reviewed-by: Chris Wilson
Reviewed-by: Eugeni Dodonov
Signed-off-by: Keith Packard
Signed-off-by: Eugeni Dodonov
Signed-off-by: Greg Kroah-Hartman -
commit 8109021313c7a3d8947677391ce6ab9cd0bb1d28 upstream.
This was forgotten in the original multi-threaded forcewake
conversion:commit 8d715f0024f64ad1b1be85d8c081cf577944c847
Author: Keith Packard
Date: Fri Nov 18 20:39:01 2011 -0800drm/i915: add multi-threaded forcewake support
Signed-off-by: Daniel Vetter
Reviewed-by: Eugeni Dodonov
Signed-off-by: Keith Packard
Signed-off-by: Eugeni Dodonov
Signed-off-by: Greg Kroah-Hartman -
commit 07c1e8c1462fa7324de4c36ae9e55da2abd79cee upstream.
We don't need to check 3rd pipe specifically, as it shares PLL with some
other one.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41977
Signed-off-by: Eugeni Dodonov
Reviewed-by: Jesse Barnes
Signed-off-by: Keith Packard
Signed-off-by: Greg Kroah-Hartman -
commit 23bd15ec662344dc10e9918fdd0dbc58bc71526d upstream.
TV Out refresh rate was half of the specification for almost all modes.
Due to this reason pixel clock was so low for some modes causing flickering screen.Signed-off-by: Rodrigo Vivi
Reviewed-by: Jesse Barnes
Signed-off-by: Keith Packard
Signed-off-by: Eugeni Dodonov
Signed-off-by: Greg Kroah-Hartman -
commit 097354eb14fa94d31a09c64d640643f58e4a5a9a upstream.
Otherwise hangcheck spuriously fires when running blitter/bsd-only
workloads.Contrary to a similar patch by Ben Widawsky this does not check
INSTDONE of the other rings. Chris Wilson implied that in a failure to
detect a hang, most likely because INSTDONE was fluctuating. Thus only
check ACTHD, which as far as I know is rather reliable. Also, blitter
and bsd rings can't launch complex tasks from a single instruction
(like 3D_PRIM on the render with complex or even infinite shaders).This fixes spurious gpu hang detection when running
tests/gem_hangcheck_forcewake on snb/ivb.Signed-Off-by: Daniel Vetter
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard
Signed-off-by: Eugeni Dodonov
Signed-off-by: Greg Kroah-Hartman -
commit 832afda6a7d7235ef0e09f4ec46736861540da6d upstream.
On DP monitor hot remove, clear DP_AUDIO_OUTPUT_ENABLE accordingly,
so that the audio driver will receive hot plug events and take action
to refresh its device state and ELD contents.Note that the DP_AUDIO_OUTPUT_ENABLE bit may be enabled or disabled
only when the link training is complete and set to "Normal".Tested OK for both hot plug/remove and DPMS on/off.
Signed-off-by: Wu Fengguang
Signed-off-by: Keith Packard
Signed-off-by: Eugeni Dodonov
Signed-off-by: Greg Kroah-Hartman -
commit 2deed761188d7480eb5f7efbfe7aa77f09322ed8 upstream.
On HDMI monitor hot remove, clear SDVO_AUDIO_ENABLE accordingly, so that
the audio driver will receive hot plug events and take action to refresh
its device state and ELD contents.The cleared SDVO_AUDIO_ENABLE bit needs to be restored to prevent losing
HDMI audio after DPMS on.CC: Wang Zhenyu
Signed-off-by: Wu Fengguang
Signed-off-by: Keith Packard
Signed-off-by: Eugeni Dodonov
Signed-off-by: Greg Kroah-Hartman -
commit 853a0c25baf96b028de1654bea1e0c8857eadf3d upstream.
When we hit EIO while writing LVID, the buffer uptodate bit is cleared.
This then results in an anoying warning from mark_buffer_dirty() when we
write the buffer again. So just set uptodate flag unconditionally.Reviewed-by: Namjae Jeon
Signed-off-by: Jan Kara
Cc: Dave Jones
Signed-off-by: Greg Kroah-Hartman -
commit b189e810619a676e6b931a942a3e8387f3d39c21 upstream.
The driver uses __napi_complete and napi_gro_receive. Without it, the
driver hits the BUG_ON(n->gro_list) assertion hard in __napi_complete.Signed-off-by: Francois Romieu
Tested-by: Marin Glibic
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit fe9161db2e6053da21e4649d77bbefaf3030b11d upstream.
In the SNAPSHOT_CREATE_IMAGE ioctl, if the call to hibernation_snapshot()
fails, the frozen tasks are not thawed.And in the case of success, if we happen to exit due to a successful freezer
test, all tasks (including those of userspace) are thawed, whereas actually
we should have thawed only the kernel threads at that point. Fix both these
issues.Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 97819a26224f019e73d88bb2fd4eb5a614860461 upstream.
Commit 2aede851ddf08666f68ffc17be446420e9d2a056 (PM / Hibernate: Freeze
kernel threads after preallocating memory) moved the freezing of kernel
threads to hibernation_snapshot() function.So now, if the call to hibernation_snapshot() returns early due to a
successful hibernation test, the caller has to thaw processes to ensure
that the system gets back to its original state.But in SNAPSHOT_CREATE_IMAGE hibernation ioctl, the caller does not thaw
processes in case hibernation_snapshot() returned due to a successful
freezer test. Fix this issue. But note we still send the value of 'in_suspend'
(which is now 0) to userspace, because we are not in an error path per-se,
and moreover, the value of in_suspend correctly depicts the situation here.Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit cb297a3e433dbdcf7ad81e0564e7b804c941ff0d upstream.
This issue happens under the following conditions:
1. preemption is off
2. __ARCH_WANT_INTERRUPTS_ON_CTXSW is defined
3. RT scheduling class
4. SMP systemSequence is as follows:
1.suppose current task is A. start schedule()
2.task A is enqueued pushable task at the entry of schedule()
__schedule
prev = rq->curr;
...
put_prev_task
put_prev_task_rt
enqueue_pushable_task
4.pick the task B as next task.
next = pick_next_task(rq);
3.rq->curr set to task B and context_switch is started.
rq->curr = next;
4.At the entry of context_swtich, release this cpu's rq->lock.
context_switch
prepare_task_switch
prepare_lock_switch
raw_spin_unlock_irq(&rq->lock);
5.Shortly after rq->lock is released, interrupt is occurred and start IRQ context
6.try_to_wake_up() which called by ISR acquires rq->lock
try_to_wake_up
ttwu_remote
rq = __task_rq_lock(p)
ttwu_do_wakeup(rq, p, wake_flags);
task_woken_rt
7.push_rt_task picks the task A which is enqueued before.
task_woken_rt
push_rt_tasks(rq)
next_task = pick_next_pushable_task(rq)
8.At find_lock_lowest_rq(), If double_lock_balance() returns 0,
lowest_rq can be the remote rq.
(But,If preemption is on, double_lock_balance always return 1 and it
does't happen.)
push_rt_task
find_lock_lowest_rq
if (double_lock_balance(rq, lowest_rq))..
9.find_lock_lowest_rq return the available rq. task A is migrated to
the remote cpu/rq.
push_rt_task
...
deactivate_task(rq, next_task, 0);
set_task_cpu(next_task, lowest_rq->cpu);
activate_task(lowest_rq, next_task, 0);
10. But, task A is on irq context at this cpu.
So, task A is scheduled by two cpus at the same time until restore from IRQ.
Task A's stack is corrupted.To fix it, don't migrate an RT task if it's still running.
Signed-off-by: Chanho Min
Signed-off-by: Peter Zijlstra
Acked-by: Steven Rostedt
Link: http://lkml.kernel.org/r/CAOAMb1BHA=5fm7KTewYyke6u-8DP0iUuJMpgQw54vNeXFsGpoQ@mail.gmail.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 304a48400d9718f74ec35ae46f30868a5f4c4516 upstream.
Different versions of the DP to LVDS bridge chip
need different panel mode settings depending on
the chip version used.Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41569Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 86698c20f71d488b32c49ed4687fb3cf8a88a5ca upstream.
Polling the outputs when the device is suspended can result in erroneous
status updates. Disable output polling during suspend to prevent this
from happening.Signed-off-by: Seth Forshee
Reviewed-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 525895ba388c949aa906f26e3ec5cb1ab041f56b upstream.
Due to a race it was possible for a fence to be destroyed while another
thread was trying to synchronise with it. If this happened in the fallback
non-semaphore path, it lead to the following oops due to fence->channel
being NULL.BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] nouveau_fence_update+0xe/0xe0 [nouveau]
*pde = a649c067
SMP
Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi]Pid: 2255, comm: gnome-shell Tainted: G O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM
EIP: 0060:[] EFLAGS: 00010296 CPU: 1
EIP is at nouveau_fence_update+0xe/0xe0 [nouveau]
EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000
ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000)
Stack:
7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f
00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0
00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000
Call Trace:
[] __nouveau_fence_signalled+0x1f/0x30 [nouveau]
[] __nouveau_fence_wait+0x43/0xd0 [nouveau]
[] nouveau_fence_sync+0x1a0/0x1c0 [nouveau]
[] validate_list+0x176/0x300 [nouveau]
[] ? ttm_bo_mem_put+0x30/0x30 [ttm]
[] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau]
[] ? die+0x31/0x80
[] drm_ioctl+0x388/0x490 [drm]
[] ? die+0x31/0x80
[] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau]
[] ? file_has_perm+0xcb/0xe0
[] ? drm_copy_field+0x80/0x80 [drm]
[] do_vfs_ioctl+0x86/0x5b0
[] ? die+0x31/0x80
[] ? selinux_file_ioctl+0x62/0x130
[] ? fget_light+0x30/0x340
[] sys_ioctl+0x6f/0x80
[] syscall_call+0x7/0xb
[] ? die+0x31/0x80
[] ? die+0x31/0x80Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit 1b61925061660009f5b8047f93c5297e04541273 upstream.
The value of this register is transferred to the V_COUNTER register at the
beginning of vertical blank. V_COUNTER is the reference for VLINE waits and
goes from VIEWPORT_Y_START to VIEWPORT_Y_START+VIEWPORT_HEIGHT during scanout,
so if VIEWPORT_Y_START is not 0, V_COUNTER actually went backwards at the
beginning of vertical blank, and VLINE waits excluding the whole scanout area
could never finish (possibly only if VIEWPORT_Y_START is larger than the length
of vertical blank in scanlines). Setting DESKTOP_HEIGHT to the framebuffer
height should prevent this for any kind of VLINE wait.Fixes https://bugs.freedesktop.org/show_bug.cgi?id=45329 .
Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit d020283dc694c9ec31b410f522252f7a8397e67d upstream.
Looks like change "PM QoS: Move and rename the implementation files"
merged during the 3.2 development cycle made PM QoS depend on
CONFIG_PM which depends on (PM_SLEEP || PM_RUNTIME).That breaks CPU C-states with kernels not having these CONFIGs, causing CPUs
to spend time in Polling loop idle instead of going into deep C-states,
consuming way way more power. This is with either acpi idle or intel idle
enabled.Either CONFIG_PM should be enabled with any pm_qos users or
the !CONFIG_PM pm_qos_request() should return sane defaults not to break
the existing users. Here's is the patch for the latter option.[rjw: Modified the changelog slightly.]
Signed-off-by: Venkatesh Pallipadi
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 181e9bdef37bfcaa41f3ab6c948a2a0d60a268b5 upstream.
Commit 2aede851ddf08666f68ffc17be446420e9d2a056
PM / Hibernate: Freeze kernel threads after preallocating memory
introduced a mechanism by which kernel threads were frozen after
the preallocation of hibernate image memory to avoid problems with
frozen kernel threads not responding to memory freeing requests.
However, it overlooked the s2disk code path in which the
SNAPSHOT_CREATE_IMAGE ioctl was run directly after SNAPSHOT_FREE,
which caused freeze_workqueues_begin() to BUG(), because it saw
that worqueues had been already frozen.Although in principle this issue might be addressed by removing
the relevant BUG_ON() from freeze_workqueues_begin(), that would
reintroduce the very problem that commit 2aede851ddf08666f68ffc17be4
attempted to avoid into that particular code path. For this reason,
to fix the issue at hand, introduce thaw_kernel_threads() and make
the SNAPSHOT_FREE ioctl execute it.Special thanks to Srivatsa S. Bhat for detailed analysis of the
problem.Reported-and-tested-by: Jiri Slaby
Signed-off-by: Rafael J. Wysocki
Acked-by: Srivatsa S. Bhat
Signed-off-by: Greg Kroah-Hartman -
…ing isolation for migration
commit 0bf380bc70ecba68cb4d74dc656cc2fa8c4d801a upstream.
When isolating for migration, migration starts at the start of a zone
which is not necessarily pageblock aligned. Further, it stops isolating
when COMPACT_CLUSTER_MAX pages are isolated so migrate_pfn is generally
not aligned. This allows isolate_migratepages() to call pfn_to_page() on
an invalid PFN which can result in a crash. This was originally reported
against a 3.0-based kernel with the following trace in a crash dump.PID: 9902 TASK: d47aecd0 CPU: 0 COMMAND: "memcg_process_s"
#0 [d72d3ad0] crash_kexec at c028cfdb
#1 [d72d3b24] oops_end at c05c5322
#2 [d72d3b38] __bad_area_nosemaphore at c0227e60
#3 [d72d3bec] bad_area at c0227fb6
#4 [d72d3c00] do_page_fault at c05c72ec
#5 [d72d3c80] error_code (via page_fault) at c05c47a4
EAX: 00000000 EBX: 000c0000 ECX: 00000001 EDX: 00000807 EBP: 000c0000
DS: 007b ESI: 00000001 ES: 007b EDI: f3000a80 GS: 6f50
CS: 0060 EIP: c030b15a ERR: ffffffff EFLAGS: 00010002
#6 [d72d3cb4] isolate_migratepages at c030b15a
#7 [d72d3d14] zone_watermark_ok at c02d26cb
#8 [d72d3d2c] compact_zone at c030b8de
#9 [d72d3d68] compact_zone_order at c030bba1
#10 [d72d3db4] try_to_compact_pages at c030bc84
#11 [d72d3ddc] __alloc_pages_direct_compact at c02d61e7
#12 [d72d3e08] __alloc_pages_slowpath at c02d66c7
#13 [d72d3e78] __alloc_pages_nodemask at c02d6a97
#14 [d72d3eb8] alloc_pages_vma at c030a845
#15 [d72d3ed4] do_huge_pmd_anonymous_page at c03178eb
#16 [d72d3f00] handle_mm_fault at c02f36c6
#17 [d72d3f30] do_page_fault at c05c70ed
#18 [d72d3fb0] error_code (via page_fault) at c05c47a4
EAX: b71ff000 EBX: 00000001 ECX: 00001600 EDX: 00000431
DS: 007b ESI: 08048950 ES: 007b EDI: bfaa3788
SS: 007b ESP: bfaa36e0 EBP: bfaa3828 GS: 6f50
CS: 0073 EIP: 080487c8 ERR: ffffffff EFLAGS: 00010202It was also reported by Herbert van den Bergh against 3.1-based kernel
with the following snippet from the console log.BUG: unable to handle kernel paging request at 01c00008
IP: [<c0522399>] isolate_migratepages+0x119/0x390
*pdpt = 000000002f7ce001 *pde = 0000000000000000It is expected that it also affects 3.2.x and current mainline.
The problem is that pfn_valid is only called on the first PFN being
checked and that PFN is not necessarily aligned. Lets say we have a case
like thisH = MAX_ORDER_NR_PAGES boundary
| = pageblock boundary
m = cc->migrate_pfn
f = cc->free_pfn
o = memory holeH------|------H------|----m-Hoooooo|ooooooH-f----|------H
The migrate_pfn is just below a memory hole and the free scanner is beyond
the hole. When isolate_migratepages started, it scans from migrate_pfn to
migrate_pfn+pageblock_nr_pages which is now in a memory hole. It checks
pfn_valid() on the first PFN but then scans into the hole where there are
not necessarily valid struct pages.This patch ensures that isolate_migratepages calls pfn_valid when
necessary.Reported-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
Tested-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Acked-by: Michal Nazarewicz <mina86@mina86.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@linuxfoundation.org> -
commit 99f02ef1f18631eb0a4e0ea0a3d56878dbcb4b90 upstream.
Fix a race condition that shows in conjunction with xip_file_fault() when
two threads of the same user process fault on the same memory page.In this case, the race winner will install the page table entry and the
unlucky loser will cause an oops: xip_file_fault calls vm_insert_pfn (via
vm_insert_mixed) which drops out at this check:retval = -EBUSY;
if (!pte_none(*pte))
goto out_unlock;The resulting -EBUSY return value will trigger a BUG_ON() in
xip_file_fault.This fix simply considers the fault as fixed in this case, because the
race winner has successfully installed the pte.[akpm@linux-foundation.org: use conventional (and consistent) comment layout]
Reported-by: David Sadler
Signed-off-by: Carsten Otte
Reported-by: Louis Alex Eisner
Cc: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit bda3a47c886664e86ee14eb79e9072b9e341f575 upstream.
commit 463894705e4089d0ff69e7d877312d496ac70e5b deleted redundant
chan_id and chancnt initialization in dma drivers as this is done
in dma_async_device_register().However, atc_enable_irq() relied on chan_id set before registering
the device, what left only channel 0 functional for this driver.This patch introduces atc_enable/disable_chan_irq() as a variant
of atc_enable/disable_irq() with the channel as explicit argument.Signed-off-by: Nikolaus Voss
Signed-off-by: Nicolas Ferre
Signed-off-by: Vinod Koul
Signed-off-by: Greg Kroah-Hartman -
commit 500823195d0c9eec2a4637484f30cc93ec633d4a upstream.
This reverts commit fb5427508abbd635e877fabdf55795488119c2d6.
The reason is that it breaks 16 bits NAND flash as it was reported by
Nikolaus Voss and confirmed by Eric Bénard.Nicolas Ferre alco confirmed:
"After double checking with designers, I must admit that I misunderstood
the way of optimizing accesses to SMC. 16 bit nand is not so common
those days..."Reported-by: Nikolaus Voss
Acked-by: Nicolas Ferre
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
commit 9398d1ce09b9009996f7d2468e1d3c785fa6feda upstream.
In MX28, if we do not reset the BCH module. The BCH module may
becomes unstable when the board reboots for several thousands times.
This bug has been catched in customer's production.The patch adds some comments (some from Wolfram Sang), and fixes it now.
Also change gpmi_reset_block() to static.
Signed-off-by: Huang Shijie
Acked-by: Marek Vasut
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
commit 55ca6140e9bb307efc97a9301a4f501de02a6fd6 upstream.
In function pre_handler_kretprobe(), the allocated kretprobe_instance
object will get leaked if the entry_handler callback returns non-zero.
This may cause all the preallocated kretprobe_instance objects exhausted.This issue can be reproduced by changing
samples/kprobes/kretprobe_example.c to probe "mutex_unlock". And the fix
is straightforward: just put the allocated kretprobe_instance object back
onto the free_instances list.[akpm@linux-foundation.org: use raw_spin_lock/unlock]
Signed-off-by: Jiang Liu
Acked-by: Jim Keniston
Acked-by: Ananth N Mavinakayanahalli
Cc: Masami Hiramatsu
Cc: Anil S Keshavamurthy
Cc: "David S. Miller"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit e47e321a35c741ee41b67976f8c6a3a7a42bc5c0 upstream.
We have just been investigating kernel panics related to
cq->ibcq.event_handler() completion calls. The problem is that
ib_destroy_qp() fails with -EBUSY.Further investigation revealed qp->usecnt is not initialized. This
counter was introduced in linux-3.2 by commit 0e0ec7e0638e
("RDMA/core: Export ib_open_qp() to share XRC TGT QPs") but it only
gets initialized for IB_QPT_XRC_TGT, but it is checked in
ib_destroy_qp() for any QP type.Fix this by initializing qp->usecnt for every QP we create.
Signed-off-by: Bernd Schubert
Signed-off-by: Sven Breuner[ Initialize qp->usecnt in uverbs too. - Sean ]
Signed-off-by: Sean Hefty
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit a6f7feae6d19e84253918d88b04153af09d3a243 upstream.
In the current code, vendor-specific MADs (e.g with the FDR-10
attribute) are silently dropped by the driver, resulting in timeouts
at the sending side and inability to query/configure the relevant
feature. However, the ConnectX firmware is able to handle such MADs.
For unsupported attributes, the firmware returns a GET_RESPONSE MAD
containing an error status.For example, for a FDR-10 node with LID 11:
# ibstat mlx4_0 1
CA: 'mlx4_0'
Port 1:
State: Active
Physical state: LinkUp
Rate: 40 (FDR10)
Base lid: 11
LMC: 0
SM lid: 24
Capability mask: 0x02514868
Port GUID: 0x0002c903002e65d1
Link layer: InfiniBandExtended Port Query (EPI) vendor mad timeouts before the patch:
# smpquery MEPI 11 -d
ibwarn: [4196] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
ibwarn: [4196] _do_madrpc: retry 1 (timeout 1000 ms)
ibwarn: [4196] _do_madrpc: retry 2 (timeout 1000 ms)
ibwarn: [4196] _do_madrpc: timeout after 3 retries, 3000 ms
ibwarn: [4196] mad_rpc: _do_madrpc failed; dport (Lid 11)
smpquery: iberror: [pid 4196] main: failed: operation EPI: ext port info query failedEPI query works OK with the patch:
# smpquery MEPI 11 -d
ibwarn: [6548] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
ibwarn: [6548] mad_rpc: data offs 64 sz 64
mad data
0000 0000 0000 0001 0000 0001 0000 0001
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
# Ext Port info: Lid 11 port 0
StateChangeEnable:...............0x00
LinkSpeedSupported:..............0x01
LinkSpeedEnabled:................0x01
LinkSpeedActive:.................0x01Signed-off-by: Jack Morgenstein
Signed-off-by: Or Gerlitz
Acked-by: Ira Weiny
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit 320cfa6ce0b3dc794fedfa4bae54c0f65077234d upstream.
The PCIe device
FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd FireWire Host Controller
[1180:e832] (prog-if 10 [OHCI])is unable to access attached FireWire devices when MSI is enabled but
works if MSI is disabled.
http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28251.htmlHence add the "disable MSI" quirks flag for this device, or in fact for
safety and simplicity for all current (R5U230, R5U231, R5U240) and
future Ricoh PCIe 1394 controllers.Reported-by: Stefan Thomas
Signed-off-by: Stefan Richter
Signed-off-by: Greg Kroah-Hartman -
commit d1bb399ad03c11e792f6dea198d3b1e23061f094 upstream.
The Audigy's SB1394 controller is actually from Texas Instruments
and has the same bus reset packet generation bug, so it needs the
same quirk entry.Signed-off-by: Clemens Ladisch
Signed-off-by: Stefan Richter
Signed-off-by: Greg Kroah-Hartman -
commit 6d08f2c7139790c268820a2e590795cb8333181a upstream.
Once /proc/pid/mem is opened, the memory can't be released until
mem_release() even if its owner exits.Change mem_open() to do atomic_inc(mm_count) + mmput(), this only
pins mm_struct. Change mem_rw() to do atomic_inc_not_zero(mm_count)
before access_remote_vm(), this verifies that this mm is still alive.I am not sure what should mem_rw() return if atomic_inc_not_zero()
fails. With this patch it returns zero to match the "mm == NULL" case,
may be it should return -EINVAL like it did before e268337d.Perhaps it makes sense to add the additional fatal_signal_pending()
check into the main loop, to ensure we do not hold this memory if
the target task was oom-killed.Signed-off-by: Oleg Nesterov
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 572d34b946bae070debd42db1143034d9687e13f upstream.
No functional changes, cleanup and preparation.
mem_read() and mem_write() are very similar. Move this code into the
new common helper, mem_rw(), which takes the additional "int write"
argument.Signed-off-by: Oleg Nesterov
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 71879d3cb3dd8f2dfdefb252775c1b3ea04a3dd4 upstream.
mem_release() can hit mm == NULL, add the necessary check.
Signed-off-by: Oleg Nesterov
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit cbcb8346054073d000ecac324763372d6abd44ac upstream.
KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland
with a 64bit kernel if the font width is not 8.This is because of the setting of the KD_FONT_FLAG_OLD flag, which makes
con_font_get return EIO in such case.This flag should *not* be set for KDFONTOP, since it's actually the whole
point of this flag (see comment in con_font_set for instance).Signed-off-by: Samuel Thibault
Reviewed-by: Arnd Bergmann
Cc: Arthur Taylor
Cc: Jiri Slaby
Cc: Jiri Olsa
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 8ef5d844cc3a644ea6f7665932a4307e9fad01fa upstream.
following statement can only change device size from 8-bit(0) to 16-bit(1),
but not vice versa:regval |= GPMC_CONFIG1_DEVICESIZE(wval);
so as this field has 1 reserved bit, that could be used in future,
just clear both bits and then OR with the desired valueSigned-off-by: Yegor Yefremov
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f upstream.
If we are context switched whilst copying into a thread's
vfp_hard_struct then the partial copy may be corrupted by the VFP
context switching code (see "ARM: vfp: flush thread hwstate before
restoring context from sigframe").This patch updates the ptrace VFP set code so that the thread state is
flushed before the copy, therefore disabling VFP and preventing
corruption from occurring.Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit 247f4993a5974e6759606c4d380748eecfd273ff upstream.
In a preemptible kernel, vfp_set() can be preempted, causing the
hardware VFP context to be switched while the thread vfp state is
being read and modified. This leads to a race condition which can
cause the thread vfp state to become corrupted if lazy VFP context
save occurs due to preemption in between the time thread->vfpstate
is read and the time the modified state is written back.This may occur if preemption occurs during the execution of a
ptrace() call which modifies the VFP register state of a thread.
Such instances should be very rare in most realistic scenarios --
none has been reported, so far as I am aware. Only uniprocessor
systems should be affected, since VFP context save is not currently
lazy in SMP kernels.The problem was introduced by my earlier patch migrating to use
regsets to implement ptrace.This patch does a vfp_sync_hwstate() before reading
thread->vfpstate, to make sure that the thread's VFP state is not
live in the hardware registers while the registers are modified.Thanks to Will Deacon for spotting this.
Signed-off-by: Dave Martin
Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman
