Re: [fedora-arm] ARMv5 and atomic operations
On 04/23/2012 09:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. Indeed it is. What would I gain from adding such a test? All I can see is extra complication, untested code paths, and larger programs. The untested code path is particularly nasty. Andrew. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/23/2012 09:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. Indeed it is. What would I gain from adding such a test? All I can see is extra complication, untested code paths, and larger programs. What alternative do you have, other than not using any atomic operations? The untested code path is particularly nasty. How buggy the following code might be: fprintf(stderr, Your kernel is too old, aborting\n) exit(1); ? Nicolas ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/24/2012 12:39 PM, Nicolas Pitre wrote: On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/23/2012 09:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. Indeed it is. What would I gain from adding such a test? All I can see is extra complication, untested code paths, and larger programs. What alternative do you have, other than not using any atomic operations? What I've done already: I have my own routines. The untested code path is particularly nasty. How buggy the following code might be: fprintf(stderr, Your kernel is too old, aborting\n) exit(1); Certainly not. I want it to work on older kernels. Andrew. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/24/2012 07:39 AM, Nicolas Pitre wrote: On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/23/2012 09:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. Indeed it is. What would I gain from adding such a test? All I can see is extra complication, untested code paths, and larger programs. What alternative do you have, other than not using any atomic operations? The untested code path is particularly nasty. How buggy the following code might be: fprintf(stderr, Your kernel is too old, aborting\n) exit(1); ? Nicolas Checking kernel characteristics of the running kernel on a Fedora build system might not be a good idea. The build system might be a chroot jail on an older release (for example fedora 17 chroot on fedora 15). This was a problem when building the early versions of the papi RPMs. RHEL6 build roots were on RHEL5 machines. Checking the kernel version with a uname -r showed a kernel RHEL5 kernel that didn't have the need perf support. However, things were being built for a RHEL6 so this test was misleading. Is it possible to get this information from kernel-headers rather than probing the running kernel? -Will ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
William Cohen wrote: On 04/24/2012 07:39 AM, Nicolas Pitre wrote: On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/23/2012 09:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. Indeed it is. What would I gain from adding such a test? All I can see is extra complication, untested code paths, and larger programs. What alternative do you have, other than not using any atomic operations? The untested code path is particularly nasty. How buggy the following code might be: fprintf(stderr, Your kernel is too old, aborting\n) exit(1); ? Nicolas Checking kernel characteristics of the running kernel on a Fedora build system might not be a good idea. The build system might be a chroot jail on an older release (for example fedora 17 chroot on fedora 15). This was a problem when building the early versions of the papi RPMs. RHEL6 build roots were on RHEL5 machines. Checking the kernel version with a uname -r showed a kernel RHEL5 kernel that didn't have the need perf support. However, things were being built for a RHEL6 so this test was misleading. Is it possible to get this information from kernel-headers rather than probing the running kernel? I am sure I remember having been bitten by this when rebuilding RHEL6 src.rpms on F12/F13 builders but for the life of me I cannot recall which packages were involved. IMO a builder that isn't the same version as the distro being built should only ever be used for a bootstrapping build - otherwise all sorts of anomalies creep in. Having said that, it is a good idea to hunt down the sources of such anomalies, so from that point of view, a kernel/distro mismatch on the builders is a good thing from the point of view of thorough testing. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Monday, 23 April 2012, Thomas Meyer wrote: Am Sonntag, den 22.04.2012, 22:34 -0400 schrieb Chris Tyler: On Sun, 2012-04-22 at 18:16 -0700, Brendan Conoboy wrote: As we get closer to having 100% package coverage in F17-ARM we're running into harder build failures due to the limitations of the chips we're building for. The problem I've noticed on many of the recent failures is due to the lack of atomic operations (These didn't arrive until ARMv6). 6. There is the kernel's user space atomic helper (kuser_cmpxchg64) at 0x0f60, see Documentation/arm/kernel_user_helpers.txt. The kernel puts an instruction sequence here tuned for the current arch that can be called by userland to provide an atomic compare/exchange -- if it can be done natively, the instruction sequence does that, otherwise it does a syscall (with IRQ protection etc). Would this solve the problems you've identified? I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. If you used the 64 bit gcc sync primitives and they called the helper functions IIRC there is a check in there for the existence and graceful abort of these handlers... Ramana with kind regards thomas ___ arm mailing list arm@lists.fedoraproject.org javascript:; https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/24/2012 12:39 PM, Nicolas Pitre wrote: On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/23/2012 09:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. Indeed it is. What would I gain from adding such a test? All I can see is extra complication, untested code paths, and larger programs. What alternative do you have, other than not using any atomic operations? What I've done already: I have my own routines. You may get some atomicity with the SWP instruction, but that is not sufficient to implement atomic increments and the like. You may use the SWP to implement some locking and perform the atomic operations under the lock protection, but that doesn't work if atomic operations are also performed in signal handlers, and that scales badly if concurency is high. So that really depends what your atomic needs are. Implementing the latest library standards without any kernel help on ARMv5 or earlier is simply impossible. But custom code can get away with less. Nicolas ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/24/2012 04:49 PM, Nicolas Pitre wrote: On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/24/2012 12:39 PM, Nicolas Pitre wrote: On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/23/2012 09:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. Indeed it is. What would I gain from adding such a test? All I can see is extra complication, untested code paths, and larger programs. What alternative do you have, other than not using any atomic operations? What I've done already: I have my own routines. You may get some atomicity with the SWP instruction, but that is not sufficient to implement atomic increments and the like. You may use the SWP to implement some locking and perform the atomic operations under the lock protection, but that doesn't work if atomic operations are also performed in signal handlers, and that scales badly if concurency is high. So that really depends what your atomic needs are. Implementing the latest library standards without any kernel help on ARMv5 or earlier is simply impossible. But custom code can get away with less. Oh I see what you mean now. I'm inside the Java VM, so I can fall back to locking if I'm on ARMv5; ldrexd is an optimization for doing long-word updates rather than needed for correctness. So, if I'm on v7 I have to have my own cmpxchg64 routines for older kernels. I have to fall back to locks on older CPUs, because I still want to work on old kernels too. I can't see any circumstances where the kernel helper will be of any use. Andrew. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/23/2012 04:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. I wasn't going to reply yet just due to lack of time and because Nico covered the kernel helper stuff so well in his earlier posts. But just to add, these kernel helpers have grown a little over time in higher kernel revisions, but there is a mechanism to discover the revision available (note: these are not VDSO but if it helps folks understand them, think of them like that). They are the right way to solve the atomics problem as best as we can for older devices. I believe the correct thing to do is to get broken upstream projects to adopt generic non-reimplemented-of-their-own routines that will transparently use the kernel helpers if needed. It would be sad to give up on v5 just yet, but we are also in this for the longer haul, and newer Plugs are going to be switching to v7 over time. So, in due course, I am open to also considering a switch to v6 (with or without smp). Let's ponder this some more on the weekly call tomorrow. I'll send out a reminder - it's going to be on #fedora-meeting this week. Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/24/2012 12:18 PM, Jon Masters wrote: On 04/23/2012 04:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. I wasn't going to reply yet just due to lack of time and because Nico covered the kernel helper stuff so well in his earlier posts. But just to add, these kernel helpers have grown a little over time in higher kernel revisions, but there is a mechanism to discover the revision available (note: these are not VDSO but if it helps folks understand them, think of them like that). They are the right way to solve the atomics problem as best as we can for older devices. I believe the correct thing to do is to get broken upstream projects to adopt generic non-reimplemented-of-their-own routines that will transparently use the kernel helpers if needed. It would be sad to give up on v5 just yet, but we are also in this for the longer haul, and newer Plugs are going to be switching to v7 over time. So, in due course, I am open to also considering a switch to v6 (with or without smp). broken does not mean to imply wrong. I mean stuff that is failing for silly reasons. This is not a jab at Java either - some projects need their own locking implementations. I wish we had the load/store reservation support on older ARM, but sadly we do not. Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/24/2012 05:18 PM, Jon Masters wrote: On 04/23/2012 04:31 PM, Nicolas Pitre wrote: On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. I wasn't going to reply yet just due to lack of time and because Nico covered the kernel helper stuff so well in his earlier posts. But just to add, these kernel helpers have grown a little over time in higher kernel revisions, but there is a mechanism to discover the revision available (note: these are not VDSO but if it helps folks understand them, think of them like that). They are the right way to solve the atomics problem as best as we can for older devices. I believe the correct thing to do is to get broken upstream projects to adopt generic non-reimplemented-of-their-own routines that will transparently use the kernel helpers if needed. But is that going to help me? Let's say I'm on an ARMv5 and need to do a longword operation. I can either use a lightweight spinlock or take the hit of a system call to do the cmpxchg8 operation. Am I really better off going into the kernel to do that? Absolutely! Because the kernel cmpxchg8 routine is _not_ a system call. and it is going to be lighter than your custom solution with a lock. Nicolas ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Tue, 24 Apr 2012, Jon Masters wrote: I wasn't going to reply yet just due to lack of time and because Nico covered the kernel helper stuff so well in his earlier posts. But just to add, these kernel helpers have grown a little over time in higher kernel revisions, but there is a mechanism to discover the revision available (note: these are not VDSO but if it helps folks understand them, think of them like that). They are the right way to solve the atomics problem as best as we can for older devices. The kernel helpers have been there, for the most part, since v2.6.15 which should be good enough. The only recent addition in v3.1 was cmpxchg64. I believe the correct thing to do is to get broken upstream projects to adopt generic non-reimplemented-of-their-own routines that will transparently use the kernel helpers if needed. It would be sad to give up on v5 just yet, but we are also in this for the longer haul, and newer Plugs are going to be switching to v7 over time. So, in due course, I am open to also considering a switch to v6 (with or without smp). Note that ARMv6 doesn't have 64-bit atomic support either. You need to move to ARMv6K and above for them to be natively available, meaning even more recent hardware than plain ARMv6. So if you really really need 64 bit atomic ops (and in most cases this is unnecessary IMHO) then you must have an SMP capable CPU in practice, or a kernel version equal to 3.1 or later. Nicolas ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/24/2012 05:40 PM, Nicolas Pitre wrote: On Tue, 24 Apr 2012, Andrew Haley wrote: On 04/24/2012 05:18 PM, Jon Masters wrote: I wasn't going to reply yet just due to lack of time and because Nico covered the kernel helper stuff so well in his earlier posts. But just to add, these kernel helpers have grown a little over time in higher kernel revisions, but there is a mechanism to discover the revision available (note: these are not VDSO but if it helps folks understand them, think of them like that). They are the right way to solve the atomics problem as best as we can for older devices. I believe the correct thing to do is to get broken upstream projects to adopt generic non-reimplemented-of-their-own routines that will transparently use the kernel helpers if needed. But is that going to help me? Let's say I'm on an ARMv5 and need to do a longword operation. I can either use a lightweight spinlock or take the hit of a system call to do the cmpxchg8 operation. Am I really better off going into the kernel to do that? Absolutely! Because the kernel cmpxchg8 routine is _not_ a system call. and it is going to be lighter than your custom solution with a lock. Okay, I think I see your point: you're going to use ldm/stm in the handler and detect an interrupt, then restart if necessary. Right, that may well be worth doing. I'll still need the locking fallback for old kernels, though. Andrew. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/23/2012 02:16 AM, Brendan Conoboy wrote: As we get closer to having 100% package coverage in F17-ARM we're running into harder build failures due to the limitations of the chips we're building for. The problem I've noticed on many of the recent failures is due to the lack of atomic operations (These didn't arrive until ARMv6). How do we want to handle this? I see a few options: 1. Abandon armv5 and move to armv6 where some of the operations we need are available. This will still support the raspberry pi- what about kirkwood *plugs? Hold on, I thought that Raspberry Pi was a separate remix, and F17 was targeted at ARMv7? Andrew. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
Andrew Haley wrote: On 04/23/2012 02:16 AM, Brendan Conoboy wrote: As we get closer to having 100% package coverage in F17-ARM we're running into harder build failures due to the limitations of the chips we're building for. The problem I've noticed on many of the recent failures is due to the lack of atomic operations (These didn't arrive until ARMv6). How do we want to handle this? I see a few options: 1. Abandon armv5 and move to armv6 where some of the operations we need are available. This will still support the raspberry pi- what about kirkwood *plugs? Hold on, I thought that Raspberry Pi was a separate remix, and F17 was targeted at ARMv7? Oh? My understanding was that F17 was to have both armv5tel and armv7hl builds. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Mon, Apr 23, 2012 at 10:40 AM, Andrew Haley a...@redhat.com wrote: On 04/23/2012 10:36 AM, Gordan Bobic wrote: Andrew Haley wrote: On 04/23/2012 02:16 AM, Brendan Conoboy wrote: As we get closer to having 100% package coverage in F17-ARM we're running into harder build failures due to the limitations of the chips we're building for. The problem I've noticed on many of the recent failures is due to the lack of atomic operations (These didn't arrive until ARMv6). How do we want to handle this? I see a few options: 1. Abandon armv5 and move to armv6 where some of the operations we need are available. This will still support the raspberry pi- what about kirkwood *plugs? Hold on, I thought that Raspberry Pi was a separate remix, and F17 was targeted at ARMv7? Oh? My understanding was that F17 was to have both armv5tel and armv7hl builds. Oh, I see. Is any of this documented anywhere? It depends on what sort of documentation you want. We're targeting both armv7hl and armv5tel architectures. And can someone tell me if there is a F17 root fs for Raspberry Pi that I can download? Not yet but soon. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Mon, 2012-04-23 at 10:40 +0100, Andrew Haley wrote: On 04/23/2012 10:36 AM, Gordan Bobic wrote: Andrew Haley wrote: On 04/23/2012 02:16 AM, Brendan Conoboy wrote: As we get closer to having 100% package coverage in F17-ARM we're running into harder build failures due to the limitations of the chips we're building for. The problem I've noticed on many of the recent failures is due to the lack of atomic operations (These didn't arrive until ARMv6). How do we want to handle this? I see a few options: 1. Abandon armv5 and move to armv6 where some of the operations we need are available. This will still support the raspberry pi- what about kirkwood *plugs? Hold on, I thought that Raspberry Pi was a separate remix, and F17 was targeted at ARMv7? Oh? My understanding was that F17 was to have both armv5tel and armv7hl builds. Oh, I see. Is any of this documented anywhere? And can someone tell me if there is a F17 root fs for Raspberry Pi that I can download? There are armv5tel and armv7hl builds for F17. The Raspbery Pi remix is the armv5tel build + some packages that can't be accepted in Fedora (due to license issues, e.g., non-open-source libraries). Brendan has *just* added the Pi as a target for his nightly rootfs images, but this hasn't been tested yet. This will be a bit different from the final image but will let anyone who wants to play early. (/me toddles off to test that out...) -Chris ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Sun, 22 Apr 2012, Brendan Conoboy wrote: As we get closer to having 100% package coverage in F17-ARM we're running into harder build failures due to the limitations of the chips we're building for. The problem I've noticed on many of the recent failures is due to the lack of atomic operations (These didn't arrive until ARMv6). How do we want to handle this? I see a few options: This is already handled, and has been so for the last 5 years or more. The kernel provides user space with atomic helpers which the kernel knows how to replay if necessary to make the result completely atomic. See Documentation/arm/kernel_user_helpers.txt in the kernel source tree for details and example usage. These helpers are usually called via some libraries providing standard APIs and semantics. The NPTL implementation of pthreads for ARMv5 is based on those helpers. And gcc's handling of atomic types is also using those kernel helpers when compiling for ARMv5, or even ARMv6 (non ARMv6k) in the 64-bit case. So everything is there for you already to support atomic operations even on ARMv3 if you so wish. Nicolas ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Sun, 22 Apr 2012, Chris Tyler wrote: 6. There is the kernel's user space atomic helper (kuser_cmpxchg64) at 0x0f60, see Documentation/arm/kernel_user_helpers.txt. The kernel puts an instruction sequence here tuned for the current arch that can be called by userland to provide an atomic compare/exchange -- if it can be done natively, the instruction sequence does that, otherwise it does a syscall (with IRQ protection etc). No, there is no syscall involved here. Doing so would have killed performances for any trivial amount of atomic operations. The way this works is to perform the operation, using non-atomic instructions as they're not available on ARMv5, and if an interrupt or a page fault occurs inside the critical region that the kernel controls, then the operation is rewinded and resumed the next time the user space task gets to run. This way you get the same performance as with native atomic instructions on later processors, except for the added branch instruction. Nicolas ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/23/2012 04:06 PM, Dan Horák wrote: the main problem no only in ARM land is that many software developers like to develop their own atomic ops implementations in their project instead of using some standard one eg. from GCC :-( I fight with this problem again and again on s390 ... Because the GCC ones didn't used to work. But things are getting much better. BTW, I still had to roll my own CompareAndSwapDouble for ARMv7: the kernel helper wasn't there. Andrew. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
Chris Tyler ch...@tylers.info writes: 1. Abandon armv5 and move to armv6 where some of the operations we need are available. This will still support the raspberry pi- what about kirkwood *plugs? That would kill the older plugs -- anything below a d2plug. However: do we care? Much? Going to v6 would let us optimize better for the Raspi, which will have greater market penetration than the plugs when existing orders are filled. Otoh, it's a whole 'nuther rebuild. I care. I've got existing plugs that I'd like to continue to use on Fedora. Unless someone wants to buy them off me so I can buy something else? ;) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
Chris Tyler ch...@tylers.info writes: Brendan has *just* added the Pi as a target for his nightly rootfs images, but this hasn't been tested yet. This will be a bit different from the final image but will let anyone who wants to play early. (/me toddles off to test that out...) Hmm, I should go figure out how to install F17 on my *plugs, or maybe upgrade my F12 system to F17... -Chris -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/23/2012 08:06 AM, Dan Horák wrote: the main problem no only in ARM land is that many software developers like to develop their own atomic ops implementations in their project instead of using some standard one eg. from GCC :-( I fight with this problem again and again on s390 ... Are the fixes you're introducing s390 specific? Would love to reuse existing solutions if they're not already in use. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Mon, Apr 23, 2012 at 5:15 PM, Jeff Voskamp j...@voskamp.ca wrote: On 04/23/2012 11:51 AM, Derek Atkins wrote: Chris Tylerch...@tylers.info writes: 1. Abandon armv5 and move to armv6 where some of the operations we need are available. This will still support the raspberry pi- what about kirkwood *plugs? That would kill the older plugs -- anything below a d2plug. However: do we care? Much? Going to v6 would let us optimize better for the Raspi, which will have greater market penetration than the plugs when existing orders are filled. Otoh, it's a whole 'nuther rebuild. I care. I've got existing plugs that I'd like to continue to use on Fedora. Unless someone wants to buy them off me so I can buy something else? ;) -derek What he said. Especially with Pi's being Xmas Christmas presents if you're ordering them now. If you'd bothered to read the full thread you'd realise that Pi's aren't in this discussion because they are ARMv6 and the discussion was if we move to ARMv6 to fix the problem, and it turns out there's likely means of dealing with the issues anyway. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
Am Sonntag, den 22.04.2012, 22:34 -0400 schrieb Chris Tyler: On Sun, 2012-04-22 at 18:16 -0700, Brendan Conoboy wrote: As we get closer to having 100% package coverage in F17-ARM we're running into harder build failures due to the limitations of the chips we're building for. The problem I've noticed on many of the recent failures is due to the lack of atomic operations (These didn't arrive until ARMv6). 6. There is the kernel's user space atomic helper (kuser_cmpxchg64) at 0x0f60, see Documentation/arm/kernel_user_helpers.txt. The kernel puts an instruction sequence here tuned for the current arch that can be called by userland to provide an atomic compare/exchange -- if it can be done natively, the instruction sequence does that, otherwise it does a syscall (with IRQ protection etc). Would this solve the problems you've identified? I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. with kind regards thomas ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/23/2012 06:36 PM, Thomas Meyer wrote: Am Sonntag, den 22.04.2012, 22:34 -0400 schrieb Chris Tyler: On Sun, 2012-04-22 at 18:16 -0700, Brendan Conoboy wrote: As we get closer to having 100% package coverage in F17-ARM we're running into harder build failures due to the limitations of the chips we're building for. The problem I've noticed on many of the recent failures is due to the lack of atomic operations (These didn't arrive until ARMv6). 6. There is the kernel's user space atomic helper (kuser_cmpxchg64) at 0x0f60, see Documentation/arm/kernel_user_helpers.txt. The kernel puts an instruction sequence here tuned for the current arch that can be called by userland to provide an atomic compare/exchange -- if it can be done natively, the instruction sequence does that, otherwise it does a syscall (with IRQ protection etc). Would this solve the problems you've identified? I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Andrew. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On Mon, 23 Apr 2012, Andrew Haley wrote: On 04/23/2012 06:36 PM, Thomas Meyer wrote: I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The rsyslog package crashed everytime because of the missing kernel support of cmpxchg64. So when relying on the kernel helpers make sure that the resp. kernel support exists. Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for just this reason. If you can't depend on a kernel helper being there I can't see it's of any use. Kernel helpers don't disappear with time. You therefore can probe for their availability (see the documentation) in case the kernel support could be backported, or just refuse to run if the kernel version isn't recent enough. This is not much different from relying on a new syscall. Nicolas ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
