freebsd-arm Digest, Vol 204, Issue 1
freebsd-a...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
or, via email, send a message with subject or body 'help' to
freebsd-a...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-arm digest..."
Today's Topics:
1. Re: bind on arm (Doug Barton)
2. Re: bind on arm (Rafal Jaworowski)
3. Re: bind on arm (M. Warner Losh)
4. Re: bind on arm (Olivier Houchard)
5. Re: bind on arm (Bernd Walter)
6. Re: bind on arm (M. Warner Losh)
7. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
----------------------------------------------------------------------
Message: 1
Date: Sun, 21 Feb 2010 13:01:21 -0800
From: Doug Barton <do...@FreeBSD.org>
Subject: Re: bind on arm
To: Olivier Houchard <cog...@ci0.org>, freeb...@FreeBSD.org
Message-ID: <4B819F2...@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1
On 02/21/10 07:28, Olivier Houchard wrote:
> Hi Doug,
>
> I'd like to get the attached patch committed. It fixes the bind arm atomic
> stuff in -CURRENT and RELENG_8. Some times ago, the RAS address was changed,
> but it was hardcoded in the bind code and the change was never reflected.
> The patch uses a macro, so that even if it happens again it won't be a problem.
First question (and I think the answer is yes, but I need to
double-check) is it the consensus of the ARM gurus that this is the
right solution? Second question, is this solution something that I can
send upstream, both in the sense that I have permission to do so, and
that it would be generally applicable to ARM on other OSs?
Thanks,
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
------------------------------
Message: 2
Date: Sun, 21 Feb 2010 22:46:14 +0100
From: Rafal Jaworowski <r...@semihalf.com>
Subject: Re: bind on arm
To: Doug Barton <do...@FreeBSD.org>
Cc: freeb...@FreeBSD.org, Olivier Houchard <cog...@ci0.org>
Message-ID: <EF0BCCA4-011C-4705...@semihalf.com>
Content-Type: text/plain; charset=us-ascii
On 2010-02-21, at 22:01, Doug Barton wrote:
> On 02/21/10 07:28, Olivier Houchard wrote:
>> Hi Doug,
>>
>> I'd like to get the attached patch committed. It fixes the bind arm atomic
>> stuff in -CURRENT and RELENG_8. Some times ago, the RAS address was changed,
>> but it was hardcoded in the bind code and the change was never reflected.
>> The patch uses a macro, so that even if it happens again it won't be a problem.
>
> First question (and I think the answer is yes, but I need to
> double-check) is it the consensus of the ARM gurus that this is the
> right solution? Second question, is this solution something that I can
> send upstream, both in the sense that I have permission to do so, and
> that it would be generally applicable to ARM on other OSs?
I believe the desired direction here is to make the cmpxchg atomic op a CPU-level routine, rather than it being part of the application code. I'm not sure what is a wider context of such a change for BIND or whether this code is FreeBSD-only, but I thought the posted changes were just a quick fix to verify that we have a problem around RAS, and there's more insight needed before considering it a final fix.
Rafal
------------------------------
Message: 3
Date: Sun, 21 Feb 2010 15:25:18 -0700 (MST)
From: "M. Warner Losh" <i...@bsdimp.com>
Subject: Re: bind on arm
To: do...@FreeBSD.org
Cc: freeb...@FreeBSD.org, cog...@ci0.org
Message-ID: <20100221.152518.366...@bsdimp.com>
Content-Type: Text/Plain; charset=us-ascii
In message: <4B819F2...@FreeBSD.org>
Doug Barton <do...@FreeBSD.org> writes:
: On 02/21/10 07:28, Olivier Houchard wrote:
: > Hi Doug,
: >
: > I'd like to get the attached patch committed. It fixes the bind arm atomic
: > stuff in -CURRENT and RELENG_8. Some times ago, the RAS address was changed,
: > but it was hardcoded in the bind code and the change was never reflected.
: > The patch uses a macro, so that even if it happens again it won't be a problem.
:
: First question (and I think the answer is yes, but I need to
: double-check) is it the consensus of the ARM gurus that this is the
: right solution? Second question, is this solution something that I can
: send upstream, both in the sense that I have permission to do so, and
: that it would be generally applicable to ARM on other OSs?
The patch isn't quite right yet.
First, there are no atomic operations on ARM ISA (prior to some of the
really recent ones that we don't yet have support in our binutils
for). In order to get atomic operations to work right, you have to
have some variation of RAS (restartable atomic sequences). RAS is OS
specific, as there's no standards what-so-ever for it. These
sequences will generate atomic operations, but only if the OS restarts
them if the OS preempts the thread.
The code that's there now is very FreeBSD specific. In fact, it is
explicitly tagged as such in the source. These patches don't change
that.
The code broke because we moved the RAS scratchpad area between
revisions of FreeBSD. I think between 7 and 8, but I've not done the
software archeology to be sure. At the very least, the code should be
ifdef'd for the RAS address. Sadly, neither version exported the RAS
constant in any useful way.
While it is true it would be nicer of the application used FreeBSD
atomic operations in the same way that all other applications do, this
isn't easy in the case of Bind. Bind defined its own set of atomic
operations, and all the other architectures conformed to bind's usage.
On most other platforms, the atomic operations aren't OS dependent,
just CPU dependent, so there wasn't a problem with Bind defining its
own. After all, atomic operations haven't been standardized and
there's a number of different ways to skin this cat.
The fanciest way to cope would be to have a run-time check to see
which address to use. This likely isn't worth the bother since the
user base is still relatively small (and none of the other atomics do
this). The next best approach would be to include <machine/sysarch.h>
and use the value defined there for ARM_RAS_START and ARM_RAS_END.
Again, I've not double checked to make sure they are defined before,
but I think they are (or at least if they aren't defined, we know to
use the old value).
Warner
------------------------------
Message: 4
Date: Mon, 22 Feb 2010 00:54:08 +0100
From: Olivier Houchard <cog...@ci0.org>
Subject: Re: bind on arm
To: "M. Warner Losh" <i...@bsdimp.com>
Cc: freeb...@FreeBSD.org, do...@FreeBSD.org
Message-ID: <20100221235...@ci0.org>
Content-Type: text/plain; charset=us-ascii
On Sun, Feb 21, 2010 at 03:25:18PM -0700, M. Warner Losh wrote:
> In message: <4B819F2...@FreeBSD.org>
> Doug Barton <do...@FreeBSD.org> writes:
> : On 02/21/10 07:28, Olivier Houchard wrote:
> : > Hi Doug,
> : >
> : > I'd like to get the attached patch committed. It fixes the bind arm atomic
> : > stuff in -CURRENT and RELENG_8. Some times ago, the RAS address was changed,
> : > but it was hardcoded in the bind code and the change was never reflected.
> : > The patch uses a macro, so that even if it happens again it won't be a problem.
> :
> : First question (and I think the answer is yes, but I need to
> : double-check) is it the consensus of the ARM gurus that this is the
> : right solution? Second question, is this solution something that I can
> : send upstream, both in the sense that I have permission to do so, and
> : that it would be generally applicable to ARM on other OSs?
>
> The fanciest way to cope would be to have a run-time check to see
> which address to use. This likely isn't worth the bother since the
> user base is still relatively small (and none of the other atomics do
> this). The next best approach would be to include <machine/sysarch.h>
> and use the value defined there for ARM_RAS_START and ARM_RAS_END.
> Again, I've not double checked to make sure they are defined before,
> but I think they are (or at least if they aren't defined, we know to
> use the old value).
>
Actually, the patch I sent Doug does just that, it uses ARM_RAS_START
(because it includes machine/atomic.h, which includes machine/sysarch.h).
It should work for 7 as well, as ARM_RAS_START was defined too (but in
machine/atomic.h)
Regards,
Olivier
------------------------------
Message: 5
Date: Mon, 22 Feb 2010 00:59:14 +0100
From: Bernd Walter <ti...@cicely7.cicely.de>
Subject: Re: bind on arm
To: Olivier Houchard <cog...@ci0.org>
Cc: freeb...@freebsd.org, do...@freebsd.org
Message-ID: <20100221235...@cicely7.cicely.de>
Content-Type: text/plain; charset=us-ascii
On Mon, Feb 22, 2010 at 12:54:08AM +0100, Olivier Houchard wrote:
> On Sun, Feb 21, 2010 at 03:25:18PM -0700, M. Warner Losh wrote:
> > In message: <4B819F2...@FreeBSD.org>
> > Doug Barton <do...@FreeBSD.org> writes:
> > : On 02/21/10 07:28, Olivier Houchard wrote:
> > : > Hi Doug,
> > : >
> > : > I'd like to get the attached patch committed. It fixes the bind arm atomic
> > : > stuff in -CURRENT and RELENG_8. Some times ago, the RAS address was changed,
> > : > but it was hardcoded in the bind code and the change was never reflected.
> > : > The patch uses a macro, so that even if it happens again it won't be a problem.
> > :
> > : First question (and I think the answer is yes, but I need to
> > : double-check) is it the consensus of the ARM gurus that this is the
> > : right solution? Second question, is this solution something that I can
> > : send upstream, both in the sense that I have permission to do so, and
> > : that it would be generally applicable to ARM on other OSs?
> >
> > The fanciest way to cope would be to have a run-time check to see
> > which address to use. This likely isn't worth the bother since the
> > user base is still relatively small (and none of the other atomics do
> > this). The next best approach would be to include <machine/sysarch.h>
> > and use the value defined there for ARM_RAS_START and ARM_RAS_END.
> > Again, I've not double checked to make sure they are defined before,
> > but I think they are (or at least if they aren't defined, we know to
> > use the old value).
> >
>
> Actually, the patch I sent Doug does just that, it uses ARM_RAS_START
> (because it includes machine/atomic.h, which includes machine/sysarch.h).
> It should work for 7 as well, as ARM_RAS_START was defined too (but in
> machine/atomic.h)
I'm also running a 7.0-CURRENT system and can do a test if required.
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
------------------------------
Message: 6
Date: Sun, 21 Feb 2010 17:06:28 -0700 (MST)
From: "M. Warner Losh" <i...@bsdimp.com>
Subject: Re: bind on arm
To: cog...@ci0.org
Cc: freeb...@freebsd.org, do...@freebsd.org
Message-ID: <20100221.170628.163...@bsdimp.com>
Content-Type: Text/Plain; charset=us-ascii
In message: <20100221235...@ci0.org>
Olivier Houchard <cog...@ci0.org> writes:
: On Sun, Feb 21, 2010 at 03:25:18PM -0700, M. Warner Losh wrote:
: > In message: <4B819F2...@FreeBSD.org>
: > Doug Barton <do...@FreeBSD.org> writes:
: > : On 02/21/10 07:28, Olivier Houchard wrote:
: > : > Hi Doug,
: > : >
: > : > I'd like to get the attached patch committed. It fixes the bind arm atomic
: > : > stuff in -CURRENT and RELENG_8. Some times ago, the RAS address was changed,
: > : > but it was hardcoded in the bind code and the change was never reflected.
: > : > The patch uses a macro, so that even if it happens again it won't be a problem.
: > :
: > : First question (and I think the answer is yes, but I need to
: > : double-check) is it the consensus of the ARM gurus that this is the
: > : right solution? Second question, is this solution something that I can
: > : send upstream, both in the sense that I have permission to do so, and
: > : that it would be generally applicable to ARM on other OSs?
: >
: > The fanciest way to cope would be to have a run-time check to see
: > which address to use. This likely isn't worth the bother since the
: > user base is still relatively small (and none of the other atomics do
: > this). The next best approach would be to include <machine/sysarch.h>
: > and use the value defined there for ARM_RAS_START and ARM_RAS_END.
: > Again, I've not double checked to make sure they are defined before,
: > but I think they are (or at least if they aren't defined, we know to
: > use the old value).
: >
:
: Actually, the patch I sent Doug does just that, it uses ARM_RAS_START
: (because it includes machine/atomic.h, which includes machine/sysarch.h).
: It should work for 7 as well, as ARM_RAS_START was defined too (but in
: machine/atomic.h)
Hmmm, missed that part of it... Then yes, it is ready to go.
Warner
------------------------------
Message: 7
Date: Mon, 22 Feb 2010 11:06:53 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <201002221106....@freefall.freebsd.org>
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker Resp. Description
--------------------------------------------------------------------------------
o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2
o arm/134338 arm [patch] Lock GPIO accesses on ixp425
o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n
3 problems total.
------------------------------
End of freebsd-arm Digest, Vol 204, Issue 1
*******************************************