loader code to zpool.cache loading
Dear collegaues, one of my friends tonight called me to help him with recovering his remote(both to me and him, heh) server with 8.0 or something with ZFS-on root (yes, I'd said he was brave enough) having troubles with loading modules by loader. During investigation it has been clear we need to load /boot/kernel.old/kernel with corresponding modules (including ZFS), but we failed to achieve this, namely: zpool.cache is not loading again, leading to "can't mount root" error. I checked the sources quickly and now I'm a bit puzzled: I see zpool_cache_load="YES" zpool_cache_type="/boot/zfs/zpool.cache" zpool_cache_name="/boot/zfs/zpool.cache" in loader.conf (actually, default one) but can't find references to it anywhere in /sys/boot -- what did I missed? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Fatal trap 12 going from 8.2 to 8.4 with ZFS
On Sat, 31 Aug 2013, Dmitry Morozovsky wrote: > > > I don't have an exact recollection of what is installed by freebsd-update > > > - are > > > *.symbols files installed? > > > > Doesn't look like it. I wonder if I can grab that from a distro site > > or somewhere? > > it seems so: > > marck@woozle:/pub/FreeBSD/releases/amd64/8.4-RELEASE/kernels> grep -c symbol > generic.mtree > 636 > > So, get kernels subdir from the release and extract symbols from them: > > cat generic.?? | tar tvjf - \*.symbols ah, ``tar xvjf'' of course -- I did test-run -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Fatal trap 12 going from 8.2 to 8.4 with ZFS
On Fri, 30 Aug 2013, Patrick wrote: > On Fri, Aug 30, 2013 at 1:30 AM, Andriy Gapon wrote: > > > > I don't have an exact recollection of what is installed by freebsd-update - > > are > > *.symbols files installed? > > Doesn't look like it. I wonder if I can grab that from a distro site > or somewhere? it seems so: marck@woozle:/pub/FreeBSD/releases/amd64/8.4-RELEASE/kernels> grep -c symbol generic.mtree 636 So, get kernels subdir from the release and extract symbols from them: cat generic.?? | tar tvjf - \*.symbols -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: tmpfs experimental?
On Tue, 16 Jun 2009, Wojciech Puchar wrote: WP> > > In other words, is there still reason for the "highly experimental WP> > > feature" warning? WP> > WP> > Last time when I added the warning, it was because some data corruption WP> > issue that can be identified by fsx which I didn't got a chance to WP> > investigate further. I think tmpfs is Ok for some usual work but maybe WP> > not ready for production at that moment. alc@ and kib@ has made a lot WP> > of changes on it recently so perhaps we need to re-visit the problems, WP> > tmpfs would be a great feature for us. WP> WP> as an ordinary user not programmer of tmpfs i can say that: WP> WP> 1) runs fine for months in production environments, including case with over WP> 40 mountpoints (jails) WP> 2) runs really fast when memory is available. WP> 3) performance is bad in case that swapping actually is used. It reads from WP> swap with too small chunks. it's a place for improvement here. WP> WP> Its great thing as it does it properly - memory is immediately freed on WP> delete, and no caching of memory disk like with md(4). Actually, buffer cache is used, so excessive memory usage are still in place; also, on rather heavy tmpfs usage (building large ports, for example) I still can panic and/or hang the machione with exhausted maxswzone, so there definitely is a place to improve things ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysinstall, GJOURNAL and ZFS
On Wed, 10 Jun 2009, Dag-Erling Sm?rgrav wrote: DS> sth...@nethelp.no writes: DS> > I've had several cases that needed manual fsck. After I turned off DS> > background fsck, the problems stopped. These days background_fsck="NO" DS> > is a standard part of my rc.conf. DS> DS> Hear, hear. Well, I can see at least one rather big problem with bgfsck (or with snapshots to be more precise): inappropriate time of file system lock on snapshot creation. On not-too-big 300G ufs2 not-too-heavy loaded snapshot creation time is 20+ minutes, and 5+ from that file system blocked even on reads. This looks unacceptable for me for any real use. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
MosChip 7840 dual port ucom
Dear colleagues, any hints/directions to get MosChip 7840 dual port USB to RS232 adapter working? In usbdevs output the device is shown as port 1 addr 2: high speed, power 100 mA, config 1, product 0x7840(0x7840), vendor 0x9710(0x9710), rev 0.01 Thanks in advance. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: profiling broken on RELENG_7/i386
On Sun, 13 Jul 2008, Bruce Cran wrote:
BC> > PJ> On 2008-Jul-04 13:01:11 +0400, Dmitry Morozovsky <[EMAIL PROTECTED]>
BC> > PJ> wrote:
BC> > PJ> >It seems we step on a bug in gcc in RELENG_7/i386
BC> > PJ> >
BC> > PJ> >It is triggered at least by profiling program which uses
BC> > PJ> >getopt(3):
BC> > PJ>
BC> > PJ> I think it's actually in the profiling initialisation code. If
BC> > PJ> you try to run sample code under gdb, you can see that .mcount()
BC> > PJ> is not preserving %ecx, though main() assumes it does.
BC> >
BC> > I see. However, I'm afraid we need knowledge of some gcc guru to
BC> > bring the fix in.
BC> >
BC>
BC> This is a known bug in 7.x and has apparently been fixed in -CURRENT.
BC> See http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/119709 for more
BC> details.
It seems it is not, at least on cluster reference -CURRENT i386 machine:
Thu Jul 3 21:52:15 UTC 2008
[EMAIL PROTECTED]:~/tmp/gprof> ./test
Segmentation fault (core dumped)
Profiling program does not always dump core, but .mcount definitely clobbers
one of the registers:
[EMAIL PROTECTED]:~/tmp/gprof> cat test-x.c
#include
int
main(int argc, char *argv[])
{
printf("Hello, world!\n");
printf("argc=%d, argv=%p\n", argc, argv);
return (0);
}
w/o -pg:
[EMAIL PROTECTED]:~/tmp/gprof> ./test
Hello, world!
argc=1, argv=0xbf7febf8
with -pg:
[EMAIL PROTECTED]:~/tmp/gprof> ./test
Hello, world!
argc=0, argv=0x0
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: profiling broken on RELENG_7/i386
On Sun, 13 Jul 2008, Peter Jeremy wrote:
PJ> On 2008-Jul-04 13:01:11 +0400, Dmitry Morozovsky <[EMAIL PROTECTED]> wrote:
PJ> >It seems we step on a bug in gcc in RELENG_7/i386
PJ> >
PJ> >It is triggered at least by profiling program which uses getopt(3):
PJ>
PJ> I think it's actually in the profiling initialisation code. If
PJ> you try to run sample code under gdb, you can see that .mcount()
PJ> is not preserving %ecx, though main() assumes it does.
I see. However, I'm afraid we need knowledge of some gcc guru to bring the fix
in.
Alexander, could you please comment?
PJ>
PJ> (gdb) disas $eip
PJ> Dump of assembler code for function main:
PJ> 0x080481d0 :lea0x4(%esp),%ecx
PJ> 0x080481d4 :and$0xfff0,%esp
PJ> 0x080481d7 :pushl 0xfffc(%ecx)
PJ> 0x080481da : push %ebp
PJ> 0x080481db : mov%esp,%ebp
PJ> 0x080481dd : push %ecx
PJ> 0x080481de : sub$0x14,%esp
PJ> 0x080481e1 : call 0x8051b50 <.mcount>
PJ> 0x080481e6 : mov0x4(%ecx),%eax
PJ> 0x080481e9 : mov(%eax),%eax
PJ> 0x080481eb : mov%eax,0x8(%esp)
PJ> 0x080481ef : mov(%ecx),%eax
PJ> 0x080481f1 : mov%eax,0x4(%esp)
PJ> 0x080481f5 : movl $0x8066b0a,(%esp)
PJ> 0x080481fc : call 0x8051b00
PJ> 0x08048201 : mov$0x0,%eax
PJ> 0x08048206 : add$0x14,%esp
PJ> 0x08048209 : pop%ecx
PJ> 0x0804820a : pop%ebp
PJ> 0x0804820b : lea0xfffc(%ecx),%esp
PJ> 0x0804820e : ret
PJ> End of assembler dump.
PJ> (gdb) x/10x $esp
PJ> 0xbfbfeadc: 0x0804815f 0x0001 0xbfbfeb08 0xbfbfeb10
PJ> 0xbfbfeaec: 0x 0x 0x 0x
PJ> 0xbfbfeafc: 0x 0x
PJ> (gdb) info regi
PJ> eax0xbfbfeb08 -1077941496
PJ> ecx0x1e968 125288
PJ> edx0x8051d1a134552858
PJ> ebx0x1 1
PJ> esp0xbfbfeadc 0xbfbfeadc
PJ> ebp0xbfbfeb00 0xbfbfeb00
PJ> esi0xbfbfeb10 -1077941488
PJ> edi0x0 0
PJ> eip0x80481d00x80481d0
PJ> eflags 0x282642
PJ> cs 0x33 51
PJ> ss 0x3b 59
PJ> ds 0x3b 59
PJ> es 0x3b 59
PJ> fs 0x3b 59
PJ> gs 0x1b 27
PJ> ...
PJ> [step through .mcount]
PJ> ...
PJ> (gdb) stepi
PJ> main (argc=Error accessing memory address 0x1b: Bad address.
PJ> ) at x.c:4
PJ> 4 printf("Hello %d %s\n", argc, argv[0]);
PJ> (gdb) info regi
PJ> eax0x1 1
PJ> ecx0x1b 27
PJ> edx0x804815f134512991
PJ> ebx0x1 1
PJ> esp0xbfbfeab0 0xbfbfeab0
PJ> ebp0xbfbfeac8 0xbfbfeac8
PJ> esi0xbfbfeb10 -1077941488
PJ> edi0x0 0
PJ> eip0x80481e60x80481e6
PJ> eflags 0x246582
PJ> cs 0x33 51
PJ> ss 0x3b 59
PJ> ds 0x3b 59
PJ> es 0x3b 59
PJ> fs 0x3b 59
PJ> gs 0x1b 27
PJ>
PJ> --
PJ> Peter Jeremy
PJ> Please excuse any delays as the result of my ISP's inability to implement
PJ> an MTA that is either RFC2821-compliant or matches their claimed behaviour.
PJ>
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: profiling broken on RELENG_7/i386
On Fri, 4 Jul 2008, Dmitry Morozovsky wrote:
DM> It seems we step on a bug in gcc in RELENG_7/i386
DM>
DM> It is triggered at least by profiling program which uses getopt(3):
[snip]
DM> other ref platforms seem to be ok.
Nah, HEAD/i386 also has this bug, though backtrace is a bit different:
[EMAIL PROTECTED]:~/tmp/gprof> make clean all
rm -f test test.o
Warning: Object directory not changed from original
/dumpster/home/marck/tmp/gprof
cc -O2 -pipe -march=prescott -g -pg -fstack-protector -c test.c
cc -O2 -pipe -march=prescott -g -pg -fstack-protector -o test test.o
[EMAIL PROTECTED]:~/tmp/gprof> ./test
Segmentation fault (core dumped)
[EMAIL PROTECTED]:~/tmp/gprof> gdb test test.core
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"...
Core was generated by `test'.
Program terminated with signal 11, Segmentation fault.
#0 0x08048242 in getopt ()
(gdb) bt
#0 0x08048242 in getopt ()
#1 0x080481f9 in main (argc=0, argv=0x0) at test.c:9
(gdb) l
9 while ((ch = getopt(argc, argv, "")) != -1) {
10 }
11
12 return (0);
13 }
(gdb) [EMAIL PROTECTED]:~/tmp/gprof> truss ./test
__sysctl(0xbf7fe728,0x2,0x8071ff0,0xbf7fe730,0x0,0x0) = 0 (0x0)
__sysctl(0xbf7fe67c,0x2,0x80776a8,0xbf7fe684,0x0,0x0) = 0 (0x0)
__sysctl(0xbf7fe6cc,0x2,0xbf7fe6d8,0xbf7fe6dc,0x0,0x0) = 0 (0x0)
readlink("/etc/malloc.conf","DMaj",1024) = 4 (0x4)
issetugid(0x806c233,0xbf7fe737,0x400,0xbf7fe730,0x0,0x0) = 0 (0x0)
break(0x810) = 0 (0x0)
break(0x820) = 0 (0x0)
sysarch(0xa,0xbf7feba0,0xbf7febc8,0x8048555,0x8102040,0xc) = 0 (0x0)
break(0x822c69c) = 0 (0x0)
profil(0x8208988,0x11e8a,0x8048148,0x8000,0x0,0x0) = 0 (0x0)
__sysctl(0xbf7feb9c,0x2,0x8072140,0xbf7feba4,0x0,0x0) = 0 (0x0)
SIGNAL 11 (SIGSEGV)
amd64 and RELENG_6 seem to perform well
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
----
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
profiling broken on RELENG_7/i386
Dear colleagues,
It seems we step on a bug in gcc in RELENG_7/i386
It is triggered at least by profiling program which uses getopt(3):
[EMAIL PROTECTED]:~/tmp/gprof> cat test.c
#include
int
main(int argc, char *argv[])
{
int ch;
while ((ch = getopt(argc, argv, "")) != -1) {
}
return (0);
}
[EMAIL PROTECTED]:~/tmp/gprof> make
Warning: Object directory not changed from original
/dumpster/home/marck/tmp/gprof
cc -O2 -fno-strict-aliasing -pipe -march=prescott -g -pg -c test.c
cc -O2 -fno-strict-aliasing -pipe -march=prescott -g -pg -o test test.o
[EMAIL PROTECTED]:~/tmp/gprof> ./test
Segmentation fault (core dumped)
[EMAIL PROTECTED]:~/tmp/gprof> gdb test test.core
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"...
Core was generated by `test'.
Program terminated with signal 11, Segmentation fault.
#0 0x080481e0 in main (argc=Cannot access memory at address 0x1b
) at test.c:6
6 {
(gdb) l
1
2 #include
3
4 int
5 main(int argc, char *argv[])
6 {
7 int ch;
8
9 while ((ch = getopt(argc, argv, "")) != -1) {
10 }
(gdb) [EMAIL PROTECTED]:~/tmp/gprof> truss ./test
__sysctl(0xbf7feb0c,0x2,0x806bf70,0xbf7feb18,0x0,0x0) = 0 (0x0)
__sysctl(0xbf7fe64c,0x2,0x806d558,0xbf7fe654,0x0,0x0) = 0 (0x0)
__sysctl(0xbf7fe69c,0x2,0xbf7fe6a8,0xbf7fe6ac,0x0,0x0) = 0 (0x0)
readlink("/etc/malloc.conf","aj",1024) = 2 (0x2)
issetugid(0x8066d0d,0xbf7fe70b,0x400,0xbf7feb18,0x0,0x0) = 0 (0x0)
break(0x810) = 0 (0x0)
break(0x820) = 0 (0x0)
sysarch(0xa,0xbf7feba0,0xbf7febc8,0x8048555,0x8102040,0xc) = 0 (0x0)
break(0x8226004) = 0 (0x0)
profil(0x82075a8,0xf52e,0x8048148,0x8000,0x0,0x0) = 0 (0x0)
SIGNAL 11 (SIGSEGV)
other ref platforms seem to be ok.
Any hints?
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
i386 jail undex amd64: libkvm
Dear colleagues, it seems this question had been arised several times, but I failed to find any solution (yet). What is (and is there?) the proper way to compile libkvm-related binaries (and libkvm itself) to assure 32bit binaries work with amd64 kernel structures? Straight way with installing i386 world, or cross-compile with TARGET=i386 leads to empty result with ps and kvm_open: kinfo_proc size mismatch (expected 768, got 1088) top: Out of memory. with top. I tried to play with lib32 libraries and different system headers, but did not succeed. Any clues? Thank you in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get filename of an open file descriptor
On Mon, 12 Nov 2007, Yuri wrote: Y> I looked at the patch. It retrieves file description information through Y> 'sysctl' calls with proprietary keys. Y> Y> Isn't it better architecturally to expose the same information through procfs Y> interface? At least from the filesystem level and up standard tools like ls/cat Y> will be able to show the the same information instead of the specialized utility. IIRC, procfs interface (and existing procfs implementation in particular) has been mostly dropped due to various privilege escalation vulnerabilities existed in the past. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Useful tools missing from /rescue
On Sat, 1 Sep 2007, Julian Stacey wrote:
JS> > I've had to use /rescue recently and felt lack of a few basic tools
JS> > in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter,
JS> > e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1),
JS> > tail(1), and even tee(1) can be emulated if one has sed(1), but the
JS> > tools are so tiny and convenient that it's a pity not to have them
JS> > all handy during hard times.
JS> >
JS> > In addition, there are chflags and chmod in /rescue, but there's
JS> > no chown in it, so the toolset is a bit incomplete.
JS> >
JS> > Would anyone mind if I add those tools to /rescue? The size growth
JS> > will be rather small:
JS> >
JS> > -r-xr-xr-x 121 root wheel 3715096 1 сен 10:22 /mnt2/rescue.old/rescue
JS> > -r-xr-xr-x 129 root wheel 3761828 1 сен 11:22 /mnt2/rescue/rescue
JS>
JS> Don't do it without approval of re@ (who might be too busy just now
JS> anyway) It might blow the limit on the tight packed rescue floppy.
JS> (& though desk workstations have CDs, lost of small boxes still
JS> just have floppies for rescue) Best try to build a rescue floppy
JS> yourself before adding bloat.
JS>
JS> BTW I've never used pgrep thus superfluous to rescue. Others also
JS> not really needed, merely nice. True rescue is just to fix FS at
JS> which point you can mount other FS or CDROM or NFS etc for more
JS> tools.
What about adding support for zfs then (see below)? I found it especially
useful when you have zfs-on-root and copy /rescue to /bootdisk and symlink bin
and sbin to rescue - this allows emergency management of zfs when booting with
/bootdisk as root.
Trick with -lm seems to be needed because libzfs itself refers to pow(3) - or
did I miss something trivial to resolve this?
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
Index: Makefile
===
RCS file: /home/ncvs/src/rescue/rescue/Makefile,v
retrieving revision 1.56
diff -u -r1.56 Makefile
--- Makefile14 Jul 2007 21:49:22 - 1.56
+++ Makefile31 Aug 2007 11:24:34 -
@@ -71,7 +71,7 @@
CRUNCH_PROGS_bin= cat chflags chio chmod cp date dd df echo\
ed expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \
realpath rm rmdir setfacl sh stty sync test
-CRUNCH_LIBS+= -lcrypt -ledit -lkvm -ll -lm -ltermcap -lutil
+CRUNCH_LIBS+= -lcrypt -ledit -lkvm -ll -ltermcap -lutil
.if ${MK_OPENSSL} != "no"
CRUNCH_LIBS+= -lcrypto
.endif
@@ -185,5 +185,17 @@
CRUNCH_PROGS_sbin+= dhclient
CRUNCH_BUILDOPTS_dhclient= -DRELEASE_CRUNCH -Dlint
+# zfs-related: zpool and zfs
+.if ${MK_CDDL} != "no" && ${MK_ZFS} != "no"
+CRUNCH_PROGS_sbin+= zfs zpool
+CRUNCH_SRCDIR_zfs= $(.CURDIR)/../../cddl/sbin/zfs
+CRUNCH_SRCDIR_zpool= $(.CURDIR)/../../cddl/sbin/zpool
+CRUNCH_LIBS+= -lzfs -lavl -lnvpair -luutil
+.endif
+
+# XXX libzfs needs pow()
+CRUNCH_LIBS+= -lm
+
##
# Programs from stock /usr/bin
#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: numbers don't lie ...
On Mon, 25 Sep 2006, Dag-Erling Sm?rgrav wrote: DS> > > > My experiments show that if you have enough memory to host radmdrive for DS> > > > /usr/src you'd better leave it for caching - there were no statistically DS> > > > meaningful performance difference, at least on machines with 1G+ RAM. DS> > > Really? My measurements show the opposite (on a system with 16GB of DS> > > RAM). DS> > My last test on amd64/dualcore with 4G of RAM and -j4 shows DS> > (buildworld+buildkernel): DS> > DS> > ==> /tmp/buildlog <== DS> > 1996.45 real 3032.94 user 624.83 sys DS> > Script done on Tue Sep 19 14:44:54 2006 DS> > DS> > ==> /tmp/buildlog.md <== DS> > 1957.45 real 3033.93 user 585.78 sys DS> > Script done on Tue Sep 19 15:20:42 2006 DS> > DS> > Second one was with 512M/4k/512 swap-backed md, the former with /usr/src on the DS> > gmirror'ed pair of SATAs. DS> DS> Seems to me that your own numbers contradict you. You saved about 40 DS> seconds (2%) by keeping /usr/src in a ram disk. Well, maybe I did used wrong wording (2% is statistically meaningful), but for me 2% is not worth all the efforts needed to organize ram disk infrastructure... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: numbers don't lie ...
On Wed, 20 Sep 2006, Eric Anderson wrote: EA> > > > My experiments show that if you have enough memory to host radmdrive EA> > for > /usr/src you'd better leave it for caching - there were no EA> > statistically EA> > > meaningful performance difference, at least on machines with 1G+ RAM. EA> > EA> > That might only be true if you have enough RAM to keep EA> > _all_ buildworld files (src, obj, toolchain) in the cache EA> > _and_ you pre-read all of /usr/src before actually starting EA> > the buildworld, so it is in the cache. If you don't have EA> > that much RAM, but enough to store /usr/src, then using EA> > a RAM disk for it is a win. EA> > EA> > Reading /usr/src from a physical disk certainly requires EA> > quite some I/O that takes more than zero time. EA> EA> But, in order to populate the ram disk, you must read /usr/src also from EA> something, and that also takes time, which you should include in the full EA> scope. ... and that populates cache with src files as well ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: numbers don't lie ...
On Tue, 19 Sep 2006, Kris Kennaway wrote: KK> > OF> Because buildworld is I/O-bound on systems with sufficiently KK> > OF> fast processors. KK> > OF> KK> > OF> Try putting the contents of /usr/src into a RAM disk and KK> > OF> repeat the benchmark. The numbers might look a little KK> > OF> different then. Of course, you should have sufficient RAM KK> > OF> in the machines -- If they're going to swap to the disks, KK> > OF> your benchmark won't be happy. KK> > OF> KK> > OF> I think putting /usr/obj onto a RAM disk is _not_ necessary KK> > OF> because of soft-updates, so the processes shouldn't block KK> > OF> on writes. KK> > KK> > My experiments show that if you have enough memory to host radmdrive for KK> > /usr/src you'd better leave it for caching - there were no statistically KK> > meaningful performance difference, at least on machines with 1G+ RAM. KK> KK> Really? My measurements show the opposite (on a system with 16GB of KK> RAM). My last test on amd64/dualcore with 4G of RAM and -j4 shows (buildworld+buildkernel): ==> /tmp/buildlog <== 1996.45 real 3032.94 user 624.83 sys Script done on Tue Sep 19 14:44:54 2006 ==> /tmp/buildlog.md <== 1957.45 real 3033.93 user 585.78 sys Script done on Tue Sep 19 15:20:42 2006 Second one was with 512M/4k/512 swap-backed md, the former with /usr/src on the gmirror'ed pair of SATAs. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: numbers don't lie ...
On Thu, 14 Sep 2006, Oliver Fromme wrote: OF> Because buildworld is I/O-bound on systems with sufficiently OF> fast processors. OF> OF> Try putting the contents of /usr/src into a RAM disk and OF> repeat the benchmark. The numbers might look a little OF> different then. Of course, you should have sufficient RAM OF> in the machines -- If they're going to swap to the disks, OF> your benchmark won't be happy. OF> OF> I think putting /usr/obj onto a RAM disk is _not_ necessary OF> because of soft-updates, so the processes shouldn't block OF> on writes. My experiments show that if you have enough memory to host radmdrive for /usr/src you'd better leave it for caching - there were no statistically meaningful performance difference, at least on machines with 1G+ RAM. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ENOMEM @ RELENG_6 graid3
On Tue, 27 Jun 2006, Eric Anderson wrote: EA> > As to ENOMEM/no memory in start, I'm fairly sure machine is not in generic EA> > memory-shortage; and, these errors are generated only on machine with EA> > graid3. EA> EA> What does your kernel config look like? Are you using (or did you ever use) EA> extended attributes on this fs? GENERIC stripped down to a minimum. geom classes loaded as modules. No extended attributes at all. nfsserver as module. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ENOMEM @ RELENG_6 graid3
On Mon, 26 Jun 2006, Eric Anderson wrote: EA> > turning on bootverbose reveals additional info to EA> > ad10: FAILURE - out of memory in start EA> > EA> > under load this machine (5 ata disks, most of their space allocated for 2 EA> > graid3's) many messages like EA> > EA> > ENOMEM 0xc6e834a4 on 0xc493c080(ad8) EA> > ENOMEM 0xc703fdec on 0xc4960480(ad10) EA> > ENOMEM 0xc6b49528 on 0xc4901400(ad0) EA> > ENOMEM 0xc6c378c4 on 0xc493ca80(ad4g) EA> > ENOMEM 0xc662b210 on 0xc4900b00(ad0f) EA> > ENOMEM 0xc6b33630 on 0xc493c380(ad4) EA> > ENOMEM 0xc7320d68 on 0xc4901400(ad0) EA> > ENOMEM 0xc6bd6948 on 0xc493c380(ad4) EA> > ENOMEM 0xc7299dec on 0xc493c200(ad6) EA> > ENOMEM 0xc6d91528 on 0xc495f700(ad6g) EA> > ENOMEM 0xc47b07bc on 0xc4960480(ad10) EA> > ENOMEM 0xc7c22bdc on 0xc493c080(ad8) EA> > EA> > Machine is rather stable; however, it panics two or three times on /ftp: EA> > bad dir ino 3454117 at offset 444: mangled entry EA> > panic: ufs_dirbad: bad dir EA> > EA> > Any hints to debug? EA> EA> Are you sure the filesystem is clean? Can you try unmounting it, and EA> running an fsck_ffs on it? Also, I think this has been discussed before on EA> freebsd-geom@, did you check the archives? Well, these two may not be linked together. (fsck does not report any errors though) As to ENOMEM/no memory in start, I'm fairly sure machine is not in generic memory-shortage; and, these errors are generated only on machine with graid3. Maybe volume size (slightly larged than 1T) is relevant as well: [EMAIL PROTECTED]:/pub/FreeBSD# graid3 list r0g Geom name: r0g State: COMPLETE Components: 5 Flags: ROUND-ROBIN GenID: 0 SyncID: 9 ID: 2611540979 Zone64kFailed: 35144 Zone64kRequested: 18641827 Zone16kFailed: 388 Zone16kRequested: 246907 Zone4kFailed: 19793 Zone4kRequested: 5651352 Providers: 1. Name: raid3/r0g Mediasize: 1118758531072 (1.0T) Sectorsize: 2048 Mode: r1w1e1 Consumers: 1. Name: ad0g Mediasize: 279689633280 (260G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Flags: DIRTY GenID: 0 SyncID: 9 Number: 4 Type: PARITY 2. Name: ad4g Mediasize: 279689633280 (260G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Flags: DIRTY GenID: 0 SyncID: 9 Number: 1 Type: DATA 3. Name: ad6g Mediasize: 279689633280 (260G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Flags: DIRTY GenID: 0 SyncID: 9 Number: 0 Type: DATA 4. Name: ad8g Mediasize: 279689633280 (260G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Flags: DIRTY GenID: 0 SyncID: 9 Number: 2 Type: DATA 5. Name: ad10g Mediasize: 279689633280 (260G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Flags: DIRTY GenID: 0 SyncID: 9 Number: 3 Type: DATA Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ENOMEM @ RELENG_6 graid3
Dear colleagues, turning on bootverbose reveals additional info to ad10: FAILURE - out of memory in start under load this machine (5 ata disks, most of their space allocated for 2 graid3's) many messages like ENOMEM 0xc6e834a4 on 0xc493c080(ad8) ENOMEM 0xc703fdec on 0xc4960480(ad10) ENOMEM 0xc6b49528 on 0xc4901400(ad0) ENOMEM 0xc6c378c4 on 0xc493ca80(ad4g) ENOMEM 0xc662b210 on 0xc4900b00(ad0f) ENOMEM 0xc6b33630 on 0xc493c380(ad4) ENOMEM 0xc7320d68 on 0xc4901400(ad0) ENOMEM 0xc6bd6948 on 0xc493c380(ad4) ENOMEM 0xc7299dec on 0xc493c200(ad6) ENOMEM 0xc6d91528 on 0xc495f700(ad6g) ENOMEM 0xc47b07bc on 0xc4960480(ad10) ENOMEM 0xc7c22bdc on 0xc493c080(ad8) Machine is rather stable; however, it panics two or three times on /ftp: bad dir ino 3454117 at offset 444: mangled entry panic: ufs_dirbad: bad dir Any hints to debug? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A New FreeBSD Server
On Sat, 24 Jun 2006, Mike Meyer wrote: MM> The other constraint on swap is that if you want the system to save a MM> core dump if it panics, you need a device to dump on that's 64Kb MM> bigger than ram. That's one device, not all of swap. This is not quite true, as there always are some unused memory regions, hence you need not add 64k to RAM size. At least, I had no trouble using swap == RAM for last 5 years or so... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
config(8), include, and INCLUDE_CONFIG_FILE
Dear colleagues, Since "include" statement has been invented in config(8), option INCLUDE_CONFIG_FILE is broken, as it's embedding only highest level config file into the kernel. I looked through the sources, but it seems fixing this is not very easy. The most natural way for me seems tracking all config while lex/yacc parsing into memory buffer, as configfile() is invoked after full config parse. Any thoughts? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
On Fri, 13 Jan 2006, Peter Jeremy wrote: PJ> >The process is running now since yesterday evening and it is at 53 MB PJ> >at a transfer rate of about 1.1 MB/s. PJ> > PJ> >In case the the result being unusable I would like to find a way to make this PJ> >copying faster. PJ> PJ> Note that whilst increasing the DD blocksize will speed up the PJ> transfer, it will also increase the amount of collateral damage when a PJ> hard error occurs. If you rummage around the ports or tools tree, PJ> you'll find a utility (its name escapes me but I believe it was PJ> written by phk) that is designed to do disk-to-disk recovery - it PJ> copys data in big slabs until it gets an error and then works around PJ> the faulty area block by block. PJ> PJ> You should also install /usr/ports/sysutils/smartmontools - this PJ> handles S.M.A.R.T. I would suggest also using src/tools/tools/recoverdisk by phk (I still not sure why it's not a port) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ffs_alloc.c: minfree Q
Colleagues, from ffs_alloc.c: case FS_OPTSPACE: /* * Allocate an exact sized fragment. Although this makes * best use of space, we will waste time relocating it if * the file continues to grow. If the fragmentation is * less than half of the minimum free reserve, we choose * to begin optimizing for time. */ request = nsize; if (fs->fs_minfree <= 5 || --->>>~~ fs->fs_cstotal.cs_nffree > (off_t)fs->fs_dsize * fs->fs_minfree / (2 * 100)) break; log(LOG_NOTICE, "%s: optimization changed from SPACE to TIME\n", fs->fs_fsmnt); fs->fs_optim = FS_OPTTIME; break; For contemporary situation, where total size of file system can grow to hundreds of Gs or even several Ts, 8% of space seems too high. Maybe this algorithm should be slightly adjusted (I'm thinking of logarithmic scale depending on file system size)? Any (contemporary) references would be highly appreciated. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mfs/mdconfig under RELENG_5: malloc vs swap-backed
On Mon, 1 Aug 2005, Giorgos Keramidas wrote:
GK> On 2005-08-01 20:50, Dmitry Morozovsky <[EMAIL PROTECTED]> wrote:
GK> >On Mon, 1 Aug 2005, Jo?o Carlos Mendes Luis wrote:
GK> >>>> can anyone please point me why mdconfig method for tmpmfs is
GK> >>>> malloc-backed instead of swap-backed, and it is hardcoded into
GK> >>>> rc.subr?
GK> >>>> Are swap-backed file systems so inefficient? If no, why not move -M to
GK> >>>> /etc/defaultc/rc.conf so admin can override this behaviour?
GK> >>>
GK> >>> Diskless systems may not have swap - the default is required as is.
GK> >>> Don't know about beeing hardcoded.
GK> >>
GK> >> It is hardcoded at /etc/rc.subr:
GK> >>
GK> >> # Provide a function for normalizing the mounting of memory
GK> >> # filesystems. This should allow the rest of the code here to remain
GK> >> # as close as possible between 5-current and 4-stable.
GK> >> # $1 = size
GK> >> # $2 = mount point
GK> >> # $3 = (optional) extra mdmfs flags
GK> >> mount_md() {
GK> >> if [ -n "$3" ]; then
GK> >> flags="$3"
GK> >> fi
GK> >> /sbin/mdmfs $flags -s $1 -M md $2
GK> >> }
GK> >>
GK> >> I would prefer it to be configurable, too.
GK> >
GK> > I did contacted keramida@ yesterday, and he seems to be happy with my
GK> > proposed patch. So, just wait for it to be committed.
GK>
GK> Yes, I like the change. I'm not an src-committer, so it is just an
GK> informed opinion by someone who eats shell scripts for breakfast, so
GK> feel free to ask the [EMAIL PROTECTED] guys too :-)
Hmm.
[EMAIL PROTECTED]:/lh/src.current> whodid etc/rc.subr
etc/rc.subr:
20 mtm
6 gordon
3 keramida
2 obrien
2 cperciva
1 schweikh
1 des
1 brooks
I supposed you can commit there, as you already did it 3 times, and I can't see
any Approved: lines in CVS logs ;-P
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mfs/mdconfig under RELENG_5: malloc vs swap-backed
On Mon, 1 Aug 2005, Jo?o Carlos Mendes Luis wrote:
JCML> > > can anyone please point me why mdconfig method for tmpmfs is
JCML> > > malloc-backed instead of swap-backed, and it is hardcoded into
JCML> > > rc.subr?
JCML> > > Are swap-backed file systems so inefficient? If no, why not move -M to
JCML> > > /etc/defaultc/rc.conf so admin can override this behaviour?
JCML> >
JCML> >
JCML> > Diskless systems may not have swap - the default is required as is.
JCML> > Don't know about beeing hardcoded.
JCML>
JCML> It is hardcoded at /etc/rc.subr:
JCML>
JCML> # Provide a function for normalizing the mounting of memory
JCML> # filesystems. This should allow the rest of the code here to remain
JCML> # as close as possible between 5-current and 4-stable.
JCML> # $1 = size
JCML> # $2 = mount point
JCML> # $3 = (optional) extra mdmfs flags
JCML> mount_md() {
JCML> if [ -n "$3" ]; then
JCML> flags="$3"
JCML> fi
JCML> /sbin/mdmfs $flags -s $1 -M md $2
JCML> }
JCML>
JCML> I would prefer it to be configurable, too.
I did contacted keramida@ yesterday, and he seems to be happy with my proposed
patch. So, just wait for it to be committed.
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mfs/mdconfig under RELENG_5: malloc vs swap-backed
Dear colleagues, can anyone please point me why mdconfig method for tmpmfs is malloc-backed instead of swap-backed, and it is hardcoded into rc.subr? Are swap-backed file systems so inefficient? If no, why not move -M to /etc/defaultc/rc.conf so admin can override this behaviour? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make_dev(9) man page: inconsistent with reality
Dear colleagues, [EMAIL PROTECTED]:/FreeBSD/src.current> cvs -R stat share/man/man9/make_dev.9 === File: make_dev.9Status: Up-to-date Working revision:1.15Mon Nov 10 10:22:33 2003 Repository revision: 1.15/home/ncvs/src/share/man/man9/make_dev.9,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) This man page refers to old dev_t machanism instead of struct cdev *. The same inconsistency applies to RELENG_5. Unfortunately, I can't provide useful diff myself (not deep enough kernel structures understanding), but I suppose it should be fixed before 5.4-R. Thanks. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i86 install images
On Fri, 11 Feb 2005, Dmitry Morozovsky wrote: DM> SL> disc2: kernel, sysinstall, no install distributions, live filesystem. DM> SL> Good for recovering broken systems. I used it for just this a few days DM> SL> ago myself. DM> DM> BTW: why not include miniinst disc onto disc2, as they fit both for RELENG5 and DM> RELENG4? I did this a while ago when build custom i686 builds, and found it DM> useful. Hmm. I would rather read your original mail more thoroughly ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i86 install images
On Sun, 6 Feb 2005, Scott Long wrote: SL> disc2: kernel, sysinstall, no install distributions, live filesystem. SL> Good for recovering broken systems. I used it for just this a few days SL> ago myself. BTW: why not include miniinst disc onto disc2, as they fit both for RELENG5 and RELENG4? I did this a while ago when build custom i686 builds, and found it useful. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea about "skeleton jail"
Dear Xin, On Mon, 31 Jan 2005, Xin LI wrote: XL> What I am going to proposal is a concept that I call it "skeleton jail", XL> or "skeljail" for short. A skel jail is something that shares most base XL> system binaries/libraries with the host, through read-only mount_null's. [snip] XL> I have some handcrafted shell scripts to implement skeljail by having XL> everything automatically mounted/dismounted. However, I think it might XL> be better if we can have jail__skeljail="YES" switch in our jail XL> rc.d(8) startup script. Please let me know if you are interested in the XL> idea and I'll post a patch for review if there's enough people that XL> wants this. I wrote some scripts for very similar process (however, I used one mount to null mount jail's /usr, and move/symlinked /bin and /sbin to /usr/Rbin and /usr/Rsbin, with /usr/local, /usr/home and /usrX11R6 linked out to jail root) I'm very interested in your patchset, at least for comparing with our (and for learning, or course! ;-) Thanks! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GVRP announces under FreeBSD
Dear colleagues, is there any existing solution for announcing dot1Q vlans from FreeBSD router via GVRP? Quick googling does not reveal anything informative. Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-STABLE: handle_workitem_freefile panic
On Mon, 24 Jan 2005, Dmitry Morozovsky wrote: DM> PJD> +> However: how can the be achieved the following goal: have mirrored swap (to DM> PJD> +> keep redundancy and HA) and a place to dump panic images to, modulo having DM> PJD> +> scratch disk and/or scratch unused partition? DM> PJD> DM> PJD> When you have dedicated mirror only for swap (e.g. mirror on ad0s1b and DM> PJD> ad2s1b) you probably should be able to dump into ad[02]s1b (but I didn't DM> PJD> test it). DM> DM> Well, dumpon -v /dev/ad4b (which is part of /dev/mirror/m0b with /dev/ad6b) DM> says it will dump on that, but: DM> DM> 1) it cannot read it on boot: DM> DM> Checking for core dump on /dev/ad4b ... DM> savecore: /dev/ad4b: Operation not permitted DM> savecore: no dumps found DM> DM> 2) entering ddb via Ctrl+Alt+Esc and issuin 'panic' command hangs the machine DM> hard. DM> DM> I'll test dumps on non-gmirrored disks tomorrow. Hmm, it cannot either. 'panic' from DDB prints stack trace, destroys all gmirror providers, and then locks hard. It's on Jan 25 17:07:20 donkey kernel: atapci0: port 0xa800-0xa8ff,0xb000-0xb00f,0xb400-0xb403,0xb800-0xb807,0xd000-0xd003,0xd400-0xd407 irq 20 at device 15.0 on pci0 Jan 25 17:07:20 donkey kernel: ata2: channel #0 on atapci0 Jan 25 17:07:20 donkey kernel: ata3: channel #1 on atapci0 Jan 25 17:07:20 donkey kernel: atapci1: port 0xa400-0xa40f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 20 at device 15.1 on pci0 Jan 25 17:07:20 donkey kernel: ata0: channel #0 on atapci1 Jan 25 17:07:20 donkey kernel: ata1: channel #1 on atapci1 Jan 25 17:07:20 donkey kernel: ad4: 238475MB [484521/16/63] at ata2-master SATA150 Jan 25 17:07:20 donkey kernel: ad6: 238475MB [484521/16/63] at ata3-master SATA150 and I was tried to dump on ad4b Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-STABLE: handle_workitem_freefile panic
On Sun, 23 Jan 2005, Pawel Jakub Dawidek wrote: PJD> On Sun, Jan 23, 2005 at 07:24:26PM +0300, Dmitry Morozovsky wrote: PJD> +> However: how can the be achieved the following goal: have mirrored swap (to PJD> +> keep redundancy and HA) and a place to dump panic images to, modulo having PJD> +> scratch disk and/or scratch unused partition? PJD> PJD> When you have dedicated mirror only for swap (e.g. mirror on ad0s1b and PJD> ad2s1b) you probably should be able to dump into ad[02]s1b (but I didn't PJD> test it). Well, dumpon -v /dev/ad4b (which is part of /dev/mirror/m0b with /dev/ad6b) says it will dump on that, but: 1) it cannot read it on boot: Checking for core dump on /dev/ad4b ... savecore: /dev/ad4b: Operation not permitted savecore: no dumps found 2) entering ddb via Ctrl+Alt+Esc and issuin 'panic' command hangs the machine hard. I'll test dumps on non-gmirrored disks tomorrow. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-STABLE: handle_workitem_freefile panic
On Sun, 23 Jan 2005, Pawel Jakub Dawidek wrote: PJD> +> However: how can the be achieved the following goal: have mirrored swap (to PJD> +> keep redundancy and HA) and a place to dump panic images to, modulo having PJD> +> scratch disk and/or scratch unused partition? PJD> PJD> When you have dedicated mirror only for swap (e.g. mirror on ad0s1b and PJD> ad2s1b) you probably should be able to dump into ad[02]s1b (but I didn't PJD> test it). Thanks Pawel, I'll give it a try. What about other two questions I asked you a couple of days ago? ;) Thanks! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-STABLE: handle_workitem_freefile panic
On Sun, 23 Jan 2005, Pawel Jakub Dawidek wrote: PJD> You cannot dump to GEOM providers, especially from rank > 1 geoms. PJD> It is better to create more mirrors for every partition you want to mirror PJD> (or slice) instead of whole disk. PJD> One of the benefits is that gmirror marks mirror as clean if there were no PJD> WRITE requests in few seconds, so even after power failure resynchonization PJD> is not needed. When you've many smaller mirrors, after unclean shutdown you PJD> probably don't need rebuild all mirrors. PJD> The argument against could be that when you synchronize many mirrors on PJD> the same disks in parallel, your disks are less happy (in one big mirror PJD> scenario, disk's heads don't have to jump from one place to another so PJD> often). Well, hope I see both sides of the picture. However: how can the be achieved the following goal: have mirrored swap (to keep redundancy and HA) and a place to dump panic images to, modulo having scratch disk and/or scratch unused partition? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd problem: Cannot detect Hard Disk (SATA)
On Sat, 22 Jan 2005, Dmitry Morozovsky wrote:
DM> DA> There is:
DM> DA> http://www.ambrisko.com/doug/ata/ata_stable_sata_7.patch
DM> DA> for 4.10. That deals with Intel and Promise SATA stuff and
DM> DA> ata-raid fixes/enhancements. It deals with legacy and enhanced modes
DM> DA> for Intel SATA.
DM> DA>
DM> DA> A bunch of people have installed it and are using this. A bunch of
DM> DA> our customers use it via our appliance.
DM>
DM> Wow, thanks! BTW, it seems some sio patches are slipped in by accident?
BTW2: here is small patch to support Promise SATA PDC20376 controller found on
our Albatron MB
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
diff -r -u sys/dev/ata/ata-all.c /FreeBSD/src/sys/dev/ata/ata-all.c
--- sys/dev/ata/ata-all.c Sun Jan 23 17:46:00 2005
+++ /FreeBSD/src/sys/dev/ata/ata-all.c Sat Jan 22 15:49:15 2005
@@ -189,6 +189,7 @@
case 0x3319105a: /* Promise SATA */
case 0x3371105a: /* Promise SATA */
case 0x3373105a: /* Promise SATA */
+case 0x3376105a: /* Promise SATA */
promise_init(ch);
break;
@@ -282,6 +283,7 @@
case 0x3319105a: /* Promise SATA */
case 0x3371105a: /* Promise SATA */
case 0x3373105a: /* Promise SATA */
+case 0x3376105a: /* Promise SATA */
{
struct ata_pci_controller *ctlr;
ctlr = device_get_softc(device_get_parent(ch->dev));
@@ -1002,6 +1004,7 @@
case 0x3319105a: /* Promise SATA */
case 0x3371105a: /* Promise SATA */
case 0x3373105a: /* Promise SATA */
+case 0x3376105a: /* Promise SATA */
promise_init(ch);
if(ch->devices & ATA_ATA_MASTER)
ata_dmadone(&ch->device[MASTER]);
diff -r -u sys/dev/ata/ata-dma.c /FreeBSD/src/sys/dev/ata/ata-dma.c
--- sys/dev/ata/ata-dma.c Sun Jan 23 17:46:00 2005
+++ /FreeBSD/src/sys/dev/ata/ata-dma.c Sat Jan 22 15:53:48 2005
@@ -205,6 +205,7 @@
case 0x3319105a:/* Promise SATA */
case 0x3371105a:/* Promise SATA */
case 0x3373105a:/* Promise SATA */
+case 0x3376105a:/* Promise SATA */
if ((device == 0 && atadev->channel->sata_master_idx)
|| (device == 1 && atadev->channel->sata_slave_idx)){
atadev->param->hwres_cblid = 1;
@@ -1349,6 +1350,7 @@
case 0x3319105a: /* Promise SATA */
case 0x3371105a: /* Promise SATA */
case 0x3373105a: /* Promise SATA */
+case 0x3376105a:/* Promise SATA */
error = ata_command(atadev, ATA_C_SETFEATURES, 0,
ATA_UDMA5, ATA_C_F_SETXFER, ATA_WAIT_READY);
ata_dmacreate(atadev, apiomode, ATA_UDMA5);
@@ -1476,6 +1478,7 @@
case 0x3319105a: /* Promise SATA */
case 0x3371105a: /* Promise SATA */
case 0x3373105a: /* Promise SATA */
+case 0x3376105a: /* Promise SATA */
s = splbio();
ATA_OUTL(ch->r_bmio, ATA_BMDTP_PORT, ds->mdmatab);
ATA_OUTL(ch->r_bmio, ATA_BMCTL_PORT,
@@ -1515,6 +1518,7 @@
case 0x3319105a: /* Promise SATA */
case 0x3371105a: /* Promise SATA */
case 0x3373105a: /* Promise SATA */
+case 0x3376105a: /* Promise SATA */
ch->flags &= ~ATA_DMA_ACTIVE;
ds->flags = 0;
return 0;
diff -r -u sys/dev/ata/ata-pci.c /FreeBSD/src/sys/dev/ata/ata-pci.c
--- sys/dev/ata/ata-pci.c Sun Jan 23 17:46:00 2005
+++ /FreeBSD/src/sys/dev/ata/ata-pci.c Sat Jan 22 15:55:01 2005
@@ -340,6 +340,7 @@
case 0x3371105a:
case 0x3373105a: /* Promise SATA */
+case 0x3376105a: /* Promise SATA */
return "Promise SATA150 TX2 controller";
case 0x3318105a:
@@ -556,6 +557,7 @@
case 0x3319105a: /* Promise SATA150 TX4 */
case 0x3371105a: /* Promise SATA150 TX4 */
case 0x3373105a: /* Promise SATA */
+case 0x3376105a: /* Promise SATA */
/* is there a valid port range to connect to ? */
rid = 0x1c;
controller->bmio[ATA_IDX_DATA].res = bus_alloc_resource(dev,
@@ -849,6 +851,7 @@
case 0x3319105a: /* Promise SATA */
case 0x3371105a: /* Promise SATA */
case 0x3373105a: /* Promise SATA */
+case 0x3376105a: /* Promise SATA */
parent = device_get_parent(ch->dev);
ctlr = device_get_softc(parent);
ata_promise_plug_scan_intr(ch, 1);
diff -r -u sys/dev/ata/ata-raid.c /FreeBSD/src/sys/dev/ata/ata-raid.c
--- sys/dev/ata/ata-raid.c Sun Jan 23 17:46:00 2005
+++ /FreeBSD/src/sys/dev/ata/ata-raid.c Sat Jan 22 15:55:30 2005
@@ -159,6 +159,7 @@
case 0x4d69105a: case 0x5275105a: case 0x6269105a:
case 0x7275105a:
case 0x3318105a: case 0x3319105a: case 0x33
Re: 5.3-STABLE: handle_workitem_freefile panic
On Sun, 23 Jan 2005, Dmitry Morozovsky wrote: DM> I'm building debig kernel now and enabling kernel dumps, just to be sure, but DM> it seems some sporadic file system inconsistencies... Hmmm... it reveals geom_mirror I use (over two SATA drives) both does not support dumping, and hides underlying ad*[a-h] partitions. Should I gmirror distinct partitions instead of whole ad4 and ad6? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.3-STABLE: handle_workitem_freefile panic
Dear colleagues,
my new testing server (RELENG_5 from 21 Jan) yesterday hangs with
handle_workitem_freefile panic (most probably during background fsck). I did
not enable kernel dumps yet, but most frustrating item for me was that system
hangs, not rebooted.
Line involved was
ufs/ffs/ffs_softdep.c:3411: panic("handle_workitem_freefile: inodedep
survived");
I'm building debig kernel now and enabling kernel dumps, just to be sure, but
it seems some sporadic file system inconsistencies...
Any clues?
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd problem: Cannot detect Hard Disk (SATA)
On Wed, 19 Jan 2005, Doug Ambrisko wrote: DA> There is: DA> http://www.ambrisko.com/doug/ata/ata_stable_sata_7.patch DA> for 4.10. That deals with Intel and Promise SATA stuff and DA> ata-raid fixes/enhancements. It deals with legacy and enhanced modes DA> for Intel SATA. DA> DA> A bunch of people have installed it and are using this. A bunch of DA> our customers use it via our appliance. Wow, thanks! BTW, it seems some sio patches are slipped in by accident? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
On Sat, 8 Jan 2005, David Malone wrote: DM> On Sat, Jan 08, 2005 at 01:21:14PM -0500, Charles Sprickman wrote: DM> > Any idea what type of impact this patch would have on say, a large qmail DM> > server that's drowning in context-switches? DM> DM> It will depend on how many processes you have running at any one DM> moment and how often processes are created/destroyed. From the look DM> of the graphs, you won't really be able to tell unless there are DM> significantly more than 1000 processes running at any moment. Then perhaps someone like scrappy@ should test it on one of his hosting planets ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: duplicate CVS modules in merged CVSROOT
On Thu, 16 Dec 2004, [iso-8859-1] Dag-Erling Sm?rgrav wrote: DS> > It seems some checks should be added to module merging code... DS> DS> ...or somebody should stop using the merged CVSROOT. In general, yes. But then, all cvsup mirror infrastructure should be converted, which is non-trivial and long process. Sincerely, D.Marck[DM5020, MCK-RIPE, DM3-RIPN] --- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
duplicate CVS modules in merged CVSROOT
Colleagues, in releaselog I found the following warning: cvs checkout: duplicate key found for `cut' at line 2585 of `/FreeBSD/ncvs/CVSROOT/modules' looking further... [EMAIL PROTECTED]:~/FreeBSD/CVSROOT> cvs ann modules | grep '[^a-z]cut[^a-z]' Annotations for modules *** 1.2 (peter28-Feb-03): cut src/usr.bin/cut 1.4267 (peter15-Dec-04): cut ports/devel/cut It seems some checks should be added to module merging code... Sincerely, D.Marck[DM5020, MCK-RIPE, DM3-RIPN] ------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-R PXE installation
On Sun, 5 Dec 2004, Dmitry Morozovsky wrote: DM> I'm trying to setup PXE istallation for new server. Up to pxeboot everything DM> goes smoothly. pxeboot mounting NFS root successively; however, it DM> immediately whines with DM> DM> Loader version 1.1+ required DM> Aborted! DM> start not found DM> DM> then it loads kernel (which I gunzipped from kern.gz from floppies) DM> successfully, draws '|', reinitializes keyboard, hangs for about 10-20 secs DM> and silently reboots. The same effect if using kernel from miniinst/fixit DM> CD. DM> DM> Any clues? For archives/searches: Answer is simple than anyone can think: pxeboot was from RELENG_4. Replacing it with RELENG_5 version fixes booting. Sorry for the noise. Sincerely, D.Marck[DM5020, MCK-RIPE, DM3-RIPN] ----------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.3-R PXE installation
Dear colleagues, I'm trying to setup PXE istallation for new server. Up to pxeboot everything goes smoothly. pxeboot mounting NFS root successively; however, it immediately whines with Loader version 1.1+ required Aborted! start not found then it loads kernel (which I gunzipped from kern.gz from floppies) successfully, draws '|', reinitializes keyboard, hangs for about 10-20 secs and silently reboots. The same effect if using kernel from miniinst/fixit CD. Any clues? Sincerely, D.Marck[DM5020, MCK-RIPE, DM3-RIPN] ------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPDIVERT option not getting compiled?
On Wed, 17 Nov 2004, Dmitry Morozovsky wrote:
DM> YT> > > I'm adding IPDIVERT option ("options IPDIVERT") to config file and
DM> YT> <...>
DM> YT> > You seem to be confused by the well-known kernel vs. module
DM> YT> > configuration issue. Alas, kernel options you specify in your
DM> YT> > kernel config file affect the kernel binary only, not modules
DM> YT> > built along with the kernel. If you want IPDIVERT, which is
DM> YT> > an option to IPFIREWALL, you have to build your kernel with
DM> YT> > both IPFIREWALL and IPDIVERT:
DM> YT> <...>
DM> YT> I did. See the config contents in originating posting. That was the
essence
DM> YT> of the problem -- familiar procedure unexplainably not working.
DM>
DM> But you did reference ipfw *module*. This combination will not work.
Currently,
DM> if you need divert you *must* compile ipfw into 4.X kernel.
Hmm. Looking at you kernel config file I see you *did* included ipfw into the
kernel. Looks strange to me.
Well, can you please provide dmesg from the failing boot?
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPDIVERT option not getting compiled?
On Tue, 16 Nov 2004, Yury Tarasievich wrote:
YT> Yar Tikhiy wrote:
YT>
YT> > On Tue, Nov 16, 2004 at 03:08:54PM +0200, Yury Tarasievich wrote:
YT> >
YT> > > I'm adding IPDIVERT option ("options IPDIVERT") to config file and
YT> <...>
YT> > You seem to be confused by the well-known kernel vs. module
YT> > configuration issue. Alas, kernel options you specify in your
YT> > kernel config file affect the kernel binary only, not modules
YT> > built along with the kernel. If you want IPDIVERT, which is
YT> > an option to IPFIREWALL, you have to build your kernel with
YT> > both IPFIREWALL and IPDIVERT:
YT> <...>
YT> I did. See the config contents in originating posting. That was the essence
YT> of the problem -- familiar procedure unexplainably not working.
But you did reference ipfw *module*. This combination will not work. Currently,
if you need divert you *must* compile ipfw into 4.X kernel.
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
thread-safe popen(3) at 4-STABLE
Dear colleagues,
checking for hanged and CPU-eating clamav, my colleague ([EMAIL PROTECTED]) found
that popen(3) is not thread safe. What about commiting tjr's fix (attached) to
RELENG_4?
Sincerely,
D.Marck[DM5020, MCK-RIPE, DM3-RIPN]
---
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
---Index: lib/libc/gen/popen.c
===
RCS file: /home/ncvs/src/lib/libc/gen/popen.c,v
retrieving revision 1.14
diff -u -r1.14 popen.c
--- lib/libc/gen/popen.c27 Jan 2000 23:06:19 - 1.14
+++ lib/libc/gen/popen.c16 Oct 2004 16:14:38 -
@@ -51,6 +51,17 @@
#include
#include
+#ifndef _THREAD_SAFE
+#define THREAD_LOCK()
+#define THREAD_UNLOCK()
+#else
+#include
+#include "libc_private.h"
+static pthread_mutex_t pidlist_mutex = PTHREAD_MUTEX_INITIALIZER;
+#defineTHREAD_LOCK() if (__isthreaded) _pthread_mutex_lock(&pidlist_mutex)
+#defineTHREAD_UNLOCK() if (__isthreaded) _pthread_mutex_unlock(&pidlist_mutex)
+#endif /* _THREAD_SAFE */
+
extern char **environ;
static struct pid {
@@ -95,8 +106,10 @@
argv[2] = (char *)command;
argv[3] = NULL;
+ THREAD_LOCK();
switch (pid = vfork()) {
case -1:/* Error. */
+ THREAD_UNLOCK();
(void)_close(pdes[0]);
(void)_close(pdes[1]);
free(cur);
@@ -134,6 +147,7 @@
_exit(127);
/* NOTREACHED */
}
+ THREAD_UNLOCK();
/* Parent; assume fdopen can't fail. */
if (*type == 'r') {
@@ -146,9 +160,11 @@
/* Link into list of file descriptors. */
cur->fp = iop;
- cur->pid = pid;
+ cur->pid = pid;
+ THREAD_LOCK();
cur->next = pidlist;
pidlist = cur;
+ THREAD_UNLOCK();
return (iop);
}
@@ -167,12 +183,23 @@
int pstat;
pid_t pid;
- /* Find the appropriate file pointer. */
+ /*
+* Find the appropriate file pointer and remove it from the list.
+*/
+ THREAD_LOCK();
for (last = NULL, cur = pidlist; cur; last = cur, cur = cur->next)
if (cur->fp == iop)
break;
- if (cur == NULL)
+ if (cur == NULL) {
+ THREAD_UNLOCK();
return (-1);
+ }
+ /* Remove the entry from the linked list. */
+ if (last == NULL)
+ pidlist = cur->next;
+ else
+ last->next = cur->next;
+ THREAD_UNLOCK();
(void)fclose(iop);
@@ -180,11 +207,6 @@
pid = _wait4(cur->pid, &pstat, 0, (struct rusage *)0);
} while (pid == -1 && errno == EINTR);
- /* Remove the entry from the linked list. */
- if (last == NULL)
- pidlist = cur->next;
- else
- last->next = cur->next;
free(cur);
return (pid == -1 ? -1 : pstat);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
On Sat, 9 Oct 2004, Mikhail P. wrote: MP> > > I reloaded OS on the new drives, then restored all data from the old MP> > > drives. All seemed to be fine for 2 months now... but today I woke up, MP> > > and noticed these messages again. MP> > MP> > A lot of them, or just one or two? Some ATA drives will spin down at MP> > regular intervals to recalibrate, and you'll get a harmless timeout if MP> > you try to write to the disk while it's doing that. MP> MP> Unfortunately, all the drives (so far - four 200GB drives). MP> I'm having the previous two drives shipped here within two weeks. MP> Most likely these drives aren't corrupted actually.. will stress them locally MP> here. Well, I suppose Dag-Erling means 'lot of errors' as opposed to one or two raisen sporadically... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Protection from the dreaded "rm -fr /"
On Sun, 3 Oct 2004, M. Warner Losh wrote: [snip] MWL> rm doesn't have to live in the chroot. Consider MWL>chroot /some/path/to/a/chroot rm -rf / MWL> in this case, everything under the /some/path/to/a/chroot would be MWL> removed. However, the rm that's running is outside of the chroot. Not to be too nit-picking, but this is not true, as far as I can understand chroot(8) and chroot(2) ;-) However, since rm is usually statically linked and/or all needed code segments are referenced during rm work are loaded/referenced, this operation finishes successfully (just checked on 4-STABLE and -CURRENT). ... and no, I do *NOT* want to participate in this bikesched color discussion! ;-P Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc strangeness
On Sun, 11 Jul 2004, Dimitry Andric wrote: DA> > 1.00 1.000 0 DA> > 2.00 2.000 1 DA> > 3.00 3.000 2 DA> > 4.00 4.000 3 DA> > 5.00 5.000 5 DA> > 6.00 6.000 6 DA> > 7.00 7.000 7 DA> > 8.00 8.000 7 DA> > 9.00 9.000 8 DA> > 9.99 10.000 9 DA> DA> Yes, this is completely normal if you use IEEE floating point, due to DA> decimal <-> binary conversion and other accumulating rounding errors. DA> In other words, floating point calculations will almost never be DA> exact... DA> DA> This is not a gcc problem. In fact, I can even reproduce your output DA> under Windows using a Microsoft C compiler! :) Wow, it's interesting for us to have exact step-by-step instructions for that! ;) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gcc strangeness
Dear colleagues,
one of my friends has raisen very strange issue regarding gcc rounding:
[EMAIL PROTECTED]:/tmp/tsostik> uname -r
4.10-STABLE
[EMAIL PROTECTED]:/tmp/tsostik> gcc -v
Using builtin specs.
gcc version 2.95.4 20020320 [FreeBSD]
[EMAIL PROTECTED]:/tmp/tsostik> cat x.c
#include
int main ()
{
float a;
for(a=0.01;a<=0.1; a+=0.01)
printf("%f %.3f %d\n", a*100, a*100, (int)(a*100));
return 0;
}
[EMAIL PROTECTED]:/tmp/tsostik> cc x.c
[EMAIL PROTECTED]:/tmp/tsostik> ./a.out
1.00 1.000 0
2.00 2.000 1
3.00 3.000 2
4.00 4.000 3
5.00 5.000 5
6.00 6.000 6
7.00 7.000 7
8.00 8.000 7
9.00 9.000 8
9.99 10.000 9
Any comments?
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Silent errors when reading CDs
Hi there, On Sat, 10 Jul 2004, Jean-Sebastien Roy wrote: JR> I'm currently using FreeBSD 4.10 on an HP D530 SFF. JR> The system is perfectly stable except for the following problem JR> I'm unable to understand : JR> JR> When I mount a cdrom (mount /cdrom), then calculate the MD5 hash JR> of a big file on a CD (md5 /cdrom/bigfile), the results are often random: JR> unmounting, mounting again and calculating again the MD5 often result in JR> a different value. What disturb me the most is that absolutely no errors JR> are reported in any log (no read errors for example). JR> JR> I thought the CDROM reader, a LITE-ON LTR-48327S PQS3, was the culprit, JR> so I replaced it with a PLEXTOR DVDR PX-712A and got the exact same JR> results (i.e. random MD5 values). I checked the RAM using memtest and JR> got no errors. The problem does not occur for files on the harddisk. JR> JR> hw.ata.atapi_dma is set since both drives support it and it seems to be JR> required for proper CD/DVD burning. The CD drive is the master on its JR> own ATA bus. JR> JR> While the problem occurs on multiple CDs (mostly RW), to my surprise, I JR> was not able to reproduce the problem by reading big files on DVDs. JR> JR> Could someone provide me a hint on what to check next or how to fix this JR> problem ? Can errors on CDs generate such a behavior ? What if you copy that big file from CD to HD twice (possibly with unmounting/remounting in the middle) and check MD5s there? Testing your memory with memtest86.com's test would also be helpful to eliminate RAM issues. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting MAC address?
On Sat, 26 Jun 2004, Ivan Voras wrote: IV> How to get the MAC address for an (ethernet) interface? The linux code IV> does this: IV> retval = ioctl(thisint->sockInt, SIOCGIFHWADDR, &ifr); IV> IV> After some searching, I found SIOCSIFLLADDR ioctl, but it appears there IV> isn't a "GET" counterpart. IV> IV> (I've got interface name & index available...) Take a look at ifconfig(8) source. getifaddrs(3), case when sa_family == AF_LINK Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: device pooling and high interrupts
On Sat, 24 Apr 2004, GiZmen wrote: G> I am runnign freebsd 5.2.1 on 386 arch with two rl lan cards. My mainboard G> is on VIA KT 266A with AMD athlon 1.1. G> I read man polling and i have HZ=1000. My problem is that when i set up G> sysctl variable kern.polling.enable=1 my interrupts greatly increase. G> When my system is idle and indicate 0-1% interrupts with out polling. G> and when i turn on polling interrupts goes up to about 20% on idle system. G> Is it normal ? I never before use polling and i dont know that i have G> something bad in my system ? G> G> Can somebody explain me this ? It seems pretty normal under such low load. polling is worth turning on when you have interrupt load spikes more than, say, 40-50% (e.g. highly saturated 100Mbps router with more than two interfaces and/or VLANs) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: [Freebsd-hackers] test
On Thu, 18 Mar 2004, Z3tbl4 wrote: Z> btw does anybody know any bugs in squirrelmail 1.4.2? Bugs do exist and are revealed from time to time. Check full-disclosure/bugtraq archives for samples ;-P Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CVS question: diff between dates on a branch
On Thu, 18 Mar 2004, Ruslan Ermilov wrote: RE> > maybe I'm stupid and blind ;-) but I still can't fugure out how can I ask CVS RE> > to get diff between two states of a branch with known dates (such as today and RE> > yesterday). All that I found was 'cvs get -jBRANCH:date1 -jBRACH:date2' but RE> > this looks very sub-optimal. Any hints? RE> > RE> Surprisingly (it's undocumented) but the exact same synopsis seems RE> to work here with "cvs diff": RE> $ cvs di -jRELENG_4:2002/01/01 -jRELENG_4:2003/01/01 --brief Makefile.inc1 Wow, thanks a lot! Backporting stability patches from RELENG_4 to RELENG_4_X is now much simpler! ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CVS question: diff between dates on a branch
Dear colleagues, maybe I'm stupid and blind ;-) but I still can't fugure out how can I ask CVS to get diff between two states of a branch with known dates (such as today and yesterday). All that I found was 'cvs get -jBRANCH:date1 -jBRACH:date2' but this looks very sub-optimal. Any hints? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP.. USB MFC coming..
On Sat, 28 Feb 2004, Julian Elischer wrote: JE> > Well, my main headache (SONY Clie SJ20) is now in a bit different state; before JE> > (at 4.9p1) it failed to attach with JE> > JE> > ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 JE> > ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 JE> > ucom0: init failed, STALLED JE> > device_probe_and_attach: ucom0 attach returned 6 JE> > ugen0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 JE> > JE> > now it is correctly identified (after HotSync activation) as JE> > JE> > ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 JE> > ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 JE> > JE> > However, I still can't figure out how to sync, as dlpsh can't attach to JE> > /dev/ucom before activatyng Sync, and never goes to the shell prompt when JE> JE> shouldn't it be /dev/ucom0? JE> (assuming it exists) They both exist and have the same pair (major, minor). JE> > I had I/O errors and hangups with cheap MemoryStick reader before, JE> > but do not have it by hand to quick check. Hope to check tomorrow. JE> JE> I'll go ahead with the MFC but I'll JE> try handle these reports afterwards... Thanks again, I'll post MS reader testing results tonight (I'm at GMT+3 ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP.. USB MFC coming..
On Fri, 27 Feb 2004, Julian Elischer wrote: JE> I plan to commit the MFC at http://www.josef-k.net/freebsd/ JE> (the latest one) in the next couple of days. If you really care about JE> USB in 4.10 you might do well to test this on your equipment, JE> ESPECIALLY if you have unusual devices. Let me know of both successes JE> and failures please.. If I hear nothing I won't know if it's because JE> no-one tested it or it was just without problems.. JE> JE> Please also check these same devices without the patch BEFORE you let me JE> know of any failures so that we can tell if they are truely caused by JE> the patch.. Well, my main headache (SONY Clie SJ20) is now in a bit different state; before (at 4.9p1) it failed to attach with ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: init failed, STALLED device_probe_and_attach: ucom0 attach returned 6 ugen0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 now it is correctly identified (after HotSync activation) as ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 Controller /dev/usb0: addr 1: low speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 addr 2: low speed, self powered, config 1, Palm Handheld(0x0066), Palm, Inc.(0x054c), rev 1.00 However, I still can't figure out how to sync, as dlpsh can't attach to /dev/ucom before activatyng Sync, and never goes to the shell prompt when statring in the middle of sync process. Googling does not help much, unfortunately. Two other USB devices I have are USB Generic storage (CF reader and MP3 player), and they seem to keep work smoothly. I had I/O errors and hangups with cheap MemoryStick reader before, but do not have it by hand to quick check. Hope to check tomorrow. Thanks for your work! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Clarification needed on Handbook: Tracking for Multiple Machines
On Tue, 24 Feb 2004, Tony Frank wrote: [snip] TF> > > : If "True", for optimized code across all machines, the code should TF> > > : just be built on each machine, right? TF> > > That would give slightly better performance. However, it can be more TF> > > pain than it is worth if the number of machine types is high. TF> > Consuming considerably more time and disk space, a shell script to TF> > alter make.conf and rename /usr/obj between the build for each machine TF> > is doable, though pro'lly not worth it. The install at each each box TF> > would just have to mount it's corresponding /usr/obj tree. TF> TF> Just need to set __MAKE_CONF and MAKEOBJDIRPREFIX before running the build. Unfortunately not, as some utilities (from phase III) will be linked against existing system libraries. Or, you should follow the process like 'make release': build world with lower CPU optimization, intall it to the sandbox, chroot to it and build world again. This was explained by ru@ some months ago [1,2] [1]: http://www.geocrawler.com/archives/3/152/2002/5/0/8811539/ [2]: http://groups.google.com/groups?hl=ru&lr=&ie=UTF-8&inlang=ru&threadm=fa.f0qca6v.f7g49v%40ifi.uio.no&rnum=4&prev=/groups%3Fq%3Dfreebsd%2Bruslan%2Bermilov%2BCPUTYPE%2Bworld%2Bproblems%2Bwhen%2Brunning%2Bmake%26hl%3Dru%26lr%3D%26ie%3DUTF-8%26inlang%3Dru%26selm%3Dfa.f0qca6v.f7g49v%2540ifi.uio.no%26rnum%3D4 Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4-stable bug: comconsole and boot -a option
Dear colleagues, I found very strange bug. Actually, bug was introduced at running system with vinum root, when I did not succeed in mounting explicit root via `boot -a' prompt. I did a bit of research, and found that there is certainly a bug when comconsole is enabled: ad0: 7339MB [15907/15/63] at ata0-master UDMA33 Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:/dev/ad0s1e Mounting root from ufs:/dev/ad0s1a Look at two last lines. Input asked at vfs_mountroot_ask() did not used, possibly because kern/vfs_conf.c:gets() dit not actually read the input from comconsole. However, I'm not kernel hacker and looking at kern/tty_cons.c scares me a bit :) Should I file a PR for this? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: symlink: /home -> /usr/home vs. /home -> usr/home in default installation
On Fri, 23 Jan 2004, Andriy Tkachuk wrote: AT> The idea is this: if you mount your / to another AT> place (for example /mnt on another computer), your AT> /mnt/home will point to correct place (/mnt/usr/home) AT> instead of /usr/home. AT> AT> What do you, falks, think about this? FWIW, I'm making virtually every symlink relative instead of absolute for just this reason. (To be exact, more similar to Solaris' approach, so /sys -> ./usr/src/sys and /home -> ./usr/home) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where is FreeBSD going?
On Thu, 8 Jan 2004, Doug Rabson wrote: DR> I've been re-evaluating the current subversion over the last couple of DR> weeks and its holding up pretty well so far. It still misses the DR> repeated merge thing that p4 does so well but in practice, merging does DR> seem to be a lot easier than with CVS due to the repository-wide DR> revision numbering system - that makes it easy to remember when your DR> last merge happened so that you don't merge a change twice. DR> DR> The three main showstoppers for moving FreeBSD to subversion would be: DR> DR> 1. A replacement for cvsup. Probably quite doable using svnadmin DR>dump and load. DR> 2. Support for $FreeBSD$ - user-specified keywords are not supported DR>and won't be until after svn-1.0 by the looks of things. DR> 3. Converting the repository. This is a tricky one - I tried the DR>current version of the migration scripts and they barfed and died DR>pretty quickly. Still, I'm pretty sure that the svn developers DR>are planning to fix most of those problems. From mailing-list DR>archives, it appears that they are using our cvs tree as test DR>material for the migration scripts. For the third point, take a look at http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.71.763.tar.g The author uses FreeBSD repository as main test field ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where is FreeBSD going?
On Tue, 6 Jan 2004, Wes Peters wrote: WP> Programmers, system administrators, end users, and anyone else who wants WP> to contribute to FreeBSD are welcome to contribute in whatever way they WP> can. Anyone can file a PR about any aspect of the system they find WP> troubling, or delightful, or have a better way of doing. Strike up a WP> relationship with a committer or two (or twenty), let your ability and WP> willingness to work be known, and become a committer too. 400 or so of WP> your peers have already done it. [EMAIL PROTECTED]:~/FreeBSD> cat CVSROOT*/access* | sort -u | grep -c '^[a-z]' 327 While you're absolutely right with the whole pic, the mob of people currently wearing a commit bit is 25% smaller ;) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reward for fixing keyboard support in FreeBSD, apply within
On Sun, 7 Dec 2003, David Gilbert wrote: DG> While keyboard support on FreeBSD should be fixed, you might want to DG> take a look at ironsystems (ironsystem.com) offerings. They have DG> several different bladeservers from 8 to 16 nodes per chassy. In DG> particular, they have a 16-in-2-U (WOW). Unfortunately you have mistype the domain name, so here are correct URLs: http://www.ironsystems.com/ base URL http://www.ironsystems.com/products/iservers/uclass.htm blade solutions at large http://www.ironsystems.com/products/iservers/uclass/u9016.htm 16-at-2U Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rsync vs installworld
On Mon, 20 Oct 2003, M. Warner Losh wrote: MWL> : MWL> : Rsync doesn't deal with file flags (chflags(2)). Thus my personal MWL> : MWL> : preference for updating machines is making installworld on a file system MWL> : MWL> : exported by the build server. MWL> : MWL> MWL> : MWL> I'm looking for ways to avoid having NFS run on the network in MWL> : MWL> question at all. MWL> : MWL> : netpipe by dds@ then? The first drawback of course is that netpipe opens MWL> : back-connection which isn't good for strict firewalls, but I think this could MWL> : be avoided by inventing something like "passive netpipe" mode... MWL> MWL> I'm not familiar with this. Can you proivde a URL? It has been announced at -hackers@ a couple of months ago, and I successfully used it for remote backups. Now dds@ changed its names, and I suppose I should take a closer look at it again. http://www.spinellis.gr/sw/unix/socketpipe/ Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rsync vs installworld
On Mon, 20 Oct 2003, M. Warner Losh wrote: MWL> In message: <[EMAIL PROTECTED]> MWL> Helge Oldach <[EMAIL PROTECTED]> writes: MWL> : Rsync doesn't deal with file flags (chflags(2)). Thus my personal MWL> : preference for updating machines is making installworld on a file system MWL> : exported by the build server. MWL> MWL> I'm looking for ways to avoid having NFS run on the network in MWL> question at all. netpipe by dds@ then? The first drawback of course is that netpipe opens back-connection which isn't good for strict firewalls, but I think this could be avoided by inventing something like "passive netpipe" mode... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rsync vs installworld
On Mon, 20 Oct 2003, Peter Pentchev wrote: [snip] PP> > > make buildworld PP> > > make installworld DESTDIR=/big/disk/freebsd/image PP> > > make mergemaster -D /big/disk/freebsd/mergemaster PP> > > PP> > > And then on each machine I want to update I'd do something like: PP> > > PP> > > sudo rsync --exclude etc --exclude usr/local --exclude boot \ PP> > > --delete -av host-server:/big/disk/freebsd/image / PP> > > sudo rm -rf /tmp/mergemaster PP> > > sudo scp host-server:/big/disk/freebsd/mergemaster /tmp/mergemaster PP> > > sudo mergemaster -someargs [snip] PP> Errr, isn't this pretty much what Colin Percival's PP> security/freebsd-update port already does? :) Take a look at PP> http://www.daemonology.net/freebsd-update/ - this might be exactly what PP> you are looking for... Nope, because: - security/freebsd-update does not handle ports at all - it is only for security branches and so does not fit in the case of locally patched system Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB keyboard thoughts.
On Sat, 27 Sep 2003, David Gilbert wrote: DG> Dmitry> On Fri, 26 Sep 2003, David Gilbert wrote: DG> DG> I acquired my first motherboard that does not have ps/2 keyboard DG> DG> and mouse connectors on it this week. It's a funny thing DG> DG> ... because a keyboard connector seems to be all it doesn't have. DG> DG> It has 6 ide channels, digital audio, firewire and 6 USB ports. DG> DG> Dmitry> Out of curiosity, who is the vendor and what is model no? DG> DG> I was going for cheap. I found a Belkin keyboard at the local shop DG> for $28 Cdn. I don't remember a model number on it, but other than DG> having both USB and ps/2 connectors, it was a fairly normal keyboard. Ughm, I meant mobo vendor/model ;-) DG> Actually... it sucks in one way. I'm a fairly quick touch typist, but DG> I've never trained on an underwood. This belkin seems to simulate the DG> underwood in that if you arn't careful enough to raise your fingers DG> off a key before pressing the next, you get extra characters on the DG> screen. PR kern/57273 ? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB keyboard thoughts.
On Fri, 26 Sep 2003, David Gilbert wrote: DG> I acquired my first motherboard that does not have ps/2 keyboard and DG> mouse connectors on it this week. It's a funny thing ... because a DG> keyboard connector seems to be all it doesn't have. It has 6 ide DG> channels, digital audio, firewire and 6 USB ports. [snip] Out of curiosity, who is the vendor and what is model no? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if bpf fd's select()able?
On Mon, 8 Sep 2003, Lev Walkin wrote: LW> > However, I found a (really stupid, yeah) bug: the first parameter of select() LW> > in this test case should be fd+1, not 1 ;-) LW> LW> Unfortunately, this could not possibly be the case, if your system's LW> documentation is in sync with the reality: LW> LW> === select(2) === LW> For historical reasons, LW> select() will always examine the first 256 descriptors. LW> === cut === Well, I suppose either this part of the documentation is obsolete, or something else went wrong, but: this select() works with fd+1 on both 4.8-R and 4.9-PRE, and does not work with both 1 and fd as nfd. I check the fd to be 3 in all cases. I did not dig into select() sources yet, though. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if bpf fd's select()able?
On Mon, 8 Sep 2003, Lev Walkin wrote: [snip] LW> > LW> Yes, you're missing the interactive mode. LW> > LW> Refer to BIOCIMMEDIATE in the bpf(4) manual page. LW> > LW> > Unfortunately not ;-) LW> LW> Fortunately, yes. LW> LW> > if (ioctl(fd, BIOCPROMISC, NULL) == -1) LW> > err(1, "can't set promisc mode"); LW> > if (ioctl(fd, BIOCIMMEDIATE, &yes) == -1) LW> > err(1, "can't set IMMEDIATE mode"); LW> LW> Are you sure that "yes" variable holds the truth value? Yes. Just attaching file from wrong directory. However, I found a (really stupid, yeah) bug: the first parameter of select() in this test case should be fd+1, not 1 ;-) Thanks for the fresh look ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if bpf fd's select()able?
On Mon, 8 Sep 2003, Peter Pentchev wrote: PP> On Sun, Sep 07, 2003 at 04:04:49PM -0700, Lev Walkin wrote: PP> > Dmitry Morozovsky wrote: PP> > >Dear colleagues, PP> > > PP> > >[all below is for 4-STABLE] PP> > > PP> > >I'm trying to write effective arp scanner for multi-interface router (esp. PP> > >multi-vlan); I plan to use multiple bpf devices attached to different PP> > >interfaces emitting ARP requests and filters listening to ARP replies; the PP> > >most PP> > >natural way to multiplex them for me is select(). PP> > > PP> > >However, my tests show that select()ing bpf fd does not lead to trigger PP> > >packets PP> > >available to bpf filter; the process hangs in select state while parallel PP> > >tcpdump process shows packets desired *and* is in bpf state. PP> > > PP> > >Am I missing something "base"? References (surely, I'd already read PP> > >manpages for bpf, pcap and related -- but did I still missed something PP> > >serious?) would be greatly appreciated. PP> > PP> > Yes, you're missing the interactive mode. PP> > PP> > Refer to BIOCIMMEDIATE in the bpf(4) manual page. PP> PP> Also, I believe that for a month or so bpf devices have been able to PP> issue kqueue notifications, too, so - at least for FreeBSD - the "most PP> natural" way might now be kqueue() and not select() :) Thanks Peter, I'm aware of these recent changes; however, I plan to support at least one or two previous security branches, so kqueue ()is not the first option for me. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if bpf fd's select()able?
On Sun, 7 Sep 2003, Lev Walkin wrote:
LW> > [all below is for 4-STABLE]
LW> >
LW> > I'm trying to write effective arp scanner for multi-interface router (esp.
LW> > multi-vlan); I plan to use multiple bpf devices attached to different
LW> > interfaces emitting ARP requests and filters listening to ARP replies; the most
LW> > natural way to multiplex them for me is select().
LW> >
LW> > However, my tests show that select()ing bpf fd does not lead to trigger packets
LW> > available to bpf filter; the process hangs in select state while parallel
LW> > tcpdump process shows packets desired *and* is in bpf state.
LW> >
LW> > Am I missing something "base"? References (surely, I'd already read
LW> > manpages for bpf, pcap and related -- but did I still missed something
LW> > serious?) would be greatly appreciated.
LW>
LW> Yes, you're missing the interactive mode.
LW> Refer to BIOCIMMEDIATE in the bpf(4) manual page.
Unfortunately not ;-)
My test program chich I suppose should catch any ARP packets around
attached.
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* bpf FSM to filter only ARP requests */
/*
struct bpf_insn insns[] = {
BPF_STMT(BPF_LD+BPF_H+BPF_ABS, ETHER_ADDR_LEN*2),
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_ARP, 0, 3),
BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 20),
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ARPOP_REQUEST, 0, 1),
BPF_STMT(BPF_RET+BPF_K, sizeof(struct ether_arp) +
sizeof(struct ether_header)),
BPF_STMT(BPF_RET+BPF_K, 0),
};*/
struct bpf_insn insns[] = {
BPF_STMT(BPF_LD+BPF_H+BPF_ABS, ETHER_ADDR_LEN*2),
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_ARP, 0, 1),
BPF_STMT(BPF_RET+BPF_K, sizeof(struct ether_arp) +
sizeof(struct ether_header)),
BPF_STMT(BPF_RET+BPF_K, 0),
};
struct bpf_program bpf_arpreply = {
sizeof(insns) / sizeof(struct bpf_insn),
insns
};
#define BUFSZ 4096
static char buf[BUFSZ];
int main(int argc, char *argv[])
{
int fd, sz;
u_int yes;
char *bpfn, *ifname;
fd_set fds;
struct ifreq ifr;
bpfn = "/dev/bpf1";
ifname = "rl0";
if ((fd = open(bpfn, O_RDWR)) == -1)
err(1, "can't open %s", bpfn);
strncpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name));
if (ioctl(fd, BIOCSETIF, &ifr) == -1)
err(1, "can't attach to %s", ifname);
if (ioctl(fd, BIOCSETF, &bpf_arpreply) == -1)
err(1, "can't set ARP reply filter");
if (ioctl(fd, BIOCPROMISC, NULL) == -1)
err(1, "can't set promisc mode");
if (ioctl(fd, BIOCIMMEDIATE, &yes) == -1)
err(1, "can't set IMMEDIATE mode");
FD_ZERO(&fds);
FD_SET(fd, &fds);
while (select(1, &fds, NULL, NULL, NULL) != -1) {
/* FD_ISSET(fd, fds) is always 1 here */
printf("we have packet to read!");
sz = read(fd, buf, BUFSZ);
printf(" its len is %d bytes!\n", sz);
}
close(fd);
return 0;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
if bpf fd's select()able?
Dear colleagues, [all below is for 4-STABLE] I'm trying to write effective arp scanner for multi-interface router (esp. multi-vlan); I plan to use multiple bpf devices attached to different interfaces emitting ARP requests and filters listening to ARP replies; the most natural way to multiplex them for me is select(). However, my tests show that select()ing bpf fd does not lead to trigger packets available to bpf filter; the process hangs in select state while parallel tcpdump process shows packets desired *and* is in bpf state. Am I missing something "base"? References (surely, I'd already read manpages for bpf, pcap and related -- but did I still missed something serious?) would be greatly appreciated. Thanks for your time, as always. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sparse files from shell [Re: file size different from ls to du]
On Tue, 29 Jul 2003, Joshua Oreman wrote:
[snip]
JO> Usually programs will manage their own sparse files; it's something hard
JO> to do at the shell.
dd is your friend.
These commands make sparse file of some ks physical and 1g logical:
VNFILE=/tmp/sparsefile
VNSZ=$((1024*1024))
dd if=/dev/zero of=${VNFILE} bs=1k count=1 seek=$((${VNSZ} - 1))
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
----
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mounting
On Mon, 23 Jun 2003, Robert Watson wrote:
RW> > Can nodev also be added to all above + /usr?
RW>
RW> nodev prevents opening specfs character devices, but doesn't prevent
RW> opening fifos or UNIX domain sockets, so is generally fine for all file
RW> systems except /dev. The common exceptions I bump into are:
RW>
RW> (1) If you have per-user chroots, make sure wherever their custom /dev is
RW> isn't nodev.
Maybe my experience would be useful for the community:
I've successfully use mfs under 4.x for chroot/jailed environment, created via
JDEV=/ar/J/j224/dev
mount_mfs -s 256 -i 768 -o nosuid /dev/ad0s1b ${JDEV} > /dev/null 2>&1
cd ${JDEV}
sh /dev/MAKEDEV std pty0
rm mem kmem pci io klog console
ln -sf null mem
ln -sf null kmem
ln -sf null console
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD-specific CVS: tagexpand question
On Thu, 13 Mar 2003, Tony Finch wrote:
TF> >Is there any way to tune FreeBSD-specific CVS (with CVSROOT/options support) to
TF> >provide the following functionality:
TF> >- ident keyword should be standard ($ Id $)
TF> >- it should be expanded as ($ CVSHeader $) to repo-relative path
TF>
TF> Why do you want to do that? It seems like a bad idea to me -- you should
TF> keep the semantics of CVS keywords constant, and you should keep per-
TF> project keywords as distinctive as possible to avoid clashes as source
TF> moves around.
Well, AFAIThink the semantics do not change -- just extends a bit, and
thus allow to be extensively checked for example by FreeBSD-styled CVSROOT
scripts like commit_prep.pl
BTW, I've written a little patch to CVS similar to peter's patches: it adds
idexpmode options to CVSROOT/options -- attached just in case anyone
interested.
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
# $Id: FreeBSD/Patches/cvs-idexpmode.patch,v 1.1 2003/03/13 12:53:15 marck Exp $
#
#-DSC-# idexpmode option for CVS
This patch adds new option for cvs. You can specify idexpmode=
in CVSROOT/options admin file to select $ Id $ RCS keyword expansion mode.
MODE may be on of the following:
Id last path component; default
Header full path including repository root
CVSHeader path relative to repository root
Index: contrib/cvs/src/main.c
===
RCS file: /home/ncvs/src/contrib/cvs/src/main.c,v
retrieving revision 1.18.2.4
diff -u -r1.18.2.4 main.c
--- contrib/cvs/src/main.c 19 Dec 2002 21:17:56 - 1.18.2.4
+++ contrib/cvs/src/main.c 13 Mar 2003 12:26:14 -
@@ -1244,6 +1244,12 @@
rcs_incexc = buf + 10;
RCS_setincexc(rcs_incexc);
}
+ if (!strncmp(buf, "idexpmode=", 10)) {
+ char *rcs_idexpmode;
+
+ rcs_idexpmode = buf + 10;
+ RCS_setidexpmode(rcs_idexpmode);
+ }
/*
* OpenBSD has a "umask=" and "dlimit=" command, we silently
* ignore them here since they are not much use to us. cvsumask
Index: contrib/cvs/src/rcs.c
===
RCS file: /home/ncvs/src/contrib/cvs/src/rcs.c,v
retrieving revision 1.19.2.5
diff -u -r1.19.2.5 rcs.c
--- contrib/cvs/src/rcs.c 21 Jan 2003 22:26:44 - 1.19.2.5
+++ contrib/cvs/src/rcs.c 13 Mar 2003 12:26:14 -
@@ -3519,6 +3519,7 @@
KEYWORD_LOCALID
};
enum keyword keyword_local = KEYWORD_ID;
+enum keyword keyword_idexmode = KEYWORD_ID;
/* Convert an RCS date string into a readable string. This is like
the RCS date2str function. */
@@ -3757,11 +3758,15 @@
old_path = NULL;
if (kw == KEYWORD_HEADER ||
(kw == KEYWORD_LOCALID &&
-keyword_local == KEYWORD_HEADER))
+keyword_local == KEYWORD_HEADER) ||
+ (kw == KEYWORD_ID &&
+keyword_idexmode == KEYWORD_HEADER))
path = rcs->path;
else if (kw == KEYWORD_CVSHEADER ||
(kw == KEYWORD_LOCALID &&
- keyword_local == KEYWORD_CVSHEADER))
+ keyword_local == KEYWORD_CVSHEADER) ||
+(kw == KEYWORD_ID &&
+ keyword_idexmode == KEYWORD_CVSHEADER))
path = getfullCVSname(rcs->path, &old_path);
else
path = last_component (rcs->path);
@@ -8627,6 +8632,25 @@
error(1, 0, "Unknown LocalId mode: %s", key);
}
free(copy);
+}
+
+void
+RCS_setidexpmode (arg)
+const char *arg;
+{
+char *key;
+
+key = xstrdup(arg);
+if (!strcmp(key, keywords[KEYWORD_ID].string))
+ keyword_idexmode = KEYWORD_ID;
+else if (!strcmp(key, keywords[KEYWORD_HEADER].string))
+ keyword_idexmode = KEYWORD_HEADER;
+else if (!strcmp(key, keywords[KEYWORD_CVSHEADER].string))
+ keyword_idexmode = KEYWORD_CVSHEADER;
+else
+ error(1, 0, "Unknown id expand mode: %s", key);
+
+free(key);
}
void
Index: contrib/cvs/src/rcs.h
===
RCS file: /home/ncvs/src/contrib/cvs/src/rcs.h,v
retrieving revision 1.7.2.4
diff -u -r1.7.2.4 rcs.h
--- contrib/cvs/src/rcs.h 19 Dec 2002 21:17:56 -
Re: FreeBSD-specific CVS: tagexpand question
Following up to myself: On Wed, 12 Mar 2003, Dmitry Morozovsky wrote: DM> Is there any way to tune FreeBSD-specific CVS (with CVSROOT/options support) to DM> provide the following functionality: DM> DM> - ident keyword should be standard ($ Id $) DM> - it should be expanded as ($ CVSHeader $) to repo-relative path looking at rcs.c:3750+ it seems to me that exactly this functionality can't be achieved without really ugly hacks. Or, am I overlooking something really simple? As always, thanks for cooperation. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD-specific CVS: tagexpand question
Colleagues, I'm not sure this is the most correct place to ask, but it at least seems so. Is there any way to tune FreeBSD-specific CVS (with CVSROOT/options support) to provide the following functionality: - ident keyword should be standard ($ Id $) - it should be expanded as ($ CVSHeader $) to repo-relative path Looking at cvs sources and peter's changes aroute versions 1.4-1.5 has not enlightened me enough, unfortunately. Any help will be greatly appreciated. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying mergemaster behavior
On Mon, 3 Feb 2003, Doug Barton wrote:
[snip]
DB> > -I '$FreeBSD:.*$'
DB> > to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to have
DB> > worked the way I wanted it to work.
DB>
DB> What do you think mm should do if the only diff between two files is the
DB> cvs ID? This comes up inside a branch if a change is checked in, then
DB> backed out. Of course, it happens a lot when upgrading from 4 to 5 for
DB> example.
Moreover, and possibly much more frequent, when upgrading between security
branches of -stable, e.g. RELENG_4_6 -> RELENG_4_7
Not that it were major PITA, but avoiding it would simplify our lives ;-)
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
On Sun, 19 Jan 2003, Darren Pilgrim wrote:
[snip-a-bit]
DP> > By the way, is (moderately complex) aggregated rule faster than mix of simple
DP> > rules? (for now, we drop accounting issues)
DP> >
DP> I'm not sure if the {a.b.c.0/24 or e.f.g.0/20} part is valid, but in theory
DP> this rule should require fewer ops on average than 8 seperate rules. What I
DP> meant when I said aggregate is that if you have a contiguous block of IPs,
DP> say 1.2.3.1 through 1.2.3.63, most need ports 22, 25, 80, and 443 open, then
DP> create one rule:
DP>
DP> pass tcp from any to 1.2.3.0/26 22,25,80,443
Yeah, I suppose we both got the point ;-)
The only side note I have for now is: it would be _extremely_ useful to
describe firewall tuning either in firewall.7 or security.7 or even excplicit
manpage as well as bring it under attention into the Handbook. However, not
being native speaker and/or kernel deep-knowledge-man, /me just silently
crouches into his corner ;-)
Anyway, thank you all the Crew and congrats for 5.0 releasing!
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
On Thu, 16 Jan 2003, Darren Pilgrim wrote:
DP> There is sorting that you can do, like putting the highest-traffic rules
DP> near the top. ipfw terminates the search on the first matching rule except
DP> for count and skipto. Also, the fewer items that have to be checked the
DP> faster the rule is. Perhaps there is some aggregation that can be done with
DP> the rules themselves?
By the way, is (moderately complex) aggregated rule faster than mix of simple
rules? (for now, we drop accounting issues)
So, will
permit tcp from {a.b.c.0/24 or e.f.g.0/20} to any 22,25,80,443 setup
perform measurably better than set of 8 corresponding rules?
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd running on a cdrom
On Sun, 5 Jan 2003, Wilko Bulte wrote: WB> On Sun, Jan 05, 2003 at 02:27:58PM +0300, Dmitry Morozovsky wrote: WB> > On Sun, 5 Jan 2003, Wilko Bulte wrote: WB> > WB> > WB> > Well, while I'd certainly agree with you regarding reliability (BTW, how many WB> > WB> > _read_ cycles do contemporary flashdisks support?), there is at least one major WB> > WB> > question: where to boot from? especially in the case of standalone WB> > WB> > moving-parts-free router ;-) WB> > WB> WB> > WB> You can boot from CompactFlash cards, they behave like IDE drives. WB> > WB> > Aha, that makes sense... But then, I suppose, one needs some IDE<->CF WB> > converting device... Would you point me to the resources 'bout them? WB> WB> http://www.tapr.org/tapr/html/Fcfa.html WB> WB> is what I have. Just remember one thing: in IDE-mode the CF cards can WB> *not* be hotplugged! Yeah, thanks, just have found some at Google. Unfortunately, none of these devices seem to be easily available here in RU, but we'll try to workaround this ;-) Hotplug unavailability is not of great sense since in situation described CF would be the only ATAPI device in whole system. Thanks again for your help. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd running on a cdrom
On Sun, 5 Jan 2003, Wilko Bulte wrote: WB> > Well, while I'd certainly agree with you regarding reliability (BTW, how many WB> > _read_ cycles do contemporary flashdisks support?), there is at least one major WB> > question: where to boot from? especially in the case of standalone WB> > moving-parts-free router ;-) WB> WB> You can boot from CompactFlash cards, they behave like IDE drives. Aha, that makes sense... But then, I suppose, one needs some IDE<->CF converting device... Would you point me to the resources 'bout them? I'm interested much as this scheme would allow us to build cheap and reliable remote routers at deep'n'far corners of our residential networks... You know, usually in totally unmaintainable corners ;-) Thanks in advance. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd running on a cdrom
On Sun, 5 Jan 2003, M. Warner Losh wrote: MWL> : CD-ROM is not what I would call a reliable media. May I suggest MWL> : booting from the network (PXE) or booting from a hard disk and MWL> : mounting the partitions read-only? MWL> MWL> It is usually the case that solid-state media, properly configured, is MWL> more reliable. CF cards have a TrueIDE mode that allows them to be MWL> accessed as a disk on the IDE bus. Timing Solutions uses this MWL> technology in all its embedded systems and we've noticed a huge MWL> reduction in RMAs from the previous generation of systems with IDE MWL> hard disks in them. MWL> MWL> I'd suspect that cdrom drives will break more often than hard disks in MWL> harsh environments. Well, while I'd certainly agree with you regarding reliability (BTW, how many _read_ cycles do contemporary flashdisks support?), there is at least one major question: where to boot from? especially in the case of standalone moving-parts-free router ;-) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading rc.conf from C programs?
On Thu, 2 Jan 2003 [EMAIL PROTECTED] wrote:
> I mean, I may certainly be missing something here, but I've never noticed
> rc.conf be anything other than a left hand value and a right hand value (often
> enclosed in quotes), with both sides being separated by an equal sign.
Nope. From our jail machine:
ALIASBASE=96
ALIASCNT=16
ALIASNO=0
while [ ${ALIASNO} -lt ${ALIASCNT} ]; do
ALIASLAST=`expr ${ALIASBASE} + ${ALIASNO}`
eval "ifconfig_rl0_alias${ALIASNO}='195.XX.YY.${ALIASLAST}/32'"
ALIASNO=`expr ${ALIASNO} + 1`
done
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: CVS_LOCAL_BRANCH_NUM?
On Tue, 10 Dec 2002, Lamont Granquist wrote: LG> >From the man page, I'm not really sure where it makes a difference other LG> than when someone is playing with IFS, but $@ seems to be more of what I LG> intended... Please note quotes explicitly, "$@" is really needed where your parameters contain spaces (bad practice in filenames, yeah, but don't make yourself another one PITA you can avoid ;-P ) LG> And in case anyone is still reading this now, I'd like to throw out the LG> suggestion that CVS_LOCAL_BRANCH_NUM should really be an option to cvs LG> rtag and should thereby be settable in one's .cvsrc file and the option LG> should get transmitted to the cvs pserver, eliminating the kind of LG> asymmetry I just documented. I do agree; however, as cvs is a contributed software, this should be discussed and/or reported via cvsbug(8). [snip] Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CVS_LOCAL_BRANCH_NUM?
On Mon, 9 Dec 2002, Lamont Granquist wrote: LG> I finally figured this out. To use CVS_LOCAL_BRANCH_NUM with a cvs LG> pserver you need to have the environment variable set server-side. That LG> means something like invoking a wrapper from inetd which sets the LG> environment variable and the calls cvs. LG> LG> Completely undocumented behavior and not terribly transparent. LG> LG> I'm working on some instructions at: LG> LG> http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html A little comment: - 8< - wrapper #!/bin/sh export CVS_LOCAL_BRANCH_NUM=1000 /usr/bin/cvs $* - 8< - Don't you think the last parameter should be "$@" ? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: maxusers and random system freezes
On Mon, 9 Dec 2002, Varshavchick Alexander wrote: VA> the server went to a swap, because it occurs practically instantly, and VA> this state goes for hours. The system is lacking some resources, or may be VA> a bug somewhere, can you give any hints to it? Hmm, what about logging vmstat/pstat/netstat -m/sysctl vm ? Possibly to remote machine via remote syslog? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shared files within a jail
On Tue, 12 Nov 2002, Hans Zaunere wrote:
HZ> After much searching and contemplation, I've decided to ask the
HZ> question directly:
HZ>
HZ> I'm implementing a jail server, which will provide a very limited set
HZ> of resources (Apache/MySQL/PHP). Setup is going well, however I've run
HZ> into a little snag that I hope can be worked out.
HZ>
HZ> I want to allow the users the ability to compile and use their own
HZ> instances of Apache and MySQL from within the jail. But instead of
HZ> duplicating the basic system libs and bins, I'd like to maintain a
HZ> single repository of this, which can then be read-only from within the
HZ> jail. Options:
HZ>
HZ> -- Symlinks won't work because of the chroot.
HZ> -- Mounts from within the jail aren't allowed, plus a single partition
HZ> can't be mounted multiple times, AFAIK.
HZ> -- I don't have NFS setup, and I would like to avoid it as much as
HZ> possible.
HZ> -- mount_null seems to be the answer, however the warning at the end of
HZ> the man page is scary.
HZ>
HZ> Is there any combination of these (or anything I'm forgetting) that
HZ> could help me here? Is mount_null stable?
HZ>
HZ> I've had an account on a jail server which had /shared visible within
HZ> the jail, and symlinks to /bin, /usr/lib and such. I'm not sure how
HZ> this was actually implemented, and I'd be interested if anyone has seen
HZ> or heard of any solutions to this type of problem.
I did multiple sets of
null:/shared/J/usr /J/jailNN/usr
procfs /J/jailNN/proc
mfs:48k/J/jailNN/dev
with a bit of tweaking such as:
/bin and /sbin moved to ${JHOME}/usr/Rbin and /Rsbin and symlinked,
/usr/home and /usr/local have moved out to jail home and symlinked
for standard jail there as also useful mount such as
null:/shared/J/local /J/jailNN/local
... and it at least seems workable for some ten to twenty jails on a moderately
powerful (1g5 Athlon with 512M of memory) machine. All jails are rather
lightweight (have only Apaches/PHP besides base system) though.
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: old way of compiling kernel
On Fri, 8 Nov 2002, Alessandro de Manzano wrote: AdM> I'm using FreeBSD in production since 3 years but I've a little question AdM> I would ask since then: AdM> AdM> _exactly_ why on a freshly installed system (no cvsup, no build AdM> anything) to compile just the kernel I must use the "old way" (1) and AdM> can't use new way (2) ? AdM> AdM> I've been told I can use (2) only after at least one "make buildworld", AdM> not on a vergin system. AdM> AdM> I'm looking for a detailed explanation, technical deep :) AdM> AdM> Someone could, please, enlight me ? :-) Just because way (2) uses config/compile/build environment from /usr/obj/..., not from the installed base system. I think some Makefile magic could be done to make second way useable in case of nonexistent /usr/obj/..., but this question should be directed to ru@, I suppose (and do not expect he would not be angry 'cause of this! ;-) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Building ports into packages, outside of /usr/ports
On Thu, 8 Aug 2002, Bruce M Simpson wrote: BMS> Has anybody thought about hacking the above to support building packages BMS> outside of the ports tree, and without installing them? Strikes me as BMS> something that could be neatly solved with judicious use of chroot(1). BMS> BMS> This is something which was raised at the FreeBSD UK Users Group meeting BMS> last night, so it's bugging me. Hmm, did you look at /usr/ports/Tools/portbuild and /usr/ports/Tools/scripts/release ? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -fomit-frame-pointer for the world build
On Fri, 2 Aug 2002, Bakul Shah wrote: BS> > I tried to build some binaries with -fomit..., then tried to debug it a BS> > bit, and gdb shows me both backtrace stack and arguments, so I was in BS> > doubt a bit -- so here is my question ;-) BS> BS> I can answer that. Consider the following two functions: [snip very descriptive answer] Thanks Bakul, you'd give me a light. ;-) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -fomit-frame-pointer for the world build
On Fri, 2 Aug 2002, Terry Lambert wrote: TL> Dmitry Morozovsky wrote: TL> [ ... -fomit-frame-pointer ... ] TL> > Yes, Terry, I'd read this note. However, it does not clarify for me which TL> > exactly functionality is lost with omitting this. TL> > TL> > I tried to build some binaries with -fomit..., then tried to debug it a TL> > bit, and gdb shows me both backtrace stack and arguments, so I was in TL> > doubt a bit -- so here is my question ;-) TL> TL> Try it again on a SPARC or other RISC machine that pushes TL> register window frames on the stack after a certain function TL> call depth is achieved. TL> TL> I was pretty sure at one time that the PPC platform had a TL> variant of this problem, as well. Well, this clarifies much more than I test -- the only platform I tried to check this was i386. TL> If you want a definative answer, then the people to ask are TL> the GCC implementors, who put the option into the compiler TL> for a reason, and added the descriptive text to the .info TL> file in the first place. I didn't doubt it ;-) TL> Realize that this is a GCC issue, not a FreeBSD issue. What's the issue? Existence of -fomit... option? ;-) Actually, I was not specific enough in my initial question. It should sound something like: I presume building FreeBSD RELENG_4 world on i386 with -fomit-frame-pointer may lead to some undesired effects. But I neither found them in my (not so deep though) tests nor read info about it except GCC-info's note that you cite. 8-12% of code efficiency is not too small... Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -fomit-frame-pointer for the world build
On Fri, 2 Aug 2002, Terry Lambert wrote: TL> > What are the drawbacks of building FreeBSD with -fomit-frame-pointer? As TL> > far as I can see, it saves both space (which is not as worth as disk space TL> > got cheaper and cheaper) and execution time (which is, AFAICC, more TL> > important). TL> > TL> > I'd already done some tests, but not really deep. TL> > TL> > Would you please clarify this issue abit, or point me to any articles TL> > describing exact -fomit-frame-pointer behaviour? TL> TL> The frame pointer is used for debugging, specifically for the TL> stack traceback function to know arguments. Removing it means TL> losing some debugging functionality. Next time try "info gcc": TL> TL> `-fomit-frame-pointer' TL> Don't keep the frame pointer in a register for functions that TL> don't need one. This avoids the instructions to save, set up and TL> restore frame pointers; it also makes an extra register available TL> in many functions. *It also makes debugging impossible on some TL> machines.* TL> TL> On some machines, such as the Vax, this flag has no effect, because TL> the standard calling sequence automatically handles the frame TL> pointer and nothing is saved by pretending it doesn't exist. The TL> machine-description macro `FRAME_POINTER_REQUIRED' controls TL> whether a target machine supports this flag. *Note Registers::. Yes, Terry, I'd read this note. However, it does not clarify for me which exactly functionality is lost with omitting this. I tried to build some binaries with -fomit..., then tried to debug it a bit, and gdb shows me both backtrace stack and arguments, so I was in doubt a bit -- so here is my question ;-) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
-fomit-frame-pointer for the world build
Hello there colleagues, I'd tried to search thru the web, but did not succeed enough. What are the drawbacks of building FreeBSD with -fomit-frame-pointer? As far as I can see, it saves both space (which is not as worth as disk space got cheaper and cheaper) and execution time (which is, AFAICC, more important). I'd already done some tests, but not really deep. Would you please clarify this issue abit, or point me to any articles describing exact -fomit-frame-pointer behaviour? Thank you in advance. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: swap & huge mem systems
On Tue, 9 Jul 2002, Terry Lambert wrote: TL> > So, if someone wants to get really quick swap and allocates 4 partitions TL> > on 4 drives *AND* also wand to get crashdumps, (s)he has to do this TL> > suboptimally (either allocate 1st more sized than phys RAM and other much TL> > smaller, or allocate approx 4 x phys RAM)? TL> > TL> > Then, the question: which technique is preferrable? TL> TL> You don't have to dump on your swap. It's just convenient to do. TL> You can actually dump on any raw partition which is large enough. TL> TL> If FreeBSD intrinsically handled "suspend to disk", then you would TL> need something seperate from swap, anyway. Yeah, this makes sense. Thank you for clarification. Hope StD feature will appear soon in -current (at least one of my friends would be *extremely* happy with this on his notebook). Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: swap & huge mem systems
On Tue, 9 Jul 2002, Erik Trulsson wrote: ET> > BTW, is it safe to create _interleaved_ swap totally sized slightly above ET> > the amount of physical RAM? I mean, is core writer interleve-aware, or ET> > does it need the first swap partiton large enough? ET> ET> The coredumping code does not know about interleaved swap. It just uses ET> a single swap partition which must be large enough. ET> Read the dumpon(8) manpage for more information. Yeah, I see (overlooked this somehow, sorry for the dumb question ;) So, if someone wants to get really quick swap and allocates 4 partitions on 4 drives *AND* also wand to get crashdumps, (s)he has to do this suboptimally (either allocate 1st more sized than phys RAM and other much smaller, or allocate approx 4 x phys RAM)? The, the question: which technique is preferrable? Sidenote: Yes, I'm aware that in "normal case" machine should not swap at all, but consider something like multi-user machine which is *normally* does not swap but need to adopt high peaks in load. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
