atomic operations in user space
-Original Message- From: linuxppc-embedded-bounces+bcook=bpointsys.com at ozlabs.org [mailto:linuxppc-embedded-bounces+bcook=bpointsys.com at ozlabs.o rg] On Behalf Of Li Yang-r58472 Sent: Tuesday, August 29, 2006 5:53 AM To: Esben Nielsen; Liu Dave-r63238 Cc: Xupei Liang; linuxppc-embedded at ozlabs.org Subject: RE: atomic operations in user space It is available for PowerPC, but not in POWER and POWER2 instructionsets according to http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607 It is the same in the ARM world: Atomic instructions was introduced in ARMv6 I believe. Older ARM processors don't have them. Yes, I do know there are lwarx and stwrx instructions. But there is only one reservation per CPU and reservation can be re-established with no difference. So there are possibilities reservation is broken and reserved again in one atomic block. Task ATask B lwarx .. lwarx stwrx . . lwarx stwrx . stwrx The addresses of above operations are the same. In this case Thread A thinks that it is atomic as it holds the same reservation, but it is actually broken. Such control flow can't be prevented in user space. This is exactly how it is supposed to work! That's why there is a loop in the atomic increment - you check if you still had the reservation after the transaction by checking the result from the stwcx, and if not, retry. This works perfectly well no matter if it is from userspace or the kernel - it is a CPU function. It even works between CPUs on some later PowerPCs - I've had it working perfectly from userspace on a dual 7448 setup. PowerPC atomic instructions are not atomic in the sense that they _lock_ anything. The only thing these instructions give you is a way to see if another thread used the instructions while your thread was using them, and if you see a conflict, you retry until your code finishes uninterrupted. This makes it fine for short transactions, like atomic increment. You probably would not want to use these instructions for protecting longer transactions of more than a few instructions. If you look at how, for instance, futexes work in Linux, they rely on being able to do atomic increment and decrement from _userspace_. Read this article to understand how it works: http://www-128.ibm.com/developerworks/library/pa-atom/ - Brent
atomic operations in user space
On Thursday 24 August 2006 05:39, Li Yang-r58472 wrote: Why do you need atomic operations in user land? IPC will be sufficient to deal with race conditions between processes. Best Regards, Leo What about multiple threads within a process updating a counter? Of course, if you look at these functions in the kernel header, they're just 2 or 3 inline assembly calls - you could easily rewrite them. Google for 'PowerPC atomic increment' and grab one of the unencumbered implementations if you need to use it in a non-GPL program. On the other hand, I see no license at the top of my /usr/include/asm-i386/atomic.h file at all, same for PowerPC - are Linux header files actually GPL or are they more like the glibc headers, with exceptions made for userspace programs? The atomic operations on x86 were accidentally exported early on, so they have to hang around apparently for compatibility (there are some mailing list threads out there to this effect.) Currently, you just have to assume in Linux that if you include something from /usr/include/linux or asm that it will not necessarily be cross-version or cross-architecture compatible. Not every arch in Linux even has atomic operations of this nature, which I guess is the main reason why they are not exported in general. - Brent -Original Message- From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of Terry Liang Sent: Thursday, August 24, 2006 3:04 AM To: linuxppc-embedded at ozlabs.org Subject: atomic operations in user space Thanks. Arnd. My main concern is whether the operations are really atomic as they are in the kernel space. I have read some discussion in another forum that on other platforms, even if you are able to compile the atomic_add(), atomic_set(), etc. from an user space application, they don't guarantee to be atomic. Thanks. Regards, Terry Liang ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/4f60ee9d/attachment.htm
Realtime preemption patch on PPC
On Thursday 10 August 2006 18:04, Ben Weintraub wrote: Howdy, I'm wondering if anyone has had success getting Ingo Molnar's realtime preemption patch (the one here: http://people.redhat.com/mingo/realtime-preempt/ ) working on the ppc arch. I have gotten them to work with MPC7448 boards, but it has hardware floating point, so no math-emu problems. Anyhow, when I boot on an MPC8555 with my hack, I get an endless stream of: BUG: sleeping function called from invalid context init(1) at arch/powerpc/math-emu/math.c:226 in_atomic():0 [], irqs_disabled():1 Call Trace: [A0BB3E90] [A000934C] show_stack+0x48/0x194 (unreliable) [A0BB3EC0] [A001B7DC] __might_sleep+0xe8/0xf4 [A0BB3EE0] [A00136C0] do_mathemu+0x30/0x8c8 [A0BB3F00] [A00036AC] program_check_exception+0x1ac/0x514 [A0BB3F40] [A0002A08] ret_from_except_full+0x0/0x4c Line 226 in arch/powerpc/math-emu/math.c is part of the do_mathemu() function, and contains a call to get_user(), which calls __might_sleep(), causing this problem.
regarding mvme6100 on kernel 2.6.13
On Tuesday 30 May 2006 09:09, Kiran Kumar.A wrote:
Hi all,
I'm porting mvme6100 for 2.6.13.
But its hanging after Now Booting the kernel..
Can anybody guide me in this regard.
thanks and regards
Eh, it's probably not hanging at all - you're just not seeing anything because
the device naming scheme changed and the serial console not getting
initialized correctly. Be sure that in your platform_notify function has
a '.' in the platform device name - this was added around 2.6.11 or so.
An example from another board I have:
static int xes_mv64x60_platform_notify(struct device *dev)
{
static struct {
char *bus_id;
void ((*rtn) (struct platform_device * pdev));
} dev_map[] = {
#ifdef CONFIG_SERIAL_MPSC
{
MPSC_CTLR_NAME .0, xes_mv64x60_fixup_mpsc_pdata}, {
MPSC_CTLR_NAME .1, xes_mv64x60_fixup_mpsc_pdata},
#endif
}
Also, be sure to enable early boot messages - they help a lot. Also, don't
overlook setting console=ttyMM0,9600 in the kernel args.
- Brent
[PATCH] Export PowerPC atomic operations to userspace
The atomic operations in asm/atomic.h are really useful from userspace too.
Other architectures (i386, x86_64, mips) export these to userspace, but the
powerpc versions are guarded by __KERNEL__ for some reason. Can we remove
these if there is no good reason to guard them?
Signed-off-by: Brent Cook bcook at bpointsys.com
Index: linux-2.6-bps/include/asm-powerpc/atomic.h
===
--- linux-2.6-bps/include/asm-powerpc/atomic.h (revision 77)
+++ linux-2.6-bps/include/asm-powerpc/atomic.h (working copy)
@@ -7,7 +7,6 @@
typedef struct { volatile int counter; } atomic_t;
-#ifdef __KERNEL__
#include linux/compiler.h
#include asm/synch.h
#include asm/asm-compat.h
@@ -414,5 +413,4 @@
#endif /* __powerpc64__ */
#include asm-generic/atomic.h
-#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_ATOMIC_H_ */
[PATCH] Export PowerPC atomic operations to userspace
On Monday 15 May 2006 12:16, Tom Rini wrote: On Mon, May 15, 2006 at 11:54:52AM -0500, Brent Cook wrote: The atomic operations in asm/atomic.h are really useful from userspace too. Other architectures (i386, x86_64, mips) export these to userspace, but the powerpc versions are guarded by __KERNEL__ for some reason. Can we remove these if there is no good reason to guard them? Signed-off-by: Brent Cook bcook at bpointsys.com NAK. i386, x86_64 and mips are broken in this regard. Please google up the previous threads that explain why you can't always get atomic operations on all architectures and why exporting this is bad. OK, I see that possibly the only reason atomic_t is even exported is so that sem.h works. Hopefully sem.h will get fixed and people like me will not be even tempted by atomic.h. What I really want is just a standard way to do atomic inc/dec in userspace; I'm sure that people are going to continue wanting to have atomic_t workalikes for their code. After reading this thread: http://www.developerweb.net/forum/archive/index.php/t-3294.html it appears that just wrapping an integer in a pthreads mutex on an NPTL machine wouldn't be much more overhead than using an atomic_t directly. Looking at glibc's sources for powerpc nptl: nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h confirms that a futex lock is really similar to an atomic_t. Thanks! - Brent
root file system mounted via NFS - retry?
On Wednesday 12 April 2006 07:35, Randy Smith wrote: Hello, I have a general question regarding having a root file system mounted via NFS. Our system consists of a linux PC that acts as the NFS server and two embedded ppc boards running linux that mount their file systems via NFS. The problem is that the embedded boards boot much faster than the PC, and when they attempt to mount the root file system, the NFS server is not up yet. The embedded boards hang and it takes quite a long time before the watchdog timer reboots them. The next time round, they come up just fine. What I would like for them to do is keep trying until the NFS server appears and then continue to boot. Sorry to try the obvious, but could you make the firmware's auto-boot timeout longer? I know that u-boot and several others support this. Also, you could try, instead of mounting root NFS directly from the kernel, an initrd or embedding an initramfs that does the mount using a script. They you could retry as much as you wanted without having to teach the kernel anything. Or, just hook up some GPIOs from your PC to the reset lines on those PPC's. Then reset them once your PC is up. Or rather than running the PPC kernel from flash, tftp it to RAM from your PC - that way your PPCs can't even load the kernel until the PC is up (assuming your firmware knows how to do this and handles faults gracefully.) - Brent
fs_enet on 2.4 and 8xx_immap
On Tuesday 07 March 2006 09:49, antonio.dibacco wrote: Hi, I'm a novice and I don't understand what is IIRC. Is something that handles the two FECs on 885ads? I knew that on 885ads the second ethernet was realized via an SCC and not FEC. Am I wrong? Bye, Antonio. That is too funny! IIRC is an abbreviation for if I recall
