| Age | Commit message (Collapse) | Author |
|---|
|
If subbuf_pages was larger than the max number of pages the pipe
buffer will hold, subbuf_splice_actor() would happily go beyond
the array size.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
no longer working for some time.
A driver that had been marked as BROKEN for such a long time seems to be
unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still present in
the older kernel releases.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Acked-by: Alan Cox <alan@redhat.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
This fixes a problem on 64-bit with 4GB with ATI RS690 chipsets. It
makes sure the pcigart table is allocated in coherent memory for DMA operations.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This fixes up the RV550 chips which are based on RV515, not RV530.
It also adds another RS690 PCI ID.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
It's worth remembering that all new bright ideas on how to make this command reader work properly and according to docs will probably fail :( Bring in some old code.
Also allow a larger SG-DMA download stride, and remove unnecessary waits for
command regulators pauses.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The i915_vblank_swap() function schedules an automatic buffer swap
upon receipt of the vertical sync interrupt. Such an operation is
lengthy so it can't be allowed to happen in normal interrupt context,
thus the DRM implements this by scheduling the work in a kernel
softirq-scheduled tasklet. In order for the buffer swap to work
safely, the DRM's central lock must be taken, via a call to
drm_lock_take() located in drivers/char/drm/drm_irq.c within the
function drm_locked_tasklet_func(). The lock-taking logic uses a
non-interrupt-blocking spinlock to implement the manipulations needed
to take the lock. This semantic would be safe if all attempts to use
the spinlock only happen from process context. However this buffer
swap happens from softirq context which is really a form of interrupt
context. Thus we have an unsafe situation, in that
drm_locked_tasklet_func() can block on a spinlock already taken by a
thread in process context which will never get scheduled again because
of the blocked softirq tasklet. This wedges the kernel hard.
To trigger this bug, run a dual-head cloned mode configuration which
uses the i915 drm, then execute an opengl application which
synchronizes buffer swaps against the vertical sync interrupt. In my
testing, a lockup always results after running anywhere from 5 minutes
to an hour and a half. I believe dual-head is needed to really
trigger the problem because then the vertical sync interrupt handling
is no longer predictable (due to being interrupt-sourced from two
different heads running at different speeds). This raises the
probability of the tasklet trying to run while the userspace DRI is
doing things to the GPU (and manipulating the DRM lock).
The fix is to change the relevant spinlock semantics to be the
interrupt-blocking form. After this change I am no longer able to
trigger the lockup; the longest test run so far was 20 hours (test
stopped after that point).
Note: I have examined the places where this spinlock is being
employed; all are reasonably short bounded sequences and should be
suitable for interrupts being blocked without impacting overall kernel
interrupt response latency.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6
* 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6:
[PARISC] make ptr_to_pide() static
[PARISC] head.S: section mismatch fixes
[PARISC] add back Crestone Peak cpu
[PARISC] futex: special case cmpxchg NULL in kernel space
[PARISC] clean up show_stack
[PARISC] add pa8900 CPUs to hardware inventory
[PARISC] clean up include/asm-parisc/elf.h
[PARISC] move defconfig to arch/parisc/configs/
[PARISC] add back AD1889 MAINTAINERS entry
[PARISC] pdc_console: fix bizarre panic on boot
[PARISC] dump_stack in show_regs
[PARISC] pdc_stable: fix compile errors
[PARISC] remove unused pdc_iodc_printf function
[PARISC] bump __NR_syscalls
[PARISC] unbreak pgalloc.h
[PARISC] move VMALLOC_* definitions to fixmap.h
[PARISC] wire up timerfd syscalls
[PARISC] remove old timerfd syscall
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
- move boot_args[] into the init section
- move $global$ into the read_mostly section
- fix the following two section mismatches:
WARNING: vmlinux.o(.text+0x9c): Section mismatch: reference to .init.text:start_kernel (between '$pgt_fill_loop' and '$is_pa20')
WARNING: vmlinux.o(.text+0xa0): Section mismatch: reference to .init.text:start_kernel (between '$pgt_fill_loop' and '$is_pa20')
Signed-off-by: Helge Deller <deller@gmx.de>
SIgned-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
|
Crestone Peak Slow is the 800MHz PA-8800 cpu in the C8000.
0x88B is probably the Crestone Peak Fast.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
|
Commit a0c1e9073ef7428a14309cba010633a6cd6719ea added code to futex.c
to detect whether futex_atomic_cmpxchg_inatomic was implemented at run
time:
+ curval = cmpxchg_futex_value_locked(NULL, 0, 0);
+ if (curval == -EFAULT)
+ futex_cmpxchg_enabled = 1;
This is bogus on parisc, since page zero in kernel virtual space is the
gateway page for syscall entry, and should not be read from the kernel.
(That, and we really don't like the kernel faulting on its own address
space...)
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
|
When we show_regs, we obviously have a struct pt_regs of the calling
frame. Use these in show_stack so we don't have the entire bogus call trace
up to the show_stack call.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
|
This patch adds the known pa8900 CPUs to the inventory list and removes
the Crestone Peak one which apparently never escaped into the wild.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
|
Cleanup some cruft. No functionality changes.
Signed-off-by: Randolph Chung <tausq@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
|
This patch moves the default parisc defconfig to
arch/parisc/configs/generic_defconfig where it belongs and selects it as
the default defconfig through KBUILD_DEFCONFIG.
Signed-off-by: Adrian Bunk <adrian.bunk@movial.fi>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
|
Signed-off-by: Thibaut VARENE <T-Bone@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
|
|
Commit 721fdf34167580ff98263c74cead8871d76936e6 introduced a subtle bug
by accidently removing the "static" from iodc_dbuf. This resulted in, what
appeared to be, a trap without *current set to a task. Probably the result of
a trap in real mode while calling firmware.
Also do other misc clean ups. Since the only input from firmware is non
blocking, share iodc_dbuf between input and output, and spinlock the
only callers.
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
Originally, show_stack was used in BUG() output. However, a recent commit
changed it to print register state (no idea what that's supposed to help,
really...) and parisc was missing a backtrace because of it.
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
Signed-off-by: Joel Soete <rubisher@scarlet.be>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
oops, forgot this in the previous commit.
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
Commit 2f569afd9ced9ebec9a6eb3dbf6f83429be0a7b4 broke the compile
rather spectacularly. Fix code errors.
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
They make way more sense here, really...
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
|
|
This essentially reverts commit 71fc47a9adf8ee89e5c96a47222915c5485ac437
("ACPI: basic initramfs DSDT override support"), because the code simply
isn't ready.
It did ugly things to the init sequence to populate the rootfs image
early, but that just ended up showing other problems with the whole
approach. The fact is, the VFS layer simply isn't initialized this
early, and the relevant ACPI code should either run much later, or this
shouldn't be done at all.
For 2.6.25, we'll just pick the latter option. We can revisit this
concept later if necessary.
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Eric Piel <eric.piel@tremplin-utc.net>
Cc: Len Brown <len.brown@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Markus Gaugusch <dsdt@gaugusch.at>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
DATA_CARRY is not boolean
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
[NET]: Fix tbench regression in 2.6.25-rc1
|
|
Use the existing calc_delta_mine() calculation for sched_slice(). This
saves a divide and simplifies the code because we share it with the
other /cfs_rq->load users.
It also improves code size:
text data bss dec hex filename
42659 2740 144 45543 b1e7 sched.o.before
42093 2740 144 44977 afb1 sched.o.after
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
|
|
Fair sleepers need to scale their latency target down by runqueue
weight. Otherwise busy systems will gain ever larger sleep bonus.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
|
|
Currently we schedule to the leftmost task in the runqueue. When the
runtimes are very short because of some server/client ping-pong,
especially in over-saturated workloads, this will cycle through all
tasks trashing the cache.
Reduce cache trashing by keeping dependent tasks together by running
newly woken tasks first. However, by not running the leftmost task first
we could starve tasks because the wakee can gain unlimited runtime.
Therefore we only run the wakee if its within a small
(wakeup_granularity) window of the leftmost task. This preserves
fairness, but does alternate server/client task groups.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
lw->weight can be 0 for a short time during bootup.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
|
|
Clear the cached inverse value when updating load. This is needed for
calc_delta_mine() to work correctly when using the rq load.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
|
|
Current min_vruntime tracking is incorrect and will cause serious
problems when we don't run the leftmost task for some reason.
min_vruntime does two things; 1) it's used to determine a forward
direction when the u64 vruntime wraps, 2) it's used to track the
leftmost vruntime to position newly enqueued tasks from.
The current logic advances min_vruntime whenever the current task's
vruntime advance. Because the current task may pass the leftmost task
still waiting we're failing the second goal. This causes new tasks to be
placed too far ahead and thus penalizes their runtime.
Fix this by making min_vruntime the min_vruntime of the waiting tasks by
tracking it in enqueue/dequeue, and compare against current's vruntime
to obtain the absolute minimum when placing new tasks.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Fix a hard to trigger crash seen in the -rt kernel that also affects
the vanilla scheduler.
There is a race condition between schedule() and some dequeue/enqueue
functions; rt_mutex_setprio(), __setscheduler() and sched_move_task().
When scheduling to idle, idle_balance() is called to pull tasks from
other busy processor. It might drop the rq lock. It means that those 3
functions encounter on_rq=0 and running=1. The current task should be
put when running.
Here is a possible scenario:
CPU0 CPU1
| schedule()
| ->deactivate_task()
| ->idle_balance()
| -->load_balance_newidle()
rt_mutex_setprio() |
| --->double_lock_balance()
*get lock *rel lock
* on_rq=0, ruuning=1 |
* sched_class is changed |
*rel lock *get lock
: |
:
->put_prev_task_rt()
->pick_next_task_fair()
=> panic
The current process of CPU1(P1) is scheduling. Deactivated P1, and the
scheduler looks for another process on other CPU's runqueue because CPU1
will be idle. idle_balance(), load_balance_newidle() and
double_lock_balance() are called and double_lock_balance() could drop
the rq lock. On the other hand, CPU0 is trying to boost the priority of
P1. The result of boosting only P1's prio and sched_class are changed to
RT. The sched entities of P1 and P1's group are never put. It makes
cfs_rq invalid, because the cfs_rq has curr and no leaf, but
pick_next_task_fair() is called, then the kernel panics.
Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: fw-ohci: shut up false compiler warning on PPC32
firewire: fw-ohci: use dma_alloc_coherent for ar_buffer
ieee1394: sbp2: fix for SYM13FW500 bridge (Datafab disk)
firewire: fw-sbp2: fix for SYM13FW500 bridge (Datafab disk)
firewire: update Kconfig help text
firewire: warn on fatal condition in topology code
firewire: fw-sbp2: set single-phase retry_limit
firewire: fw-ohci: Apple UniNorth 1st generation support
firewire: fw-ohci: PPC PMac platform code
firewire: endianess annotations
firewire: endianess fix
|
|
This bug was always here, but before my commit 6fa02839bf9412e18e77
("recheck for secure ports in fh_verify"), it could only be triggered by
failure of a kmalloc(). After that commit it could be triggered by a
client making a request from a non-reserved port for access to an export
marked "secure". (Exports are "secure" by default.)
The result is a struct svc_export with a reference count one too low,
resulting in likely oopses next time the export is accessed.
The reference counting here is not straightforward; a later patch will
clean up fh_verify().
Thanks to Lukas Hejtmanek for the bug report and followup.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The comments in the definition of struct export_operations don't match the
current members.
Add a comment for the 2 new functions and remove 2 comments for unused ones.
Signed-off-by: Marc Dionne <marc.c.dionne@gmail.com>
Acked-by: David Howells <dhowells@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Add support for new wacom tablets - Bamboo1, BambooFun, and Cintiq 12WX
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
Document 'noloop' kernel parameter of i8042 controller driver.
Pointed out in #10236.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
Document the keyboard notifier.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
SIgned-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
drivers/input/touchscreen/ads7846.c: In function 'ads7846_read12_ser':
drivers/input/touchscreen/ads7846.c:216: warning: 'sample' may be used uninitialized in this function
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
SNI RM200 don't have the i8042 controller connected to the EISA bus,
but have a second address range for onboard devices. This patch handles
the two possible address ranges for the i8042 on SNI RMs.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
Lenovo 3000 N100 needs entry in nomux blacklist.
Reported-by: Christopher Desjardins <cddesjardins@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
Commit c18bab80 ("Input: i8042 - non-x86 build fix") introduced the
following warning on non-x86 builds:
drivers/input/serio/i8042.c: In function 'i8042_probe':
drivers/input/serio/i8042.c:1154: warning: unused variable 'param'
Fix this by moving the parameter variable declaration into the #ifdef too.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
- fix compile errors (keymap is in bdev, not pdev)
- cdev is no more (must use dev.parent)
- update copiright notice
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
This avoids the harmless WARNING by lockdep in acpi_processor_idle().
The reason for WARNING is because at the depth of idle handling code,
some of the idle handlers disable interrupts, some times, while returning from
the idle handler. After return, acpi_processor_idle and few other routines
in the file did an unconditional local_irq_enable(). With LOCKDEP, enabling
irq when it is already enabled generates the below WARNING.
> > [ 0.593038] ------------[ cut here ]------------
> > [ 0.593267] WARNING: at kernel/lockdep.c:2035 trace_hardirqs_on+0xa0/0x115()
> > [ 0.593596] Modules linked in:
> > [ 0.593756] Pid: 0, comm: swapper Not tainted 2.6.25-rc5 #8
> > [ 0.594017]
> > [ 0.594017] Call Trace:
> > [ 0.594216] [<ffffffff80231663>] warn_on_slowpath+0x58/0x6b
> > [ 0.594495] [<ffffffff80495966>] ? _spin_unlock_irqrestore+0x38/0x47
> > [ 0.594809] [<ffffffff80329a86>] ? acpi_os_release_lock+0x9/0xb
> > [ 0.595103] [<ffffffff80337840>] ? acpi_set_register+0x161/0x173
> > [ 0.595401] [<ffffffff8034c8d4>] ? acpi_processor_idle+0x1de/0x546
> > [ 0.595706] [<ffffffff8020a23b>] ? default_idle+0x0/0x73
> > [ 0.595970] [<ffffffff8024fc0e>] trace_hardirqs_on+0xa0/0x115
> > [ 0.596049] [<ffffffff8034c6f6>] ? acpi_processor_idle+0x0/0x546
> > [ 0.596346] [<ffffffff8034c8d4>] acpi_processor_idle+0x1de/0x546
> > [ 0.596642] [<ffffffff8020a23b>] ? default_idle+0x0/0x73
> > [ 0.596912] [<ffffffff8034c6f6>] ? acpi_processor_idle+0x0/0x546
> > [ 0.597209] [<ffffffff8020a23b>] ? default_idle+0x0/0x73
> > [ 0.597472] [<ffffffff8020a355>] cpu_idle+0xa7/0xd1
> > [ 0.597717] [<ffffffff80485fa1>] rest_init+0x55/0x57
> > [ 0.597957] [<ffffffff8062fb49>] start_kernel+0x29d/0x2a8
> > [ 0.598215] [<ffffffff8062f1da>] _sinittext+0x1da/0x1e1
> > [ 0.598464]
> > [ 0.598546] ---[ end trace 778e504de7e3b1e3 ]---
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Shut up "may be used uninitialised in this function" warnings due to
PPC32's implementation of dma_alloc_coherent().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Currently, we do nothing to guarantee we have a consistent DMA buffer for
asynchronous receive packets. Rather than doing several sync's following a
dma_map_single() to get consistent buffers, just switch to using
dma_alloc_coherent().
Resolves constant buffer failures on my own x86_64 laptop w/4GB of RAM and
likely to fix a number of other failures witnessed on x86_64 systems with
4GB of RAM or more.
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
