freebsd-arm Digest, Vol 206, 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: Performance of SheevaPlug on 8-stable (Maks Verver)
2. Re: Performance of SheevaPlug on 8-stable (Bernd Walter)
3. Re: Performance of SheevaPlug on 8-stable (Rafal Jaworowski)
4. Re: Performance of SheevaPlug on 8-stable (Mark Tinguely)
5. Re: Performance of SheevaPlug on 8-stable (Maks Verver)
6. Re: Performance of SheevaPlug on 8-stable (Bernd Walter)
7. Re: Performance of SheevaPlug on 8-stable (Bernd Walter)
8. Re: Performance of SheevaPlug on 8-stable (Bernd Walter)
9. Re: Performance of SheevaPlug on 8-stable (Mark Tinguely)
10. Smallest ARM Device for FreeBSD (li...@walkertc.com)
11. Re: Performance of SheevaPlug on 8-stable (Bernd Walter)
12. Re: Performance of SheevaPlug on 8-stable (Jacques Fourie)
13. Re: Performance of SheevaPlug on 8-stable (Hans Petter Selasky)
14. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
----------------------------------------------------------------------
Message: 1
Date: Sun, 07 Mar 2010 20:56:14 +0100
From: Maks Verver <maksv...@geocities.com>
Subject: Re: Performance of SheevaPlug on 8-stable
To: freeb...@freebsd.org
Message-ID: <4B9404D...@geocities.com>
Content-Type: text/plain; charset=ISO-8859-1
On 03/07/2010 08:00 AM, Bernd Walter wrote:
> That's probably just because of different CPUs.
> I see a similar output on all of my systems with ARM920T CPU and
> still there is something wrong.
That's strange indeed. I'm not sure if our problems are at all related
(as in: caused by the same problem) as you seem to be using fairly
different hardware.
In my case the kernel (at boot up) doesn't seem to even think caches are
enabled, which gives me some hope that if they were, then they would
work. In your case the kernel claims to enable them but then they don't
work. Seems different to me.
> Your loop isn't doing any data access, so it's just saying something
> about ICACHE not working.
True enough.
> But maybe it is not ICACHE itself and the memory pages are just
> declared uncacheable?
Another possibility. If anyone has suggestions on how to investigate
this, I'd love to hear it.
- Maks Verver.
------------------------------
Message: 2
Date: Sun, 7 Mar 2010 21:12:23 +0100
From: Bernd Walter <ti...@cicely7.cicely.de>
Subject: Re: Performance of SheevaPlug on 8-stable
To: Maks Verver <maksv...@geocities.com>
Cc: freeb...@freebsd.org
Message-ID: <20100307201...@cicely7.cicely.de>
Content-Type: text/plain; charset=us-ascii
On Sun, Mar 07, 2010 at 08:56:14PM +0100, Maks Verver wrote:
> On 03/07/2010 08:00 AM, Bernd Walter wrote:
> > That's probably just because of different CPUs.
> > I see a similar output on all of my systems with ARM920T CPU and
> > still there is something wrong.
>
> That's strange indeed. I'm not sure if our problems are at all related
> (as in: caused by the same problem) as you seem to be using fairly
> different hardware.
That's true, but the symptoms I see are quite similar, although the
OS version seem to have an influence on how high the performance loss
actually is.
This fact is especially puzzling, because I would have either expected
similar results or calulated performance.
> In my case the kernel (at boot up) doesn't seem to even think caches are
> enabled, which gives me some hope that if they were, then they would
> work. In your case the kernel claims to enable them but then they don't
> work. Seems different to me.
It is just different code printing the details for your CPU.
Take a look into sys/arm/arm/identcpu.c.
There is "if xxx IC disabled else IC enabled" printing - if you see
neither it is not printing from this code at all.
> > Your loop isn't doing any data access, so it's just saying something
> > about ICACHE not working.
>
> True enough.
>
> > But maybe it is not ICACHE itself and the memory pages are just
> > declared uncacheable?
>
> Another possibility. If anyone has suggestions on how to investigate
> this, I'd love to hear it.
Me too.
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
------------------------------
Message: 3
Date: Sun, 7 Mar 2010 21:30:55 +0100
From: Rafal Jaworowski <r...@semihalf.com>
Subject: Re: Performance of SheevaPlug on 8-stable
To: Maks Verver <maksv...@geocities.com>
Cc: freeb...@freebsd.org
Message-ID: <FB81E027-0CCC-4DF6...@semihalf.com>
Content-Type: text/plain; charset=us-ascii
On 2010-03-07, at 20:56, Maks Verver wrote:
> On 03/07/2010 08:00 AM, Bernd Walter wrote:
>> That's probably just because of different CPUs.
>> I see a similar output on all of my systems with ARM920T CPU and
>> still there is something wrong.
>
> That's strange indeed. I'm not sure if our problems are at all related
> (as in: caused by the same problem) as you seem to be using fairly
> different hardware.
>
> In my case the kernel (at boot up) doesn't seem to even think caches are
> enabled, which gives me some hope that if they were, then they would
> work. In your case the kernel claims to enable them but then they don't
> work. Seems different to me.
The reason there is not output about cache ena/dis-able status for the Sheeva CPU is just a minor bug. Please try the patch below to get the status info at boot time:
Index: sys/arm/arm/identcpu.c
===================================================================
--- sys/arm/arm/identcpu.c (wersja 204729)
+++ sys/arm/arm/identcpu.c (kopia robocza)
@@ -415,6 +415,7 @@ identify_arm_cpu(void)
case CPU_CLASS_ARM9EJS:
case CPU_CLASS_ARM10E:
case CPU_CLASS_ARM10EJ:
+ case CPU_CLASS_MARVELL:
case CPU_CLASS_SA1:
case CPU_CLASS_XSCALE:
case CPU_CLASS_ARM11J:
I would expect L1 caches are enabled on your system (please verify with the above patch) and it must be some other problem. If the caches were disabled the whole system would crawl (including networking). I also checked on another 6281-based dev board running with caches ON and observed the same ill effect.
Rafal
------------------------------
Message: 4
Date: Sun, 7 Mar 2010 15:25:41 -0600 (CST)
From: Mark Tinguely <ting...@casselton.net>
Subject: Re: Performance of SheevaPlug on 8-stable
To: maksv...@geocities.com, r...@semihalf.com
Cc: freeb...@freebsd.org
Message-ID: <201003072125....@casselton.net>
FreeBSD-current has kernel and user witness turned on. Witness is for
locks, so it should not change the performance of a tight arithmetic loop
like this.
I don't know the marvell interals, and from what I tell, their technial
docs require NDA. That said, many of the ARM processors also have a
instruction internal cache (instruction prefetch) in addition to the
instruction cache. I don't think the prefetch has an enable/disable.
It looks like from the cpu identification that the the branch prediction
is turned on. Branch prediction compensates for the longer pipelines.
I can't see how in the tight loop how that could go astray.
Thus says the ARM ARM:
ARM implementations are free to choose how far ahead of the
current point of execution they prefetch instructions; either
a fixed or a dynamically varying number of instructions. As well
as being free to choose how many instructions to prefetch, an ARM
implementation can choose which possible future execution path to
prefetch along. For example, after a branch instruction, it can
choose to prefetch either the instruction following the branch
or the instruction at the branch target. This is known as branch
prediction.
There are a few data dangling allocations that I would like to see
closed from the multiple kernel allocation fix. *IN THEORY, IF* a page
is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then
it is never marked as unallocated. *IN THEORY*, if that page is used
again, then we could falsely believe that page is being shared and
we turn off the cache, eventhough it is not shared.
http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff
* Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in
the Sheeva implementation. This is a theoritical observation of a side
effect of the multiple kernel mapping patch that we did just before
FreeBSD 8-release.
--Mark Tinguely
------------------------------
Message: 5
Date: Sun, 07 Mar 2010 22:38:36 +0100
From: Maks Verver <maksv...@geocities.com>
Subject: Re: Performance of SheevaPlug on 8-stable
To: freeb...@freebsd.org
Message-ID: <4B941CDC...@geocities.com>
Content-Type: text/plain; charset=ISO-8859-1
On 03/07/2010 09:30 PM, Rafal Jaworowski wrote:
> The reason there is not output about cache ena/dis-able status for
> the Sheeva CPU is just a minor bug. Please try the patch below to get
> the status info at boot time:
Thanks. I figured this out myself after Bernd's last message. There is
another (bigger) bug in identcpu.c though: cpu_classes[] defines only 17
entries while enum cpu_class defines 18 values, CPU_CLASS_MARVELL being
the last one. Therefore, identcpu.c reads outside the cpu_classes array!
(That's why I got the nonsensical "write-through core" in my output;
although it's better than a crash.)
I think both of these bugs should be fixed, but that doesn't help with
the performance problem of course.
> I would expect L1 caches are enabled on your system (please verify
> with the above patch) and it must be some other problem. If the
> caches were disabled the whole system would crawl (including
> networking). I also checked on another 6281-based dev board running
> with caches ON and observed the same ill effect.
You're right. It prints that L1 data and instruction caches are on. The
L2 cache bit is off, but this was to be expected, as I understand from
the Linux code that the Feroceon's L2 cache is not configured through
the standard system control register.
So the problem must lie somewhere else then. Any suggestions where to
look next?
- Maks Verver.
------------------------------
Message: 6
Date: Mon, 8 Mar 2010 01:27:04 +0100
From: Bernd Walter <ti...@cicely7.cicely.de>
Subject: Re: Performance of SheevaPlug on 8-stable
To: Mark Tinguely <ting...@casselton.net>
Cc: freeb...@freebsd.org
Message-ID: <20100308002...@cicely7.cicely.de>
Content-Type: text/plain; charset=us-ascii
On Sun, Mar 07, 2010 at 03:25:41PM -0600, Mark Tinguely wrote:
>
> FreeBSD-current has kernel and user witness turned on. Witness is for
> locks, so it should not change the performance of a tight arithmetic loop
> like this.
I have no kernel debugging enabled.
I have no malloc.conf on current, but I have on the 8.0-current system,
so malloc debugging is enabled on one machine, but it shouldn't hurt in
this case since it is not allocating anything.
> I don't know the marvell interals, and from what I tell, their technial
> docs require NDA. That said, many of the ARM processors also have a
> instruction internal cache (instruction prefetch) in addition to the
> instruction cache. I don't think the prefetch has an enable/disable.
>
> It looks like from the cpu identification that the the branch prediction
> is turned on. Branch prediction compensates for the longer pipelines.
> I can't see how in the tight loop how that could go astray.
>
> Thus says the ARM ARM:
>
> ARM implementations are free to choose how far ahead of the
> current point of execution they prefetch instructions; either
> a fixed or a dynamically varying number of instructions. As well
> as being free to choose how many instructions to prefetch, an ARM
> implementation can choose which possible future execution path to
> prefetch along. For example, after a branch instruction, it can
> choose to prefetch either the instruction following the branch
> or the instruction at the branch target. This is known as branch
> prediction.
>
> There are a few data dangling allocations that I would like to see
> closed from the multiple kernel allocation fix. *IN THEORY, IF* a page
> is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then
> it is never marked as unallocated. *IN THEORY*, if that page is used
> again, then we could falsely believe that page is being shared and
> we turn off the cache, eventhough it is not shared.
>
> http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff
>
> * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in
> the Sheeva implementation. This is a theoritical observation of a side
> effect of the multiple kernel mapping patch that we did just before
> FreeBSD 8-release.
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
------------------------------
Message: 7
Date: Mon, 8 Mar 2010 02:31:05 +0100
From: Bernd Walter <ti...@cicely7.cicely.de>
Subject: Re: Performance of SheevaPlug on 8-stable
To: Mark Tinguely <ting...@casselton.net>
Cc: freeb...@freebsd.org
Message-ID: <20100308013...@cicely7.cicely.de>
Content-Type: text/plain; charset=us-ascii
On Mon, Mar 08, 2010 at 01:27:04AM +0100, Bernd Walter wrote:
> On Sun, Mar 07, 2010 at 03:25:41PM -0600, Mark Tinguely wrote:
> >
> > FreeBSD-current has kernel and user witness turned on. Witness is for
> > locks, so it should not change the performance of a tight arithmetic loop
> > like this.
>
> I have no kernel debugging enabled.
> I have no malloc.conf on current, but I have on the 8.0-current system,
> so malloc debugging is enabled on one machine, but it shouldn't hurt in
> this case since it is not allocating anything.
>
> > I don't know the marvell interals, and from what I tell, their technial
> > docs require NDA. That said, many of the ARM processors also have a
> > instruction internal cache (instruction prefetch) in addition to the
> > instruction cache. I don't think the prefetch has an enable/disable.
> >
> > It looks like from the cpu identification that the the branch prediction
> > is turned on. Branch prediction compensates for the longer pipelines.
> > I can't see how in the tight loop how that could go astray.
> >
> > Thus says the ARM ARM:
> >
> > ARM implementations are free to choose how far ahead of the
> > current point of execution they prefetch instructions; either
> > a fixed or a dynamically varying number of instructions. As well
> > as being free to choose how many instructions to prefetch, an ARM
> > implementation can choose which possible future execution path to
> > prefetch along. For example, after a branch instruction, it can
> > choose to prefetch either the instruction following the branch
> > or the instruction at the branch target. This is known as branch
> > prediction.
> >
> > There are a few data dangling allocations that I would like to see
> > closed from the multiple kernel allocation fix. *IN THEORY, IF* a page
> > is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then
> > it is never marked as unallocated. *IN THEORY*, if that page is used
> > again, then we could falsely believe that page is being shared and
> > we turn off the cache, eventhough it is not shared.
> >
> > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff
> >
> > * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in
> > the Sheeva implementation. This is a theoritical observation of a side
> > effect of the multiple kernel mapping patch that we did just before
> > FreeBSD 8-release.
This sounds possible.
My 8.0-current system should be before that change and it is much faster
than my current system.
It is still slower than the calculated ~80s and the difference looks
a bit large to just think it is a stalled pipeline because of the branch.
Has anyone access to a RM9200 system running Linux?
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
------------------------------
Message: 8
Date: Mon, 8 Mar 2010 03:16:42 +0100
From: Bernd Walter <ti...@cicely7.cicely.de>
Subject: Re: Performance of SheevaPlug on 8-stable
To: Mark Tinguely <ting...@casselton.net>
Cc: freeb...@freebsd.org
Message-ID: <20100308021...@cicely7.cicely.de>
Content-Type: text/plain; charset=us-ascii
On Mon, Mar 08, 2010 at 02:31:05AM +0100, Bernd Walter wrote:
> On Mon, Mar 08, 2010 at 01:27:04AM +0100, Bernd Walter wrote:
> > On Sun, Mar 07, 2010 at 03:25:41PM -0600, Mark Tinguely wrote:
> > >
> > > FreeBSD-current has kernel and user witness turned on. Witness is for
> > > locks, so it should not change the performance of a tight arithmetic loop
> > > like this.
> >
> > I have no kernel debugging enabled.
> > I have no malloc.conf on current, but I have on the 8.0-current system,
> > so malloc debugging is enabled on one machine, but it shouldn't hurt in
> > this case since it is not allocating anything.
> >
> > > I don't know the marvell interals, and from what I tell, their technial
> > > docs require NDA. That said, many of the ARM processors also have a
> > > instruction internal cache (instruction prefetch) in addition to the
> > > instruction cache. I don't think the prefetch has an enable/disable.
> > >
> > > It looks like from the cpu identification that the the branch prediction
> > > is turned on. Branch prediction compensates for the longer pipelines.
> > > I can't see how in the tight loop how that could go astray.
> > >
> > > Thus says the ARM ARM:
> > >
> > > ARM implementations are free to choose how far ahead of the
> > > current point of execution they prefetch instructions; either
> > > a fixed or a dynamically varying number of instructions. As well
> > > as being free to choose how many instructions to prefetch, an ARM
> > > implementation can choose which possible future execution path to
> > > prefetch along. For example, after a branch instruction, it can
> > > choose to prefetch either the instruction following the branch
> > > or the instruction at the branch target. This is known as branch
> > > prediction.
> > >
> > > There are a few data dangling allocations that I would like to see
> > > closed from the multiple kernel allocation fix. *IN THEORY, IF* a page
> > > is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then
> > > it is never marked as unallocated. *IN THEORY*, if that page is used
> > > again, then we could falsely believe that page is being shared and
> > > we turn off the cache, eventhough it is not shared.
> > >
> > > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff
> > >
> > > * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in
> > > the Sheeva implementation. This is a theoritical observation of a side
> > > effect of the multiple kernel mapping patch that we did just before
> > > FreeBSD 8-release.
>
> This sounds possible.
> My 8.0-current system should be before that change and it is much faster
> than my current system.
> It is still slower than the calculated ~80s and the difference looks
> a bit large to just think it is a stalled pipeline because of the branch.
> Has anyone access to a RM9200 system running Linux?
With your patch my current system is faster as well.
[55]chipmunk.cicely.de# ./test
207.000u 0.000s 4:01.13 86.0% 46+1516k 0+0io 0pf+0w
[56]chipmunk.cicely.de# ./test
207.000u 0.000s 3:55.66 87.9% 45+1516k 0+0io 0pf+0w
It is still puzzling me why it is not near 80 seconds.
This would mean it is loosing something about 5-6 cycles.
Well - Ok - the pipeline might be that long and real loops are
mostly some instructions longer.
But I would still be interested to see Linux results on RM9200.
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
------------------------------
Message: 9
Date: Sun, 7 Mar 2010 21:00:03 -0600 (CST)
From: Mark Tinguely <ting...@casselton.net>
Subject: Re: Performance of SheevaPlug on 8-stable
To: ti...@cicely.de
Cc: freeb...@freebsd.org
Message-ID: <201003080300....@casselton.net>
<deletes>
> It is still puzzling me why it is not near 80 seconds.
> This would mean it is loosing something about 5-6 cycles.
> Well - Ok - the pipeline might be that long and real loops are
> mostly some instructions longer.
> But I would still be interested to see Linux results on RM9200.
>
> --
> B.Walter <be...@bwct.de> http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Thinking way out of the box ... has anyone tried this in single user mode?
--Mark Tinguely
------------------------------
Message: 10
Date: Sun, 7 Mar 2010 22:44:30 -0500
From: <li...@walkertc.com>
Subject: Smallest ARM Device for FreeBSD
To: <freeb...@freebsd.org>
Message-ID: <000201cabe71$a8f830a0$fae891e0$@com>
Content-Type: text/plain; charset="us-ascii"
What is the smallest ARM device that FreeBSD can run on?
I am also looking for recommendations with respect to the most compatible
ARM device that works with FreeBSD - and possibly the tradeoffs between
devices. The web site doesn't go into much detail.
------------------------------
Message: 11
Date: Mon, 8 Mar 2010 09:20:43 +0100
From: Bernd Walter <ti...@cicely7.cicely.de>
Subject: Re: Performance of SheevaPlug on 8-stable
To: Mark Tinguely <ting...@casselton.net>
Cc: freeb...@freebsd.org, ti...@cicely.de
Message-ID: <20100308082...@cicely7.cicely.de>
Content-Type: text/plain; charset=us-ascii
On Sun, Mar 07, 2010 at 09:00:03PM -0600, Mark Tinguely wrote:
>
> <deletes>
>
> > It is still puzzling me why it is not near 80 seconds.
> > This would mean it is loosing something about 5-6 cycles.
> > Well - Ok - the pipeline might be that long and real loops are
> > mostly some instructions longer.
> > But I would still be interested to see Linux results on RM9200.
>
> Thinking way out of the box ... has anyone tried this in single user mode?
Would be difficult for me since I have no loader to submit bootflags.
Loader support is definitiv on my wishlist, but that's a another subject.
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
------------------------------
Message: 12
Date: Mon, 8 Mar 2010 10:25:59 +0200
From: Jacques Fourie <jacques...@gmail.com>
Subject: Re: Performance of SheevaPlug on 8-stable
To: Mark Tinguely <ting...@casselton.net>
Cc: freeb...@freebsd.org, ti...@cicely.de
Message-ID:
<be2f52431003080025s3d9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Mar 8, 2010 at 5:00 AM, Mark Tinguely <ting...@casselton.net> wrote:
>
> <deletes>
>
>> �It is still puzzling me why it is not near 80 seconds.
>> �This would mean it is loosing something about 5-6 cycles.
>> �Well - Ok - the pipeline might be that long and real loops are
>> �mostly some instructions longer.
>> �But I would still be interested to see Linux results on RM9200.
>>
>> �--
>> �B.Walter <be...@bwct.de> http://www.bwct.de
>> �Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>
>
> Thinking way out of the box ... has anyone tried this in single user mode?
>
> --Mark Tinguely
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm...@freebsd.org"
>
The xscale platforms now have hwpmc(4) support, maybe this will help
in tracking down this issue?
------------------------------
Message: 13
Date: Mon, 8 Mar 2010 10:07:14 +0100
From: Hans Petter Selasky <hsel...@c2i.net>
Subject: Re: Performance of SheevaPlug on 8-stable
To: freeb...@freebsd.org
Cc: Mark Tinguely <ting...@casselton.net>, ti...@cicely.de
Message-ID: <201003081007....@c2i.net>
Content-Type: Text/Plain; charset="iso-8859-1"
On Monday 08 March 2010 09:25:59 Jacques Fourie wrote:
> On Mon, Mar 8, 2010 at 5:00 AM, Mark Tinguely <ting...@casselton.net>
wrote:
> > <deletes>
> >
> >> It is still puzzling me why it is not near 80 seconds.
> >> This would mean it is loosing something about 5-6 cycles.
> >> Well - Ok - the pipeline might be that long and real loops are
> >> mostly some instructions longer.
> >> But I would still be interested to see Linux results on RM9200.
> >>
> >> --
> >> B.Walter <be...@bwct.de> http://www.bwct.de
> >> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> >
> > Thinking way out of the box ... has anyone tried this in single user
> > mode?
> >
Was the output from "vmstat -i" and "top" posted?
--HPS
------------------------------
Message: 14
Date: Mon, 8 Mar 2010 11:06:52 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <201003081106....@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 206, Issue 1
*******************************************