Re: FreeBSD 7 on old SMP server?
Brian [EMAIL PROTECTED] wrote: Joshua Coombs wrote: For a very short while with 6.0 I was tweaking the kernel to detect 386s as 486s, as well as using CPU_DISABLE_CMPXCHG and having ok luck. I've now got a Cyrix 486DrX-2 66 installed in place of my Am386DX-40, which supports CMPXCHG as well as ID'ing as a 486 so I don't need to do any tweaking to stay running. If I can get another viable 386DX box reassembled I'll see if 7 can be pressed into functioning on it as 6 could. Would that be a multiday buildworld? I would certainly be wise to perform the buildworld on a faster machine and only do the installworld on the slow one. ALternatively, install directly on the slow machines disk if you can plug it into the fast one temporarily. By the way, I don't think that omitting -pipe helps that much on a machine that is really low on memory. It only separates the preprocessor and assembly stages from the main compilation, but it is the main compilation which is the actual memory hog (at least with gcc 4.2) due to the code optimization. Of course, omitting -pipe might help a little, but don't hold your breath. It might help much better to reduce the optimization level from the default -O2 to -O1 (in addition to omitting -pipe). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7 on old SMP server?
Joshua Coombs wrote: MaXX wrote: I have an old netfinity 7000 (Quad PIII 500, 1Gb RAM) running 6.2 at the moment. I was wondering if it will take benefit of all the SMP improvement of 7 or is it too old? It runs a few postgresql databases, peak loads in the 2 to 4 range. It's not too old, and I would recommend that you give 7.0 a try. Don't forget to enable the ULE scheduler. I've got a dual Celeron-466 with 448 MB RAM, and it's certainly not too old, either. (OK, Celerons aren't the best processor to build an SMP system, but it does work nicely for me. And it was dead cheap for an SMP system at the time when I built it, about 10 years ago.) My hacked up 386 showed gains going from 6.2 to 7, the big win that I've noticed is scp throughput, I can sustain 40 to 45kbps where in the past the box walled at around 30kbps. Apache seems to have less latency responding to gets also. I'm just running a 7b3 kernel at the moment, I'm going to have to repartition with a lot more swap space to be able to build a 7 world (When did the ram use for a buildworld skyrocket?!) but even with this setup, 7 + ULE is a win for me. Are you saying you run FreeBSD 7 on an 80386(SX/DX) machine? How exactly did you hack it? As far as I know, support for 80386 processors was removed from FreeBSD a while ago. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0BETA4 /usr/src/gnu/usr.bin/cc/cc_int Thrashes
Julian Stacey wrote: Has 7.0-BETA4 perhaps wrongly got a -pipe in the .mk macros ? It was added 9 years 7 months ago my JKH (see the CVS repository, src/share/mk/sys.mk rev 1.31). He wrote: Add -pipe to default CFLAGS. The optimization it provides is cheap and does not require any special action on the part of the user to take advantage of it. It might not be that cheap anymore with gcc 4.2 being the default compiler now, known to be somewhat more RAM- hungry than its predecessors. However, I still think that -pipe should be kept on by default, because it will help on the vast majority of machines. Old machines with very little RAM need some special-tuning anyway, so it's reasonable to give them special CFLAGS that don't contain -pipe. (Apart from that I would recommend to use a faster and sufficiently RAM-equipped machine for building and then perform only the install on the smaller machine, or install directly on its harddisk by plugging it into the faster machine temporarily. That's how I used to update an old 486SX notebook that had only 4 MB RAM and no network except SLIP/PLIP.) YMMV, of course. Please take the above only as my personal opinion on the matter. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code (taken from comp.lang.awk FAQ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jlogin.sh - a small nice jails helper!
Miroslav Lachman wrote:
It is nice idea, but I think you should have a better scripting style ;)
Yes, it almost looked like perl. :-)
May I suggest a few further improvements?
login_shell=/bin/tcsh
I certainly wouldn't want tcsh. How about looking at
$SHELL, and if it doesn't exist, then fall back to the
standard shell (which is /bin/sh).
Also, the last command (jexec) should be preceded by
exec so the shell doesn't hang around. So the last
part of the script would look like this:
jail_path=$(jls | awk '$1=='$jail_id' {print $4}')
if [ -z $SHELL -o ! -x $jail_path/$SHELL ]; then
login_shell=$SHELL
else
login_shell=/bin/sh
fi
echo Logging in to $jail_hostname
exec jexec $jail_id $login_shell
Best regards
Oliver
PS: By the way, here's another useful script that displays
processes running in jails, ordered by jail IDs:
http://www.secnetix.de/~olli/scripts/jps
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Also seeing 2 x quad-core system slower that 2 x dual core
Steven Hartland wrote:
sysctl -a |grep dirhash
Check vfs.ufs.dirhash_mem is not close to vfs.ufs.dirhash_maxmem if it is
and only most used boxes this seems to be the case increase maxmem.
Seems this could either do with an auto tune option or a larger max by
default in today's day and age.
I think it would make sense to tie it to the maxusers value
(which in turn depends on the amount of RAM, by default).
For example, setting dirhash_maxmem to maxusers/32 MB with
a lower limit of 2 MB seems reasonable. By default, the
maximum of the autotuned maxuers value is 384, so the auto-
tuned value of dirhash_maxmem would be between 2 and 12 MB,
depending on the amount of RAM. Of course the admin could
still adjust it manually if required.
I.e. something like this:
--- ufs_dirhash.c.orig 2005-10-31 16:41:28.0 +0100
+++ ufs_dirhash.c 2007-12-11 13:56:05.0 +0100
@@ -1074,6 +1074,9 @@
void
ufsdirhash_init()
{
+ ufs_dirhashmaxmem = maxusers * (1024 * 1024 / 32);
+ if (ufs_dirhashmaxmem 2 * 1024 * 1024)
+ ufs_dirhashmaxmem = 2 * 1024 * 1024;
ufsdirhash_zone = uma_zcreate(DIRHASH, DH_NBLKOFF * sizeof(doff_t),
NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0);
mtx_init(ufsdirhash_mtx, dirhash list, NULL, MTX_DEF);
I haven't actually tried that, though, but the patch is
trivial enough so there shouldn't be too many bugs.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
We're sysadmins. To us, data is a protocol-overhead.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: garbled gjournal messages in dmesg with 7.0-BETA3
Toomas Aas wrote: kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains data. kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains journal. kernel: GEOM_JOURNAL: Journal aacd1s2 clean. kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3 contains data. kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3 contains journal. kernel: GEOM_JOURNAL: Journal aacd1s3 clean. kernel: GEOM_JOURNAL: BIO_FLUSH not supported by aacd1s2. kernel: GEOM_JOURNAL: BIO_FLUSH not supported by aacd1s3. kernel: WARNING: Expected rawoffset 0, found 514080 kernel: WARNING: Expected rawoffset 0, found 42443730 Now I updated RELENG_7 today (20071119), and upon rebooting there are some garbled messages: kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains data. kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains journal. kernel: GEOM_JOURNAL: Journal aacd1s2 clean. kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3G EcOoMn_tJaOiUnRsN AdLa:t aB.IO kernel: _GFELOUMS_HJ OnUoRtN AsLu:p pJoorutrenda lb y 3a3a7c2d819s325.22 kernel: : aacd1s3 contains journal. kernel: GEOM_JOURNAL: Journal aacd1s3 clean. kernel: GEOM_JOURNAL: BIO_FLUSH not supported by aacd1s3. kernel: WARNING: Expected rawoffset 0, found 514080 kernel: WARNING: Expected rawoffset 0, found 42443730 Both sets of messages are exactly identical, except that in the second set, a few parts got interleaved. Try to copy the garbled parts and delete every second character, then you can recognize it. It's a known problem, but it's not trivial to solve in a generic and efficient way. The filesystem on aacd1s3.journal was mounted successfully and files seem to be intact, (but I haven't really verified all the files). Don't worry, your file systems are OK. It's just a display problem. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Filesystems in 7.0 reliability
Norberto Meijome wrote: Any issues with ZFS on a single HD ? I think it's currently not recommended to use swapfiles on ZFS. Other than that, I'm not aware of any issues. any point doing that? Sure! Getting rid of static partition sizes, checksums for everything (preventing silent corruption), the ability to store multiple copies of important files, compression, and lots of other useful things. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [ANN] 8-CURRENT, RELENG_7 and RELENG_6 have gotten latest ?unionfs improvements
[Note: stripped excessive Cc.] Dmitry Marakasov [EMAIL PROTECTED] wrote: Btw, I was wondering: is unionfs related in any way with -ounion option of mount_*? No. The union mount option (-o union) is completely separate from UNIONFS, although it can be used to achieve a somewhat similar effect. It depends on your requirements whether it is sufficient or not. I was told long time ago that -ounion is even more broken than unionfs. That's wrong. The union mount option was _never_ really broken. I'm using it for almost as long as FreeBSD exists. However UNIONFS was broken for a long time (along with NULLFS and UMAPFS). NULLFS has been fixed some time ago, UMAPFS was abandoned apparently, i.e. nobody showed up to fix it, and UNIONFS was pretty much completely overhauled by Daichi GOTO and his team. I would now regard it as stable. Though, those two features seem to do very similar thing and I think that -ounion option is pretty useful. Yes, it is useful. The biggest differences are: - The union mount option newly mounts a filesystem on top of an arbitrary existing directory tree, while UNIONFS mounts another representation of one existing directory tree on top of another one. That means UNIONFS does the same as NULLFS, but unlike NULLFS it does not hide the underlying directory tree. - When using the union mount option, only the entries in the root directory show through from the lower file system. When using UIONFS, _all_ entries in _all_ directories are visible (unless masked by an identical entry in the upper file system, of course). - The implementation of the union mount option is rather simple has rather low overhead. UNIONFS is much more complex and has some overhead for certain operations, especially when files and directories have to be created automatically in the upper layer. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered. -- Guido van Rossum ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-BETA1
rihad [EMAIL PROTECTED] wrote: My question was more a theoretical one: it's called BETA for some reason, otherwise it'd still be in HEAD. To me BETA means that no major architectural changes are expected in it any more, no? That's correct. In theory, if BETA had no bugs (and no new ones are discovered during the beta/rc phase), the exact same code would probably become the RELEASE. Of course, in practice there are always bugs. But: TEST FIRST! I concur with Per. Me too. I've been running 7-CURRENT on a couple of production machines for some months, without any serious problems -- but these are not mission-critical machines. I've updated a production machine from 6-stable to 7-stable last week, without any issues. It was even a remote update without console access, which presented a certain risk. But all went well (and I had backups, of course). Our machine-to-be is quite mission-critical... But if I start with the latest 6.x release, it would be more difficult to migrate to 7.0 when it comes out than if I start with 7.0-BETA?. Not necessarily. The update from 6-stable to 7-stable was just as easy as an update within the 6-stable branch. It was just the usual buildworld, kernel, mergemaster dance. Nothing special at all, except that mergemaster took a little longer because there were more differences, and I had to do a few edits to the kernel config (enable the new scheduler). But you have to do that anyway, whether you go for 7.x now or later. Again it's named BETA for a reason, so it could be less intrusive than STABLE?.. BETA means it is on its way to the RELEASE (with some RCs in between, i.e. release candidates). It means that no architectural changes are made (those usually only happen in -current anyway), and no major new features, only fixes. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a Python Object Oriented Programming Seminar, but the acronym was unpopular. -- Joseph Strout ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: cvs commit: src/crypto/openssl/ssl ?d1_both.c ?dtls1.h ssl.h ssl_err.c]
Ken Smith wrote: Oliver Fromme wrote: Uhm, are you sure? In the past, whenever a new RELENG branch was created, it was implicitly the next -stable branch, because -current moved on to the next version number. Did that policy change? It is implicitly the *next* -stable but it's not there yet. That's what Simon was saying. FreeBSD's development (specifically the CVS repository) is public. But the bottom line is that the RELENG_X branches are *development* branches. I'm well aware of that. My question was only about naming conventions. People often talk about either -current and -stable, so was curious what RELENG_7 would be called right now. Obviously it's not called -current, but (according to you and Simon) it's not called -stable either. Actually the often used terms -current and -stable are ambiguous and not really accurate. E.g. someone talks about the -stable branch and you have no idea which one of the several RELENG_* ones he means. It's probably better to always use the CVS names or the branch name (from sys/conf/newvers.sh). No change in any policies or anything like that. What I'm describing has been the status quo for a long time but people tend to forget or never quite get it or ... so I'm sure you're not the only one thinking this way. I'm not thinking that way. :-) I do know very well that the -stable branches are development branches. Although in pre-4.0 days (when release branches didn't exist) -stable had a slightly different meaning, but it has really been a long time since then. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Can the denizens of this group enlighten me about what the advantages of Python are, versus Perl ? python is more likely to pass unharmed through your spelling checker than perl. -- An unknown poster and Fredrik Lundh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: cvs commit: src/crypto/openssl/ssl d1_both.c ?dtls1.h ssl.h ssl_err.c]
Simon L. Nielsen wrote: RELENG_7 isn't -STABLE yet Uhm, are you sure? In the past, whenever a new RELENG branch was created, it was implicitly the next -stable branch, because -current moved on to the next version number. Did that policy change? If it did change, I'm curious to know what the version 7 branch is called right now (6 being -stable and 8 being -current)? I assume we do not have two -current branches at the same time, do we? Best regards Oliver PS: I do agree that the DTLS security fix doesn't need a FreeBSD Security Advisory, for the reason that it doesn't seem to affect any _released_ FreeBSD version. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd ipsc -a output missing
The Presence [EMAIL PROTECTED] wrote: I have a generic kernel on my FreeBSD 6.2 system, and I am getting errors regarding PMAP_SHPGPERPROC which is set at 201 (default). The default value is 200. Because the system is a heavy load websever, this happens quite often. I want to calculate the proper value to to it to, but my ipcs software isn't working. Anyone know how to reconcile it? It has nothing to do with ipcs. The ipcs tool is used to report SysV IPC data. I suggest you try increasing PMAP_SHPGPERPROC in your kernel config, or adjust the vm.pmap.shpgperproc loader tunable (same effect, but doesn't require building a new kernel). I do have: options SYSVSHM # SYSV-style pscshared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores compiled into the kernel. Irrelevant. Output from ipcs -a: mercury# ipcs -a Message Queues: T ID KEY MODEOWNERGROUPCREATOR CGROUP CBYTES QNUM QBYTESLSPID LRPID STIMERTIMECTIME Shared Memory: T ID KEY MODEOWNERGROUPCREATOR CGROUP NATTCHSEGSZ CPID LPID ATIMEDTIMECTIME Semaphores: T ID KEY MODEOWNERGROUPCREATOR CGROUP NSEMS OTIMECTIME Obviously nothing on your machine uses SysV IPC, so all fields are empty. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd When your hammer is C++, everything begins to look like a thumb. -- Steve Haflich, in comp.lang.c++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
Artem Kuchin wrote: What value of HZ option would you recommend for a hosting (web) server with a lot of processes (about 900) and polling off (as decided from previous discussion polling is useless in this situation). In that case, I would recommend not to override the default at all (which is 1000). What parts of kernel does this option affect? What depends on it? The value of HZ specifies the minimum timing quantum of the kernel. It affects the granularity of the scheduler and all timing-related functions (nanosleep(2) and others), and the accuracy of dummynet and polling. I'm sure there are more things. Basically, the kernel cannot handle time slices smaller than 1/HZ seconds, for any purpose. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
Artem Kuchin wrote: Oliver Fromme wrote: Artem Kuchin wrote: What value of HZ option would you recommend for a hosting (web) server with a lot of processes (about 900) and polling off (as decided from previous discussion polling is useless in this situation). In that case, I would recommend not to override the default at all (which is 1000). Umm.. default is 100 (one hundred), i think. No, the default is 1000 for quite a few years. Well, except on the alpha platform, but I guess you're on either i386 or amd64, not alpha. Quote from src/sys/kern/subr_param.c: #ifndef HZ # if defined(__amd64__) || defined(__i386__) || defined(__ia64__) || defined(__sparc64__) #define HZ 1000 # else #define HZ 100 # endif #endif Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
Craig Boston wrote: Oliver Fromme wrote: In that case, I would recommend not to override the default at all (which is 1000). ISTM that it would be better to use kern.hz=100 in this case. I haven't seen a benchmark yet which would support that. My reasoning is that a web server shouldn't be terribly sensitive to latency, so it's better to have longer quantums to get more work done without context switching overhead. With HZ=1000 any modern CPU still performs millions of instructions per scheduling quantum. The context switch overhead for the case that a process exceeds its time slice is negligible. If you're not using polling, you'll be getting interrupts for network traffic anyway. Right. Probably many more of them than the scheduler switches between processes. With polling on however, a high HZ value makes sense. Yes, I've seen servers running at HZ=5000 and even more. Basically, the kernel cannot handle time slices smaller than 1/HZ seconds, for any purpose. It should still be able to schedule a new process for the remainder of the slice should the current one block or yield though, right? Right. And in that case a context switch happens anyway, so reducing the HZ value doesn't buy you anything, except reducing latency for those processes that can do their job quickly (e.g. serving static inline images). I still believe that it's best to not modify the default value of HZ=1000 on such a server. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Bob Johnson wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. The expansion of * does not include . or ... (As a side note, i also think that a tool should not try to mess with shell expansion, or make assumptions about it. For example, most shells have an optional feature to ask for confirmation when the user typed rm * or similar. If a user wants such protection, he can enable it. There is no reason that rm(1) or other tools try to be clever about it.) Having a different behavior for rm -rf ../ may have been intentional on someone's part so you can override the protection if you really want to. If it was intentional, then there wouldn't be a misleading error message (and exit code 1). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The last good thing written in C was Franz Schubert's Symphony number 9. -- Erwin Dieterich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device polling and weird timer interrupt count from vmstat
Artem Kuchin wrote: Well, problem with top is that on dual 3GHZ box it alsway s shows 0% load when not loaded with real traffic (web traffic) no matter if it is polling of int handling. Great, so your machine doesn't have any significant overhead for the timer interrupt. That was your question, wasn't it? And when loaded with real traffic web server eat a lot more cpu power then traffic handling, so, no separate measurement of traffic cpu load is possible. By traffic cpu load you mean the handling in the TCP/IP stack and in the device driver, right? That's always the same, no matter whether polling is enabled or not. In fact, with polling enabled you get _less_ interrupts, so the overhead caused by the actual interrupt handling is smaller. Also, when it comes to public web server i can never be secure enough and crazy load of traffic can come any time from DDOS attack which can bring down any box. So, for public web server it is a matter of security and managebility to have server interactive even on high traffic load. So, even from this poing of view polling can be usefull. Not really. DDoS attacks against web servers usually work on userland level, not on kernel level. For example, a simple way to perform such an attack would be to make many requests so that your apache runs out of resources. Polling does not help at all in that case. Polling only helps when the _kernel_ side is saturated with network traffic, but that's usually not the case on a web server where the Apache kicks the bucket much earlier than the kernel. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Being really good at C++ is like being really good at using rocks to sharpen sticks. -- Thant Tessman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Dan Nelson wrote: Oliver Fromme said: The expansion of * does not include . or ... Under /bin/sh, .* does match . and .., so be careful :) For that reason I got used to type .??* instead of .* since I started with UNIX almost 20 years ago. ;-) Apart from that, zsh is my shell of choice. It never matches . or .. with any globbing patterns. I think no shell should. I would submit an appropriate patch for FreeBSD's sh if it would be committed, but I doubt it would. Even this discussion here about an obvious bug in rm has bikeshed tendencies. :-( Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: an octopus made by nailing extra legs onto a dog -- Steve Taylor, 1998 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device polling and weird timer interrupt count from vmstat
Artem Kuchin wrote: I enabled device polling in the kernel, in nics and set HZ=1000. HZ=1000 is the default anyway. You only need to set it if you want a value other than 1000. For example, on my notebook I have set HZ=600 because that machine often used for various media playback (video). 600 is a multiple of 24, 25 and 30, which are common frame rates of video files. Aligning the kernel's scheduling quantum with the frame rate improves video playback. On a very fast processor I would probably use HZ=1200, but mine is only an older single-core. How, when i do omni2# vmstat -i i see interrupt total rate irq14: ata0 47 0 irq15: ata1 41 0 irq28: em0 2268 4 irq72: twe058380120 cpu0: timer 965994 1995 cpu3: timer1 0 cpu1: timer1 0 cpu2: timer 965857 1995 Total1992589 4116 Looks perfectly normal. What i don't understand is why timer rate on each cpu is 1995? I have set it to 1000, not 1995 or 2000. I have seen it showing 2000 on another box. The timer frequencies are not necessarily the same as the HZ setting. They are related, but don't have to be the same. It depends on several things, in particular the type of your processor and sysctl kern.timecounter settings. There are several formulas, dependencies and requirements for time counters. For example, the frequency must be set so the counter does not roll over in less than about max(2 msec, 2/HZ sec), which depends on the bit width of the counter (see src/sys/sys/timetc.h). On the other hand, you want a counter which runs as fast as possible, so you get better precision for time keeping. For those reasons the cpu timer can be set to a multiple of HZ. I've made a quick survery on a few machines around me (unless otherwise noted, all of these run FreeBSD/i386 6-stable and have the default of HZ=1000): Pentium III, 800 MHz: cpu0: timer 1893955760 1999 Xeon 5160, 3000 MHz: cpu0: timer 243483 1996 Athlon64, 2200 MHz: cpu0: timer 3964659397960 Athlon64 X2, 2x 2000 MHz, 7-current: cpu0: timer847083650 2000 cpu1: timer847081624 2000 VIA C3 Nehemiah, 1000 MHz, HZ=250: irq0: clk 167288669249 3) Is timer int really generated on each cpu? Am i really wasting cpu time on ~4000 ints per second? 4000 ints per second is rather nothing on any modern CPU. Have a look at the top(1) display of an otherwise idle system. The %interrupt column should be zero, even if it's processing 4000 timer interrupts per second. As far as I know, the cpu timer interrupt handler is very light- weight. 4) does twe driver use polling? whay about twa? No, they don't. They aren't even NIC drivers. Currently polling is only implemented for (some of) the NIC drivers. how to check it in the sources? The polling(4) manual page lists all supported devices. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd When your hammer is C++, everything begins to look like a thumb. -- Steve Haflich, in comp.lang.c++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-STABLE does not lauch 2nd core of Pentium e2160 CPU
vermaden [EMAIL PROTECTED] wrote: FreeBSD 6.2-STABLE (GENERIC SMP kernel rebuild from today sources) does not launch second core of Pentium Dual Core e2160 CPU, it detects the cores [Cores per package: 2] but it does not launch the second CPU [SMP: AP CPU #1 Launched! -- this should pop in dmesg but it doesnt] My guess is that you forgot to include options SMP in your kernel config. Otherwise, what's the output from sysctl kern.smp on that machine? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is to C as Lung Cancer is to Lung. -- Thomas Funke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device polling and weird timer interrupt count from vmstat
Artem Kuchin wrote: Oliver Fromme wrote: Artem Kuchin wrote: 3) Is timer int really generated on each cpu? Am i really wasting cpu time on ~4000 ints per second? 4000 ints per second is rather nothing on any modern CPU. Have a look at the top(1) display of an otherwise idle system. The %interrupt column should be zero, even if it's processing 4000 timer interrupts per second. As far as I know, the cpu timer interrupt handler is very light- weight. Thank you for the answer. My convern is that with 4 CPUs i get 8000 ints/second. While em generates only about 200 ints/second. As i undertand not all int handlers are the same. Some are heavy and some are light on CPU. So, the question is what is better (better=less CPU time): 8000 ints/sec from timer or 200 ints/sec from NIC? There's no simple answer to the question. The best way is to just try it. As I wrote, run top(1) while the system is idle, so only the cpu timer interrupts are active. If the %interrupt column is zero most of the time, then there is nothing to worry about at all. However, if you have a constant non-zero %interrupt value, you might consider lowering HZ, and you might reconsider whether polling really has advantages in your situation. Do you have reasons to believe so? Remember that the main purpose of polling is to improve interactivity under very high network load. If you're not in such a situation, then polling probably doesn't buy you much. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing. -- Dick Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
rm(1) bug, possibly serious
Hi, Today I noticed the following behaviour on a 6-stable machine: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ rm -rf ../ $ Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. The very same command. Further investigation: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ ls -al .. ls: ..: No such file or directory $ ls /tmp/foo/bar ls: /tmp/foo/bar: No such file or directory That means: Even though rm -rf ../ prints an error message, indicating that the argument is invalid, it *DOES* remove the contents of the parent directory! To add further confusion, another rm -rf ../ does not print an error message and seemingly succeeds, even though .. does not exist anymore in the current directory (which has been removed). Shall I file a PR? Or is rm working correctly, and my assumptions are wrong? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired. -- Chris Torek ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Torfinn Ingolfsen wrote: Oliver Fromme wrote: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ rm -rf ../ $ Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. The very same command. What happens if you issue a 'pwd' command after each 'rm -rf ../'? We want to see the output. It's /tmp/foo/bar every time. IMHO, the only way the second rm command *should* succeed, is if it invalidates the current working directory, thus releasing the last lock on the directory. Quick testing here: [...] Ok, I think it is a bug. Yes, I think so, too. By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is executable pseudocode. Perl is executable line noise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel hangs if build without I486_CPU
Andris [EMAIL PROTECTED] wrote: I have the same problem, but in my case it was not I486_CPU, but SCHED_ULE. After changing SCHED_ULE to SCHED_4BSD problem was gone. If you shot your foot, don't complain that it hurts. SCHED_ULE is declared experimental and known to be broken in FreeBSD 6. It's supposed to be fixed in 7-current. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The most important decision in [programming] language design concerns what is to be left out. -- Niklaus Wirth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Via padlock
Daniel O'Connor wrote: On Wed, 12 Sep 2007, Minseok Choi wrote: I found out from googling that VIA Padlock would be supported in FreeBSD 6.2. But I don't know how to activate it. Is there any kernel configuration or specific application for the Padlock? It appears the man page is missing, but putting device crypto device padlock in your kernel should work. In 7.0 it's a module. It's a module in 6.x, too. I have the following line in /boot/loader.conf on my RELENG_6 machine (VIA C3): padlock_load=YES So there's no need to modify your kernel. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing. -- Mother Teresa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic after removing usb flash disk
Roman Bogorodskiy wrote: Artem Kuchin wrote: [FreeBSD crashes when a mounted device disappears] It's not a bug, it's a feature. I certainly wouldn't call it a feature. As others have noted, it is a known shortcoming in FreeBSD, and fixing it is non-trivial. Always remember to umount devices before removing them. Using amd(8) with a short timeout can help somewhat. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a Python Object Oriented Programming Seminar, but the acronym was unpopular. -- Joseph Strout ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Static linking and memory usage
Jeremy Chadwick wrote: Pete French wrote: If I have an executable which is staticly linked with many copies of it running (a CGI script in fact), will all those copies share the text segment of the executable on the disc, or will it actually use up real memory resource with many copies of the executable ? I have been assuming the former, but possibly that is not correct. How I understand it: A statically-linked binary contains portions/copies of the text, data, and bss segments of .a library. These are part of the actual binary itself, thus become part of the memory space of the program when run. Only the text segment gets shared; the data and bss segments, as far as I know, do not get shared. Upon a fork() the data and bss segments are also shared, but marked copy-on-write. That is, as soon as the child tries to modify something, a copy of the page is made and assigned to the child process in place of the parent's page. Of course, unrelated processes (i.e. which ave no parent- child relationship) never share data segments. With a statically-linked binary, when the binary forks, the text segment is kept intact between the parent and child -- that is, there is only 1 in-memory copy of that segment. However, *different parents* will have their own copy of that library in their memory space. Are you sure? I _think_ (but I'm not 100% sure) that the mapped text pages of a binary are associated with the vnode of the executable file, but not with a particular process. That means that unrelated processes running from the same binary file (vnode) will share the same text pages in memory. Please, someone correct me if I'm wrong. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll. -- Frank Klemm, de.comp.os.unix.discussion ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: viapm - SMBus support for lmmon
Heiko Wundram wrote: I've just set up boxes with FreeBSD 6.2 (currently not running stable yet, but will in a day or so), and as the motherboard is a VIA-based something (with a VIA C3 CPU), I thought that viapm should be the appropriate driver to enable smbus for lmmon and the like. Anyway, the driver loads fine: [...] /dev/smb0 is properly created, but when I then try to run lmmon, the output is the following: --- goettingen01# lmmon IOCTL: Device busy Are you sure your moinboard does contain monitoring hardware that is supported by lmmon? I have a very similar VIA C3 system on an EPIA PD10K mainboard. The viapm driver supports it fine, but it doesn't have lmmon-supported monitoring hardware, unfortunately. Here's dmesg, pciconf and sysctl output if you're interested: http://www.secnetix.de/~olli/dmesg/epia/ Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly. -- RFC 2549 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
moused(8) consuming cpu for nothing
Hi,
I noticed that the moused(8) process had accumulated about
one minute of CPU time, after only three days of uptime.
That's really a lot, given the fact that this server
doesn't have a mouse connected at all. :-) Well, it is
connected to a KVM switch, but it was never used since the
last reboot. Accoding to vmstat -i psm0 received zero
interrupts. So I really wonder why it has consumed that
much CPU time.
So I tried to strace the process, and got an endless series
of these:
15:22:31.017275 gettimeofday({...}, NULL) = 0
15:22:31.017386 select(1024, [?], NULL, NULL, {...}) = 0 (Timeout)
15:22:31.038275 gettimeofday({...}, NULL) = 0
15:22:31.038386 select(1024, [?], NULL, NULL, {...}) = 0 (Timeout)
15:22:31.059276 gettimeofday({...}, NULL) = 0
15:22:31.059387 select(1024, [?], NULL, NULL, {...}) = 0 (Timeout)
15:22:31.080275 gettimeofday({...}, NULL) = 0
15:22:31.080387 select(1024, [?], NULL, NULL, {...}) = 0 (Timeout)
15:22:31.101276 gettimeofday({...}, NULL) = 0
15:22:31.101387 select(1024, [?], NULL, NULL, {...}) = 0 (Timeout)
15:22:31.122276 gettimeofday({...}, NULL) = 0
15:22:31.122388 select(1024, [?], NULL, NULL, {...}) = 0 (Timeout)
15:22:31.143275 gettimeofday({...}, NULL) = 0
15:22:31.143386 select(1024, [?], NULL, NULL, {...}) = 0 (Timeout)
15:22:31.164276 gettimeofday({...}, NULL) = 0
15:22:31.164388 select(1024, [?], NULL, NULL, {...}) = 0 (Timeout)
15:22:31.185276 gettimeofday({...}, NULL) = 0
15:22:31.185387 select(1024, [?], NULL, NULL, {...}) = 0 (Timeout)
.. and so on.
So it seems to call select(2) with a 0.02s timeout and
then gettimeofday(2) within a loop. 50 times per second.
Without doing anything useful (remember there's no mouse
device connected and zero interrupts occuring).
Is that normal, or is it a bug? For now I have killed and
disabled moused(8) on all machines in the server farm, but
it is somewhat inconvenient to have to start moused(8)
manually each time a server is switched onto the KVM.
Best regards
Oliver
PS: Just in case it matters (these are all the defaults):
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
kern.timecounter.choice: TSC(-100) HPET(2000) ACPI-fast(1000) i8254(0)
dummy(-100)
kern.timecounter.hardware: HPET
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
It's trivial to make fun of Microsoft products,
but it takes a real man to make them work,
and a God to make them do anything useful.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
Doug Barton wrote: Oliver Fromme wrote: By the way, I have changed from hints to slaves on the DNS servers for a large server farm (just testing right now; I might go back to hints if I don't feel it's worth it). Depending on how many name servers you have you might get a bigger win by slaving the root to one server, then slaving it to the others from your local master. If you're only talking about a few name servers it's probably not worth it though. It's three name servers, and they're intended to be completely independent of each other. That's why I've configured each of them to retrieve the root zone of its own. It _seems_ a few applications run with lower latency, but I'll need to run some benchmarks in order to get some hard numbers. If your stuff is relatively well behaved, and generally only queries a few TLDs you might not get much of a benefit in terms of reduced latency. In this scenario the main advantage is better resilience to a root DDoS. Where this technique really works well is a scenario where you are answering a lot of random queries that could potentially include invalid TLDs and other junk. Not sending those queries to the roots helps reduce traffic for them and for you, and gives you much better latency on the inevitable NXDOMAIN response. The farm contains several mail servers with spam and virus scanners, http proxies with (roughly) several thousands of users, a few dozen web servers and other things. I think especially the mail scanners and the proxies generate some amount of dns junk queries. Thanks for your suggestions! Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind. -- Alan Kay, OOPSLA '97 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
Doug Barton wrote: Oliver Fromme wrote: However, I noticed that the refresh interval of the root zone is 1800, i.e. it would be fetched every 30 minutes, No, refresh is how often the master servers are checked for serial number changes. True, I forgot about that. Thanks for reminding me. This is why what's suggested below is not a good idea either. Of course, you're right. By the way, I have changed from hints to slaves on the DNS servers for a large server farm (just testing right now; I might go back to hints if I don't feel it's worth it). It _seems_ a few applications run with lower latency, but I'll need to run some benchmarks in order to get some hard numbers. I will keep the hints zone on my office workstation and on my home machine. There seems to be consensus that slaving the root is not desirable in these cases. (Please correct me if I'm wrong.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
Hi, Just for the record, I like the current solution, i.e. default being a hint zone, and slave zones being commented out, ready to be used for those who know what they're doing. However, I noticed that the refresh interval of the root zone is 1800, i.e. it would be fetched every 30 minutes, even though the zone seems to be updated at most once per day. Therefore, wouldn't it make sense to add the following option to the slave zones? min-refresh-time 86400; Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Peter Jeremy wrote: Dennis Melentyev wrote: Is there any correct way to initiate funding to rewrite VM/VFS related parts (getting non-panicable removable devices)? Who should one contact for this? I would suggest that the first step is finding someone (or a few people) with the necessary skills who is/are willing to work on the problem. Offering funding may increase the potential pool but will not automatically solve the skills/knowledge issue. By the way, the problem apparently has been solved in DragonFly BSD (i.e. DF BSD does not panic when a mounted FS is physically removed). Maybe it is worth to have a look at what they did to fix it, and possibly port it over to FreeBSD. On the other hand, the internal data structures of the VM subsystem have diverged quite a lot from FreeBSD, so I don't know if it would really help. (No, I'm not volunteering; lack of time and interest.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [resolved, ?naively] Re: geom vs ich through ar device - benchmarks?
Scott Long wrote: Howard Goldstein wrote: Naive test: dd if=/dev/zero of=/fsundertest/tstfile bs=1m count=1000 *not including buffered stuff unwritten, the test simply reported dd's idea of the transfer time*, and then the other way where it doesn't matter In firmware's RAID1 Using the awesome gmirror write 1gb: 13.275 13.7 rd 12.9 13.8 Of course after this I used gmirror... Just so we're clear, the ICH5 doesn't have any firmware and doesn't actually do any RAID operations. What is has is hook into the system BIOS during boot. That hook allows the BIOS to do RAID-like operations during boot, until the OS takes over control of the devices. After that, it's up to the OS to do all the RAID work. The 'ar' driver is still software RAID, just like gmirror. What you've effectively done merely compare the performance of one software RAID stack to another. That's certainly an interesting comparison, but maybe not exactly what you had in mind. As an additional note: _If_ the ICH RAID was in hardware (which it isn't, as Scott pointed out), it might be preferable to use it instead of gmirror, even if it's 5% slower, but because it would save a lot of cpu. Of course, since both are in software and probably consume similar amounts of cpu, it's better to use gmirror because it's a little faster. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [resolved, ?naively] Re: geom vs ich through ar device - benchmarks?
Howard Goldstein [EMAIL PROTECTED] wrote: [...] You should fix your e-mail setup. I can't reach you: - Transcript of session follows - ... while talking to ns1.queue.to.: RCPT To:[EMAIL PROTECTED] 553 local-rblblacklist complain to your provider 550 5.1.1 [EMAIL PROTECTED]... User unknown I'm not going to complain to my provider because that would be myself. :-) This is not a dynamic IP address, and it certainly has never sent spam to anywhere, so I'm curious why it would be included in a blacklist. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd on a NAT gateway seems to do nothing
Andrew Reilly wrote: Peter Jeremy wrote: The major difference is that ntpd will use a source port of 123 whilst ntpdate will use a dynamic source port. Is that behaviour that can be defeated? If it uses a fixed source port, then multiple ntpd clients behind a nat firewall will be competing for the same ip quadtuple at the NAT box. Usually the clients behind the NAT gateway use the ntpd running on the gateway itself, not any servers beyond. So NTP queries never have to be forwarded across the gateway, so they're not subject to NAT translation at all. The gateway rather acts as server and client at the same time. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with Hitachi 1TB SATA drives
Jeremy Chadwick wrote: * Hard disks are growing in capacity, but are not growing in physical size. We're pushing 1TB in a 3.5 form factor. And the same applies to laptop (2.5) drives. The margin of error continues to increase as we try to cram more and more data in such a small medium. I personally would *love* to see drives go back to using a 5.25 form factor, especially for large capacity disks, since chances are it means higher reliability (read: less chance of error). As far as reliability goes, I agree. However, the problem is, you cannot make 5.25 disks spin at 10 or 15 krpm. Well, maybe you can, but it's a hell of an engineering problem. Even 7200 rpm isn't trivial to do for such large discs. And who wants to buy a slow 3600 rpm 5.25 drive? Apart from that, the larger radius also means slower end-to-end movement for the heads. * All this leads me to the topic of backups. Hard disks are growing in capacity at a rate which the backup industry cannot follow. It's getting to the point where you have to buy hard drives to back up the data on other hard drives, but anyone with half a brain knows RAID is not a replacement for backups. Correct, RAID and backups are completely different. But you can use disk drives for both. I solved my backup problem by putting a hot-swap ATA frame into my home server (they're pretty cheap nowadays), and using a bunch of ATA disks as removable media. It's just like tape backups, but much cheaper, faster and easier to use. It beats every tape technology hands down. going to sit around once a week backing up a terabyte of data to ~120 dual-layer 8.5GB DVDs? I wouldn't even start thinking about considering that. The closest thing out there right now is a product from IOMega called REV, which (at most) offers 70GB of storage per disk, or 140GB with compression. A new IOMega REV (which includes one 70GB disk) costs US$600 MSRP. You read that right. Ugh. For US$600 you get four 400 GB disk drives, including four trays and one frame (hot-swap capable). That's 1.6 TB of backup capacity. Compare that to 70 GB. I also guess that that REV thing is much slower than an ATA disk. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd on a NAT gateway seems to do nothing
Pete French wrote: [...] Any suggestions ? I assume it has something to do with the NAT, but I am not sure what. All other TCP connections out from that machine to external systems work fine, so it is not as if outbound connections from there are not working at all. Note that NTP does not use TCP, but UDP. Are you sure that your filter rules are OK? It's certainly possible to have a bug in the rule set so it forwards NTP replies for the internal clients, but doesn't allow them to reach the ntpd running on the machine itself. Another question: Do you have a dynamically assigned IP address? In that case ntpd needs to be restarted when a new address is assigned, because ntpd has the unfortunate habit to bind to all addresses that exist at the time it is started. I'm running ntpd on a NAT gateway myself (RELENG_6), and there are no problems at all. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Stefan Esser wrote: Oliver Fromme wrote: Momchil Ivanov wrote: I don`t know how things work, but shutting down the system when some mounted fs is no longer present seems like the wrong thing to me. As Josh wrote, it's expected. The problem is known to exist for a long time already (probably as long as FreeBSD itself exists), and if there was an easy solution, certainly someone would have fixed it. I have to check this, but AFAIK this problem exists only for devices/partitions that are mounted R/W. Do you happen to know this? (I can not risk to crash my box right now for a test ;-) I'm afraid the problem affects _all_ mounts, including read-only mounts. There once was an autofs implementation, but IIRC it has later been removed. It could not only automatically mount removable media, but it could also help with the problem of devices that are rarely written to, but still mounted R/W just in case for easy write-access. Long time ago I had the idea that a clean file system could be mounted R/O after a short delay. When all dirty buffers are flushed, the device could be forcefully disconnected without causing inconsistencies in the kernel. If there are no open file descriptors, the super-block could be written with the clean flag set, to signal that no fsck is needed when the partition is mounted next time. Internally, the device can be treated as R/O, with the only exeption that an attempted write is not rejected, but that it instead triggers the change back to R/W operation (this means setting the in-RAM copy of the super-block to dirty before the write is allowed to proceed as normal). That's a very interesting idea. Unfortunately it doesn't solve the problem, because read-only mounts have the same problem, unfortunately. So, currently the best work-around is to use amd with a very short timeout. Or simply remember to umount your removable media manually. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd just sits there and does nothing
[LoN]Kamikaze [EMAIL PROTECTED] wrote: My original intention was just to say that openntpd works just out of the box, while ntpd doesn't. That's just plain wrong. ntpd _does_ work out of the box (unless your configuration is broken), and it seems to be more accurate than openntpd. Demanding to replace ntpd with openntpd in the FreeBSD base system because you cannot get the configuration right is ridiculous. ntp.conf server 0.de.pool.ntp.org minpoll 4 maxpoll 8 server 1.de.pool.ntp.org minpoll 4 maxpoll 8 server 2.de.pool.ntp.org minpoll 4 maxpoll 8 server ntp1.rz.uni-karlsruhe.de minpoll 4 maxpoll 8 server ntp2.rz.uni-karlsruhe.de minpoll 4 maxpoll 8 server ntp3.rz.uni-karlsruhe.de minpoll 4 maxpoll 8 server ntp4.rz.uni-karlsruhe.de minpoll 4 maxpoll 8 restrict default ignore restrict 127.0.0.1 You need to add proper restrict lines for the servers, of course. Basically you have configured ntpd to ignore all servers. Also, putting minpoll 4 maxpoll 8 on all servers is somewhat suboptimal and puts an unnecessary burden on the servers and networks without reason. I recommend to use low polling intervals and the iburst option for one or two local servers only (e.g. for NTP servers located in your direct upstream or at your ISP), and higher polling intervals for other public servers. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Software gets slower faster than hardware gets faster. -- Niklaus Wirth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Momchil Ivanov wrote: On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote: Josh Paetzel wrote: Yes, it's expected behavior. The workaround is to not unplug mounted devices. (There's nothing special about USB here, if you unplugged an IDE drive you'd get the same behavior) Wouldn't it make some sense not to panic if mounted devices that are in sync get removed? A few applications might get in trouble, but that's hardly a reason to bring a whole system down. I don`t know how things work, but shutting down the system when some mounted fs is no longer present seems like the wrong thing to me. As Josh wrote, it's expected. The problem is known to exist for a long time already (probably as long as FreeBSD itself exists), and if there was an easy solution, certainly someone would have fixed it. Just remember to always umount first, and you're safe. In the early 90s I panicked a FreeBSD machine by removing a floppy disk that was mounted. I did that mistake only once -- afterwards I always remembered. If you have problems remembering, another work-around is to use the auto mounter daemon (amd(8)). It umounts file systems automatically that are not in use. Another nice feature of amd(8) is that you don't have to mount the file system either -- Simply plug the USB stick in, then access it, and amd(8) will automatically mount it for you. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I learned Java 3 years before Python. It was my language of choice. It took me two weekends with Python before I was more productive with it than with Java. -- Anthony Roberts ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When inode change time changes?
Artem Kuchin wrote: Also, i use inode time because i only need files which really have been changed. For example, i you restore a file from a month ago it will have a date which is a month ago. Then that backup is destroyed but this file would not be backed up because the date is too much in the past. So, we loose the file. If i used inode change time the file will be backup in any case. However, some stupid programs like mysql or qmail seem to touch files so, Pretty much _any_ operation on a file (except reading it) will update the ctime of the inode. So I'm not surprised that the ctime of database files and mail files gets updated often. (However, I do agree that mysql and qmail are stupid, but for entirely different reasons. ;-) for example, all mail message and databases are backed up every time. And this sucks. Seems like you need to make a distinction: Use mtime for /var/mail and /var/db/mysql/data (or wherever your db files are), and use ctime for everything else. With find(1) and bsdtar(1) that's pretty easy: # set -f# disable shell-expansion of * # MDIRS=( -path ./var/mail/* -o -path /var/db/mysql/data/* ) # FLAG=/var/db/lastbackup.flag # find . $MDIRS -mnewer $FLAG -o ! $MDIRS -cnewer $FLAG \ | tar -cn -T- -f- | gzip -c $DESTINATION.tar.gz However, as you pointed out, it will not record the fact that a file has been deleted since the last level-0 backup, so it's not a perfect incremental backup. (However, it's sufficient for me personally. Another solution would be to store the output from find along with the level-1 backup, so you can easily find out what files didn't exist anymore when you restore the backup.) You might also use the -print0 flag on find(1) and the --null flag on tar(1) if there's the possibility that file names could contain whitespace ... I omitted some details for brevity. Anyhow, it's just a suggestion. It works perfectly fine for me, but it might not work for you. YMMV. What is still do not understand is what time gtar uses for --newer option. Man page says: --newer dateOnly store files with creation time newer than date. This is simply not true. NOT creation time defenetly. Sure? Did you test it? It is either modification time or inode change time. Which one? You can either simply test it by creating a few test files and making a test archive. Or look it up in the source code of gtar. I don't have gtar installed so I can't tell. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When inode change time changes?
Julian H. Stacey wrote:
Oliver Fromme wrote:
Artem Kuchin wrote:
Also, i use inode time because i only need files
which really have been changed. For example,
i you restore a file from a month ago it will have
a date which is a month ago. Then that backup
is destroyed but this file would not be backed up
because the date is too much in the past. So, we
loose the file. If i used inode change time the file
will be backup in any case. However, some
stupid programs like mysql or qmail seem to
touch files so,
Pretty much _any_ operation on a file (except reading it)
will update the ctime of the inode. So I'm not surprised
that the ctime of database files and mail files gets
updated often.
I was uncertain what when changed st_ctime st_atime st_mtime
when I had to use SCO (ugh!) in 1990, as well as BSD. Not enough source
then there, manuals were insufficient, so to observe, I wrote
http://berklix.com/~jhs/src/bsd/jhs/bin/public/statv/
More tools since, but might still be handy.
Well, this is FreeBSD in 2007. :-)
All syscalls that change st_{a,m,c,birth}time should be
documented in the stat(2) manpage. I think that those
enumerations in the manpage are complete, but if someone
finds something that's missing there, then he should
file a PR to fix that bug.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?
-- Tom Cargil, C++ Journal
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Have some troubles after deleting group of packages...
Xazker Xazkerov wrote: Recently I've deleted some packages on my server, those packages was installed on It at 21.06.07(DATE) by mistake. What to learn exactly which packages was installed on system, I used command ls -la /var/db/pkg|grep Jun 21 . I'm afraid that was a mistake. When you install a package, sometimes new files are written to thesubdirectories of other packages in order to record dependencies. The time of those directories are also updated. If you deleted them all, then you probably deleted too many. To fix that, review the list of deleted packages (if you don't remember it, then try to look for the pkg_delete commands in your shell's history). Install any that might be still needed. After it I've deleted those packages by pkg_delete command. Firstly it seemed all OK, but later I have collided with such problems: $ sudo tcpdump /libexec/ld-elf.so.1: /lib/libpcap.so.4: Shared object has no run-time symbol table That's strange, because /lib/libpcap.so.4 is part of the FreeBSD base system. It doesn't come from any package. It seems that something else was also broken inadvertently, apart from the package deletions. What time stamp does that library have? You might have to reinstall that file from installation media (CD, FTP server or similar). Or, if you have the system sources installed, you can rebuild and install that library in /usr/src/lib/libpcap: # cd /usr/src/lib/libpcap # make clean depend all install Except for that, when I was trying to build hping, I've got such error: [...] /usr/lib/libpcap.so: file not recognized: Memory exhausted That's probably caused by the same thing. I am very sorry for my cRoOKeD English. You're perfectly comprehendible. I think your English is not worse than mine. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how much beer do I need to get this patch applied?
Miroslav Lachman wrote:
I think that topic is not about how we can do it another way, but why
this patch was not commited. This patch doesn't change current behavior,
but allows operator to choose another behavior.
Allowing more choices is always good thing, so I am for commiting this
patch.
I agree completely. The point of this patch is to
add an option (remember: options are optional ;-)
and the default is off, i.e, no change in behaviour.
So those who don't like the new option don't have to
do anything, and nothing will change. Those for whom
the new option is useful will enable it. Everybody
happy, right?
I also vote for committing the patch. (Personally I
will probably also enable that new option. I prefer
to be notified only if something does _not_ work.
YMMV, of course.)
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
PI:
int f[9814],b,c=9814,g,i;long a=1e4,d,e,h;
main(){for(;b=c,c-=14;i=printf(%04d,e+d/a),e=d%a)
while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When inode change time changes?
Artem Kuchin [EMAIL PROTECTED] wrote: I use gtar (gtar because it has incremental backups, and tar does not) You _can_ use BSD tar for incremental backups. I do that every day. When you do a level-0 backup, simply touch a flag file somewhere. Then when you do the level-1 backup, use the --newer-than option with that flag file, so only files that were modified after the level-0 backup get archived. The --newer-than option checks the ctime. If you want to look at the mtime only (i.e. ignoring renames, chmod, chown etc.), use --newer-mtime-than instead. Please refer to the tar(1) manpage for details. I use inode change time in order to backup all changed files. I have notices that some files are always backed up even if they did not change. For example all mysql database. I checked their file change time and it is not changed, howeever, inode change time changes on every mysql restart. Maybe someone can englighten me when inode change time changes? What must be done with file to change it (except writing to it)? I tried chmoding - it does not affect inode time. The mtime changes upon every data write to the file, the ctime additionally changes upon every change of the inode data (i.e. file meta data). This is documented in the stat(2) manpage: st_ctime Time when file status was last changed (inode data modification). Changed by the chmod(2), chown(2), link(2), mknod(2), rename(2), unlink(2), utimes(2) and write(2) system calls. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libtiff, spandsp
olivier.taylor [EMAIL PROTECTED] wrote: after having install libtiff, I am trying to install spandsp and get the following error : configure: error: Can't build without libtiff (does your system require a libtiff-devel package?) Look for that error message in the configure.log file and check what command exactly failed (whether it's missing a library or include file, or a certain symbol within an existing library, or whatever). Unfortunately, gnu configure sucks pretty much and is not very good at helping to debug failures. Building programs would often be easier without gnu configure. :-( Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargil, C++ Journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Server setup as a Diskless Server on reboot sends DHCP Discover packets out
Kim Attree wrote: I've setup a machine as a diskless server, using PXEBoot with ihc-dhcpd to offer dhcp and dhcp configuration information. I did a test reboot on the server, and found to my dismay that the server NIC's are sending out dhcp discover packets and trying to get an address. The NIC's IP info is captured correctly in /etc/rc.conf: [...] and the /etc/dhclient.conf file is empty. I thought maybe it was the /conf directory used in the diskless Root structure creation, so I renamed it out of the way, but that made no difference. I can't seem to find where the definition is that makes the NIC's ask for DHCP info. Shortened output of /var/run/dmesg.boot pertaining to the DHCP Discover packets: snip Sending DHCP Discover packet from interface bge0 (00:0b:db:e6:a9:33) Sending DHCP Discover packet from interface bge1 (00:0b:db:e6:a9:35) That's the kernel itself trying to perform BOOTP/DHCP. It does that before mounting the root file system (which might be mounted via NFS anyway, requiring an IP address to be obtained via BOOTP or DHCP). If you don't want that, then remove options BOOTP from your kernel config file and rebuild your kernel. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade 6.2 to xorg 7.2
Stephen Clark wrote: Tom Evans wrote: Stephen Clark wrote: I'd read /usr/ports/UPDATING again, if you follow the exact instructions I have it printed out sitting right in front of me. Then there shouldn't be any problem. But what about this paragraph under caveats from /usr/ports/UPDATING: Make sure you have the x11/xorg meta-port installed. If you do not have this meta-port installed with X.Org 6.9, you will miss out on a lot of the new X.Org 7.2 sub-ports. Exactly what that paragraph says. I've read your first email message again and I'm still unable to find out what your actual problem is. What exactly is unclear to you, or what part of the update failed for you? (Please paste the error message if you got one.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror on a disk with data already on it
Marc UBM Bocklet [EMAIL PROTECTED] wrote: The gmirror man page says that if gmirror is used on a disk, the last sector of that disk is overwritten with the metadata gmirror uses. So what I would like to know is, how risky is it to mirror a disk which already has data on it? Is there a chance that I might render my system unbootable? If you follow the procedure in the Handbook, then there is no risk at all. It involves preparing one side of the mirror on the second (unused) device first, then attaching the first device to the mirror. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall replacement
Craig Boston wrote: Ivan Voras wrote: See http://wiki.freebsd.org/finstall . Somewhat tangental, the only thing that really jumps out at me is this: I propose the UFS+gjournal be the default FS type (even for root+boot?) I think this is not such a good idea. While I like gjournal, and use it quite a bit, I don't think it's suitable as a default. For one thing, with default settings, it carves out a full GB of usable space from each filesystem that it's used on. This would prove highly surprising to new users, especially on smaller filesystems such as /var, and may well cause them to think FreeBSD uses a highly inefficient filesystem. Also, gjournal journals *everything*, not just metadata. When the data and journal are on the same physical device, as they would be in most setups that take the defaults, all write operations are effectively done twice (modulo any write-combining). Again, this probably wouldn't be expected for a default and would lead to perceived slowness. Both of these are quite acceptable tradeoffs for what gjournal does, but the user should be aware of them before choosing to employ it. I think it would be wonderful to have in the installer, just not as the default. I agree completely. Having it as a non-default option would be best. I also don't think that ext2 should be offered in the installer, as there have been periodic stability problems with it, and new users accustomed to Linux may pick it out of habit and get bitten. Actually I think having it as an option would be good, but I agree that it could cause problems so a warning should be printed, indicating that UFS (or UFS2) is the native BSD file system, and that ext2fs only exists for Linux compatibility and might cause problems. P.S. I pretty much never use sysinstall anymore, preferring to set up things as gjournal and geli using Fixit mode, then just extract the tarballs into the new filesystems. I use sysinstall to install FreeBSD on virgin machines or when there's a major jump (like from 4.x to 6.x). Of course, in all other cases I use source-level updates via make world. Having a good standalone partitioning tool would be nice though, as doing all the math by hand can be tedious. Not sure if you already know this ... In the bsdlabel tool you can use m and g suffixes for sizes to specify megabytes and gigabytes, respectively, so you don't have to calculate block numbers. The size of the last partition can be given as * so it will receive all the remaining free space of the device. Furthermore you can use the * wildcard for the offsets, so the bsdlabel tool will calculate the offsets by adding the sizes of the preceding partitions. So, in fact, you don't have to do any math at all. If you want a curses GUI, you can run sysinstall with the apropriate functions (»sysinstall diskLabelEditor«). Personally I prefer bsdlabel(8), though, which throws me into my favourite editor (neither v* nor e*) and lets me edit the label directly. That's _much_ faster than navigating through sysinstall. YMMV, of course. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly. -- RFC 2549 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet Loss w/bge BCM5703 on Dell PE2650
Vinny Abello wrote: I've isolated a problem which appears to be a bug causing packet loss with FreeBSD 6.0 and later on the Dell PowerEdge 2650 servers and the integrated Broadcom BCM5703 NICs. Have you enabled polling on the interface? I experienced a similar problem on a HP Proliant DL360 running 6.2-stable (RELENG_6 of a few weeks ago). The problem disappeared upon ifconfig bge0 polling. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible. -- John William Chambless ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam cd error from freebsd-stable Digest, Vol 207, Issue 6
JoaoBR wrote: same as ipfw some weeks ago :S lucky us that atapicam is an exotic driver and not so widely used and still more lucky us that it is atapicam and not ahd or aac right? Sorry dear clients our mail cluster is out of service and when it does not work in three weeks or so please give me a new call ok ... First, I don't think atapicam is an exotic driver. I'm using it for several years (in fact, since it was an inofficial patch, before it hit the repository). It's working perfectly fine for me, including with today's RELENG_6. Second, if you run a mission-critical mail cluster (or similar things) and update it along RELENG_6 without proper testing, then you deserve to be shot in the foot. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam cd error from; ?was: freebsd-stable Digest, Vol 207, Issue 9
Joe Altman wrote: You have atapicam as a kernel module; and what version of atapi-cam.c? No, I've always compiled it statically in my kernel. It looks like this one is current: Revision 1.54 That's the HEAD version (in 7-current). The version is RELENG_6 is 1.42.2.5, which is practically identical to 1.53. And the only difference between 1.53 and 1.54 (HEAD) is MPSAFE work by Scott Long. So, Oliver, you are using (I think) the file touched by scottl on 2007/05/02? No, as I wrote, I'm using RELENG_6. By the way, I am _not_ using k3b or any other krap. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xorg 7.2 start problem
JoaoBR wrote: Roland Smith wrote: It didn't. All the drivers were in one huge package, the X server. Now they are in seperate ports. But the xorg or xorgs-drivers meta-ports should install all of them. ok, that is what I ment, the better way would be that portupgrade installs them all as before (when they were in the package) That's exactly what happens when you install the xorg meta port (as explained in the UPDATING instructions). Tools like portupgrade and portmaster and even the ports system are great but they have their limitations. I think they are kept relatively simple for a reason. It's much better to have a simple (maintainable) tool that does 95% of the jobs well than to build an extremely complicated ACME contraption that can cover all the corner cases and oddball situations. It's just not worth the effort. I agree and totally understandable but when there is a big change involved then it would be wise to advise more clearly what is happening from within the upgrade process because almost nobody reads the files I think that's wrong. Almost everybody reads UPDATING. Those who don't start threads on one of the mailing lists. other ports do it for less and a message like local base has changed you need to edit your xorg.conf or something would do good here If someone refused to read UPDATING, then why would he not ignore a message that scrolls through the screen at some point? As others have already stated, there are very detailed instructions in /usr/port/UPDATING. You should not blindly update your ports without looking at that file. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network performance 6.1 stable vs 4.9
Stephen Clark wrote: The appliance is basically a firewall/nat/vpn device. We started on 6.1 last year and it has taken us a while to get things tested, plus I don't like to use a brand new release. If we go to a later release it means we have to do complete regression testing, etc. We are basically using a GENERIC config for our kernel. We, meaning the RD team don't see any performance issues in a controlled environment - 6.1 performs just as well as 4.9. In subjective tests RD has done using the following setup we see no problem: freebsd+firefox --100mbs lan--- 6.1 network appliance T1 link internet freebsd+firefox --100mbs lan--- 4.9 network appliance T1 link internet One of our testers has the same setup but is using winblows/ie in place of freebsd+firefox and subjectively says the 6.1 system is slower than the 4.9 system. I think I remember there were some problems with TCP window scaling earlier along the FreeBSD 6 branch, but I'm not sure exactly when that was. Maybe 6.1 is affected. The problem was that Windows uses an algorithm that interfered badly with FreeBSD's. While connections between FreeBSD machines didn't show any issues, the performance was suboptimal between FreeBSD and Windows. Therefore I recommend you update to 6.2-RELEASE or, even better, to RELENG_6 (6-stable). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargil, C++ Journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broken locale after upgrade to 6-STABEL from 5-STABLE
Artem Kuchin wrote: Ahh, well, i just forgot. Of course it is not for a long time now. But anyhow, why locale in C does not work? And how 'so' lib is selected for an executable? How OS selected so.5 or so.6 for a executable file? During compile-time linking (when ld(1) is called), usually the newest version of the library is used (note that libfoo.so is usually a symlink to the newest libfoo.so.*). At runtime, the dynamic linker (rtld(1)) uses the same library version that was used during compilation. If you want a binary to use a different version, you have to recompile it. (Well, there are ways to trick the dynamic linker via libmap.conf and environment variables, but that will break if the libraries in question aren't 100% ABI compatible.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to test locale in C? All my tests fail.
Artem Kuchin wrote:
I have a very stupid problem. I cannot convert to upper
or lower case using manually set locale (setlocale(..)).
A very simple program:
[...]
printf(IS UPPER ?: %d\n,isupper('?'));
printf(IS UPPER ?: %d\n,isupper('?'));
printf(IS LOWER ?: %d\n,islower('?'));
printf(IS LOWER ?: %d\n,islower('?'));
printf(LOCALE %s\n,setlocale(LC_CTYPE,NULL));
printf(1: TO UPPER %c TO LOWER %c\n,toupper('?'),tolower('?'));
printf(1-0: TO UPPER %c TO LOWER %c\n,toupper('?'),tolower('?'));
printf(2: TO UPPER %c TO LOWER %c\n,toupper('r'),tolower('R'));
[...]
IS UPPER ?: 0
IS UPPER ?: 0
IS LOWER ?: 0
IS LOWER ?: 0
LOCALE ru_RU.CP1251
1: TO UPPER ? TO LOWER ?
1-0: TO UPPER ? TO LOWER ?
2: TO UPPER R TO LOWER r
That's a common pitfall. Chars are signed by default on
FreeBSD, and the isupper() etc. function take an int type
argument. That means that characters = 128 end up as
negative numbers, so they fail all isupper() and islower()
checks, and toupper()/tolower() don't touch them at all.
The solution is to typecast the constants to unsigned char
explicitly, like this: isupper((unsigned char) '?') etc.
Your program will work fine then.
Best regards
Oliver
PS: You should also #include stdio.h
PPS: This is not a FreeBSD-specific pitfall. The ISO-C
standard does not specify the signedness of chars, and
most implementations (but not all) seem to prefer to
have chars signed by default. So, in order to write
portable programs, you always need to typecast if the
difference between signed and unsigned matters in your
application.
PPPS: I think follow-ups should go to the -standards
mailing list.
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
With sufficient thrust, pigs fly just fine. However, this
is not necessarily a good idea. It is hard to be sure where
they are going to land, and it could be dangerous sitting
under them as they fly overhead. -- RFC 1925
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ghosthunting: machine freeze 6.2R
Roger Miranda wrote: Volker wrote: [...] I've attached the latest dmesg, can you see any similarities (as it still might be a hardware issue)? [...] Our current version is: FreeBSD 6.2-RELEASE FreeBSD 6.2-RELEASE #0 Looks like you are also using the EM network adapter driver. We are suspecting the driver or Network adapters them self. Our other boxes are using xl0 (3com) and are working fine. The em(4) driver has received quite a few updates lately, and I think some of them have been MFCed to RELENG_6 since 6.2-RELEASE. I don't use any em(4) interfaces myself (I prefer bge(4) and others), so I'm not sure if there's any relationship with your trouble, but I suggest you try updating to the latest 6-stable (RELENG_6) code. (Or even give 7-current a try if you have a spare disk for installation so you can quickly swap it back with 6.x if any show-stoppers arise. In general I don't recommend installing 7-current on production machines, though.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no glxgears with xorg 7.2?
Iulian M wrote: Pietro Cerutti wrote: Michael Rudolph wrote: Harald Schmalzbauer wrote: I wanted to test OpenGL with my navidia driver but ould not find glxgears anymore (fresh 7.0/7.2 installation). Does anybody know what additionalport I have to install? Or is there a replacement? running pkg_which(1) on glxgears on my not yet updated system, reveals xorg-clients as the origin of glxgears(1). If I'm not mistaken, xorg-clients was renamed to xorg-apps during the upgrade of xorg 6.9 to xorg 7.2. That's true, xorg-apps is a meta-package for a lot of small applications X11-related. ... but glxgears isn't included. Don't ask me why, I also was looking for it some time ago, but couldn't find it. I do believe glxgears has moved to graphics/mesa-demos Correct. That's what search engines are good for. ;-) The following URL locates glxgears in graphics/mesa-demos and in x11/XFree86-4-clients: http://www.secnetix.de/tools/porgle/?plst=1q=glxgears Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing. -- Mother Teresa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Native SATA vs. PATA-emulation - difference?
Patrick M. Hausen [EMAIL PROTECTED] wrote: I have a Tyan barebone on my desk that is based on the ServerWorks HT1000 chipset. It features 4 SATA connectors and 4 hot plug drive bays. I installed FreeBSD on the system with the BIOS settings as set by the manufacturer. This includes setting the SATA mode to P-ATA emulation. The devices are probed by FreeBSD like this: [...] I set up a GEOM mirror on my boot disk, again, everythings working as expected: [...] Out of curiosity I changed the BIOS setup setting for the SATA controller to native SATA. When booting, the controller and all disks are probed OK. The output shows SATA150 for the devices. Yet, the root filesystem on /dev/mirror/gm0s1 cannot be found. Hitting ? at the prompt that asks for manual root dev specification, I get ad4, ad4s1, ad4s1a ... ad6, ad6s1, ad6s1a I can even boot ad4s1 to single user mode, so all data on the disk can be read just like when in P-ATA emulation mode. Why does gmirror fail to load? Are the disk sizes exactly the same in both cases? Please provide dmesg output from the 2nd case (native SATA). Most GEOM modules (gmirror, gjournal etc.) store their meta data in the last sector of the device. If the size of the devices change when you change the emulation mode, gmirror won't be able to locate the sector that contains the meta data anymore. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence -- Jacek Generowicz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNIX domain sockets MFC's
Marc G. Fournier wrote: That's the fun part ... I can't seem to re-create it anywhere except that one server :( And it doesn't seem to matter how many jail(s) I have on it ... I just dump'd 25 jails off of it and onto another server, and its still rising ... Then maybe it's not related to the jails at all? Dunno if this is easily possible, but you could try to boot the machine without starting any of the jails, and then check if there's already an unusual socket usage. If there isn't, then start the jails one after another (not all at once) and keep checking. Maybe it's just one specific jails (or a few of them) which trigger the problem. With that procedure it should be possible to find it (or them). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot). -- Terry Lambert, FreeBSD-hackers mailing list. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Does a pipe take a socket ... ?
Marc G. Fournier wrote: For those that remmeber the other day, I had that swzone issue, where I ran out of swap space? I just about hit it again today, swap was up to 99% used ... I was able to get a ps listing in, and there were a whack of find processes running ... Now, I think I know which VPS they were running in, so that isn't a problem ... and I suspect that the find was just part of a longer pipe ... I'm just curious if those pipes would happen to use up any of those sockets that are 'evaporating', or is this totally unrelated to sockets? In FreeBSD, pipe() is implemented with the socketpair(2) system call. Every pipe uses two sockets (one for each endpoint). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd FreeBSD is Yoda, Linux is Luke Skywalker -- Daniel C. Sobral ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNIX domain sockets MFC's
Marc G. Fournier wrote: I'm curious about something ... way back, when I was using unionfs, I had a major problem with vnode leakage ... as I mentioned before, this server is the only one I have that uses geom/gmirror on its drives, the rest all use hardware RAID ... is there *any* possibility that I'm seeing some sort of interaction issue? It really bothers me that the only server that I'm seeing this one is the one that I'm using software RAID on ... FWIW, I have two servers running RELENG_6 (2 months old) using gmirror and with a few jails (not many, though ... they're used for Apache web servers and PostgreSQL). I'm not seeing any socket leakage. $ sysctl kern.ipc | grep sockets kern.ipc.numopensockets: 118 kern.ipc.maxsockets: 12328 $ uptime 3:55PM up 82 days, 20:39, 3 users, load averages: 0.04, 0.05, 0.02 $ gmirror status NameStatus Components mirror/gm0 COMPLETE ad0 ad1 If you have more hints how to reproduce the problem, I might give it a try if it's not too much trouble. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd File names are infinite in length, where infinity is set to 255 characters. -- Peter Collinson, The Unix File System ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock problem
M. Warner Losh wrote: Oliver Fromme wrote: : M. Warner Losh wrote: : Peter Jeremy wrote: : : There seems to be a bug in ntpd where the PLL can saturate at : : +/-500ppm and will not recover. This problem seems too occur mostly : : where the reference servers have lots of jitter (ie a fairly congested : : link to them). : : Yes. This is a rather interesting misfeature of ntpd. Its rails are : at +/- 500ppm, and when it hits the rail it assumes that things are : too bad to continue and it stops. : : I think it is related to the maximum slew rate of 1/2000, : which is equivalent to 500 ppm. The ntpd(8) manpage says: : : Since the slew rate of typical Unix kernels is limited to : 0.5 ms/s, each second of adjustment requires an amortization : interval of 2000 s. : : And a bit further down: : : The maximum slew rate possible is limited to 500 parts-per- : million (PPM) as a consequence of the correctness principles : on which the NTP protocol and algorithm design are based. : As a result, the local clock can take a long time to converge : to an acceptable offset, about 2,000 s for each second the : clock is outside the acceptable range. I think you are confusing two things here. One is the maximum frequency error of the system clock that ntpd can tolerate. The other is the maximum slew rate of the system clock. I'm aware of that. It just caught my eye that both of those values are the same. : Of course, the best solution is to buy a GPS or DCF radio : receiver and set up a startum-1 yourself. But last time : I tried to do that with a cheap DCF plug, it wasn't very : well supported on FreeBSD. Even an expensive Mainberg : receiver ( http://www.meinberg.de/english/ ) with an RS232 : output worked much more accurately with a Solaris machine : than with FreeBSD. (Unfortunately, the Mainberg model : availbale to us did not have NTP support via ethernet : itself, only serial output.) I have to admit that that : was in FreeBSD 4.x days. The situation might have : improved in the meantime (I don't know). My company has used FreeBSD's ntpd since 3.x with a small, custom driver that I wrote. It turns out to work very well in practice. I'd suggest that it is well supported, even in FreeBSD 4.x. It isn't well documented. I guess you're talking about the kernel part. That's probably true. However, we had two problems (with that Meinberg receiver in particular): First, there was no working driver. I had to hack one of the existing drivers so it would work with the signals sent from the Meinberg clock. And I agree that it isn't well documented. Second, the serial port code of FreeBSD was a problem. It caused terrible jitter, and I wasn't able to fix it. It was completely unusable. I'm afraid I don't have exact numbers anymore, it has been a few years ago, but when we connected the same receiver to a Solaris machine, the jitter went away. On a related note, some time ago I got a cheap DCF radio receiver for my private use (~ EUR 50). It has a parallel port connector, I think. I was unable to find a driver that would work under FreeBSD. It caused me to do a bit of research about what receivers are actually supported under FreeBSD, and which can be bought without too much trouble (without paying EUR 1000 like those Meinberg boxes cost). I couldn't find any. The ntp docs mention some devices that seemingly could be bought 10 years ago, but they're not available anymore today. Well, so now I'm back to using a bunch of public NTP servers in my ntp.conf, and the DCF receivers catches dust in some cardboard box in the attic. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I have stopped reading Stephen King novels. Now I just read C code instead. -- Richard A. O'Keefe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock problem
M. Warner Losh wrote: Peter Jeremy wrote: : There seems to be a bug in ntpd where the PLL can saturate at : +/-500ppm and will not recover. This problem seems too occur mostly : where the reference servers have lots of jitter (ie a fairly congested : link to them). Yes. This is a rather interesting misfeature of ntpd. Its rails are at +/- 500ppm, and when it hits the rail it assumes that things are too bad to continue and it stops. I think it is related to the maximum slew rate of 1/2000, which is equivalent to 500 ppm. The ntpd(8) manpage says: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. And a bit further down: The maximum slew rate possible is limited to 500 parts-per- million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. Most PC clocks have a frequency error on the order of 10-150ppm, so it doesn't take a whole lot of jitter from a conjectsted remote network to exceed the limits... I think the burst and iburst options for the server lines in ntp.conf might help in such cases. Of course, the best solution is to buy a GPS or DCF radio receiver and set up a startum-1 yourself. But last time I tried to do that with a cheap DCF plug, it wasn't very well supported on FreeBSD. Even an expensive Mainberg receiver ( http://www.meinberg.de/english/ ) with an RS232 output worked much more accurately with a Solaris machine than with FreeBSD. (Unfortunately, the Mainberg model availbale to us did not have NTP support via ethernet itself, only serial output.) I have to admit that that was in FreeBSD 4.x days. The situation might have improved in the meantime (I don't know). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is to C as Lung Cancer is to Lung. -- Thomas Funke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd and securelevel question
Gót András [EMAIL PROTECTED] wrote: So. The simple question is: Why FreeBSD has securelevel 0 if init sets it to 1, if it sees at boot that the level is 0? :) It's OK that it's in the manual, but there are two default ways to set securelevel at boot time also. I don't really get the point of this forced 0 to 1 changing. The reason is so that /etc/rc and all of the related startup scripts can run at level 0, which might be necessary for various reasons, and afterwards the level is autmatically increased to 1. If you don't want that, you should leave the level at the default of -1. We'd like to use our machines with securelevel 0 by default, so I had comment out the relevant two lines from init.c. Uhm, could you please explain why you want to do that? It doesn't make sense. Note that level -1 behaves exactly the same as level 0 (i.e. no restrictions at all), the only difference is that -1 prevents the automatic increase to level 1 when the system goes multi-user. So, if you want to run permanently without restrictions, then you should leave the secure level at the default value of -1. It's all explained in the init(8) manual page. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing. -- Dick Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top shows 'swapped'
Ken Chen [EMAIL PROTECTED] wrote: When I use 'top' command to check my system, some processes are shown like 'php'. The manual told these processes are swapped out. Actually it means that they're not mapped into RAM, but in practice that should be the same. Just out of cusiosity I grepped the kernel sources for the PS_INMEM flag and found just two places where it could possibly be cleared for a process: during creation of a child process within the fork() system call, and when a process is being swapped out. But my problem is .. I don't have swapping device (swapoff -a). Where are they swapped to ? If you don't plan to configure any swap at all, I recommend you build a kernel with options NO_SWAPPING. It removes the code for swapping processes from the kernel. (By the way, I recommend you always configure some swap, even if you don't intend to use it under normal circumstances, except maybe on diskless machines.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargil, C++ Journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock problem
Jeffrey Goldberg wrote: Oliver Fromme wrote: Martin Dieringer wrote: Oliver Fromme wrote: Are you sure that your /etc/ntp.conf ist correct? # cat /etc/ntp.conf server time.fu-berlin.de iburst maxpoll 9 driftfile /var/db/ntp.drift logfile /var/log/ntpd You must add restrict lines for every server and for localhost, like these: restrict time.fu-berlin.de nomodify restrict 127.0.0.1 Sorry, I forgot one line: restrict default ignore Why? The default line is for security reasons, so nobody else can modify your ntpd. The nomodify line enables time synchronization with the server, but prevents it from being able to modify your ntpd settings. Finally, the line for localhost enables you to use tools like ntpdc and ntpq locally. It's all explained in the ntp.conf(5) manual page. Other than that, the config looks good. There's no need to add further time servers. The time adjustment algorithms of NTP make use of multiple time sources. NTP works best with having at least three reachable servers. Of course ntp is designed to keep good time even when you are disconnected from the net, but it builds up its data from multiple sources and using triangulation to correct for errors. NTP works perfectly well with a single source. Having multiple sources is not necessary on an end client (but it doesn't hurt either, of course). Of course, on a server that provides NTP service itself to a subnet or similar, having multiple upstream servers is desirable. In fact, ntpd refuses to synchronize against a server that does not have at least two upstream servers (non- stratum-16) itself. Martin's Problem with ntpd is not a precision problem. His problem is that his ntpd does not synchronize at all. Adding more servers certainly won't solve that problem. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock problem
Martin Dieringer wrote: # ntpq -p remote refid st t when poll reach delay offset jitter == *time192.53.103.108 2 u 19 64 77 91.454 301.926 860.104 and the clock is only 3 seconds late now... The delay, offset and jitter values are in milliseconds, so your current offset is about 0.3 ms. When you keep ntpd running, the offset should be reduced slowly. ntpd calculates the drift of the local clock. During times when it cannot reach the server, it corrects the local clock using the recorded drift. ok this sounds beautiful, but what if the drift is irregular? Normal quartz-controlled hardware clocks don't have an irregular drift. PC clocks aren't well-known for their precision, but the drift should be fairly constant. If your drift is noticeably irregular, then there is some- thing very wrong with your machine. I'm afraid that ntpd won't work very well under such circumstances. In that case you'll have to find out the cause of the problem and fix it, or help a FreeBSD to fix it (by providing the necessary pieces of information). But 2 minutes is also too much ntpd should be able to handle that without problems. yes maybe, sometimes... Well, I agree that 2 minutes per day is much. Normally the maximum drift that can be corrected by slewing the clock is about 45 seconds per day (500 ppm). However, if the offset is larger than a certain limit, ntpd will step the clock anyway, so even a drift of 2 minutes should be correctable. (I think the limit is 128 ms, and the step will occur if the limit is exceeded for at least 15 minutes. But I'd have to look at the source code to be sure; the manual pages are sometimes not up- to-date with regard to such details.) I have to redialup every 24h which normally works fine. How are you redialling? If you get a new dynamic IP address, it might be necessary to restart ntpd. MYADDR: !bg /etc/rc.d/ntpd restart great! 8-( as restart does not work because the pid seems to be wrong and usually there are 5 or so ntpd's running... ? Hu? There should be exactly one ntpd process running. You should clean up (kill all of them, remove any bogus PID file if there's one left, then restart ntpd). btw, this is on the other machine which is now 2 minutes off again, maybe 1 hour after correct setting: # ntpq -p remote refid st t when poll reach delay offset jitter == chronos.zedat.f .PPS.1 u 457 512 377 366.965 37369.6 8640.85 log: 8 May 16:11:08 ntpd[57617]: synchronized to 130.133.1.10, stratum=1 8 May 16:11:08 ntpd[57617]: time reset +0.651381 s 8 May 16:11:08 ntpd[57617]: kernel time sync disabled 2041 8 May 16:12:22 ntpd[57617]: synchronized to 130.133.1.10, stratum=1 8 May 16:13:30 ntpd[57617]: no servers reachable now: 16:57 A jitter of 8 seconds is really a lot. Is your uplink that bad? Of course, that adds to the problem that you already have because of (supposedly) irregular drift. If you have multiple machines behind the same uplink, it might be a good idea to configure one of them as an NTP server (preferably the one which has the smallest drift), and let all your other machines use that machine as the NTP time source. So at least all your own machines are synchronized with each other, and you separate the problem of the drift from the problem of a bad uplink. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top shows 'swapped'
Thomas Hurst wrote: I'm seeing this sort of thing too -- I do have swap, but it's not being used by these processes (swapoff -a didn't do anything to them): Mem: 1672M Active, 5337M Inact, 279M Wired, 400M Cache, 215M Buf, 74M Free Swap: 10G Total, 12K Used, 10G Free 1251 www 1 40 87884K 0K accept 2 0:00 0.00% httpd 1106 root 1 200 12756K 0K pause 1 0:00 0.00% smbd 950 root 1 1150 8536K 0K select 3 0:00 0.00% pure-ftpd 1143 mysql 1 80 5220K 0K wait 3 0:00 0.00% sh 1288 root 1 50 3644K 0K ttyin 2 0:00 0.00% getty The bulk of the data is probably swapped to the on-disk binaries, You probably mean that the text pages of the binary have not been paged into memory (that's different from swapping). That's unlikely. but this would imply there isn't a single page unique to each process. I don't think that could happen. As soon as you link with libc (which sh, httpd and others certaily do), you get a bunch of global variables and other things that are not shared across processes. Quite why it's bothering in the first place with 5GB Inact I'm not sure -- is it unmapping idle processes to conserve VM objects? That doesn't happen. FreeBSD has a feature to proactively swap processes that have been idle for a certain time, but it's disabled by default, see: sysctl vm.swap_idle_enabled I also find it interesting that I only noticed this behavior a few days ago and suddenly someone else mentions it too :) I don't see it on any of my FreeBSD 6-stable machines, but they run RELENG_6 of about 2 months ago. Maybe a subtle bug has been introduced recently. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock problem
Martin Dieringer wrote:
My clock is now _15 minutes_ late, after about 1 day with powerd
running.
ntpd is running also.
Can nobody tell where the problem is here?
Are you sure that your /etc/ntp.conf ist correct?
Are there any messages from ntpd in /var/log/messages?
What's the output from ntpq -p?
Make sure that you have these two lines in /etc/rc.conf:
ntpd_enable=YES
ntpd_sync_on_start=YES
The second one is important -- it passes the -g option to
ntpd. Without that option, ntpd refuses to perform an
initial correction if the clock offset is too large.
If there are still problems, please show us the contents
of your /etc/ntp.conf file.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
PI:
int f[9814],b,c=9814,g,i;long a=1e4,d,e,h;
main(){for(;b=c,c-=14;i=printf(%04d,e+d/a),e=d%a)
while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Socket leak (Was: Re: What triggers No Buffer Space) ?Available?
Marc G. Fournier wrote: Oliver Fromme wrote: If I remember correctly, you wrote that 11k sockets are in use with 90 jails. That's about 120 sockets per jail, which isn't out of the ordinary. Of course it depends on what is running in those jails, but my guess is that you just need to increase the limit on the number of sockets (i.e. kern.ipc.maxsockets). The problem is that if I compare it to another server, running 2/3 as many jails, I'm finding its using 1/4 as many sockets, after over 60 days of uptime: kern.ipc.numopensockets: 3929 kern.ipc.maxsockets: 12328 What kind of jails are those? What applications are running inside them? It's quite possible that the processes on one machine use 120 sockets per jail, while on a different machine they use only half that many per jail, on average. Of course, I can't tell for sure without knowing what is running in those jails. But, let's try what I think it was Matt suggested ... Yes, that was a good suggestion. right now, I'm at just over 11k sockets on that machine, so I'm going to shutdown everything except bare minimum server (all jails shut off) and see where sockets drop to after that ... I'm down to ~7400 sockets: kern.ipc.numopensockets: 7400 kern.ipc.maxsockets: 12328 ps looks like: mars# ps aux USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND [kernel threads omitted] root 1 0.0 0.0 768 232 ?? ILs Sat12PM 3:22.01 /sbin/init -- root 480 0.0 0.0 528 244 ?? Is Sat12PM 0:04.32 /sbin/devd root 539 0.0 0.0 1388 848 ?? Ss Sat12PM 0:07.21 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log -s -s daemon 708 0.0 0.0 1316 748 ?? Ss Sat12PM 0:02.49 /usr/sbin/rwhod root 749 0.0 0.0 3532 1824 ?? Is Sat12PM 0:07.60 /usr/sbin/sshd root 768 0.0 0.0 1412 920 ?? Is Sat12PM 0:02.23 /usr/sbin/cron -s root2087 0.0 0.0 2132 1360 ?? Ss Sat01PM 0:04.73 screen -R root 88103 0.0 0.1 6276 2600 ?? Ss 11:41PM 0:00.62 sshd: [EMAIL PROTECTED] (sshd) root 91218 0.0 0.1 6276 2664 ?? Ss 11:49PM 0:00.24 sshd: [EMAIL PROTECTED] (sshd) root 813 0.0 0.0 1352 748 v0 Is+ Sat12PM 0:00.00 /usr/libexec/getty Pc ttyv0 root 88106 0.0 0.1 5160 2516 p0 Ss 11:41PM 0:00.20 -tcsh (tcsh) root 97563 0.0 0.0 1468 804 p0 R+ 12:17AM 0:00.00 ps aux root2088 0.0 0.1 5352 2368 p2 Is+ Sat01PM 0:00.03 /bin/tcsh root2112 0.0 0.1 5220 2360 p3 Ss+ Sat01PM 0:00.04 /bin/tcsh root 91221 0.0 0.1 5140 2440 p4 Ss+ 11:49PM 0:00.12 -tcsh (tcsh) I don't think those processes should consume 7400 sockets. Indeed, this really looks like a leak in the kernel. And netstat -n -funix shows 7355 lines similar to: d05f1000 stream 0 00 d05f109000 d05f1090 stream 0 00 d05f100000 cf1be000 stream 0 00 cf1bdea000 cf1bdea0 stream 0 00 cf1be00000 cec42bd0 stream 0 00 cf2ac48000 cf2ac480 stream 0 00 cec42bd000 with the final few associated with running processes: How do you determine that? You _cannot_ tell from netstat which sockets are associated with running processes. I'm willing to shut everthing down like this again the next time it happens (in 2-3 days) if someone has some other command / output they'd like fo rme to provide the output of? Maybe sockstat -u and/or fstat | grep -w local (both of those commands should basically list the same kind of information). My guess is that the output will be rather short, i.e. much shorter than 7355 lines. If that's true, it is another indication that the problem is caused by a kernel leak. And, I have the following outputs as of the above, where everythign is shutdown and its running on minimal processes: # ls -lt total 532 - -rw-r--r-- 1 root wheel 11142 May 8 00:20 fstat.out - -rw-r--r-- 1 root wheel 742 May 8 00:20 netstat_m.out - -rw-r--r-- 1 root wheel 486047 May 8 00:20 netstat_na.out - -rw-r--r-- 1 root wheel 735 May 8 00:20 sockstat.out ^^^ Aha. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list
Re: mfs and buildworlds on the SunFire x4600
Mars G. Miro wrote: Oliver Fromme wrote: Mars G. Miro wrote: there's been a lot of threads in teh past that a buildworld on mfs increases speed --- tho it might not be the appropriate test for high-end machines (speaking of w/c I just gots a T2000). It depends on what exactly you want to test, and for what reason. You probably have already wasted much more time with your experiments and testing than you can ever save by using mfs for buildworld. wasted my time? dont think so. now we know buildworld on mfs dont really matter on high-end machines, No, we knew that before. I could have told you. :-) That was the first thing I tested when I first had access to a machine with sufficient RAM, about 10 years ago. I put /usr/src on an MFS disk, ran buildworld, and was disappointed. so teh conclusion would be, buildworld isnt teh appropriate test if mfs does really speed things up, other apps/tools may be much more appropriate --- that or, does mfs speeding things up really work? remains to be seen ... The only case for which a memory file system is really faster is when you're handling a huge number of inodes, for example the ports collection. And even then a real disk isn't much slower as soon as the whole bunch is in the cache. there's prolly other appropriate apps/tools for mfs-testing ... I don't think it makes much sense to benchmark mfs. It is a known fact that a real tmpfs (like Solaris and Linux have) would be better. I think it's even listed on the FreeBSD ideas web page, but nobody is actively working on it, AFAIK. On the other hand, I'm not 100% convinced that it would be worth the effort either. it does to me, however, and perhaps other people too ;-) Why? I wonder why you are so eager to test MFS? It would be interesting to see how ZFS on a swap-backed vnode device would perform on FreeBSD 7-current (with and without compression). You didn't comment on that one. Aren't you interested in how a ZFS-based memory disk would perform, as opposed to a UFS-based one (a.k.a. MFS)? (Of course, performance isn't everything. ZFS has other features such as compression, checksums and dynamic growth that might be very useful for a memory disk.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock problem
Martin Dieringer wrote: Oliver Fromme wrote: Are you sure that your /etc/ntp.conf ist correct? # cat /etc/ntp.conf server time.fu-berlin.de iburst maxpoll 9 driftfile /var/db/ntp.drift logfile /var/log/ntpd You must add restrict lines for every server and for localhost, like these: restrict time.fu-berlin.de nomodify restrict 127.0.0.1 Other than that, the config looks good. There's no need to add further time servers. Restart ntpd for the changes to take effect (``/etc/rc.d/ntpd restart''). # ntpq -p No association ID's returned That's because the default (when no restrict lines are there) doesn't allow a connection at all.. Make sure that you have these two lines in /etc/rc.conf: ntpd_enable=YES ntpd_sync_on_start=YES how can I sync on start if I have to first dialup? ntpd does that as soon as it can reach the server for the first time. You don't have to worry about it. I have ntpd_flags=-g - the same? Yes. ntpd_sync_on_start is exactly the same. and how will the clock run when not connected to the internet? ntpd calculates the drift of the local clock. During times when it cannot reach the server, it corrects the local clock using the recorded drift. it should at least be somehow in a sensible range Yes, it should, if the off-line times aren't too long. now this is the machine with 2 minutes offset after 30hours uptime (the other one has ntpd killed at signal 15 - some version problem I think) But 2 minutes is also too much ntpd should be able to handle that without problems. I can ping the server ok and internet was working at that time. I have to redialup every 24h which normally works fine. How are you redialling? If you get a new dynamic IP address, it might be necessary to restart ntpd. For example, if you use ppp(8) for dial-up, you can write a linkup script that performs the restart. I.e. create a script /etc/ppp/ppp.linkup with these lines in it: MYADDR: !bg /etc/rc.d/ntpd restart Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd (On the statement print 42 monkeys + 1 snake:) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives 42 monkeys1 snake, when the answer is clearly 41 monkeys and 1 fat snake.-- Jim Fulton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incorrect df -k output??
Newtunes Support [EMAIL PROTECTED] wrote: I have resolved this issue using forsed unmount (umount -f /var) Not a good idea. It breaks all sorts of things. And after I mounted /var again df -k shows me correct value. The value was correct before, too. There probably were some files that were removed, but some processes still had them open. du(1) doesn't see those files, so they're not included in the sum. df(1) sees the allocated space, of course. It can happen on the /var file system if an error occurs during log file rotation, so the programs writing to the log files (e.g. syslogd) are not properly informed about the rotation, so they keep the old files open. A good way to view such files/processes is to use the command lsof +L1 (lsof can be installed from the ports collection: /usr/ports/sysutils/lsof). It lists all file descriptors in use that have a link count of zero. The correct way to resolve the issue is to find those processes and tell them to close the files (usually a kill -HUP will do that). If everything else fails, kill the processes (use kill -KILL if necessary). Do not use umount -f. But I have new problem. fsck -y does not fix anything. That only works when the file system is not mounted (or only mounted read-only). It's usually done in single- user mode. (However, I assume that your file system doesn't need fsck, but it certainly wouldn't hurt either.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python tricks is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure wink. -- Tim Peters ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror security problem on jail env?
Manuel Martini wrote: # sysctl -a | grep jail [...] security.jail.jailed: 1 # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/gm0s1g 129719744 17056610 10228555614%/ # gmirror status NameStatus Components mirror/gm0 COMPLETE da0 so I think I can do... gmirror remove.. stop.. deactive... No, you can do status and list, but everything else should result in permission denied. Note that you can do gmirror status and gmirror list as normal user, even as user nobody. It doesn't require any special privileges, so it works in jails, too. In fact, you can get the geom status (in XML format) with the command sysctl -b kern.geom.confxml. Unfortunately there is currently no easy way to suppress that information. If you don't want jailed users to be able to see your geom configuration, you need to modify the kernel source code. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'. -- Oddbjorn Steffensen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mfs and buildworlds on da SunFire x4600
Mars G. Miro wrote: Actually, it's not about having to finish building da world in da smallest amount of time, it's about whether mfs would really speed things up... I've made similar tests in the past, and my conclusion is that it's not worth it. Using a memory disk for /usr/obj doesn't make much sense, because soft-updates decouples the physical writes pretty well from the build process. On the other hand, using a memory disk for /usr/src _might_ help a little, but it depends on a lot of things. Especially if you have a speedy I/O system and plenty of RAM (so all of the files can be cached) and /usr/src is mounted with the noatime option, the difference is very small. By the way, please stop writing da instead of the. It looks childish and makes your mails difficult to read, so it might prevent people from helping you. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly. -- RFC 2549 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Socket leak (Was: Re: What triggers No Buffer Space) Available?
Marc G. Fournier wrote: Now, that makes sense to me, I can understand that ... but, how would that look as far as netstat -nA shows? Or, would it? For example, I have: You should use -na to list all sockets, not -nA. mars# netstat -nA | grep c9655a20 c9655a20 stream 0 00 c95d63f000 c95d63f0 stream 0 00 c9655a2000 mars# netstat -nA | grep c95d63f0 c9655a20 stream 0 00 c95d63f000 c95d63f0 stream 0 00 c9655a2000 They are attached to each other, but there appears to be no 'referencing process' netstat doesn't show processes at all (sockstat, fstat and lsof list sockets by processes). The sockets above are probably from a socketpair(2) or a pipe (which is implemented with socketpair(2), AFAIK). That's perfectly normal. If I remember correctly, you wrote that 11k sockets are in use with 90 jails. That's about 120 sockets per jail, which isn't out of the ordinary. Of course it depends on what is running in those jails, but my guess is that you just need to increase the limit on the number of sockets (i.e. kern.ipc.maxsockets). Again, if I'm reading / understanding things right, without the 'referencing process', it won't show up in sockstat -u, which is why my netstat -nA numbers keep growing, but sockstat -u numbers don't ... which also means that there is no way to figure out what process / program is leaving 'dangling sockets'? :( Be careful here, sockstat's output is process-based and lists sockets multiple times. For example, the server sockets that httpd children inherit from their parent are listed for every single child, while you see it only once in the netstat output. On the other hand, sockstat doesn't show sockets that have been closed and are in TIME_WAIT state or similar. Are you sure that UNIX domain sockets are causing the problem? Can you rule out other sockets (e.g. tcp)? In that case you should run netstat -funix to list only UNIX domain sockets (basically the same as the -u option to sockstat). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD vs Region Code DVDs
Ulrich Spoerlein wrote: [...] Anyway, how can I tell cd(4) to give me more error output? How can I access the DVD at the bottom-most layer? Something line sending a Test Unit Ready command? Or checking if the drive recognizes an inserted medium? camcontrol tur will do that. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Life is short (You need Python) -- Bruce Eckel, ANSI C++ Comitee member, author of Thinking in C++ and Thinking in Java ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mfs and buildworlds on the SunFire x4600
I took the liberty to s/da/the/g in your mail. Mars G. Miro wrote: Oliver Fromme wrote: Mars G. Miro wrote: Actually, it's not about having to finish building the world in the smallest amount of time, it's about whether mfs would really speed things up... I've made similar tests in the past, and my conclusion is that it's not worth it. Using a memory disk for /usr/obj doesn't make much sense, because soft-updates decouples the physical writes pretty as i've mentioned in my original email, the mfs's were created w/ softupdates turned off No, I'm not talking about the memory disks. It's rather irrelevant whether you use soft-updates on them or not. What I meant is this: If you use a normal disk (not memory disk) for /usr/obj, soft-updates will decouple the writes from the compilation process, so the buildworld will be less I/O-bound. With good hardware it should be just as fast as a memory disk. Therefore it does not make sense to use a memory disk for /usr/obj, IMHO. well from the build process. On the other hand, using a memory disk for /usr/src _might_ help a little, but it depends on a lot of things. Especially if you have a again, both /usr/src and /usr/obj were mfs, and even async, noatime Doesn't matter for memory disks. speedy I/O system and plenty of RAM (so all of the files can be cached) and /usr/src is mounted with the noatime option, the difference is very small. as Kris mentioned, a buildworld isnt prolly the appropriate test for mfs, That's correct. as for the chrooted /usr or the buildkernel tests, I havent really tried them --- will try to do so and report back when i get the time ... By the way, what are you actually trying to do? What is your goal? Do you need to reduce the buildworld time? In that case, excluding some things that you don't need (via NO_* variables in /etc/make.conf) will probably give much better results than trying to play with mfs. For example, on most of my machines, I have the following in /etc/make.conf, reducing buildworld times noticeably: NO_KERBEROS=yes NO_BLUETOOTH=yes NO_FORTRAN=yes NO_I4B=yes NO_ATM=yes NO_VINUM=yes NO_OBJC=yes NO_SHAREDOCS=yes NO_PROFILE=yes Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code (taken from comp.lang.awk FAQ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mfs and buildworlds on the SunFire x4600
Mars G. Miro wrote: Oliver Fromme wrote: By the way, what are you actually trying to do? What is your goal? Do you need to reduce the buildworld time? as i've mentioned in my original email, does mfs speed up I/O stuff ? Sometimes it does. But most of the time, a real disk partition with soft-updates on it is just as fast. With soft-updates, writing is asynchronous, i.e. it goes to RAM first, just like a memory disk. The data is later committed to disk in the background, so the processes don't have to wait for it. And once the data is in the cache, reading is just as fast (or even faster) as a memory disk. Note that /usr/src will fit in the cache easily if you have several GB of RAM. I usually have a memory disk as /tmp, but that's really just for historical reasons. And it's easier to clean up -- just umount it. ;-) there's been a lot of threads in teh past that a buildworld on mfs increases speed --- tho it might not be the appropriate test for high-end machines (speaking of w/c I just gots a T2000). It depends on what exactly you want to test, and for what reason. You probably have already wasted much more time with your experiments and testing than you can ever save by using mfs for buildworld. there's prolly other appropriate apps/tools for mfs-testing ... I don't think it makes much sense to benchmark mfs. It is a known fact that a real tmpfs (like Solaris and Linux have) would be better. I think it's even listed on the FreeBSD ideas web page, but nobody is actively working on it, AFAIK. On the other hand, I'm not 100% convinced that it would be worth the effort either. It would be interesting to see how ZFS on a swap-backed vnode device would perform on FreeBSD 7-current (with and without compression). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xfce4 desktop broken, complaining about libmd5.so.1
Chris Rees [EMAIL PROTECTED] wrote: Kind of embarrassing, I'm running 6.2-STABLE, and I recently used pkg_cutleaves to free some disk space. However, xfce's desktop doesn't work any more, neither will Thunar, and they both complain about missing file /usr/local/lib/libmd5.so.1. My locate database says it was there before I deinstalled all those packages, but I can't work out which ones I got rid of, nor which package libmd5.so.1 came from Could anyone please help me out? Install /usr/ports/www/libwww. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xfce4 desktop broken, complaining about libmd5.so.1
Oliver Fromme wrote: Chris Rees [EMAIL PROTECTED] wrote: Kind of embarrassing, I'm running 6.2-STABLE, and I recently used pkg_cutleaves to free some disk space. However, xfce's desktop doesn't work any more, neither will Thunar, and they both complain about missing file /usr/local/lib/libmd5.so.1. My locate database says it was there before I deinstalled all those packages, but I can't work out which ones I got rid of, nor which package libmd5.so.1 came from Could anyone please help me out? Install /usr/ports/www/libwww. Just a small addendum _how_ to find it out: $ cd /usr/ports $ echo */*/pkg-plist | xargs grep libmd5.so.1 (That approach works for most ports and files, but not for all of them. Some ports generate their packing list (plist) dynamically, but fortunately those are a small minority.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind. -- Alan Kay, OOPSLA '97 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xfce4 desktop broken, complaining about libmd5.so.1
Oliver Fromme wrote: Just a small addendum _how_ to find it out: $ cd /usr/ports $ echo */*/pkg-plist | xargs grep libmd5.so.1 I'm very sorry for repeatedly replying to myself, but I almost forgot that there's a much faster way to find the port which has that library: http://www.secnetix.de/tools/porgle/ Enter libmd5.so.1 into the search field, check the packing list checkbox, and click the Search button. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Being really good at C++ is like being really good at using rocks to sharpen sticks. -- Thant Tessman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xfce4 desktop broken, complaining about libmd5.so.1
Daniel O'Connor wrote: Oliver Fromme wrote: Oliver Fromme wrote: $ cd /usr/ports $ echo */*/pkg-plist | xargs grep libmd5.so.1 [...] http://www.secnetix.de/tools/porgle/ Enter libmd5.so.1 into the search field, check the packing list checkbox, and click the Search button. I suspect both of these methods wouldn't help if the plist was dynamically generated (alas) Yes, that's correct, at least for the first method (grep). I mentioned that in the previous mail (it was omitted from the quote): (That approach works for most ports and files, but not for all of them. Some ports generate their packing list (plist) dynamically, but fortunately those are a small minority.) However, the second method uses a few hacks so the plist files from most ports are included, even dynamically generated ones. There are still a few exceptions, in particular those linux ports that use AUTOMATIC_PLIST, but those are only 10 out of 16,925 ... so I'm not terribly worried. :-) For example, searching for inflate.java will correctly find the port archivers/jzlib, even though that port generates its plist dynamically. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months. -- Cliff Sarginson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xfce4 desktop broken, complaining about libmd5.so.1
Chris Rees [EMAIL PROTECTED] wrote: Maybe I should suggest adding libwww as dependiencies to xfce4 You should talk to the port's maintainer about that. However, it's not always a trivial thing to get all the possible dependencies right. Sometimes the configure script of a software happens to find a library and decides to use it and to link against it, even though it is purely optional, and the port maintainer didn't think about the possibility. Such cases aren't detected by a clean build when the library in question is not installed (such as on the FreeBSD package cluster). Of course, the opposite case _is_ detected: If a software requires a library (i.e. it's non-optional), then it will break if the library is not present. So, in fact, simply re-installing libwww will make it work, but it might still cause problems in the long run (e.g. at an update in the future), because the dependencies are still incorrectly recorded. You have two options: 1. Install libwww and fix the dependencies manually: - Add a line @pkgdep libwww-... to the file /var/db/pkg/xfce-.../+CONTENTS - Add a line xfce-... to the file /var/db/pkg/libwww-.../+REQUIRED_BY. If you use portupgrade, you probably have to rebuild its database. 2. Do _not_ install libwww, and instead rebuild xfce4. Then the configure script will not find libwww and will not link against it. Well, at least that's the theory. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: an octopus made by nailing extra legs onto a dog -- Steve Taylor, 1998 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS: optimization changed
Caution, tutorial about ufs/ffs fragmentation, space and time optimization ahead ... :-) Oleg Gritsak wrote: I'm just curious about some possible mismatch in between documentation and reallife OS behaviour... Noticed this thing for more than two years ago in 4.X and now seing this in 6.2... I agree that the description in the manual pages is oversimplifying and slightly inaccurate. It is said in man newfs and man tunefs that threshhold for online optimization (space or time) is 8 percent. It's more complex than that. There is no simple threshold, but a hysteresis which is a function of the minsize value (the -m option to newfs(8) and tunefs(1)) and the current fragmentation of the file system. If the fragmentation grows beyond minfree-2 percent (i.e. beyond 6% for the default minfree value of 8), the file system switches to space optimization in order to reduce fragmentation, or at least avoid further fragmentation. If the fragmentation drops below half of the minfree value (i.e. 4% for the default case), it switches back to time optimization. Within the hysteresis interval (i.e. 4% to 6% in the default case), you can change the optimization with tunefs -m. Otherwise the file system selects the optimization automatically whenever it needs to allocate a new block during a write operation, overriding the tunefs setting. But actually, FreeBSD switches to SPACE far more earlier (or at least reports to system message buffer). Yes, it depends on the fragmentation, as explained Does it have any sense? As also noted in man newfs, the performance while optimizing for space fragmentation is reduced. So, why FreeBSD does this when file system is for example 50% empty and has 4-5GBs of free space? That can happen if the file system is heavily fragmented. If you need to avoid it, there are several possibilities. First, during newfs, you could set fsize == bsize (e.g. both 16K). If a fragment is the same size as a whole block, fragmentation is always 0%. However, you will possibly waste some space because a fragment is the smallest allocation unit. But disks are cheap nowadays ... Second, you could increase the minfree value with tunefs -m. For example, set it to 25%, so the hysteresis grows to cover your current fragmentation. Then use tunefs -o to manually set the optimization back to time. The obvious disadvantage is that larger part of the file system (25%) is reserved and cannot be used by non-root users, i.e. some space might be wasted. But, as above, disks are cheap nowadays ... However, note that a heavily fragmented file system can theoretically run out of allocatable free space, even if it has plenty of free space -- if that free space consists only of unused parts of fragmented blocks. It can happen in exceptional circumstances. The purpose of switching to space optimization is to avoid such a situation. Therefore, to answer your question Does it have any sense?: Yes, it does. By the way, the current fragmentation is reported by fsck during boot (dmesg -a | grep fragm if it is still in your kernel message buffer). Otherwise, type dumpfs your-file-system | head and look for the blocks and nffree values. The current fragmentation is the percent value of nffree of the total blocks, i.e. nffree * 100 / blocks. For example, this is the output from one of my file systems: $ dumpfs /dev/ad0s1f | head magic 19540119 (UFS2) timeThu Apr 26 09:40:19 2007 superblock location 65536 id [ 42d80392 3470461f ] ncg 398 size37389708blocks 36211584 bsize 16384 shift 14 mask0xc000 fsize 2048shift 11 mask0xf800 frag8 shift 3 fsbtodb 2 minfree 8% optim timesymlinklen 120 maxbsize 16384 maxbpg 2048maxcontig 8 contigsumsize 8 nbfree 973428 ndir48445 nifree 8879640 nffree 290762 bpg 11761 fpg 94088 ipg 23552 You see that blocks is 36211584 and nffree is 290762, so the current fragmentation is 0.80%. Also, the current optimization is reported in the first line (time in this case). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Top not showing 4 cpus on 2 xeons with HT
Adrian Chadd wrote: anyone have any recent information about this? some people say HT sucks for almost all workloads, others say recent scheduler improvements make HT more useful.. is there anything reasonably authoritative? No, because it depends on your applications and workload. for some it is better, for some it is not. Therefore it's best you try both variants on your own machine with your own applications and measure the difference. There's one rule of thumb, however: If you only have one HTT-capable processor, then a UP kernel will almost always be the better option, because the locking overhead of an SMP kernel will probably outweigh any advantages of HTT. On the other hand, if you have a real SMP system (i.e. multiple processors or cores, not counting HTT), then you will want to use an SMP kernel anyway. In that case, enabling HTT will probably not hurt -- _but_ there have been reports of some people that HTT hurts in such a case for certain kinds of applications (I think databases was one of them, but I don't remember exactly). Anyway, there are exceptions to any rule, so you should measure yourself. Personally I disable HTT on all of my machines because of the security issue (jails do _not_ help here at all!), and speed improvements -- if any -- are marginally small, according to my own measurements. In fact I had a hard time finding any reproducible measurable improvements at all for my typical workloads; consequently my decision was governed by the security issue. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-RELEASE does not use second CPU on pentium D
Alex Povolotsky wrote: I have a Pentium D box, running 6.2-RELEASE. In dmesg, I see CPU#1 launched, but I never see any process running on it, and mptable shows Hyperthreading is disabled by default in FreeBSD (for security reasons). You can enable it via sysctl if you want (machdep.hyperthreading_allowed=1). However, note that it might not make your machine any faster (in fact, a UP kernel might be faster; it depends on the kind of programs that you're running). Also not that there is a potential security issue with hyper- threading (information leak). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd When your hammer is C++, everything begins to look like a thumb. -- Steve Haflich, in comp.lang.c++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: question: +swap_pager_getswapspace(16): failed
Harald Schmalzbauer wrote: I have a little understanding problem: My box has 128MB memory, far enough for the task. Are you sure? I see you're running perl scripts. Those can easily (and sometimes unexpectedly) eat a lot of memory. After a few days I always see some processes dying because: +swap_pager_getswapspace(2): failed +pid 48211 (perl5.8.8), uid 58, was killed: out of swap space AFAIK, the kernel selects the largest process for killing when it runs out of swap. So your perl was probably quite large. Why won't for example the 21MB Buf get freed before more swap space gets requested than available (swap is very low, it's FlashDisk!)? Is there a way to find out what process is swapped? There's a difference between swapped and paged. Swapped means that a process has been _completely_ moved to swap space. Such processes had a W flag in the state column of ps(1). In contrast to that, paging happens on pages, not on processes. Note that pages are not uniquely assigned to one process, but they can be shared between processes, so it's difficult (or even impossible) to give clear numbers on the amount of paging per process. Thanks for any hints. My only way to circumvent this problem is to reboot the machine daily. I've also set up machines with limited RAM and without hard disk for swapping. I never swap onto flash memory, because flash has a limited number of write cycles (it suffers from certain wear). If you have another server within short network distance, you should consider remote swapping via NFS. It's not as slow as it sounds (depending on the speed of the network and the server), and at least it's better than nothing. Otherwise, don't swap (or page) at all. The folowing sysctl will optimize your system for that case: vm.swap_enabled=0 vm.swap_idle_enabled=0 vm.defer_swapspace_pageouts=1 vm.disable_swapspace_pageouts=1 kern.ipc.shm_use_phys=1 You should also build a custom kernel that contains options NO_SWAPPING. Also make sure that you remove everything from your kernel that you don't need, so more memory is availale for userland. In particular, remove options UFS_DIRHASH, because the dirhash code can eat quite a lot of memory. And of course you should not run any processes that you don't really need. But I guess you already know that. It might also help to set the R malloc flag: # ln -s R /etc/malloc.conf It can reduce memory fragmentation for processes that do a lot of small (re)allocations. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is to C as Lung Cancer is to Lung. -- Thomas Funke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
Stefan Lambrev wrote: All those things work only under i386 right ? There is no option VESA in amd64 ? Right. Calling function in the VESA BIOS (which is 32bit i386 code) is not supported under FreeBSD/amd64. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
JoaoBR [EMAIL PROTECTED] wrote: On Wednesday 04 April 2007 00:05, you wrote: Console is not intended for everyday use! You should login to your FreeBSD box with ssh-client of your choise and from the OS of your choise (preferably from graphic mode). please stay on topic the question is not what one should or not but to hook into your talk, if there is a console it can be used as wanted He is perfectly on topic. Normally you shouldn't have to use syscons at all. On desktop machines, you install X and run it at your favourite resolution. Server machines usually run headless anyway, and you connect to them via ssh or via a serial terminal server. Having to go to a server and work at the syscons console would be an exception (e.g. in case of emergency, when you're not even able to get the box up in single-user mode on the serial console). Of course there are exceptions to those rules. But that's what they are: exceptions. If you need to work on a server regularly at its physical display, it's probably a good idea to install X, as if it was a desktop machine. In fact, if you do work there regularly, then it acts partially as a desktop machine or workstation, so it deserves to run X. If installed and configured properly, the overhead of starting and running the X server is low. Having said that, FreeBSD's syscons _does_ support higher resolutions if you really want to have them (see the pixel mode support and the VESA options in the vindcontrol(8) manpage). If that's still not enough, well, then you have to write code yourself and submit it. The fact that nobody has done that so far indicates that not too many people are in need for more than what's already there. 1024x768 is more than enough for 120x50 virtual terminals. may be for you, for me and lot of other users it is definitly not How did you get the number of lot of other users? From the discussion so far it rather seems to be a small minority. p.s. Or you just trolling? RH is rather professional, but definitely not because of graphics in console... :-\ don't try to be smart with me Admittedly your style of writing looks a lot like trolling. (But I assume anyway that you're not intentionally trolling, otherwise I wouldn't reply at all and instead add you to my killfile.) nobody said that RH is professional because of it's graphics in console I said that for example RH looks professional with the graphic boot they offer I rather agree with Peter Jeremy here. FreeBSD's boot looks more professional than a colorful but less informative graphical boot like the one on RH or SuSE (or even Windows). Of course, that matters only if you're a professional yourself. If you're not, then I certainly believe that you prefer the graphical boot. FWIW, most of the time machines boot without _anyone_ watching anyway. If you need to see the boot messages, you ssh into the box and type dmesg -a or look at the file /var/run/dmesg.boot (and /var/log/console.log which can be enabled via /etc/syslog.conf). Best regards Oliver PS: Please respect the Reply-To header. I do read the list and do not want to get additional copies of mails. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd (On the statement print 42 monkeys + 1 snake:) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives 42 monkeys1 snake, when the answer is clearly 41 monkeys and 1 fat snake.-- Jim Fulton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Chris H. [EMAIL PROTECTED] wrote: Oliver Fromme wrote: [...] However, I don't think that your actual problem (lock-up and panics) is related to rpc.lockd or rpc.statd. It rather sounds like something else is wrong with your machine. NFS works perfectly fine for me, including copying huge files. You wrote that you had a lot of crashes that accumulated many files in lost+found. Well, maybe your filesystem was somehow damaged in the process. It is possible to damage file systems in a way that can lead to panics, and it's not necessarily detected and repaired by fsck. Indeed. I /too/ considered this. However, I largely dismissed this as a possibility as most all of them are 0 length in size. The others are fragments of logs. I'm not /completely/ ruling this out though. The files in lost+found aren't the problem. The problem is the things that you cannot see, and fsck won't move those to lost+found. In particular, if you use softupdates on drives that have write-caching enabled, or on drives that illegally cache data even if it's disabled (be it intentionally or because of bugs in the firmware), it's almost guaranteed that the FS will take damage beyond repair on a crash, and even more so after several crashes. Another potential cause of problems is the background fsck feature in FreeBSD 6. I'm not sure if it has been fixed in 6-stable, maybe it has. I don't want to spread FUD. But in the past, if a machine crashed and rebooted during a background fsck, that was almost a guarantee for damage beyond repair, too. That's why I always disable background fsck on my machines. (Let me repeat: It _might_ be fixed in 6-stable, I don't know. I haven't seen a definitive confirmation of it being fixed on the mailing lists so far. If somebody knows otherwise, please correct me.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered. -- Guido van Rossum ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd64: cc -dumpmachine [ffmpeg]
Andriy Gapon wrote: [sorry for spamming so many lists but all of them seem to be relevant] $ uname -srm FreeBSD 6.2-RELEASE-p2 amd64 $ cc -dumpmachine $ I get the same empty result on a 32bit RELENG_6 (i386) machine here. It seems to be normal. At least configure script of the latest ffmpeg-devel port seems to be confused by this. Works fine here on said i386 machine. So it must be something else, no related to the -dumpmachine output, but maybe amd64-related. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
Craig Boston wrote: [...] I only wish 1024x768x4 worked right as (on most cheap video hardware anyway) pushing all the data for 16-bit modes though VESA is quite slow. As it's mostly an IO bandwidth issue, the planar modes should be faster. I can get 800x600x8 working and it's definitely quicker than 800x600x16. I think 800x600x4 would be even quicker, because no VESA calls are required at all for screen output. (All x4 modes use a planar layout. If such a bitplane is larger than 64K, so-called bank switching is required to access all of the video memory, because the VGA address space allows only a 64K window for access at once. VESA calls are required to perform the bank switching. For a resolution of 800x600, a bitplane is 60K, so no bank switching is required, and the whole video memory can be accessed directly.) I think FreeBSD's syscons supports it via flags 0x80 for the sc device in the kernel config file. See the section Driver Flags in the sc(4) manual page. Best regards Oliver PS: It should be noted that all of that VESA stuff only works for FreeBSD/i386. FreeBSD/amd64 isn't capable of performing calls into the 32bit VESA BIOS. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Chris H. [EMAIL PROTECTED] wrote: Thomas David Rivers wrote: I have found that if I kill rpc.lockd on the NFS server, most of the NFS issues I have (including a similar lock-up on 6.1-RELEASE) go away. FWIW, I also had problems with running rpc.lockd and rpc.statd (no panics, though). If you don't need them (i.e. you don't need cross-machine locking), then don't use them. Use the -L flag to mount_nfs so at least local locking works. You don't happen to have any experiences keeping rpc.statd running? Basically, it doesn't make much sense to run one without the other. If you disable rpc.lockd, you can also safely disable rpc.statd. However, I don't think that your actual problem (lock-up and panics) is related to rpc.lockd or rpc.statd. It rather sounds like something else is wrong with your machine. NFS works perfectly fine for me, including copying huge files. You wrote that you had a lot of crashes that accumulated many files in lost+found. Well, maybe your filesystem was somehow damaged in the process. It is possible to damage file systems in a way that can lead to panics, and it's not necessarily detected and repaired by fsck. # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined You should try to setup a dump device, so you get a kernel crash dump next time. The crash dump can be used to find out where the crash occured -- and I bet it's not in the NFS code. See the Handbook for details on how to setup a dump device. By the way, does the problem also occur when copying the file to/from a memory disk, so no physical disk is involved? That way you would exclude the disk and the disk driver as potential causes. Similarly, try a loopback NFS mount (i.e. mount from 127.0.0.1) in order to exclude the network interface driver as a potential cause. If the problem still exists when copying a 10 MB file from a memory disk to a memory disk (same or other) via a localhost mount on the same machine, then it looks like the NFS code might be at fault. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi/mpt problem with latest source
Matthew Jacob wrote: (xpt0:mpt0:0:-1:-1): reset bus periph:sim:channel:target:lun target == lun == -1 == wildcard, so the initial bus reset applies to a nexus for all targets and luns on that channel on that sim (mpt0) on that periph (xpt0) would you mind to tell why it happens and this -1 values ? As far as the why is concerned: _All_ scsi controller drivers reset their busses at first, in order to reset all devices to a well-known state. Then they wait a short time, in order to give the devices an opportunity to finish their reset, then the busses are scanned for devices. Well, at least that's who the scsi controller drivers work that I've used in the past (not including mpt), but I guess it's basically the same for all of them. So, the bus reset during boot is perfectly normal. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw add pipe broken?
JoaoBR [EMAIL PROTECTED] wrote: On Sunday 01 April 2007 12:04, Mike Tancsa wrote: At 10:07 AM 4/1/2007, JoaoBR wrote: it seems I can not add pipes with releng6 sources from the last days ipfw add pipe 1 ip from any to any ipfw: getsockopt(IP_FW_ADD): Invalid argument or any similar add pipe command does not work (sure I have options DUMMYNET in kernel) world and kernel from march 29 works still fine anything changed? There were a bunch of MFCs. When I try from a kernel today, seems the thing happened on saturday by all respect to Julians work but with ipfw broken and sunday fucked up ... kind of scaring when seeing I have no time to check, I do it on tuesday or I need to do the userland ipfw too to add some new features, but, not today.. Well, FreeBSD is mostly a volunteer project, so people work on it when they have time. Admittedly, you're right that any changes should be tested. But in reality it's not always that easy. Some changes are complex so that not all possible things can be tested. And some changes _seem_ trivial and obviously don't need to be tested (especially if a nearly identical change ran for months in -current), but then that might turn out to be a mistake. Errare humanum est. (Translation: shit happens.) please do it all or don't do it, ipfw is an mature and essential part where we do not espect such sudden surprises in releng6 to happen First, if you absolutely don't want surprises, then you should run RELENG_6_2, not RELENG_6. If you run RELENG_6, you should be prepared and able to deal with breakages. (Even if it's unusual that RELENG_x breaks, it does happen sometimes. The FreeBSD Handbook chapter staying stable contains appropriate warnings.) And second, it's not a big deal to go back to Friday's sources until Julian had time to fix the issue, is it? Best regards Oliver PS: Right now I'm much more concerned with the security issue of the file utility. FreeBSD's version of file(1) in the base system seems to be vulnerable to the recently discovered (~ 2 weeks ago) issue, as far as I can tell. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
