search for: atomic_add_unless

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 ++++++++++++++++++++++++++++++-