Re: Customizing ubldr build...
On May 23, 2012, at 8:24 AM, Adrian Chadd wrote: > This looks fine to me. > > Thanks for this! What's the pandaboard require, just out of curiosity? Based on a quick skim of the OMAP 4460 TRM, it looks like the Pandaboard ES should come up with the same general memory layout as the BeagleBone, with DRAM starting at 0x8000 . I think the PandaBoard ES is fully supported by U-Boot, so it should be possible to use ubldr as part of the boot chain for that just like I've been doing with BeagleBone. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UFS+J panics on HEAD
- Original Message - From: "Mark Linimon" On Wed, May 23, 2012 at 10:58:48PM +0100, Steven Hartland wrote: While it might be a shame to see FFS go by the wayside are there any big reasons why you would rather stick with FFS instead of moving to ZFS with all the benefits that brings? - ZFS eats bytes for breakfast. It is completely inappropriate for anything with less than 4GB RAM. It does like more RAM than FFS, but can be tuned to work under smaller amounts however given current pricing does anyone use HW for servers with that little RAM? Sure old i386 machines still running legacy ABC that just works so no need to upgrade it may still have less than 4GB RAM, but modern machines running large disk sets are a totally different matter. - ZFS performs poorly under disk-nearly-full conditions. Not experienced that here, care to clarify / quantify? While if this is the case I can see that may cause problems, but the solution to that is simple don't let your system get that full. Disks are still relatively cheap even after the disasters, so keep on top of your space and you wont see that problem; particularly as ZFS makes it so easy to expand existing pools :) Regards steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UFS+J panics on HEAD
On Wed, May 23, 2012 at 10:58:48PM +0100, Steven Hartland wrote: > While it might be a shame to see FFS go by the wayside are there any > big reasons why you would rather stick with FFS instead of moving > to ZFS with all the benefits that brings? - ZFS eats bytes for breakfast. It is completely inappropriate for anything with less than 4GB RAM. - ZFS performs poorly under disk-nearly-full conditions. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UFS+J panics on HEAD
- Original Message - From: "Lev Serebryakov" Or should we call FFS officially dead and promote ZFS as only usable FS on modern FreeBSD now? Slightly OT but I must say I'm a big fan of ZFS since I first tried it under FreeBSD a few years back. Not only is it a dream to use as an admin, making all traditionally hard tasks easy; its also helped us identify failing hardware which nothing else has spotted. While it might be a shame to see FFS go by the wayside are there any big reasons why you would rather stick with FFS instead of moving to ZFS with all the benefits that brings? With regards protective panics I must agree, in this case it does seem there are much better paths which could be chosen. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: buildworld fails
On Wed, May 23, 2012 at 1:52 PM, O. Hartmann
wrote:
> On 05/19/12 22:33, Garrett Cooper wrote:
>> On Sat, May 19, 2012 at 6:55 AM, O. Hartmann
>> wrote:
>>> Since approx. a week for now, I can not build FreeBSD 10.0-CURRENT/amd64
>>> anymore! This happens to be on ALL(!) FreeBSD 10 boxes around here I
>>> maintain.
>>
>> ...
>>
>>> b) build and install /usr/src/lib via "make clean cleandepend depend obj
>>> all install" doesn't work anymore, it fails with
>>> ."/usr/src/lib/Makefile", line 179: Malformed conditional (${MK_NAND} !=
>>> "no")
>>> "/usr/src/lib/Makefile", line 181: if-less endif
>>
>> Your mk files in /usr/share/mk are out of synch with your build tree.
>> If you opt out of using buildworld, then you need to do 'make -C
>> share/mk install' beforehand.
...
> My problems occured around the May, 15th and hit ALL of my FreeBSD
> 10-CURRENT/amd64 boxes on which I do most time daily buildworld. Two of
> them could be fixed, I did this two days ago by
The problem has been on and off "mild" breakage for the past couple
days (yacc, format string qualifier issues, etc).
> cd /usr/src
> make installincludes
> make -C {lib|libexec|sbin ...} clean cleandepend depend obj all install
>
> On one specific machine it didn't work that way. I found out that
> several binaries in the system's tree remained dated on 15th May, so
> like "ld" or other essential pieces. Therefore I suspect a crushed system.
I ran into a similar issue when my copy of mtree went MIA after a
freshly installed world corrupted my VM during an nlm panic
(thankfully it was my VM and not something else).
> Does anyhow do have any idea how to repair the system?
Trial and error for the base system is the only method I'm aware of
right now, but if portions of the base system are corrupted and not
others, I would suspect all of the contents on disk (esp after recent
reports about UFS filesystem corruption with SUJ).
> I can compile a kernel, but I can not compile ports (or even update them, I
> receive
> multiple weird errors of missing header files or "changed" libstdc++.so.
You can resolve the ports issue via another port that's shell based or
C based. Memory serves me correctly it was
ports-mgmt/port-maintenance-tools ..
> The idea was to take a very recent binary installation set and install
> this selective peice by piece over the existing installation, but I need
> to preserve /etc and other directories. Any ideas ?
You can save files that would be in the dist tarballs on the install
media to another directory (/etc/*, customizations in /root, /usr,
etc). Then you can extract the tarballs (I would use a test directory
first though). Passing certain flags to tar to just copy out some
binaries might help.
> Help is appreciated and thanks in advance,
Lesson to maybe learn:
1. Always have a backup machine running a stable version of FreeBSD
that is fast enough that you can use to generate images and push out
to machines on the fly. If not possible, always have a static
toolchain on hand (I would assume that it's safe to say that anything
listed in bootstrap-tools would be game for the toolchain).
2. Expect warts on CURRENT right after a major release cycle has run
its course. If this is too much to worry about, don't run 10-CURRENT
and instead run 9-STABLE, etc.
Cheers,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UFS+J panics on HEAD
Hello, Konstantin. You wrote 23 мая 2012 г., 17:10:46: KB> This panic is another protective panic caused by on-disk inconsistent KB> structures. The bitmap indicated that an inode was free, but actual inode KB> context suggested that the inode is in use. KB> I would not worry much about ffs code until known hardware problem on KB> the machine are fixed. Konstantin, it is very sad, that official position of one of FFS maintainers (according to mailing list activity), is to blame hardware on every FFS/SU/SUJ inconsistency and do nothing with code. According to my experience, we all live in real world, where HDDs could lost write cache on power failure or kernel panic unrelated to FFS, UPSes and PSUs fails (which leads to power failures) and HDDs with turned off write cache are unusable -- because they become slow like hell without writing cache. You could name it "broken hardware," but let face it -- all non-top-server hardware, everything, but HBAs with battery installed in double-PSU-equipped cases, are "broken" now in this sense. My home server with almost-read-only load crashes due to burned out PSU twice in last 2 years (and I buy "good" desktop PSUs, in $150-$200 price range, not china boxes for $30) and I've got one memory problem in this time period (DIMM was detected and replaced, but I've got two or three panics before I become sure, that it is memory problem, because memtest86+ doesn;t find any problems in 12+ hours run). It is good desktop hardware, with good cooling system, not something low-end, but not server-grade one, of course. And after EVERY of such crashes my main storage area (95% read, 5% write) had dozens of "unexpected SU inconsistences," background fsck fails to create snapshot and I was need to run foreground fsck for many hours. It seems, that "async" mount without SU will not be worse that SU solution! And, if you read through mailing lists, you cold find dozens such reports. And answer almost always is "broken hardware". Yes, Ok, it is broken hardware, all right. But we haven't other one! We need to live with what we have! What I want to say: FFS/SU become almost unusable on this hardware. Protective panic, my ass! Every solution (link this inode to lost+found and mark as used, mark it as free, etc) is better than protective panic. One mismatched inode is not the end of the world, it is even not end of cylinder group, not to say about whole FS, system could (and must) complain about it, but not panic! Did you hear term ``self-healing''? It seems, that modern hardware needed better solution, that "just panic and blame hardware." Or should we call FFS officially dead and promote ZFS as only usable FS on modern FreeBSD now? -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: buildworld fails
On 05/19/12 22:33, Garrett Cooper wrote:
> On Sat, May 19, 2012 at 6:55 AM, O. Hartmann
> wrote:
>> Since approx. a week for now, I can not build FreeBSD 10.0-CURRENT/amd64
>> anymore! This happens to be on ALL(!) FreeBSD 10 boxes around here I
>> maintain.
>
> ...
>
>> b) build and install /usr/src/lib via "make clean cleandepend depend obj
>> all install" doesn't work anymore, it fails with
>> ."/usr/src/lib/Makefile", line 179: Malformed conditional (${MK_NAND} !=
>> "no")
>> "/usr/src/lib/Makefile", line 181: if-less endif
>
> Your mk files in /usr/share/mk are out of synch with your build tree.
> If you opt out of using buildworld, then you need to do 'make -C
> share/mk install' beforehand.
>
> Thanks,
> -Garrett
My problems became more desperate.
Since May, 15th, I'm unable to compile a buildworld and I suspect I
messed up my OS somehow.
I have already completely deleted /usr/src and checked out via SVN again.
Deleting /etc/src.conf and /etc/make.conf, performing buildworld with
the system's original make.conf (using the legacy GCC 4.2.1) ends up
with the below shown error.
Try to compile with CLANG as suggested via the Wiki page and the
attached /etc/src.conf gives a very short approach in how to trap into a
error, also shown below.
My problems occured around the May, 15th and hit ALL of my FreeBSD
10-CURRENT/amd64 boxes on which I do most time daily buildworld. Two of
them could be fixed, I did this two days ago by
cd /usr/src
make installincludes
make -C {lib|libexec|sbin ...} clean cleandepend depend obj all install
On one specific machine it didn't work that way. I found out that
several binaries in the system's tree remained dated on 15th May, so
like "ld" or other essential pieces. Therefore I suspect a crushed system.
Does anyhow do have any idea how to repair the system? I can compile a
kernel, but I can not compile ports (or even update them, I receive
multiple weird errors of missing header files or "changed" libstdc++.so.
The idea was to take a very recent binary installation set and install
this selective peice by piece over the existing installation, but I need
to preserve /etc and other directories. Any ideas ?
Help is appreciated and thanks in advance,
Oliver
[ BUILD with legacy gcc 4.2.1]
===> bin/ed (all)
cc -O2 -pipe -DDES -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/bin/ed/buf.c
cc -O2 -pipe -DDES -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/bin/ed/cbc.c
cc -O2 -pipe -DDES -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/bin/ed/glbl.c
cc -O2 -pipe -DDES -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/bin/ed/io.c
cc -O2 -pipe -DDES -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/bin/ed/main.c
cc -O2 -pipe -DDES -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/bin/ed/re.c
cc -O2 -pipe -DDES -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredunda
Re: RFC: [PATCH] disabling buckets under "low memory"
On Wed, May 23, 2012 at 1:05 PM, Maksim Yevmenkin <
maksim.yevmen...@gmail.com> wrote:
> hello,
>
> would anyone object to the following patch?
>
>
No objection. There shouldn't be any controversy here. Your patch is
correct. The existing code in UMA is doing the wrong comparison.
Alan
> ===
>
> Index: uma_core.c
> ===
> --- uma_core.c (revision 616)
> +++ uma_core.c (working copy)
> @@ -267,10 +267,7 @@
> static void
> bucket_enable(void)
> {
> - if (cnt.v_free_count < cnt.v_free_min)
> - bucketdisable = 1;
> - else
> - bucketdisable = 0;
> + bucketdisable = vm_page_count_min();
> }
>
> ===
>
> i've observed situation where per-cpu buckets were disabled while
> there were enough free cached pages. basically, cnt.v_free_count was
> sitting stable at a value lower than cnt.v_free_min and that caused
> massive performance drop. tuning down vm.v_free_min sysctl immediately
> helped.
>
> thanks,
> max
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RFC: [PATCH] disabling buckets under "low memory"
hello,
would anyone object to the following patch?
===
Index: uma_core.c
===
--- uma_core.c (revision 616)
+++ uma_core.c (working copy)
@@ -267,10 +267,7 @@
static void
bucket_enable(void)
{
- if (cnt.v_free_count < cnt.v_free_min)
- bucketdisable = 1;
- else
- bucketdisable = 0;
+ bucketdisable = vm_page_count_min();
}
===
i've observed situation where per-cpu buckets were disabled while
there were enough free cached pages. basically, cnt.v_free_count was
sitting stable at a value lower than cnt.v_free_min and that caused
massive performance drop. tuning down vm.v_free_min sysctl immediately
helped.
thanks,
max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Customizing ubldr build...
This looks fine to me. Thanks for this! What's the pandaboard require, just out of curiousity? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10 prognostication...
.. then: * test out pkgng on FreeBSD-9.x and provide as much feedback as you can; * help test out massive deployment, upgrade and auditing scenarios - exactly the kinds of things which cloud using people need. Installing 1 boxes is difficult. Auditing, upgrading and integrating services on 10,000 boxes.. much more difficult. * help out with the cloud provision-y service things that FreeBSD is missing - for example, get the vmware vmdk installer stuff be part of the install/release system - so people _can_ easily build FreeBSD VMDK's as appliance/cloud images. * integrate it with Puppet and other configuration/monitoring/management frameworks. Upgrade that integration to whatever counts as Tier-1 in those projects. I bet they focus on Linux only. There's a whole lot of useful work that doesn't at all leave the userland. If you'd like to see FreeBSD in "the cloud", these are the things you need to address. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (no subject) (was panic in vfs_lookup/kern_statat_vnhook?)
Konstantin Belousov wrote:
> On Wed, May 23, 2012 at 03:42:14PM +0200, Ian FREISLICH wrote:
> > John Baldwin wrote:
> > > On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
> > > > (kgdb) frame 7
> > > > #7 0xc0878682 in pmap_enter (pmap=3D0xc09e4060, va=3D3359633408, acc=
> ess=3D7 '\a'
> > ,=20
> > > > m=3D0xc191bf70, prot=3D7 '\a', wired=3D1) at=20
> > > /usr/src/sys/i386/i386/pmap.c:1596
> > > > 1596root =3D vm_page_splay(mpte->pindex, root);
> > > > (kgdb) l
> > > > 1591root =3D pmap->pm_root;
> > > > 1592if (root =3D=3D NULL) {
> > > > 1593mpte->left =3D NULL;
> > > > 1594mpte->right =3D NULL;
> > > > 1595} else {
> > > > 1596root =3D vm_page_splay(mpte->pindex, root);
> > > > 1597if (mpte->pindex < root->pindex) {
> > > > 1598mpte->left =3D root->left;
> > > > 1599mpte->right =3D root;
> > > > 1600root->left =3D NULL;
> > >=20
> > > Ok, can you do 'p root', 'p mpte', and 'p *mpte'?
> >=20
> > (kgdb) frame 7
> > #7 0xc0878682 in pmap_enter (pmap=3D0xc09e4060, va=3D3359633408, access=
> =3D7 '\a',=20
> > m=3D0xc191bf70, prot=3D7 '\a', wired=3D1) at /usr/src/sys/i386/i386/p=
> map.c:1596
> > 1596root =3D vm_page_splay(mpte->pindex, root);
> > (kgdb) p root
> > No symbol "root" in current context.
> > (kgdb) p mpte
> > $1 =3D 0x0
> > (kgdb) p *mpte
> > Cannot access memory at address 0x0
>
> Do you have r235776 in your tree ? This could be another manifestation of
> this bug.
I'm not sure. I'm still using cvs. But, it happened with sources
updated last night if that helps.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re:
On Wednesday, May 23, 2012 9:42:14 am Ian FREISLICH wrote:
> John Baldwin wrote:
> > On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
> > > (kgdb) frame 7
> > > #7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7
'\a'
> ,
> > > m=0xc191bf70, prot=7 '\a', wired=1) at
> > /usr/src/sys/i386/i386/pmap.c:1596
> > > 1596root = vm_page_splay(mpte->pindex, root);
> > > (kgdb) l
> > > 1591root = pmap->pm_root;
> > > 1592if (root == NULL) {
> > > 1593mpte->left = NULL;
> > > 1594mpte->right = NULL;
> > > 1595} else {
> > > 1596root = vm_page_splay(mpte->pindex, root);
> > > 1597if (mpte->pindex < root->pindex) {
> > > 1598mpte->left = root->left;
> > > 1599mpte->right = root;
> > > 1600root->left = NULL;
> >
> > Ok, can you do 'p root', 'p mpte', and 'p *mpte'?
>
> (kgdb) frame 7
> #7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a',
> m=0xc191bf70, prot=7 '\a', wired=1) at
/usr/src/sys/i386/i386/pmap.c:1596
> 1596root = vm_page_splay(mpte->pindex, root);
> (kgdb) p root
> No symbol "root" in current context.
> (kgdb) p mpte
> $1 = 0x0
> (kgdb) p *mpte
> Cannot access memory at address 0x0
Well, mpte being NULL is the cause of your fault. :( It also seems that the
system is trying to promote a superpage, but it can't find the page table
page that currently maps the individual pages that make up the superpage
(which is odd).
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (no subject)
On Wed, May 23, 2012 at 03:42:14PM +0200, Ian FREISLICH wrote:
> John Baldwin wrote:
> > On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
> > > (kgdb) frame 7
> > > #7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7
> > > '\a'
> ,
> > > m=0xc191bf70, prot=7 '\a', wired=1) at
> > /usr/src/sys/i386/i386/pmap.c:1596
> > > 1596root = vm_page_splay(mpte->pindex, root);
> > > (kgdb) l
> > > 1591root = pmap->pm_root;
> > > 1592if (root == NULL) {
> > > 1593mpte->left = NULL;
> > > 1594mpte->right = NULL;
> > > 1595} else {
> > > 1596root = vm_page_splay(mpte->pindex, root);
> > > 1597if (mpte->pindex < root->pindex) {
> > > 1598mpte->left = root->left;
> > > 1599mpte->right = root;
> > > 1600root->left = NULL;
> >
> > Ok, can you do 'p root', 'p mpte', and 'p *mpte'?
>
> (kgdb) frame 7
> #7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a',
> m=0xc191bf70, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:1596
> 1596root = vm_page_splay(mpte->pindex, root);
> (kgdb) p root
> No symbol "root" in current context.
> (kgdb) p mpte
> $1 = 0x0
> (kgdb) p *mpte
> Cannot access memory at address 0x0
Do you have r235776 in your tree ? This could be another manifestation of
this bug.
pgp7mjyn2TWVe.pgp
Description: PGP signature
(no subject)
John Baldwin wrote:
> On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
> > (kgdb) frame 7
> > #7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a'
,
> > m=0xc191bf70, prot=7 '\a', wired=1) at
> /usr/src/sys/i386/i386/pmap.c:1596
> > 1596root = vm_page_splay(mpte->pindex, root);
> > (kgdb) l
> > 1591root = pmap->pm_root;
> > 1592if (root == NULL) {
> > 1593mpte->left = NULL;
> > 1594mpte->right = NULL;
> > 1595} else {
> > 1596root = vm_page_splay(mpte->pindex, root);
> > 1597if (mpte->pindex < root->pindex) {
> > 1598mpte->left = root->left;
> > 1599mpte->right = root;
> > 1600root->left = NULL;
>
> Ok, can you do 'p root', 'p mpte', and 'p *mpte'?
(kgdb) frame 7
#7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a',
m=0xc191bf70, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:1596
1596root = vm_page_splay(mpte->pindex, root);
(kgdb) p root
No symbol "root" in current context.
(kgdb) p mpte
$1 = 0x0
(kgdb) p *mpte
Cannot access memory at address 0x0
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in vfs_lookup/kern_statat_vnhook?
On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
> John Baldwin wrote:
> > On Tuesday, May 22, 2012 2:36:06 pm Ian FREISLICH wrote:
> > > Hi
> > >
> > > I've had quite a few reproduceable panics that look to be VFS
> > > related. The trigger is relatively heavy concurrent disk IO.
> > > I can trigger it easily two ways:
> > >
> > > 1. running my backup script which essentially does:
> > > cd /; rsync --one-file-system --delete -aHv . /backup
> > > cd /tmp; rsync --one-file-system --delete -aHv . /backup/tmp
> > > cd /usr; rsync --one-file-system --delete -aHv . /backup/usr
> > > cd /var; rsync --one-file-system --delete -aHv . /backup/var
> > >
> > > 2. While updating with cvsup or csup, launch firefox.
> > >
> > > Both reliably provoke the panic:
> > >
> > > #0 doadump (textdump=1) at pcpu.h:244
> > > #1 0xc06aa895 in kern_reboot (howto=260)
> > > at /usr/src/sys/kern/kern_shutdown.c:454
> > > #2 0xc06aad36 in panic (fmt=Variable "fmt" is not available.
> > > ) at /usr/src/sys/kern/kern_shutdown.c:642
> > > #3 0xc087adee in trap_fatal (frame=0xedb365c8, eva=28)
> > > at /usr/src/sys/i386/i386/trap.c:1022
> > > #4 0xc087aed8 in trap_pfault (frame=0xedb365c8, usermode=0, eva=28)
> > > at /usr/src/sys/i386/i386/trap.c:875
> > > #5 0xc087bc4d in trap (frame=0xedb365c8) at
/usr/src/sys/i386/i386/trap.c:
> 546
> > > #6 0xc086687c in calltrap () at /usr/src/sys/i386/i386/exception.s:169
> > > #7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7
'\a'
> ,
> > > m=0xc3073f70, prot=7 '\a', wired=1) at
/usr/src/sys/i386/i386/pmap.c:15
> 96
> >
> > This is the actual panic. Can you go to this frame? The VFS bits don't
> > matter, the pmap code blew up trying to malloc another vnode.
>
> (kgdb) frame 7
> #7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a',
> m=0xc191bf70, prot=7 '\a', wired=1) at
/usr/src/sys/i386/i386/pmap.c:1596
> 1596root = vm_page_splay(mpte->pindex, root);
> (kgdb) l
> 1591root = pmap->pm_root;
> 1592if (root == NULL) {
> 1593mpte->left = NULL;
> 1594mpte->right = NULL;
> 1595} else {
> 1596root = vm_page_splay(mpte->pindex, root);
> 1597if (mpte->pindex < root->pindex) {
> 1598mpte->left = root->left;
> 1599mpte->right = root;
> 1600root->left = NULL;
Ok, can you do 'p root', 'p mpte', and 'p *mpte'?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UFS+J panics on HEAD
On Wed, May 23, 2012 at 12:40:34AM +, Bjoern A. Zeeb wrote: > Hi, > > I have a machine that since updated to r235609 started to constantly panic > in the FS code while building universe, first with > > ufs_dirbad: /scratch: bad dir ino 1137225 at offset 17920: mangled entry > > which a clri and a fully forced fsck -y -f seems to have cleared (thanks to > kib) and now it is giving me: > > mode = 040700, inum = 14560, fs = /scratch > panic: ffs_valloc: dup alloc > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x1ce > ffs_valloc() at ffs_valloc+0x70c > ufs_makeinode() at ufs_makeinode+0x86 > VOP_CREATE_APV() at VOP_CREATE_APV+0x44 > vn_open_cred() at vn_open_cred+0x4c8 > kern_openat() at kern_openat+0x1f9 > amd64_syscall() at amd64_syscall+0x61e > Xfast_syscall() at Xfast_syscall+0xf7 > --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x4b94bc, rsp = > 0x7fffc998, rbp = 0x10 --- > > /scratch has USF+J enabled as another hint. The machine is also reporting > ECC memory corrections once in a while (replacement is on its way) but had > done that the months before the update to the latest HEAD as well w/o the > FS trouble. > > Anyone an idea on what's going on there or what had changed since Feb/March > that could cause this? I am willing to try things if I manage to get a > kernel compile for testing;-) otherwise I might dump/dd/newfs/restore and > see if I can still reproduce it afterwards or whether it just got into a state > that fsck is failing to correct... > This panic is another protective panic caused by on-disk inconsistent structures. The bitmap indicated that an inode was free, but actual inode context suggested that the inode is in use. I would not worry much about ffs code until known hardware problem on the machine are fixed. You could try another pass of the full fsck on the volume, but my expectations are that bad hardware causes continuous damage to the data and metainformation. pgp04Bg1jzI8R.pgp Description: PGP signature
Re: Broken symbolic links in /usr/lib after compiling and installing -CURRENT
On Tue, May 22, 2012 2:27 pm, Jeremie Le Hen wrote: > This is expected I think, as "make buildenv" defines $_SHLIBDIRPREFIX > which is used to make the toolchain use libraries built during stage 4.2 > of buildworld. > > Just run "make installworld" with the correct DESTDIR and your chroot > will be fine. > It helped! Thank you very much! -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab...@jabber.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on amd64/amd64
TB --- 2012-05-23 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-23 06:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-23 06:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-05-23 06:40:00 - cleaning the object tree TB --- 2012-05-23 06:43:57 - cvsupping the source tree TB --- 2012-05-23 06:43:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-05-23 06:50:32 - building world TB --- 2012-05-23 06:50:32 - CROSS_BUILD_TESTING=YES TB --- 2012-05-23 06:50:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-23 06:50:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-23 06:50:32 - SRCCONF=/dev/null TB --- 2012-05-23 06:50:32 - TARGET=amd64 TB --- 2012-05-23 06:50:32 - TARGET_ARCH=amd64 TB --- 2012-05-23 06:50:32 - TZ=UTC TB --- 2012-05-23 06:50:32 - __MAKE_CONF=/dev/null TB --- 2012-05-23 06:50:32 - cd /src TB --- 2012-05-23 06:50:32 - /usr/bin/make -B buildworld >>> World build started on Wed May 23 06:50:33 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/ppp/throughput.c:124: warning: format '%6qu' expects type 'long unsigned int', but argument 4 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:124: warning: format '%6qu' expects type 'long unsigned int', but argument 5 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:126: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c: In function 'throughput_clear': /src/usr.sbin/ppp/throughput.c:270: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:279: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:279: warning: format '%6qu' expects type 'long unsigned int', but argument 4 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:291: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/usr.sbin/ppp. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-23 09:24:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-23 09:24:22 - ERROR: failed to build world TB --- 2012-05-23 09:24:22 - 6442.97 user 881.05 system 9861.28 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/pc98
TB --- 2012-05-23 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-23 06:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-23 06:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-05-23 06:40:00 - cleaning the object tree TB --- 2012-05-23 06:43:36 - cvsupping the source tree TB --- 2012-05-23 06:43:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-05-23 06:46:03 - building world TB --- 2012-05-23 06:46:03 - CROSS_BUILD_TESTING=YES TB --- 2012-05-23 06:46:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-23 06:46:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-23 06:46:03 - SRCCONF=/dev/null TB --- 2012-05-23 06:46:03 - TARGET=pc98 TB --- 2012-05-23 06:46:03 - TARGET_ARCH=i386 TB --- 2012-05-23 06:46:03 - TZ=UTC TB --- 2012-05-23 06:46:03 - __MAKE_CONF=/dev/null TB --- 2012-05-23 06:46:03 - cd /src TB --- 2012-05-23 06:46:03 - /usr/bin/make -B buildworld >>> World build started on Wed May 23 06:46:04 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/ppp/throughput.c:124: warning: format '%6qu' expects type 'long unsigned int', but argument 4 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:124: warning: format '%6qu' expects type 'long unsigned int', but argument 5 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:126: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c: In function 'throughput_clear': /src/usr.sbin/ppp/throughput.c:270: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:279: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:279: warning: format '%6qu' expects type 'long unsigned int', but argument 4 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:291: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/usr.sbin/ppp. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-23 09:20:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-23 09:20:12 - ERROR: failed to build world TB --- 2012-05-23 09:20:12 - 6391.14 user 875.34 system 9611.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/i386
TB --- 2012-05-23 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-23 06:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-23 06:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-05-23 06:40:00 - cleaning the object tree TB --- 2012-05-23 06:43:51 - cvsupping the source tree TB --- 2012-05-23 06:43:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-05-23 06:46:06 - building world TB --- 2012-05-23 06:46:06 - CROSS_BUILD_TESTING=YES TB --- 2012-05-23 06:46:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-23 06:46:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-23 06:46:06 - SRCCONF=/dev/null TB --- 2012-05-23 06:46:06 - TARGET=i386 TB --- 2012-05-23 06:46:06 - TARGET_ARCH=i386 TB --- 2012-05-23 06:46:06 - TZ=UTC TB --- 2012-05-23 06:46:06 - __MAKE_CONF=/dev/null TB --- 2012-05-23 06:46:06 - cd /src TB --- 2012-05-23 06:46:06 - /usr/bin/make -B buildworld >>> World build started on Wed May 23 06:46:07 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/ppp/throughput.c:124: warning: format '%6qu' expects type 'long unsigned int', but argument 4 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:124: warning: format '%6qu' expects type 'long unsigned int', but argument 5 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:126: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c: In function 'throughput_clear': /src/usr.sbin/ppp/throughput.c:270: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:279: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:279: warning: format '%6qu' expects type 'long unsigned int', but argument 4 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:291: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/usr.sbin/ppp. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-23 09:19:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-23 09:19:02 - ERROR: failed to build world TB --- 2012-05-23 09:19:02 - 6429.27 user 879.54 system 9541.67 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on arm/arm
TB --- 2012-05-23 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-23 06:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-23 06:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-05-23 06:40:00 - cleaning the object tree TB --- 2012-05-23 06:43:01 - cvsupping the source tree TB --- 2012-05-23 06:43:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-05-23 06:45:27 - building world TB --- 2012-05-23 06:45:27 - CROSS_BUILD_TESTING=YES TB --- 2012-05-23 06:45:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-23 06:45:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-23 06:45:27 - SRCCONF=/dev/null TB --- 2012-05-23 06:45:27 - TARGET=arm TB --- 2012-05-23 06:45:27 - TARGET_ARCH=arm TB --- 2012-05-23 06:45:27 - TZ=UTC TB --- 2012-05-23 06:45:27 - __MAKE_CONF=/dev/null TB --- 2012-05-23 06:45:27 - cd /src TB --- 2012-05-23 06:45:27 - /usr/bin/make -B buildworld >>> World build started on Wed May 23 06:45:29 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/ppp/throughput.c:124: warning: format '%6qu' expects type 'long unsigned int', but argument 4 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:124: warning: format '%6qu' expects type 'long unsigned int', but argument 5 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:126: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c: In function 'throughput_clear': /src/usr.sbin/ppp/throughput.c:270: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:279: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:279: warning: format '%6qu' expects type 'long unsigned int', but argument 4 has type 'long long unsigned int' /src/usr.sbin/ppp/throughput.c:291: warning: format '%6qu' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/usr.sbin/ppp. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-23 07:53:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-23 07:53:40 - ERROR: failed to build world TB --- 2012-05-23 07:53:40 - 2351.45 user 554.29 system 4420.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
