Re: make KNOBS
Hello Jeremy, and thank you for your /very/ informative reply.
You rock! :)
Quoting Jeremy Chadwick [EMAIL PROTECTED]:
On Mon, Feb 25, 2008 at 11:35:23PM -0800, Chris H. wrote:
But am struggling with finding the port(s) equivalent. If there isn't
one, I'd be more that happy to dedicate a domain/ web site solely to
providing this resource. Perhaps a wiki that I, and anyone else can
add the WITH_/WITHOUT_ options, along with descriptions of exactly
/what/ they provide. Seems like a /real/ valuable, and /needed/
resource.
There is no equivalent. Some ports allow make showconfig to show you
what knobs there are, but the majority do not. And with the OPTIONS
framework, it deprecates the need for showconfig entirely.
Yes, I've noticed there are differences, and /assumed/ that this was
simply a migration period that would /eventually/ provide a more
consistent/robust tuning mechanism for the config/make process.
Just dreaming? :)
Additionally, the WITH/WITHOUT variables seen in the Makefile are not
always what they seem. For ports that use OPTIONS, you cannot define
these on the command-line (e.g. make WITHOUT_FRUIT=yes);
I believe that /should/ be:
WITHOUT_FRUIT=true - (true/false)
--
you absolutely
MUST do 'make config' and then toggle them there. (This is one piece of
the OPTIONS framework which I have always disliked, because some of us
use /etc/make.conf to define WITH/WITHOUT variables, and prefer to do
cd /usr/ports/whatever make clean make make install and not
have something interactive pop up.
May I insert a me too here?
That's for another discussion
though...)
I'll be contributing to /that/ discussion. :)
Also, there are some variables which are generally global across most
ports, such as WITHOUT_IPV6. You wouldn't want to list those off in
every single port, because that'd be somewhat redundant.
My approach (for the most part) seems to overcome this. An example
of my final choice(s) related to our earlier Apache2 discussion:
in make.conf
.if ${.CURDIR:M*/www/apache20}
WITH_MPM=worker
WITH_KQUEUE_SUPPORT=true
WITH_AUTH_MODULES=true
WITH_DAV_MODULES=true
WITH_MISC_MODULES=true
WITH_PROXY_MODULES=true
WITH_THREADS_MODULES=true
.endif
This allows for a per port WITH_/WITHOUT_, somewhat eliminating the
redundancy/ies, and let's me circumvent the global limitations.
There is no
existing list of these global-like variables either, although some are
listed in the /usr/ports/Mk/bsd.*.mk files.
Yes, I've looked to those, and /did/ find some helpful tuning KNOBS.
Providing a web site listing them all off would not make much sense,
because ports change very often/quickly (the site would become outdated
the minute someone changes a port to add/remove a feature), and there's
no guarantee that the maintainer of the port will go to your site and
edit the Wiki page.
Yea, I considered this. But even so, many don't change enough to invalidate
the information that might have already been provided. It also allows
for those whom have figured out many/some of the tuning variables, even
though they aren't the port Author. So I felt it would/could still be a
valuable resource.
Instead, I would think said effort would be better spent implementing
the showconfig feature apply to all ports, and have it understand
OPTIONS stuffs.
Agreed. I think that would be the /ultimate/ answer to this situation. :)
Once again, thank you for your informative reply.
--Chris H
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
--
panic: kernel trap (ignored)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
On Mon, Feb 25, 2008 at 11:35:23PM -0800, Chris H. wrote: But am struggling with finding the port(s) equivalent. If there isn't one, I'd be more that happy to dedicate a domain/ web site solely to providing this resource. Perhaps a wiki that I, and anyone else can add the WITH_/WITHOUT_ options, along with descriptions of exactly /what/ they provide. Seems like a /real/ valuable, and /needed/ resource. There is no equivalent. Some ports allow make showconfig to show you what knobs there are, but the majority do not. And with the OPTIONS framework, it deprecates the need for showconfig entirely. Additionally, the WITH/WITHOUT variables seen in the Makefile are not always what they seem. For ports that use OPTIONS, you cannot define these on the command-line (e.g. make WITHOUT_FRUIT=yes); you absolutely MUST do 'make config' and then toggle them there. (This is one piece of the OPTIONS framework which I have always disliked, because some of us use /etc/make.conf to define WITH/WITHOUT variables, and prefer to do cd /usr/ports/whatever make clean make make install and not have something interactive pop up. That's for another discussion though...) Also, there are some variables which are generally global across most ports, such as WITHOUT_IPV6. You wouldn't want to list those off in every single port, because that'd be somewhat redundant. There is no existing list of these global-like variables either, although some are listed in the /usr/ports/Mk/bsd.*.mk files. Providing a web site listing them all off would not make much sense, because ports change very often/quickly (the site would become outdated the minute someone changes a port to add/remove a feature), and there's no guarantee that the maintainer of the port will go to your site and edit the Wiki page. Instead, I would think said effort would be better spent implementing the showconfig feature apply to all ports, and have it understand OPTIONS stuffs. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re:more than 4gb of RAM (configurations)
On Wed, 2008-02-20 at 13:41 -0500, Zaphod Beeblebrox wrote: On Feb 19, 2008 5:10 PM, Kevin K [EMAIL PROTECTED] wrote: I have a box that we recently installed 16GB of RAM on. The box is i386 FreeBSD 6.2. It only recognizes 4gb. Siding with most of the group (go amd64), I'll add my own comment: Using PAE to access 4G of RAM (because 4G shows up as 2.5 to 3.5 gig, depending on the motherboard) under i386 is a reasonable solution, IMHO. Maybe even 6 gig or 8 gig... if you're trying to extend the life of an ia32 server. But with amd64 supporting ia32 binaries well, it seems the only reason left might be drivers --- except ... are there _any_ drivers that support PAE and _not_ amd64? We use this system while we slowly port our 32 bit code to 64 bit. There are some outstanding unresolved issues running 32 bit binaries on 64 bit (or at least, on 6.2-RELEASE-p8). http://www.mail-archive.com/freebsd-stable@freebsd.org/msg94092.html This should be fixed, although I've not tested whether 7.0 (and the change to gcc 4.2.1) might fix this anyway. Tom signature.asc Description: This is a digitally signed message part
Re: make KNOBS
Hello, and thank you for your reply. Quoting Yuri Pankov [EMAIL PROTECTED]: On 02/26/2008 10:35, Chris H. wrote: Hello, and thank you for your reply. Quoting Ruslan Ermilov [EMAIL PROTECTED]: On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote: Hello All, Maintaining a make.conf file can be a fairly daunting task within itself. But when upgrading, it becomes even more laborious. Peeking into the port Makefile to discover any /new/, or /changed/ knobs is standard fare. But it's not always obvious exactly /what/ the WITH_this, or WITHOUT_that actually provides. To the point: Is there, or does anyone maintain a KNOBS list possibly categorized by application/port/version, etc...? If not, are there any resources that might help me facilitate one online for myself and others to refer to? Thank you for all your time and consideration. For src/, there is an src.conf(5) manpage that documents supported WITH_*/WITHOUT_* knobs. For ports/, I'm not aware of such a list. Indeed. I was aware of, and make much use of it. But am struggling with finding the port(s) equivalent. If there isn't one, I'd be more that happy to dedicate a domain/ web site solely to providing this resource. Perhaps a wiki that I, and anyone else can add the WITH_/WITHOUT_ options, along with descriptions of exactly /what/ they provide. Seems like a /real/ valuable, and /needed/ resource. Thanks again for your response. --Chris H There's /usr/ports/KNOBS file, which lists some of most used KNOBS, but, sadly enough, every other port maintainer tries to invent his own knob names :-) Indeed - /sadly/, so it seems. :) --Chris H Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer Yuri -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote: Is there, or does anyone maintain a KNOBS list possibly categorized by application/port/version, etc...? ports/KNOBS? mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
On 02/26/2008 10:35, Chris H. wrote: Hello, and thank you for your reply. Quoting Ruslan Ermilov [EMAIL PROTECTED]: On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote: Hello All, Maintaining a make.conf file can be a fairly daunting task within itself. But when upgrading, it becomes even more laborious. Peeking into the port Makefile to discover any /new/, or /changed/ knobs is standard fare. But it's not always obvious exactly /what/ the WITH_this, or WITHOUT_that actually provides. To the point: Is there, or does anyone maintain a KNOBS list possibly categorized by application/port/version, etc...? If not, are there any resources that might help me facilitate one online for myself and others to refer to? Thank you for all your time and consideration. For src/, there is an src.conf(5) manpage that documents supported WITH_*/WITHOUT_* knobs. For ports/, I'm not aware of such a list. Indeed. I was aware of, and make much use of it. But am struggling with finding the port(s) equivalent. If there isn't one, I'd be more that happy to dedicate a domain/ web site solely to providing this resource. Perhaps a wiki that I, and anyone else can add the WITH_/WITHOUT_ options, along with descriptions of exactly /what/ they provide. Seems like a /real/ valuable, and /needed/ resource. Thanks again for your response. --Chris H There's /usr/ports/KNOBS file, which lists some of most used KNOBS, but, sadly enough, every other port maintainer tries to invent his own knob names :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
lists.freebsd.org is down?
Greetings, I cannot open port 80 on lists.freebsd.org. Is it just me? Sorry if this is not the proper maillist. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic in ufs_lookup (6.2-STABLE)
Hi all, freebsd box connected to Eonstor RAID with 5-6 exported partitions (each one has ~950Gb size, fs is UFS2) every night we have a lot of running rsyncs (rsnapshots) on these partitions this happens 2-4 times per month db bt Tracing pid 70595 tid 100178 td 0xc95fa600 kdb_enter(c0634690) at kdb_enter+0x2b panic(c0640603,da7e1200,e8c99a58,c05b591e,cb8cc18c,...) at panic+0x127 ufs_dirbad(cb8cc18c,200,c06405bd,c95fa600,0,...) at ufs_dirbad+0x3a ufs_lookup(e8c99a7c) at ufs_lookup+0x36a VOP_CACHEDLOOKUP_APV(c066ae00,e8c99a7c) at VOP_CACHEDLOOKUP_APV+0x38 vfs_cache_lookup(e8c99b18) at vfs_cache_lookup+0xb2 VOP_LOOKUP_APV(c066ae00,e8c99b18) at VOP_LOOKUP_APV+0x43 lookup(e8c99ba0) at lookup+0x4c1 namei(e8c99ba0) at namei+0x39a kern_lstat(c95fa600,bfbfd870,0,e8c99c74) at kern_lstat+0x47 lstat(c95fa600,e8c99d04) at lstat+0x1b syscall(809003b,bfbf003b,bfbf003b,8132a5f,bfbfd790,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (190, FreeBSD ELF32, lstat), eip = 0x35dd3427, esp = 0xbfbfcd7c, ebp = 0xbfbfce08 --- db show proc Process 70595 (rsync) at 0xc95f6648: state: NORMAL uid: 0 gids: 0, 0, 5 parent: pid 70594 at 0xc83a5648 ABI: FreeBSD ELF32 arguments: /usr/local/bin/rsync threads: 1 100178 Run CPU 2 rsync what is exactly wrong? -- WBR, Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
On Tue, Feb 26, 2008 at 03:05:09AM -0800, Chris H. wrote:
Additionally, the WITH/WITHOUT variables seen in the Makefile are not
always what they seem. For ports that use OPTIONS, you cannot define
these on the command-line (e.g. make WITHOUT_FRUIT=yes);
I believe that /should/ be:
WITHOUT_FRUIT=true - (true/false)
--
The value itself does not matter; it could be WITHOUT_FRUIT=false; it
makes no difference. The code simply detects whether or not the
variable is set at all. This is why you have WITH_xxx and WITHOUT_xxx,
rather than something like FEATURE_xxx=(yes|no|true|false).
The make.conf(5) manpage documents this fact. :-)
Also, there are some variables which are generally global across most
ports, such as WITHOUT_IPV6. You wouldn't want to list those off in
every single port, because that'd be somewhat redundant.
My approach (for the most part) seems to overcome this. An example
of my final choice(s) related to our earlier Apache2 discussion:
in make.conf
.if ${.CURDIR:M*/www/apache20}
WITH_MPM=worker
WITH_KQUEUE_SUPPORT=true
WITH_AUTH_MODULES=true
WITH_DAV_MODULES=true
WITH_MISC_MODULES=true
WITH_PROXY_MODULES=true
WITH_THREADS_MODULES=true
.endif
This allows for a per port WITH_/WITHOUT_, somewhat eliminating the
redundancy/ies, and let's me circumvent the global limitations.
I don't think I did a good job explaining what I was talking about. I'm
talking about variables like WITHOUT_IPV6, WITHOUT_X11, and some others.
There is a common standard for those variable names, meaning they are
used consistently throughout the ports tree, because the authors of said
ports wondered at one point Do other people use a variable elsewhere
which already does this? What's its name, so I can keep it consistent.
On our systems, we use stuff like this:
# For ports
WITHOUT_X11=yes
WITH_APACHE2=yes
WITHOUT_IPV6=yes
.if ${.CURDIR:M*/databases/phpmyadmin}
WITH_SUPHP=yes
WITHOUT_PDF=yes
WITHOUT_MCRYPT=yes
WITHOUT_BZ2=yes
WITHOUT_OPENSSL=yes
.endif
If the phpmyadmin port made use of WITHOUT_IPV6, it would *not* include
IPv6 stuff. That's what I mean by global -- it applies to all ports.
Note that the phpmyadmin entry in our make.conf has no *functional*
purpose, because phpmyadmin uses the OPTIONS framework. It's used
solely as a reminder whenever I do make rmconfig and need to re-pick
what options to use.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 6.3-RELEASE panic
Hi all,
I've encountered the panic on 6.3-RELEASE once again - this time with
prepared debug kernel, so here you go. It seems like the panic is usually
initiated when firefox exits. Let me know if any further information is
Petr
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x9ef418
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc07f2348
stack pointer = 0x28:0xea61cb08
frame pointer = 0x28:0xea61cb14
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1808 (firefox-bin)
trap number = 12
panic: page fault
Uptime: 4d23h12m54s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 863
847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575
(CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 559 543 527 511 495
479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191
175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06a4ad6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc06a4d6c in panic (fmt=0xc096ba63 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc090d0d4 in trap_fatal (frame=0xea61cac8, eva=10417176)
at /usr/src/sys/i386/i386/trap.c:838
#4 0xc090ce3b in trap_pfault (frame=0xea61cac8, usermode=0, eva=10417176)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc090ca79 in trap (frame=
{tf_fs = -1066532856, tf_es = -648871896, tf_ds = -949551064, tf_edi =
2590720, tf_esi = 0, tf_ebp = -362689772, tf_isp = -362689804, tf_ebx = 0,
tf_edx = 2590720, tf_ecx = 10417152, tf_eax = -981897076, tf_trapno = 12,
tf_err = 0, tf_eip = -1065409720, tf_cs = 32, tf_eflags = 2163206, tf_esp =
-981897076, tf_ss = 132}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc08f9f0a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc07f2348 in pagedep_find (pagedephd=0xc579708c, ino=2590720, lbn=)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:1165
#8 0xc07f23ea in pagedep_lookup (ip=0xc771f7bc, lbn=0, flags=1,
pagedeppp=0xea61cb64) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1204
#9 0xc07f620b in newdirrem (bp=0xd953e678, dp=0xc771f7bc, ip=0xc6736084,
isrmdir=0, prevdirremp=0xea61cb90)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3301
#10 0xc07f5fc0 in softdep_setup_remove (bp=0xd953e678, dp=0xc771f7bc,
ip=0xc6736084, isrmdir=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3230
#11 0xc0806bb6 in ufs_dirremove (dvp=0xc719b440, ip=0xc6736084,
flags=83918860, isrmdir=0) at /usr/src/sys/ufs/ufs/ufs_lookup.c:1020
#12 0xc0809b93 in ufs_remove (ap=0x278800)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:798
#13 0xc091e8b0 in VOP_REMOVE_APV (vop=0xc579708c, a=0xea61cc3c)
at vnode_if.c:1077
#14 0xc070401f in kern_unlink (td=0xc7678480,
path=0xbc29288 Address 0xbc29288 out of bounds, pathseg=UIO_USERSPACE)
at vnode_if.h:563
#15 0xc0703e8e in unlink (td=0xc7678480, uap=0xc579708c)
at /usr/src/sys/kern/vfs_syscalls.c:1642
#16 0xc090d3eb in syscall (frame=
{tf_fs = 134611003, tf_es = 134742075, tf_ds = -1078001605, tf_edi =
197300736, tf_esi = 17, tf_ebp = -1077950232, tf_isp = -362689180, tf_ebx =
673223176, tf_edx = 197300736, tf_ecx = 197300736, tf_eax = 10, tf_trapno =
0, tf_err = 2, tf_eip = 684230759, tf_cs = 51, tf_eflags = 2097810, tf_esp =
-1077950388, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984
#17 0xc08f9f5f in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:200
#18 0x0033 in ?? ()
(kgdb) bt full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc06a4ad6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0xc06a4d6c in panic (fmt=0xc096ba63 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
td = (struct thread *) 0xc7678480
bootopt = 260
newpanic = 0
ap = 0xc7678480 0t%ČŕzĺĹ\200'[EMAIL PROTECTED]'`ÇězĺĹ
buf = page fault, '\0' repeats 245 times
#3 0xc090d0d4 in trap_fatal (frame=0xea61cac8, eva=10417176)
at /usr/src/sys/i386/i386/trap.c:838
code = 40
ss = 40
esp = 0
type = 12
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27,
ssd_dpl = 0, ssd_p = 1, ssd_xx = 4, ssd_xx1 = 3, ssd_def32 = 1,
ssd_gran = 1}
msg = 0x0
#4 0xc090ce3b in
Re: make KNOBS
Quoting Mark Linimon [EMAIL PROTECTED]: On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote: Is there, or does anyone maintain a KNOBS list possibly categorized by application/port/version, etc...? ports/KNOBS? Yes. I have been aware of that file since it has been available in the ports dir. But I can't help but notice the omission of, for example: the mention of: APACHE2Use www/apache2 port doesn't mention a pointer to MK/bsd.apache.mk which holds many of the tunables available for the Apache1.3 || 2.0 || 2.2 ports. Perhaps my post wasn't as concise as it might have been. But my goal was to find an efficient, consistent, and not /too/ laborious method of discovering all the options for a given port, and when in doubt; /what/ the particular option provides - eg; WITH_this, or WITHOUT_that. Thank you for taking the time to reply. --Chris H mcl -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
Quoting Jeremy Chadwick [EMAIL PROTECTED]:
On Tue, Feb 26, 2008 at 03:05:09AM -0800, Chris H. wrote:
Additionally, the WITH/WITHOUT variables seen in the Makefile are not
always what they seem. For ports that use OPTIONS, you cannot define
these on the command-line (e.g. make WITHOUT_FRUIT=yes);
I believe that /should/ be:
WITHOUT_FRUIT=true - (true/false)
--
The value itself does not matter; it could be WITHOUT_FRUIT=false; it
makes no difference. The code simply detects whether or not the
variable is set at all. This is why you have WITH_xxx and WITHOUT_xxx,
rather than something like FEATURE_xxx=(yes|no|true|false).
The make.conf(5) manpage documents this fact. :-)
Indeed. In fact I read that the /preferred/ method was: true || false
Which was why I mentioned it - which is /not/ to say you were wrong.
I was just being anal, and forgot the ;) on the end. After all:
true == yes, no? ;)
Also, there are some variables which are generally global across most
ports, such as WITHOUT_IPV6. You wouldn't want to list those off in
every single port, because that'd be somewhat redundant.
My approach (for the most part) seems to overcome this. An example
of my final choice(s) related to our earlier Apache2 discussion:
in make.conf
.if ${.CURDIR:M*/www/apache20}
WITH_MPM=worker
WITH_KQUEUE_SUPPORT=true
WITH_AUTH_MODULES=true
WITH_DAV_MODULES=true
WITH_MISC_MODULES=true
WITH_PROXY_MODULES=true
WITH_THREADS_MODULES=true
.endif
This allows for a per port WITH_/WITHOUT_, somewhat eliminating the
redundancy/ies, and let's me circumvent the global limitations.
I don't think I did a good job explaining what I was talking about. I'm
talking about variables like WITHOUT_IPV6, WITHOUT_X11, and some others.
There is a common standard for those variable names, meaning they are
used consistently throughout the ports tree, because the authors of said
ports wondered at one point Do other people use a variable elsewhere
which already does this? What's its name, so I can keep it consistent.
On our systems, we use stuff like this:
# For ports
WITHOUT_X11=yes
WITH_APACHE2=yes
WITHOUT_IPV6=yes
.if ${.CURDIR:M*/databases/phpmyadmin}
WITH_SUPHP=yes
WITHOUT_PDF=yes
WITHOUT_MCRYPT=yes
WITHOUT_BZ2=yes
WITHOUT_OPENSSL=yes
.endif
If the phpmyadmin port made use of WITHOUT_IPV6, it would *not* include
IPv6 stuff. That's what I mean by global -- it applies to all ports.
Note that the phpmyadmin entry in our make.conf has no *functional*
purpose, because phpmyadmin uses the OPTIONS framework. It's used
solely as a reminder whenever I do make rmconfig and need to re-pick
what options to use.
I think we are /ultimately/ saying the same thing, but in /slightly/
different context. In any case; understood. :)
Thanks again.
--Chris H
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
--
panic: kernel trap (ignored)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lists.freebsd.org is down?
On Tue, Feb 26, 2008 at 12:02:38PM +0200, Stefan Lambrev wrote: I cannot open port 80 on lists.freebsd.org. Is it just me? Looks OK to me: $ telnet lists.freebsd.org 80 Trying 69.147.83.38... Connected to lists.freebsd.org. Escape character is '^]'. ^] telnet close Connection closed. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
On Tue, Feb 26, 2008 at 03:49:48AM -0800, Chris H. wrote: Quoting Mark Linimon [EMAIL PROTECTED]: On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote: Is there, or does anyone maintain a KNOBS list possibly categorized by application/port/version, etc...? ports/KNOBS? Yes. I have been aware of that file since it has been available in the ports dir. But I can't help but notice the omission of, for example: the mention of: APACHE2Use www/apache2 port doesn't mention a pointer to MK/bsd.apache.mk which holds many of the tunables available for the Apache1.3 || 2.0 || 2.2 ports. Perhaps my post wasn't as concise as it might have been. But my goal was to find an efficient, consistent, and not /too/ laborious method of discovering all the options for a given port, and when in doubt; /what/ the particular option provides - eg; WITH_this, or WITHOUT_that. No such method exists. Many of the options available in ports are not documented at all. Those that are documented often have only a brief one-line description. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
Note that the phpmyadmin entry in our make.conf has no *functional* purpose, because phpmyadmin uses the OPTIONS framework. It's used solely as a reminder whenever I do make rmconfig and need to re-pick what options to use. Is the idea to move all the ports over to the OPTIONS stuff ? That's going to be a real pain for those of us maintaining a lot of machines. I like to keep everything in make.conf too - I found that for Apache it is possible to do 'WITHOUT_APACHE_OPTIONS=yes' and then it uses the make.conf knbos crrectly - will other ports end up working like this as well ? cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
On Tue, Feb 26, 2008 at 2:03 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
Additionally, the WITH/WITHOUT variables seen in the Makefile are not
always what they seem. For ports that use OPTIONS, you cannot define
these on the command-line (e.g. make WITHOUT_FRUIT=yes); you absolutely
MUST do 'make config' and then toggle them there. (This is one piece of
the OPTIONS framework which I have always disliked, because some of us
use /etc/make.conf to define WITH/WITHOUT variables, and prefer to do
cd /usr/ports/whatever make clean make make install and not
have something interactive pop up. That's for another discussion
though...)
You should be able to do:
cd /usr/ports/whatever make clean make -DBATCH make -DBATCH install
Check the port to see if it disables parts of its build/install
process when BATCH is defined.
Another way would be to define _OPTIONS_OK=yes in /etc/make.conf, but
this is an internal variable to bsd.ports.mk.
Also defining WITH/WITHOUT variables in /etc/make.conf and/or
${PREFIX}/etc/ports.conf (sysutils/portconf) should work with ports
that use the OPTIONS framework.
Scot
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
On Tue, Feb 26, 2008 at 06:33:37AM -0600, Scot Hetzel wrote:
On Tue, Feb 26, 2008 at 2:03 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
Additionally, the WITH/WITHOUT variables seen in the Makefile are not
always what they seem. For ports that use OPTIONS, you cannot define
these on the command-line (e.g. make WITHOUT_FRUIT=yes); you absolutely
MUST do 'make config' and then toggle them there. (This is one piece of
the OPTIONS framework which I have always disliked, because some of us
use /etc/make.conf to define WITH/WITHOUT variables, and prefer to do
cd /usr/ports/whatever make clean make make install and not
have something interactive pop up. That's for another discussion
though...)
You should be able to do:
cd /usr/ports/whatever make clean make -DBATCH make -DBATCH install
Check the port to see if it disables parts of its build/install
process when BATCH is defined.
I thought using BATCH had some substantial risks associated with it? I
wish I could remember where I read or heard that...
Another way would be to define _OPTIONS_OK=yes in /etc/make.conf, but
this is an internal variable to bsd.ports.mk.
What are the risks involved with using this?
Also defining WITH/WITHOUT variables in /etc/make.conf and/or
${PREFIX}/etc/ports.conf (sysutils/portconf) should work with ports
that use the OPTIONS framework.
In the case of the lesser, it doesn't. In the case of the latter, I
don't use portconf, so I don't have an answer to that one.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_7 tinderbox] failure on powerpc/powerpc
TB --- 2008-02-26 12:52:24 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-26 12:52:24 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2008-02-26 12:52:24 - cleaning the object tree TB --- 2008-02-26 12:52:37 - cvsupping the source tree TB --- 2008-02-26 12:52:37 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2008-02-26 12:52:45 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-26 12:52:45 - cd /src TB --- 2008-02-26 12:52:45 - /usr/bin/make -B buildworld World build started on Tue Feb 26 12:52:47 UTC 2008 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 World build completed on Tue Feb 26 13:58:18 UTC 2008 TB --- 2008-02-26 13:58:18 - generating LINT kernel config TB --- 2008-02-26 13:58:18 - cd /src/sys/powerpc/conf TB --- 2008-02-26 13:58:18 - /usr/bin/make -B LINT TB --- 2008-02-26 13:58:18 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-26 13:58:18 - cd /src TB --- 2008-02-26 13:58:18 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Feb 26 13:58:18 UTC 2008 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/sctp_cc_functions.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/sctp_crc32.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/sctp_indata.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/sctp_input.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/sctp_output.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/sctp_pcb.c /src/sys/netinet/sctp_pcb.c: In function 'sctp_free_vrf':
Re: ntpd fails to synchronize on FreeBSD 6.3-STABLE
Thanks Proto and Chadwick
I can't help you with the IPv6 stuff; I don't use IPv6.
Actually I don't force ntpd to use IPv6. Hostnames could be resolved to any
IPv4 addresses. I have no problem with that.
The only thing I want is ``synchronization''.
Please do not define driftfile in /etc/ntp.conf. The /etc/rc.d/ntpd
framework will take care of that for you by using -f /var/db/ntpd.drift.
I have tried it, still not work.
If I were you, I'd try sniffing traffic on your LAN segment to see if
you're even getting responses from the remote NTP servers. Using
tcpdump, you should be able to achieve this by doing:
# tcpdump -l -n -s 8192 -p port 123
I'm willing to bet you're not even getting responses from the remote
servers, which would imply firewall rules on your gateway, or the
machine itself.
# tcpdump -l -n -s 8192 -p port 123
tcpdump: listening on fxp0, link-type EN10MB (Ethernet), capture size 8182 bytes
0 packets captured
12 packets received by filter
0 packets dropped by kernel
^C
(after awaiting around 20secs then hits interrupt)
You are right, I didn't get any responses.
I have doubly checked. Firewall on my router/gateway is disabled, not active.
I have also tried disabling firewall on my machine.
It still doesn't work.
Actually I am not suspecting my /etc/ipfw.rules, which has been being used
for long since FreeBSD 5.4. ntpd has never encountered any problems for such
ipfw configuration with dial-up (both 5.4-RELEASE and 6.2-RELEASE).
(I also didn't forget to change interface name from dial-up to ethernet.)
# find /usr/share/man/cat* -type f -exec rm -f {} \;
or
# find /usr/share/man/cat* -type f -delete
I have tested it, I still get outdated man pages.
I even dive into /usr/src/share/man.
Man pages over there are all FreeBSD 6.2.
But some timestamps dated Feb 13, 2008; but footer is still FreeBSD 6.2
And then enable weekly creation of the catman pages via the weekly
periodic script, by placing this in /etc/periodic.conf:
weekly_catman_enable=yes
You can also create those catman pages right now by setting the above
variable in periodic.conf and doing the following:
/etc/periodic/weekly/330.catman
Keep something in mind, however: by enabling this, you're also prone to
get a lot of nasty messages from groff/troff/nroff every week. A lot of
manpages are not 100% syntactically correct or compatible with the
version of troff FreeBSD uses, so they emit warnings.
I want them to be compatible with the current version of FreeBSD.
So I will not use it, thanks.
Finally, when you upgraded from 6.2 to 6.3, did you follow all of the
instructions in /usr/src/Makefile perfectly? See the 10-11 steps
listed under For individuals wanting to upgrade their sources
I'm left wondering if you didn't do the mergemaster step.
No, but I perfectly followed instruction in handbook.
# cvsup -g -L 2 /usr/share/examples/cvsup/stable-supfile
backup data and /etc
read /usr/src/UPDATING
# mergemaster -p
# shutdown now (drop to single user)
# fsck -p
# mount -u /
# mount -a -t ufs
# swapon -a
# adjkerntz -i
# cd /usr/obj
# chflags -R noschg *
# rm -rf *
# cd /usr/src
# make [-j4] buildworld
# make buildkernel KERNCONF=SMP
# make installkernel KERNCONF=SMP
# shutdown -r now (reboot the new kernel in single user mode)
# make installworld
# mergemaster
# shutdown -r now (reboot the new system)
# uname -a (show the new kernel)
And I also look in some forums.
I think that the procedure above is correct.
I also got many new man pages in /usr/src/share/man,
but as said all are 6.2 (with some new timestamps).
If so, archives in cvs repository (cvsup.th.freebsd.org) are probably outdated.
If I did anything wrong, please tell me.
Please note that I have been using FreeBSD since 5.0. But I ALWAYS install
new system from iso image. This is my first time updating from source.
And what about updating handbook?
# cvsup -g -L 2 /usr/share/examples/cvsup/doc-supfile
# cd /usr/doc (many dirs/files in here, like sgml files)
# make all install (or) make install
It just doesn't work.
I don't want to waste your time; it is also irrelevant to freebsd-stable.
Please just give me a brief hint.
Thanks,
Pongthep
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0 RC3 and usb problems
--On Tuesday, February 26, 2008 16:58:45 +1030 Daniel O'Connor [EMAIL PROTECTED] wrote: On Tue, 26 Feb 2008, Jeremy Chadwick wrote: Doesn't make much sense to me. I'm not very familiar with how the usb system works, so I'm not sure where to look to find the problem. There's no /dev/umass either. For umass devices to work, you need to have uhci (or ohci if your system uses that USB bus type), ehci (for USB2.0), usb (obvious), and umass. The kicker is that you also need scbus, da, and possibly pass. They must be in the kernel otherwise it wouldn't have linked. Does the device appear in usbdevs -v when it's connected? Does anything show up in dmesg? # uname -a FreeBSD utd65257.utdallas.edu 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Tue Feb 26 09:07:31 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 I recompiled the kernel this morning, and the symptoms have changed. (I noticed some recent commits to cvs.) Now, if I have my Maxtor hard drive attached to the system during boot, the system hangs and I get umass errors. umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, TIMEOUT umass0: BBB bulk-out clear stall failed, TIMEOUT These continue until the system reboots. If I disconnect (physically) the drive, the system boots normally and *then* I can attach the drive and mount it. # usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x), rev 1.00 port 1 addr 5: high speed, self powered, config 1, Maxtor 3200(0x3200), Maxtor Corporation(0x0d49), rev 0.01 port 2 addr 2: high speed, self powered, config 1, product 0x2504(0x2504), vendor 0x0424(0x0424), rev 0.01 port 1 addr 3: low speed, power 100 mA, config 1, USB Optical Mouse(0x4d15), vendor 0x0461(0x0461), rev 2.00 port 2 addr 4: low speed, power 100 mA, config 1, Microsoft Natural Keyboard Elite(0x000b), vendor 0x045e(0x045e), rev 2.07 port 3 powered port 4 powered port 3 powered port 4 powered port 5 powered port 6 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb4: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb5: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb6: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPv6 in Jail
Christian [EMAIL PROTECTED] wrote: can anyone say me what the current status of running IPv6 in Jail is? Please see this thread: http://lists.freebsd.org/pipermail/freebsd-current/2008-February/083830.html Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered. -- Guido van Rossum ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd fails to synchronize on FreeBSD 6.3-STABLE
On Tue, Feb 26, 2008 at 10:09:10PM +0700, Pongthep Kulkrisada wrote:
Please do not define driftfile in /etc/ntp.conf. The /etc/rc.d/ntpd
framework will take care of that for you by using -f /var/db/ntpd.drift.
I have tried it, still not work.
I was pointing this out not as this will fix your problem, but this
will cause you problems when it comes to driftfile usage. So, keep it
the way I said, otherwise you'll need to override some ntp_* settings in
rc.conf.
If I were you, I'd try sniffing traffic on your LAN segment to see if
you're even getting responses from the remote NTP servers. Using
tcpdump, you should be able to achieve this by doing:
# tcpdump -l -n -s 8192 -p port 123
I'm willing to bet you're not even getting responses from the remote
servers, which would imply firewall rules on your gateway, or the
machine itself.
# tcpdump -l -n -s 8192 -p port 123
tcpdump: listening on fxp0, link-type EN10MB (Ethernet), capture size 8182
bytes
0 packets captured
12 packets received by filter
0 packets dropped by kernel
^C
(after awaiting around 20secs then hits interrupt)
This isn't enough time. Please try this instead.
# /etc/rc.d/ntpd stop
# /etc/rc.d/ntpdate start
This should set your clock, even if only by a few milliseconds.
Assuming the ntpdate part is successful, continue on:
# tcpdump -l -n -s 8192 -p port 123
Now, in another window, execute:
# /etc/rc.d/ntpd start
Then let the tcpdump go for about 15 minutes. You aren't using the
iburst feature on any of the servers, so it will take some time before
they try to sync up.
You are right, I didn't get any responses.
I have doubly checked. Firewall on my router/gateway is disabled, not active.
I have also tried disabling firewall on my machine.
It still doesn't work.
Actually I am not suspecting my /etc/ipfw.rules, which has been being used
for long since FreeBSD 5.4. ntpd has never encountered any problems for such
ipfw configuration with dial-up (both 5.4-RELEASE and 6.2-RELEASE).
(I also didn't forget to change interface name from dial-up to ethernet.)
tcpdump has priority over any firewalling layer, so even if you had ipfw
or ipfilter or pf rules blocking NTP traffic, tcpdump would still show
the packets coming in across the wire. You're simply not seeing
traffic, probably because you didn't wait long enough. ntpd *does not*
sync every 20 seconds, or even every 60. Like I said: try 15 minutes.
# find /usr/share/man/cat* -type f -exec rm -f {} \;
or
# find /usr/share/man/cat* -type f -delete
I have tested it, I still get outdated man pages.
I even dive into /usr/src/share/man.
Man pages over there are all FreeBSD 6.2.
But some timestamps dated Feb 13, 2008; but footer is still FreeBSD 6.2
I can confirm this on my RELENG_6 box (using 6.3). I wouldn't worry
about the footer saying 6.2.
Finally, when you upgraded from 6.2 to 6.3, did you follow all of the
instructions in /usr/src/Makefile perfectly? See the 10-11 steps
listed under For individuals wanting to upgrade their sources
I'm left wondering if you didn't do the mergemaster step.
No, but I perfectly followed instruction in handbook.
# cvsup -g -L 2 /usr/share/examples/cvsup/stable-supfile
backup data and /etc
read /usr/src/UPDATING
# mergemaster -p
# shutdown now (drop to single user)
# fsck -p
# mount -u /
# mount -a -t ufs
# swapon -a
# adjkerntz -i
# cd /usr/obj
# chflags -R noschg *
# rm -rf *
# cd /usr/src
# make [-j4] buildworld
# make buildkernel KERNCONF=SMP
# make installkernel KERNCONF=SMP
# shutdown -r now (reboot the new kernel in single user mode)
# make installworld
# mergemaster
# shutdown -r now (reboot the new system)
# uname -a (show the new kernel)
And I also look in some forums.
I think that the procedure above is correct.
The procedure is documented in /usr/src/Makefile, and you should really
follow that. I haven't read the Handbook's documentation on what to do,
but the above seems awfully extensive for something that is described in
the Makefile (which I have used since the days of 4.x without issue).
I can't help you with anything relating to updating doc-all or your
/usr/doc tree. I'm not familiar with that, sorry.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in ufs_lookup (6.2-STABLE)
Andrew N. Below wrote: Hi all, freebsd box connected to Eonstor RAID with 5-6 exported partitions (each one has ~950Gb size, fs is UFS2) every night we have a lot of running rsyncs (rsnapshots) on these partitions this happens 2-4 times per month db bt Tracing pid 70595 tid 100178 td 0xc95fa600 kdb_enter(c0634690) at kdb_enter+0x2b panic(c0640603,da7e1200,e8c99a58,c05b591e,cb8cc18c,...) at panic+0x127 ufs_dirbad(cb8cc18c,200,c06405bd,c95fa600,0,...) at ufs_dirbad+0x3a ... what is exactly wrong? There were some bugs in the past: http://www.google.com/search?hl=enrlz=q=freebsd+ufs_dirbad but they should have been fixed by now. What version of FreeBSD do you use? signature.asc Description: OpenPGP digital signature
Re: lists.freebsd.org is down?
Stefan Lambrev wrote: Greetings, I cannot open port 80 on lists.freebsd.org. Is it just me? Sorry if this is not the proper maillist. The hardware was being migrated. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lists.freebsd.org is down?
On Tue, Feb 26, 2008 at 11:27 AM, Kris Kennaway [EMAIL PROTECTED] wrote: Stefan Lambrev wrote: Greetings, I cannot open port 80 on lists.freebsd.org. Is it just me? Sorry if this is not the proper maillist. The hardware was being migrated. Kris Yes, mail processing is running on a new box. It took longer than I expected, due to a couple of colossal mistakes. The fact that you're reading this email means that it is working again. For example, after 19 years of doing unix stuff, I finally fell for the 'rm -rf *' in / classic newbie blunder. On the plus side, it was my netboot environment for doing machine migration/installations. On the minus side, I took out 12 other machines at once. Oops. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in ufs_lookup (6.2-STABLE)
On Tue, 26 Feb 2008, Ivan Voras wrote: Andrew N. Below wrote: Hi all, freebsd box connected to Eonstor RAID with 5-6 exported partitions (each one has ~950Gb size, fs is UFS2) every night we have a lot of running rsyncs (rsnapshots) on these partitions this happens 2-4 times per month db bt Tracing pid 70595 tid 100178 td 0xc95fa600 kdb_enter(c0634690) at kdb_enter+0x2b panic(c0640603,da7e1200,e8c99a58,c05b591e,cb8cc18c,...) at panic+0x127 ufs_dirbad(cb8cc18c,200,c06405bd,c95fa600,0,...) at ufs_dirbad+0x3a ... what is exactly wrong? There were some bugs in the past: http://www.google.com/search?hl=enrlz=q=freebsd+ufs_dirbad but they should have been fixed by now. What version of FreeBSD do you use? RELENG_6 cvsuped at 2007-01-15 what should I check (source revisions) to ensure we have same bug? -- WBR, Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fsck_ufs: cannot alloc 94208 bytes for inoinfo
Hello, fsck_ufs: cannot alloc 94208 bytes for inoinfo This is what I get after about one hour while trying a fsck on a large (1.4TB) partition broken since a power outage. HW: HP DL380G5, under freebsd 6.1/i386, with 1GB of RAM and: da0: COMPAQ RAID 5 VOLUME OK Fixed Direct Access SCSI-4 device da0: 135.168MB/s transfers da0: 1430488MB (2929640988 512 byte sectors: 255H 63S/T 65535C) Mounting with option -f (force) seems to work, so I guess there is still hope :) Now I added this to the /boot/loader.conf: kern.maxdsiz=1073741824 # 1GB kern.dfldsiz=1073741824 # 1GB and I'm trying the fsck again, but I'm not sure it will help. Would you maybe have other suggestions? Regards, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck_ufs: cannot alloc 94208 bytes for inoinfo
* Olivier Mueller [EMAIL PROTECTED] [080226 14:32] wrote: Hello, fsck_ufs: cannot alloc 94208 bytes for inoinfo This is what I get after about one hour while trying a fsck on a large (1.4TB) partition broken since a power outage. HW: HP DL380G5, under freebsd 6.1/i386, with 1GB of RAM and: da0: COMPAQ RAID 5 VOLUME OK Fixed Direct Access SCSI-4 device da0: 135.168MB/s transfers da0: 1430488MB (2929640988 512 byte sectors: 255H 63S/T 65535C) Mounting with option -f (force) seems to work, so I guess there is still hope :) Now I added this to the /boot/loader.conf: kern.maxdsiz=1073741824 # 1GB kern.dfldsiz=1073741824 # 1GB and I'm trying the fsck again, but I'm not sure it will help. Would you maybe have other suggestions? See limit/ulimit to make sure you're giving the fsck process unlimited data size. you can also likely safely increase the maxdsiz to 1.5GB and still be ok, just make sure to turn on swapping. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
pthread_cond_wait hanging in libthr
I have been debugging a problem with ushare in FreeBSD 7.0,
specifically I have tracked it down to the pthread_cond_wait call
inside the libupnp library that ushare uses. UpnpInit ultimately calls
the below ithread_cond_wait, which is where I am seeing the hang.
The code in question is on line 650 of:
/usr/ports/devel/upnp/work/libupnp-1.6.0/threadutil/src/ThreadPool.c
648 while( tp-totalThreads currentThreads ) {
649
650 ithread_cond_wait( tp-start_and_shutdown, tp-mutex );
651
652 }
The call to ithread_cond_wait (#defined to pthread_cond_wait) hangs
indefinitely, causing ushare to never listen on the UPnP port. It only
does this when ushare is run with the -D option, indicating it should
daemonize. If I run it without -D, it works fine.
Here is the tail end of a truss of ushare when run with -D, at which
point it hangs and subsequently does not listen on the UPnP socket.
22539: mprotect(0x7f9fe000,4096,PROT_NONE) = 0 (0x0)
22539:
thr_new(0x7fffe590,0x68,0x7fffe620,0x0,0xb05a9d40,0x7fffe538)
= 0 (0x0)
22539: _umtx_op(0x40e1c160,0x6,0x0,0x0,0x0,0x7fffe578) ERR#1
'Operation not permitted'
22539: _umtx_op(0x40e1e160,0x8,0x1,0x40e1e140,0x0,0x7fffe598)#
and here's the tail end of the ktrace for the same:
ushare CALL
mmap(0x7f9fe000,0x201000,PROT_READ|PROT_WRITE,MAP_STACK,0x,0)
ushare RET mmap -6299648/0x7f9fe000
ushare CALL mprotect(0x7f9fe000,0x1000,PROT_NONE)
ushare RET mprotect 0
ushare CALL thr_new(0x7fffe9c0,0x68)
ushare RET thr_new 0
ushare RET fork 0
ushare CALL _umtx_op(0x40e1e160,0x8,0x1,0x40e1e140,0)
ushare RET _umtx_op -1 errno 1 Operation not permitted
ushare CALL _umtx_op(0x40e1e140,0x5,0,0,0)
ushare CALL _umtx_op(0x40e1c160,0x5,0,0,0)
ushare RET _umtx_op RESTART
ushare PSIG SIGTERM SIG_DFL
I pointed ushare and libupnp.so to libkse instead with libmap.conf,
and it works properly with libkse. It only exhibits this behavior with
libthr.
For now, I am using libmap.conf as a workaround, but there seems to be
a problem with libthr in this particular usage.
Please let me know if any other information is required. This is
7.0-RELEASE on amd64.
Thanks!
Josh
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
