Displaying 11 results from an estimated 11 matches for "atomic_add_unless".
Did you mean:
atomic64_add_unless
2009 Oct 26
9
Latest Pv_ops dom0 fails to boot
...fff5b089cb0 error 4 in nash[400000+239000]
[ 0.862695] Kernel panic - not syncing: Attempted to kill init!
[ 0.862702] Pid: 1, comm: init Not tainted 2.6.31.4 #1
[ 0.862708] Call Trace:
[ 0.862721] [<ffffffff8106a6b9>] panic+0xa0/0x15f
[ 0.862730] [<ffffffff8109d3f1>] ? atomic_add_unless+0x29/0x42
[ 0.862739] [<ffffffff810901bd>] ? raw_local_irq_disable+0x19/0x1b
[ 0.862748] [<ffffffff8152d02e>] ? _write_lock_irq+0xd/0x21
[ 0.862756] [<ffffffff8107327b>] ? raw_local_irq_enable+0x19/0x1b
[ 0.862763] [<ffffffff81073b65>] ? exit_ptrace+0xa0/0x11...
2015 Oct 19
1
[PATCH] drm/virtio: use %llu format string form atomic64_t
...prototype and x86 only differs
in the use of inline instead __inline__. And anyway, that function on
MIPS is only built for CONFIG_64BIT.
What's wrong on MIPS is the comment describing the function's return value
which was changed by f24219b4e90cf70ec4a211b17fbabc725a0ddf3c (atomic: move
atomic_add_unless to generic code) and I've queued up a patch to fix that
since a few days. I guess that was a cut and paste error from
__atomic_add_unless which indeed does return the old value.
Ralf
2015 Oct 19
1
[PATCH] drm/virtio: use %llu format string form atomic64_t
...prototype and x86 only differs
in the use of inline instead __inline__. And anyway, that function on
MIPS is only built for CONFIG_64BIT.
What's wrong on MIPS is the comment describing the function's return value
which was changed by f24219b4e90cf70ec4a211b17fbabc725a0ddf3c (atomic: move
atomic_add_unless to generic code) and I've queued up a patch to fix that
since a few days. I guess that was a cut and paste error from
__atomic_add_unless which indeed does return the old value.
Ralf
2015 Oct 19
0
[PATCH] drm/virtio: use %llu format string form atomic64_t
...e instead __inline__. And anyway, that function on
> MIPS is only built for CONFIG_64BIT.
Ah, got it. Sorry about that.
> What's wrong on MIPS is the comment describing the function's return value
> which was changed by f24219b4e90cf70ec4a211b17fbabc725a0ddf3c (atomic: move
> atomic_add_unless to generic code) and I've queued up a patch to fix that
> since a few days. I guess that was a cut and paste error from
> __atomic_add_unless which indeed does return the old value.
Thanks!
Arnd
2012 Aug 23
2
Kernel panic - not syncing: Attempted to kill init
.../sbin/init: No such file or directory
[ 6.272833] Kernel panic - not syncing: Attempted to kill init!
[ 6.272870] Pid: 1, comm: run-init Not tainted 2.6.32.57 #1
[ 6.272888] Call Trace:
[ 6.272919] [<ffffffff8107758b>] panic+0xa0/0x168
[ 6.272947] [<ffffffff810b038e>] ? atomic_add_unless+0x29/0x42
[ 6.272977] [<ffffffff810a1166>] ? raw_local_irq_disable+0x19/0x1b
[ 6.273005] [<ffffffff81080350>] ? raw_local_irq_enable+0x19/0x1b
[ 6.273032] [<ffffffff81080362>] ? __write_unlock_irq+0x10/0x12
[ 6.273062] [<ffffffff81080cfd>] ? exit_ptrace+0x9c/...
2015 Oct 07
3
[PATCH] drm/virtio: use %llu format string form atomic64_t
On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote:
> On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote:
> > The virtgpu driver prints the last_seq variable using the %ld or
> > %lu format string, which does not work correctly on all architectures
> > and causes this compiler warning on ARM:
> >
> >
2015 Oct 07
3
[PATCH] drm/virtio: use %llu format string form atomic64_t
On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote:
> On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote:
> > The virtgpu driver prints the last_seq variable using the %ld or
> > %lu format string, which does not work correctly on all architectures
> > and causes this compiler warning on ARM:
> >
> >
2015 Feb 24
4
[PATCH 1/2] nouveau: make nouveau importing global buffers completely thread-safe, with tests
...atomic_inc_uint_nv(&(x)->atomic))
# define atomic_dec_and_test(x) (atomic_dec_uint_nv(&(x)->atomic) == 0)
# define atomic_add(x, v) (atomic_add_int(&(x)->atomic, (v)))
# define atomic_dec(x, v) (atomic_add_int(&(x)->atomic, -(v)))
@@ -112,3 +115,4 @@ static inline int atomic_add_unless(atomic_t *v, int add, int unless)
}
#endif
+
--
2.3.0
2015 Feb 25
0
[PATCH 1/2] nouveau: make nouveau importing global buffers completely thread-safe, with tests
...amp;(x)->atomic))
> # define atomic_dec_and_test(x) (atomic_dec_uint_nv(&(x)->atomic) == 0)
> # define atomic_add(x, v) (atomic_add_int(&(x)->atomic, (v)))
> # define atomic_dec(x, v) (atomic_add_int(&(x)->atomic, -(v)))
> @@ -112,3 +115,4 @@ static inline int atomic_add_unless(atomic_t *v, int add, int unless)
> }
>
> #endif
> +
Extra white-space.
IMHO sending the series for dri-devel might be nice, for at least the
xf86atomic.h changes.
Cheers
Emil
P.S. Bless you dude for going through the lovely experience to fix this.
2015 Feb 25
1
[PATCH 1/2] nouveau: make nouveau importing global buffers completely thread-safe, with tests
...ic))
>> # define atomic_dec_and_test(x) (atomic_dec_uint_nv(&(x)->atomic) == 0)
>> # define atomic_add(x, v) (atomic_add_int(&(x)->atomic, (v)))
>> # define atomic_dec(x, v) (atomic_add_int(&(x)->atomic, -(v)))
>> @@ -112,3 +115,4 @@ static inline int atomic_add_unless(atomic_t *v, int add, int unless)
>> }
>>
>> #endif
>> +
> Extra white-space.
>
> IMHO sending the series for dri-devel might be nice, for at least the
> xf86atomic.h changes.
Probably, not sure anyone will review it though, so I think just adding in a separat...
2010 Feb 01
4
[PATCH 1/3] Introduce nouveau_bo_wait for waiting on a BO with a GPU channel
nouveau_bo_wait will make the GPU channel wait for fence if possible,
otherwise falling back to waiting with the CPU using ttm_bo_wait.
The nouveau_fence_sync function currently returns -ENOSYS, and is
the focus of the next patch.
Signed-off-by: Luca Barbieri <luca at luca-barbieri.com>
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 68 ++++++++++++++++++++++++++++++-