Re: gvinum start volume returns EBUSY
On Mon, May 01, 2006 at 03:27:11PM -0500, Rick C. Petty wrote: > When rebuilding a degraded plex with "gvinum start volume" on a mounted > filesystem, gvinum reports "errno: 16" (EBUSY). In the CVS: > > src/sys/geom/vinum/geom_vinum_init.c, lines 363-364 (of MAIN, added > 2005-Oct-09, rev 1.10.2.1) has the check: > > if (gv_is_open(p->geom)) > return (EBUSY); > > Why is this the case? The log for that change suggests this is to prevent > sync operations from starting when they are already in progress, but that > really refers to lines 366-367: > > if (p->flags & GV_PLEX_SYNCING) > return (EINPROGRESS); > > It seems to me that lines 363-364 should be deleted. If you have a > degraded volume but need to keep it mounted (such as /usr or /home, etc.), > I can't see any reason why you should be forced to unmount the volume > before rebuilding (if the volume is RAID5). Maybe this restriction is > useful for non-RAID5 configurations, but gv_rebuild_plex is only called > in the context of GV_PLEX_RAID5 on degraded plexes. > > Maybe I'm misunderstanding something. Feel free to enlighten me! :-) While regular vinum allowed rebuilding plexes that were mounted, I have seen resulting filesystem corruption afterwards. Unfortunately I don't know whether Lukas has implemented & tested rebuilding online plexes for gvinum yet. --Stijn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
loop in kgdb unread message buffer?
Hi, I just had a crash, luckily I could dump a core with 'call doadump'. However something with the serial console was wrong so my screen was spammed with %%% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) %%% etc. Now I did not worry about this because I thought I could use kgdb on the dump after the reboot. However it seems that kgdb is running into some infinite loop printing these messages; I have ran it for about 20 minutes where it kept repeating this message, with some block nrs. intertwined. I think it repeats though because I have seen block nr '96' (lucky ^S timing) and it still doesn't stop. Is there a way to *not* print the 'Unread portion of the kernel message buffer' (as it is apparently called) on startup? --Stijn -- Coffee is the path to the bouncy side. Coffee leads to activity. Activity leads to moving. Moving leads to bouncing. ... (meaningful silence) ... I sense much coffee in you. -- Matthijs Piek pgpzRQRUw1CYg.pgp Description: PGP signature
Re: telnetd/sshd and Kerberos tickets (PAM)
On Fri, Oct 21, 2005 at 05:10:39PM +0200, Harti Brandt wrote:
> On Fri, 21 Oct 2005, Stijn Hoop wrote:
> SH>On Fri, Oct 21, 2005 at 04:08:14PM +0200, Harti Brandt wrote:
> SH>> I have enabled the pam_krb5 module in pam.d/{login,telnetd,sshd}. When
> SH>> login in locally I get a Kerberos ticket as I would expect. When logging
> SH>> in via ssh or telnet I don't get one. I have digged around in the
> sources
> SH>> and it locks like telnetd never calls pam_setcred() which would do this
> SH>> work. My PAM-foo is rather limited so my question is: shouldn't sshd and
> SH>> telnetd call pam_setcred() somewhere?
> SH>
> SH>WRT sshd I bugged des@ about this but did not receive an answer :( See
> SH>the attached mail.
>
> Hmm. I digged around a little bit and found something:
>
> http://bugzilla.mindrot.org/show_bug.cgi?id=789
>
> From a first glance it seems that this bug was introduced by fixing
> another bug.
I see. If I understand correctly, disabling privsep will fix it?
Still, I would really like to get an answer to my PAM question:
"Is it allowed for an application to only call pam_setcred with the
PAM_REINITIALIZE_FLAG, while never having called it with PAM_ESTABLISH_CRED?"
Did you find out yet?
--Stijn
--
"An adult is a child who has more ethics and morals, that's all."
-- Shigeru Miyamoto
pgpkayQNm7aCg.pgp
Description: PGP signature
Re: telnetd/sshd and Kerberos tickets (PAM)
On Fri, Oct 21, 2005 at 04:08:14PM +0200, Harti Brandt wrote:
> I have enabled the pam_krb5 module in pam.d/{login,telnetd,sshd}. When
> login in locally I get a Kerberos ticket as I would expect. When logging
> in via ssh or telnet I don't get one. I have digged around in the sources
> and it locks like telnetd never calls pam_setcred() which would do this
> work. My PAM-foo is rather limited so my question is: shouldn't sshd and
> telnetd call pam_setcred() somewhere?
WRT sshd I bugged des@ about this but did not receive an answer :( See
the attached mail.
--Stijn
--
There are of course many problems connected with life, of which some of
the most popular are 'Why are people born?', 'Why do they die?', and
`Why do they spend so much of the intervening time wearing digital
watches?'
-- Douglas Adams, "The Hitchhikers Guide To The Galaxy"
Hi,
I sent this 2 weeks ago but got no response. Did I miss anything? I'd
appreciate even a quick 'yes' or 'no' (although a pointer to more
docs would also be nice).
--Stijn
- Forwarded message from Stijn Hoop <[EMAIL PROTECTED]> -
From: Stijn Hoop <[EMAIL PROTECTED]>
Date: Wed, 7 Sep 2005 20:48:09 +0200
To: [EMAIL PROTECTED]
Subject: pam_krb5 / pam_sm_setcred not getting called with PAM_ESTABLISH_CRED
Hi Dag-Erling,
sorry to bother you directly but I can't find good info on PAM
internals on the net. If you do have some pointers I'll gladly read
more myself.
In any case, the quick quick version of the problem is this:
is it allowed for an application to only call pam_setcred with the
PAM_REINITIALIZE_FLAG, while never having called it with PAM_ESTABLISH_CRED?
More details below and in my other post to arch@ with the same subject.
I would be obliged if you could answer this question.
Thanks!
--Stijn
- Forwarded message from Stijn Hoop <[EMAIL PROTECTED]> -
From: Stijn Hoop <[EMAIL PROTECTED]>
Date: Sat, 3 Sep 2005 16:55:06 +0200
To: [EMAIL PROTECTED]
Subject: Re: pam_krb5 / pam_sm_setcred not getting called with
PAM_ESTABLISH_CRED'
On Sat, Sep 03, 2005 at 11:44:34AM +0200, Stijn Hoop wrote:
> I'm debugging a problem on 5-STABLE where I've setup a KDC using Heimdal
> in the base system, and activated pam_krb5 in /etc/pam.d/sshd. It turns out
> that pam_krb5 does not establish the credential cache for the authenticated
> user. After reinstalling pam with DEBUG & PAM_DEBUG, it turns out that
> pam_sm_setcred is only called with PAM_REINITIALIZE_CRED as flags, and
> never with PAM_ESTABLISH_CRED, which is the only case for which a credential
> cache will be saved (in all other cases, PAM_SUCCESS is returned immediately,
> which is why I don't have a cache).
Further digging reveals that this is due to the sshd code; it turns
out that unless PrivilegeSeparation is off, it will not 'establish'
credentials, only 'reinitialize' them. Found in src/crypto/openssh/auth-pam.c
and session.c. I really wouldn't know if this is appropriate or not, but it
seems confusing to me.
The second question still stands:
> - shouldn't pam_krb5 re-establish the credential cache when called with
> PAM_REINITIALIZE_CRED, instead of just returning PAM_SUCCESS? I'm a total
> pam newbie so I'm going only by the name of the flag; I couldn't find a
> manpage that made the semantics of these flags more clear.
Or of course someone pointing out the correct way to get an initialized
Kerberos 5 ticket cache upon succesful ssh login...
--Stijn
- End forwarded message -
pgpSISSw4MSHm.pgp
Description: PGP signature
Re: File create permissions, what am I missing?
On Sun, Aug 14, 2005 at 03:01:52AM -0300, João Carlos Mendes Luís wrote: > I could not find any vulnerability, but I do not like the idea that a > user could create files belonging to a group himself does not belong. It can come in handy sometimes. I have apache setup in a specific group. The document root on which it operates is owned by a user that owns that website. The group owner of that directory is set to the apache group, and luckily the user does not need to be in that group. This way a user can control availability of files on the web by simply denying group access, without needing to belong to yet another group just for the sake of being able to do just that. --Stijn -- "I'm not under the alkafluence of inkahol that some thinkle peep I am. It's just the drunker I sit here the longer I get." pgpR6NL3YANNO.pgp Description: PGP signature
Re: Kernel [memory] tweaking question
On Thu, Apr 07, 2005 at 06:36:39PM +1000, Peter Jeremy wrote: > As far as I can tell, neither Apache nor MySQL > use any SystemV IPC on FreeBSD. (The only thing that I've found that > does use SHM is X in some modes). I know for a fact that PostgreSQL does use SysV IPC, and many times it will run better if given more room to work with. But as you said, use ipcs(1) to verify this for yourself if you're running Postgres. --Stijn -- "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc., 1989 pgpWkOEkbI3dc.pgp Description: PGP signature
Re: Re; tcsh is not csh
On Fri, Nov 12, 2004 at 09:20:28AM -0600, Kevin Lyons wrote: > FreeBSD - does not work (they knew better and renamed tcsh csh rather > than just calling a spade a spade, some commit bit vandal got a hair to > rename parts of the world for the sake of mankind.) [...] > >I'm not opposed to adding a real csh to /bin, but if we're only adding > >it to work around a minor incompatability that few if any programs rely > >on I don't see it as being a necessity. > > And the microsoft mentality lives on. God help freebsd. You know, I actually thought you had a point hidden inside those ugly words somewhere. Care to share it in a civil way? --Stijn -- My server has more fans than Britney. -- Steve Warwick, from a posting at [EMAIL PROTECTED] pgpAQwzEZYABH.pgp Description: PGP signature
Re: Protection from the dreaded "rm -fr /"
On Mon, Oct 04, 2004 at 01:49:51PM +0300, Giorgos Keramidas wrote: > I've lost interest in making any sort of changes to rm(1) after the first > dozen or so of messages like this one. Don't get too disappointed: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/rm/rm.c.diff?r1=1.48&r2=1.49 changes by [EMAIL PROTECTED] --Stijn -- Nostalgia ain't what it used to be. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pthread_mutex_trylock and glib-2
Hi, thanks for digging at this! On Mon, Sep 06, 2004 at 03:12:08PM -0700, Pascal Hofstee wrote: > After a few hours of digging through both the glib-2 as well as the > beep-media-player sources i finally managed to figure out why > beep-media-player apprently crashes on startup when using libpthread, > but not when using libc_r. > > i filed a bugreport against this problem on bugzilla.gnome.org ... in > the hope to get some feedback from glib-developers ... > > http://bugzilla.gnome.org/show_bug.cgi?id=152009 > > The problem is with the actual return value of pthread_mutex_trylock > returning EDEADLK instead of EBUSY. > > from what i have been able to glance from this previous discussion > regarding this particular subject > (http://lists.freebsd.org/pipermail/freebsd-threads/2004-January/001539.html) > > pthread_mutex_trylock should behave identical to pthread_mutex_lock > except return immediately in case of a blocking mutex, which would > suggest EDEADLK as a possible return value. Well, according to http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_trylock.html (linked from the discussion above), I would read this: %%% The pthread_mutex_trylock() function shall fail if: [EBUSY] The mutex could not be acquired because it was already locked. The pthread_mutex_lock() function may fail if: [EDEADLK] A deadlock condition was detected or the current thread already owns the mutex. %%% as the glib developers apparently did -- namely that pthread_mutex_trylock cannot return EDEADLK, only EBUSY. The fact that it is the current thread that has already locked the mutex is only required to be detected by the pthread_mutex_lock function. In other words, I agree with Mike Makonnen in your quoted e-mail, but apparently the implementation does not. In any case, modifying glib to also check for EDEADLK would probably be appropriate. --Stijn -- I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work." -- Gallagher pgpXsqnDvDflW.pgp Description: PGP signature
ndis/if_ndis kernel configuration patch
Hi,
after I got frustrated by forgetting to manually make the if_ndis module after
an upgrade to -CURRENT, and subsequently having to fix /boot/loader.conf
again, I was motivated enough to try and think of a way to integrate
ndis/if_ndis into the build system.
Attached is my first try at this. Since most of the stuff has been copy &
pasted there's bound to be something wrong here, but I have verified that
having
NDIS_INF=/path/to/ndis.inf
NDIS_SYS=/path/to/ndis.sys
in /etc/make.conf makes the if_ndis module build, and I also compiled
a static kernel with
device ndisapi
device ndis
options NDIS_INF
makeoptions NDIS_INF=/path/to/ndis.inf
options NDIS_SYS
makeoptions NDIS_SYS=/path/to/ndis.sys
which booted & detected my Dell Truemobile 1300 card fine.
I did ran into 2 build errors when statically compiling ndisapi/ndis -- maybe
the kernel build has stricter CFLAGS? Also attached is a patch to fix those
warnings.
Any comments most welcome.
--Stijn
--
I have great faith in fools -- self confidence my friends call it.
-- Edgar Allan Poe
Index: conf/files.i386
===
RCS file: /freebsd/cvsroot/src/sys/conf/files.i386,v
retrieving revision 1.504
diff -u -u -r1.504 files.i386
--- conf/files.i386 16 Aug 2004 12:25:47 - 1.504
+++ conf/files.i386 1 Sep 2004 07:42:35 -
@@ -56,6 +56,11 @@
compile-with"uudecode < $S/contrib/dev/ath/freebsd/i386-elf.hal.o.uu" \
no-implicit-rule
#
+ndis_driver_data.h optionalndis ndis_inf ndis_sys \
+ compile-with"ndiscvt -i ${NDIS_INF} -s ${NDIS_SYS} > ${.TARGET}" \
+ no-obj no-implicit-rule before-depend \
+ clean "ndis_driver_data.h"
+#
#
compat/linux/linux_file.c optionalcompat_linux
compat/linux/linux_getcwd.coptionalcompat_linux
Index: conf/options.i386
===
RCS file: /freebsd/cvsroot/src/sys/conf/options.i386,v
retrieving revision 1.215
diff -u -u -r1.215 options.i386
--- conf/options.i386 19 Aug 2004 20:58:23 - 1.215
+++ conf/options.i386 1 Sep 2004 07:49:30 -
@@ -162,3 +162,6 @@
# Device options
DEV_APIC opt_apic.h
DEV_NPXopt_npx.h
+
+NDIS_INF opt_dontuse.h
+NDIS_SYS opt_dontuse.h
Index: i386/conf/NOTES
===
RCS file: /freebsd/cvsroot/src/sys/i386/conf/NOTES,v
retrieving revision 1.1172
diff -u -u -r1.1172 NOTES
--- i386/conf/NOTES 30 Aug 2004 23:03:57 - 1.1172
+++ i386/conf/NOTES 1 Sep 2004 07:47:24 -
@@ -511,6 +511,7 @@
# Intel EtherExpress
# lnc: Lance/PCnet cards (Isolan, Novell NE2100, NE32-VL, AMD Am7990 and
# Am79C960)
+# ndis: NDISulator, support for using Windows(R) drivers using a wrapper
# oltr: Olicom ISA token-ring adapters OC-3115, OC-3117, OC-3118 and OC-3133.
# Olicom PCI token-ring adapters OC-3136, OC-3137, OC-3139, OC-3140,
# OC-3141, OC-3540 and OC-3250.
@@ -583,6 +584,13 @@
device ath_hal # Atheros HAL (includes binary component)
#devicewlan# 802.11 layer
+device ndisapi # NDISulator API wrapper
+#devicendis# NDIS driver wrapper interface
+#options NDIS_INF
+#makeoptions NDIS_INF=bcmwl5.inf
+#options NDIS_SYS
+#makeoptions NDIS_SYS=bcmwl5.sys
+
#
# ATA raid adapters
#
Index: modules/Makefile
===
RCS file: /freebsd/cvsroot/src/sys/modules/Makefile,v
retrieving revision 1.397
diff -u -u -r1.397 Makefile
--- modules/Makefile30 Aug 2004 03:37:36 - 1.397
+++ modules/Makefile1 Sep 2004 06:14:16 -
@@ -94,6 +94,7 @@
if_faith \
if_gif \
if_gre \
+ ${_if_ndis} \
if_ppp \
if_sl \
if_stf \
@@ -301,6 +302,9 @@
_i2c= i2c
_ibcs2=ibcs2
_ie= ie
+.if defined(NDIS_INF) && defined(NDIS_SYS)
+_if_ndis= if_ndis
+.endif
_io= io
_linprocfs=linprocfs
_linux=linux
Index: modules/if_ndis/Makefile
===
RCS file: /freebsd/cvsroot/src/sys/modules/if_ndis/Makefile,v
retrieving revision 1.4
diff -u -u -r1.4 Makefile
--- modules/if_ndis/Makefile26 May 2004 00:53:04 - 1.4
+++ modules/if_ndis/Makefile1 Sep 2004 06:13:34 -
@@ -6,4 +6,11 @@
SRCS= if_ndis.c if_ndis_pci.c if_ndis_pccard.c
SRCS+= opt_bdg.h device_if.h bus_if.h pci_if.h card_if.h pccarddevs.h
+.if defined(NDIS_INF) && defined(NDIS_SYS)
+SRCS+= ndis_driver_data.h
+
+ndis_driver_data.h: ${NDIS_INF} ${NDIS_SYS}
+ ndiscvt -i ${NDIS_INF} -s ${NDIS_SYS} -o ${.OBJDIR}/ndis_driver_data.h
+.endif
Re: Subversion/CVS experiment summary
On Mon, Feb 09, 2004 at 01:26:45PM -0600, Craig Boston wrote: > On Monday 09 February 2004 11:53 am, Stijn Hoop wrote: > > Did you have to modify the script, or pass unusual options? I'd like to > > reproduce this, but I didn't get very far when I tried a few days ago with > > the 0.37.0 version of the tool. > > No, I used the script as-is. The version I have is > LastChangedRevision: 8527, with a date of Jan. 29. It looks like that > version is slightly newer than the one included with 0.37 (Rev 8512). Well, that explains a lot -- for some reason I tested using $LastChangedRevision: 7921 $. I'll try with an up-to-date one then. > One thing that may have made a difference is that so far I've been importing > things in chunks rather than trying to do the whole repo at once. Yes, I was afraid though that commits might have spanned subtrees. But then again, even if they did they would just get committed as separate revisions to the tree, and I suppose one could live with that. > > but although it looks like it handles things much better (even vendor > > branches etc), it loads EVERYTHING into memory -- which means that it > > eventually grew to 1G of memory/swap at which point my memory was > > exhausted, and this was at pass 2 of 7... > > Does the Python version do the same thing? I didn't think to look at memory > usage very closely while it was running :-/ As far as I understood it builds a disk cache instead of using malloc(). This might explain the slowness :) > > My thoughts were now going to do something like Tom Lord proposed for an > > Arch gateway -- just import a CVS working copy into SVN at a certain > > cut-off date, and setup a bi-directional gateway between the two. > > If I'm reading that right, it sounds similar to a thought I had about just > routinely checking out snapshots and committing them on a vendor branch. > Of course you'd have to do that separately for each branch you're interested > in. Yes, that's the idea. You 'just' need a tool that can determine changesets from a CVS repository to automate this. See http://wiki.gnuarch.org/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree but substitute Subversion for arch :) > IMO, I find it immensely useful to have the entire history of a file at hand. But you do have all history of a file at hand; you just need to have a separate version system for the older history. Which is admittedly a bit unwieldy, but it certainly makes for a smooth transition in the distributed repository case... > > Actually, would a sort of access control wrapper that is now also used with > > the FreeBSD CVS repository not work? I do agree that it would be nice to > > have per-directory access control with the svnserve method. > > Yes, I think the same sort of access hooks (pre-commit?) can be used. The > Subversion manual even mentions that, I just forgot about it... > > That method has always seemed a little... hackish to me. It is, but it does work. Maybe I'll test and see if I can 'port' those scripts to Subversion :) --Stijn -- My server has more fans than Britney. -- Steve Warwick, from a posting at [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Subversion/CVS experiment summary
On Mon, Feb 09, 2004 at 07:49:55PM +0100, Dag-Erling Sm?rgrav wrote: > Stijn Hoop <[EMAIL PROTECTED]> writes: > > I also tried refinecvs (formerly cvs2svn.pl), found at > > > > http://lev.serebryakov.spb.ru/refinecvs/ > > > > but although it looks like it handles things much better (even vendor > > branches etc), it loads EVERYTHING into memory -- which means that it > > eventually grew to 1G of memory/swap at which point my memory was exhausted, > > and this was at pass 2 of 7... > > Unfortunately there's no good way to avoid this. CVS discards a lot > of information about each commit, and in order to reconstruct that > information you have to view the repo as a whole. > > That's not really a problem though, since this is a one-time > operation. If / when we decide to switch to SVN, we can easily find a > machine with enough RAM to do the job. Very true, but... First of all it would make these kind of tests easier if the script implemented it's own sort of cache function. Then I could try and see the feasibility of converting to Subversion by myself, just like the OP has done. I tried reading the source to see if this is "easily" implemented, but it's still way beyond my meagre perl skills. Second, even after you get the initial conversion done, I think there is a need for resyncing the SVN repository with the CVS repository -- with a state dump from refinecvs this would be relatively easy (only examine the deltas since last time), but this sort of behaviour is impossible with the current script. It would also be useful to implement a bi-directional gateway between SVN and CVS repositories, analogous to the idea someone from the arch project had. See point 3 at http://wiki.gnuarch.org/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree (and of course substitute Subversion for arch). That said, as with my comments on Subversion, I was actually pleasantly surprised with my findings about all the tools involved, and the above is certainly only meant as constructive criticism. I think Lev is actually using the FreeBSD repository for testing his script, isn't he? --Stijn -- Tact, n.: The unsaid part of what you're thinking. pgp0.pgp Description: PGP signature
Re: Subversion/CVS experiment summary
On Mon, Feb 09, 2004 at 11:30:05AM -0600, Craig Boston wrote: > This is an informal report on the viability of using Subversion to manage the > FreeBSD source code repository. Some of this is generic and will be familiar > to anyone who has looked at SVN before, some is more FreeBSD-specific. Wow, you have done the experiment I thought to do one of these days! Cool! > - > Section the 1st - Motive > - > My main motivation for these tests was to bring my local modifications to > FreeBSD into some semblance of order. It seems I've amassed a bit of a > collection of local patches, 3rd party patches, and side projects -- some of > which are mutually exclusive or apply to different branches. Simply keeping > a working copy with my changes in it works fine for one project but becomes > painful when there are several. I'd also like to be able to keep version > history for my modifications. That is my primary motivation as well -- sort of a private branch for mods / testing things. > - > Section the 2nd - Setup and conversion > - > I've heard of attempts to convert the repo for testing using the cvs2svn.py > failing (for more details, see the thread at > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=640133+0+archive/2004/freebsd-hackers/20040111.freebsd-hackers). > These problems seem to be fixed in the most recent version of the script -- I > have been able to successfully import sys, bin, sbin, and lib so far. The > next target for testing is contrib as it seems to be the most likely > candidate for problems with all those vendor branches. Did you have to modify the script, or pass unusual options? I'd like to reproduce this, but I didn't get very far when I tried a few days ago with the 0.37.0 version of the tool. I also tried refinecvs (formerly cvs2svn.pl), found at http://lev.serebryakov.spb.ru/refinecvs/ but although it looks like it handles things much better (even vendor branches etc), it loads EVERYTHING into memory -- which means that it eventually grew to 1G of memory/swap at which point my memory was exhausted, and this was at pass 2 of 7... > Comments on importing: It's SLOOW. It took 43.9 hours just for > src/sys, and this is a relatively speedy system! It starts out at a pretty > good pace, but the more commits it processes, the slower each one seems to > take. That doesn't bode well. Is committing in the new SVN repository also slow? > For my purposes I would also need some method of incrementally updating the > repository with any new commits made to CVS. This doesn't exist yet, but I'm > thinking about trying to hack cvs2svn to do this. Kind of an inverse vendor > branch I guess. My thoughts were now going to do something like Tom Lord proposed for an Arch gateway -- just import a CVS working copy into SVN at a certain cut-off date, and setup a bi-directional gateway between the two. That way people can use either tool. The hard problem to solve is indeed getting the changeset from CVS (at least it is when you're not running when a commit is made, as is the case in my setup where I simply cvsup the repository and thus get lots of commits at once). But if the whole repository can be converted it's probably the way to go. > - > Section the 3rd - Head to Head > - Great summary of the pros/cons of either system. > * "Requires" Apache for the network server. There is a simpler CVS-like > network protocol, but it suffers from the same problems with access > control and locking and the like that CVS does. In order to overcome > those limitations, you pretty much have to use Apache/WebDAV. Some may > argue that this isn't really a negative, but it certainly doesn't go with > the K.I.S.S. philosophy. Actually, would a sort of access control wrapper that is now also used with the FreeBSD CVS repository not work? I do agree that it would be nice to have per-directory access control with the svnserve method. > * No cvsup equivalent yet. You can fairly easily use WebDAV to pull a copy > of the trunk or a particular branch, but it's not nearly as efficient as > the rsync algorithm. There's also no way to use WebDAV to grab a certain > date or revision like you can with cvsup -- you have to have the svn > client installed. In order to be even a contender to replace CVS, it > still needs a *FAST* and *SIMPLE* way to synchronize source with an > arbitrary tag or revision. Agreed. > * Still no solution for the repeated merge problem. This is supposed to b
Re: PCI interrupt allocation question..
On Tue, Jan 13, 2004 at 04:14:10PM -0800, Julian Elischer wrote: > xmbmon uses the SMBus to read the temperatures but it does it from > userland using direct read and write operations Oh, I didn't know that. Like I said the box is gone so I can't really verify what I did anymore :( > and when there are timing glitches caused by the process not getting > scheduled quite quick enough you get garbage results.. > teh theory is that the kernel driver wouldn't be susceptible to this > but it looks like unless I resort to polling I will not be able to use > it because it relies on the interrupts and they are not being delivered. :( > ASUS motherboards actually turn off the SMBus. (why?) > So you need to turn it back on before you can read the temperatures.. > I have a little script that uses pciconf to do it.. The machine I tested this on was a Dell GX115 I think, but even when that bit was enabled using pciconf there was no SMBus device/reading possible... Anyway, it seems to be some other problem so I'm off again :) --Stijn -- "I used to think I was indecisive, but now I'm not so sure." pgp0.pgp Description: PGP signature
Re: PCI interrupt allocation question..
On Tue, Jan 13, 2004 at 03:26:00PM -0800, Julian Elischer wrote: > The kernel includes teh ichsmb driver to try access the SMBus > for temperature reading reasons (yes I know I can do it other ways..) > > Any thoughts that move me towards getting th eichsmb driver working on > this machine are welcome. Make sure that the mainboard really does support SMBus -- it turns out that this is optional. The ICH docs talk about a bit that should be enabled in the PCI config when SMB is present. I ran into this once, it should be documented in the archives (of -current off the top of my head). OTOH, I didn't even succeed in getting an ichsmb device probed so this might be something totally unrelated. FWIW, I had to try other ways to get the temperature (xmbmon & related). I don't have the box anymore or I'd show you the exact config... --Stijn -- Beware of he who would deny you access to information. For in his heart he thinks himself your master. -- Sid Meier, "Sid Meier's Alpha Centauri" pgp0.pgp Description: PGP signature
Re: apache2's perchild MPM not working under 5.0-RELEASE
On Wed, Jul 16, 2003 at 02:07:55PM -0700, Jeremy C. Reed wrote: > The apache2 port build and installed with WITH_MPM=perchild does not work > for me for DAV and SSL under FreeBSD 5.0-RELEASE (i386). All of my "research" on the topic (that is to say, I've spent two afternoons searching lots of confusing Google sites) indicates that perchild is broken by design, even on Linux. Some people on the IRC apache channel confirmed this. Although I obviously am not aware of their technical competence I'm inclined to believe them. There is someone working on a similar MPM but it only has a mailinglist without archives. I forgot the URL. If you find something to make it work, or a suitable replacement, please post it here -- I'm extremely interested in making it work. --Stijn -- Fairy tales do not tell children that dragons exist. Children already know dragons exist. Fairy tales tell children the dragons can be killed. -- G.K. Chesterton pgp0.pgp Description: PGP signature
Re: portupgrade
Hi, On Fri, Jul 11, 2003 at 10:38:52PM -0700, Andrew Konstantinov wrote: > I've written a simple script to make my life easier, but there is a > problem with that script and I can't figure out the source of that problem. I'm inferring from your email that you want to pass make flags to certain port builds? Have you checked /usr/local/etc/pkgtools.conf.sample, which is usable when you copy it to /usr/local/etc/pkgtools.conf -- there is a section in it where you can specify make arguments for individual ports. Search for MAKE_ARGS to find it. HTH, --Stijn -- "A mouse is a device used to point at the xterm you want to type in." -- Kim Alm, alt.sysadmin.recovery pgp0.pgp Description: PGP signature
gethostbyname_r
Hi, I was wondering if anybody was working on an implementation of a reentrant gethostbyname_r function, mostly because it looks like mozilla/firebird will finally gain support for an async DNS thread in the near future. However, it is claimed in Mozilla's bug reporting system that FreeBSD 5.x doesn't have support for this. See http://bugzilla.mozilla.org/show_bug.cgi?id=70213#c36 A quick grep -r in /usr/src shows only hits in contrib, so it's probably true that it's not implemented. Any status? --Stijn -- The right half of the brain controls the left half of the body. This means that only left handed people are in their right mind. pgp0.pgp Description: PGP signature
Re: mixer for /etc/rc
On Thu, Mar 20, 2003 at 11:18:24AM +0900, Norikatsu Shigemura wrote: > On Wed, 19 Mar 2003 12:58:27 +0100 > Stijn Hoop <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 19, 2003 at 03:23:07AM -0800, Doug Barton wrote: > > > > I want to mixer in /etc/rc (setting sound volume on boot). > > > > I add it to /etc/rc, /etc/defaults/rc.conf, etc... > > > > Would you review and commit? > > > Off hand, I'd say this is more of an /etc/rc.local, or /usr/local/etc/rc.d > > > thing. We haven't really started down the road of what I generically refer > > > to as "desktop" configuration items in rc. > > Why *not*? As long as it behaves when run in a system without sound, I don't > > see any reason to make things easier for users, whether they use the machine > > as a server or as a desktop. > > I'd very much like to see (something like) this in the base -- I haven't > > even looked at these patches but the idea is IMHO worthwhile. > > I think that I don't need it if a little machines requires sound. > But I have many machines (mine or not mine) which use sound (or can > use it). I almost hate to install these to /etc/rc.local. And even > I want it, many users want it:-). Different point from setting > /etc/rc.conf is that anyone always check this file, but /etc/rc.local > is not so. Yes, I agree with you. Making a port out of this is imho plain silly, or is someone actually relying on the mixer being set to a default value on bootup? --Stijn -- "What if everything you see is more than what you see -- the person next to you is a warrior and the space that appears empty is a secret door to another world? What if something appears that shouldn't? You either dismiss it, or you accept that there is much more to the world than you think. Perhaps it really is a doorway, and if you choose to go inside, you'll find many unexpected things." -- Shigeru Miyamoto pgp0.pgp Description: PGP signature
Re: mixer for /etc/rc
On Wed, Mar 19, 2003 at 03:23:07AM -0800, Doug Barton wrote: > On Wed, 19 Mar 2003, Norikatsu Shigemura wrote: > > I want to mixer in /etc/rc (setting sound volume on boot). > > I add it to /etc/rc, /etc/defaults/rc.conf, etc... > > Would you review and commit? > > Off hand, I'd say this is more of an /etc/rc.local, or /usr/local/etc/rc.d > thing. We haven't really started down the road of what I generically refer > to as "desktop" configuration items in rc. Why *not*? As long as it behaves when run in a system without sound, I don't see any reason to make things easier for users, whether they use the machine as a server or as a desktop. I'd very much like to see (something like) this in the base -- I haven't even looked at these patches but the idea is IMHO worthwhile. --Stijn -- The right half of the brain controls the left half of the body. This means that only left handed people are in their right mind. pgp0.pgp Description: PGP signature
Re: DHCP Client DoS
On Tue, Feb 18, 2003 at 04:11:14PM +0100, Volker Stolz wrote: > In local.freebsd-hackers, you wrote: > > We've recently found a problem with dhclient that can DoS a DHCP > > server. If you have schg flags set on /etc/resolv.conf to stop dhcp > > overwriting your existing nameservers, the problem occurs. > > Basically, the client just keeps rejecting the IP details it has > > received from the server and requesting another. The server marks the > > record as used, and moves onto the next one. Over the course of a couple > > of minutes, you can pretty much mark an entire class C as in use. > > The problem of read-only resolv.conf is already documented in the PR > database and I think recently somebody started thinking about a solution. > Check http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/38778 > > That the server runs out of IPs is his probably his own fault. It > should be configured to not eat up all IPs when a host which already > has obtained a lease requests another one but simply hand out the old > one or deny the request... > > Stijn: Could you add your suggestion to the above PR? Well I could but it's a workaround -- dhclient should imho be made not to fail when it cannot write /etc/resolv.conf. That's a separate issue from being able to set the contents of the newly written resolv.conf, which is essentially what the supersede option does. All I was trying to say was that there already is a solution for keeping your own nameservers in /etc/resolv.conf. That said, I will add some words to this effect to the PR. --Stijn -- The rain it raineth on the just And also on the unjust fella, But chiefly on the just, because The unjust steals the just's umbrella. msg39997/pgp0.pgp Description: PGP signature
Re: DHCP Client DoS
On Tue, Feb 18, 2003 at 01:41:12PM +, Ian Watkinson wrote:
> We've recently found a problem with dhclient that can DoS a DHCP
> server. If you have schg flags set on /etc/resolv.conf to stop dhcp
> overwriting your existing nameservers, the problem occurs.
>
> Basically, the client just keeps rejecting the IP details it has
> received from the server and requesting another. The server marks the
> record as used, and moves onto the next one. Over the course of a couple
> of minutes, you can pretty much mark an entire class C as in use.
>
> If you remove the schg flag from resolv.conf, this problem does not
> happen.
While this is of course very bad, you do know about the 'supersede'
command in dhclient.conf to override any DHCP-supplied values?
Something like
interface "fxp0" {
supersede domain-name-servers 127.0.0.1;
}
should work.
That should at least solve the 'overwriting /etc/resolv.conf' problem.
man dhclient.conf for details.
--Stijn
--
Fairy tales do not tell children that dragons exist. Children already
know dragons exist. Fairy tales tell children the dragons can be
killed.
-- G.K. Chesterton
msg39995/pgp0.pgp
Description: PGP signature
determining inserted floppy size
Hi, I'm trying to write a kind of 'floppy dump' program, and therefore I would like to know if it is possible to determine the size of the floppy inserted into the drive. ioctl(fd, FD_GTYPE) gives me the type of the *drive* which is not what I want, ioctl(fd, DIOCGDINFO) doesn't work because there is no disklabel, and looking through /sys/isa/fd.c doesn't give me a further clue either. Is this not possible? --Stijn -- ] Nothing safer than a 'cat /dev/wallet | grep $price > real-person; \ ] mv $thing-to-buy $my-case I'd prefer 'mv $thing-to-buy $my-case && cat /dev/wallet | \ grep $price > real-person -- Anonymous, [EMAIL PROTECTED], in message <[EMAIL PROTECTED]> msg39209/pgp0.pgp Description: PGP signature
Re: burncd raw mode
On Tue, Dec 17, 2002 at 09:39:06AM +0100, Soeren Schmidt wrote: > It seems Sean Hamilton wrote: > > I have a 2352-byte block mode1 CD image, and wish to burn this with burncd. > > I know I can use bin2iso or bchunk to decode it, but I'd rather keep the > > block metadata intact from the file itself instead of having the > > burner/driver(?) reconstruct it. > > > > I assembled a small stack of coasters by trying a few combinations of -d, > > 'raw', etc, to no avail. The best I got was from raw, a track which needed > > to be read with 2352 byte blocks, so it wasn't being interpreted as > > metadata. I presume if I were to dd this entire disc into a file, I would > > have a verbatim copy of my original, albeit less fault tolerant. > > > > Can this be done with burncd? > > Not as is, but it could be done, however there is absolutly no point > in doing it, *unless* its to make an exact copy of a CD that is > copyprotected in one of the usual ways. OK, but what if it is? Tools, not policy? I got interested in this the other day also, seeing as there were windows tools to extract the 'subchannel data' (that's the same, isn't it?) and I couldn't find any tool to do the same on FreeBSD. I can understand if you don't want to spend any of your limited time on this, but the fact that it may be used in illegal ways should make no difference in the implementation of this feature... > So, assuming you have a legit image, you simply rip out the 2048 bytes > of real data from each 2352 byte block in that file, and burn it as > a normal data CD, bingo.. > > > How does the drive/driver know to interpret the remaining 304 bytes as > > metadata? > > Thats a long explanation, its checksumming etc etc. Actually, is it the driver that constructs this metadata, or mkisofs, or ... ? > > Is it possible to extract the full 2352 byte blocks from a track which is > > advertised as only 2048, ie a typical data track? There are a few Windows > > apps for doing exactly this. > > Sure it is, but why would you need to ? For making a backup of my PSX CDs to play with an emulator? (perfectly legal for me to do). Windows apps can do this. --Stijn -- The sexual urge of the camel is stranger than anyone thinks. He's lived for years on the desert, and tried to seduce the Sphinx. But the Sphinxs center of pleasure lies buried deep in the Nile, which accounts for the hump on the camel and the Sphinxs inscrutable smile. -- Frantic Fran, http://www.franticfran.com/jokes.htm msg38728/pgp0.pgp Description: PGP signature
Re: CVS_LOCAL_BRANCH_NUM?
On Wed, Dec 11, 2002 at 10:59:55AM +0200, Peter Pentchev wrote: > On Tue, Dec 10, 2002 at 11:56:26AM -0800, Lamont Granquist wrote: > > On Tue, 10 Dec 2002, Dmitry Morozovsky wrote: > > > Please note quotes explicitly, "$@" is really needed where your parameters > > > contain spaces (bad practice in filenames, yeah, but don't make yourself > > > another one PITA you can avoid ;-P ) > > > > got it. > > Mmm.. I am not really sure if we need quotes in this particular case. > In my experience, the CVS invocation in the server or pserver case > almost always has more than one argument (at the very least, the > 'server' or 'pserver' keyword and one 'allow-root' option). The quotes > around "$@" would make the whole param string be passed as a single > parameter to the "real" CVS binary, which might not be quite the desired > result... No, that's not the behaviour with /bin/sh, from the man page: @ Expands to the positional parameters, starting from one. When the expansion occurs within double-quotes, each positional param- eter expands as a separate argument. If there are no positional parameters, the expansion of @ generates zero arguments, even when @ is double-quoted. What this basically means, for example, is if $1 is ``abc'' and $2 is ``def ghi'', then "$@" expands to the two arguments: "abc" "def ghi" I think "$@" (with the quotes) is ok. --Stijn -- Help Wanted: Telepath. You know where to apply. msg38616/pgp0.pgp Description: PGP signature
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Thu, Dec 05, 2002 at 01:58:24AM -0800, Terry Lambert wrote: > Stijn Hoop wrote: > > I'd argue it isn't flawed for the measuring it is supposed to do - namely > > the overhead for the various _sleep functions. Care to tell me why it is > > flawed according to you? > > Because it measures the API one way, but the code uses it another. > The results you get are not predictive of the code that you are > going to be running. But the code is going to use the _sleep functions as used in the benchmark -- to sleep for less than 10 ms (which evidently makes no sense on a default FreeBSD system, as pointed out by the results). > Well, really, something that requires RT performance should be in > the kernel. That's why we put interrupt handlers there. 8-). /me ponders having an option XMAME in the kernel nah, lets not go there :) > Probably the place to do this is in the POSIX RT scheduling; if > the RT scheduling is active (meaning a process has called it, and > that process is still running), it's probably a reasonable thing > to crank up the Hz. This would make it self-adjusting, and also > self-healing, so that you could safely degrade the overall system > performance by intentionally running your application, but not > otherwise. That's a good suggestion, but how many OSs implement those? Where can I learn more about them? Any open standards? > Note that if this were implemented, it would mean your benchmark > is still broken, because it doesn't call the necessary interfaces. ? I don't get this. > Another alternative would be a nanosleep call with an argument below > a certain value. I would hesitate to do it that way, though, since > I think that it ought to take a priviledged program to do the evil > deed, given the impact on the rest of the system. And that would sleep less than 10ms on average? --Stijn -- SIGSIG -- signature too long (core dumped) msg38502/pgp0.pgp Description: PGP signature
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Wed, Dec 04, 2002 at 11:34:30AM -0800, Terry Lambert wrote: > Stijn Hoop wrote: > > On Wed, Dec 04, 2002 at 10:06:16AM -0800, Terry Lambert wrote: > > > Actually, for the case you are talking about, your emulator should > > > be using aggregate instead of discrete timeouts, and you would not > > > be having a problem. It's not useful to do 100 1ms timeouts to > > > achieve a 100ms timeout, when you can ask for a single 100ms > > > timeout. I would count this as a bug in your emulator. > > > > Yes, I would count it as a bug in any application in fact. But these > > benchmarks are used to determine which of the various _sleep functions > > would be appropriate to use in the idle loop of the emulator while > > not dropping too many frames. Sleeping for a minimum of 10 ms is a > > lot if you want to achieve a steady 60 frames / second. > > It's a flawed benchmark. I'd argue it isn't flawed for the measuring it is supposed to do - namely the overhead for the various _sleep functions. Care to tell me why it is flawed according to you? > I would argue that that application was special purpose, as well. Yes it most certainly is. > The hardclock rate gets boosted in the kernel under certain usage > conditions, among them being using the PC speaker driver. I > believe there is an interface available that you could abuse to > raise it the same way. Far be it for sotware to know about the > hardware it's running on, though... 8-). That sounds gross... :) --Stijn -- Help Wanted: Telepath. You know where to apply. msg38498/pgp0.pgp Description: PGP signature
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Wed, Dec 04, 2002 at 10:06:16AM -0800, Terry Lambert wrote: [snip] > Increased context switch overhead. Yes, Mike's explanation was clear. > Actually, for the case you are talking about, your emulator should > be using aggregate instead of discrete timeouts, and you would not > be having a problem. It's not useful to do 100 1ms timeouts to > achieve a 100ms timeout, when you can ask for a single 100ms > timeout. I would count this as a bug in your emulator. Yes, I would count it as a bug in any application in fact. But these benchmarks are used to determine which of the various _sleep functions would be appropriate to use in the idle loop of the emulator while not dropping too many frames. Sleeping for a minimum of 10 ms is a lot if you want to achieve a steady 60 frames / second. --Stijn -- The rain it raineth on the just And also on the unjust fella, But chiefly on the just, because The unjust steals the just's umbrella. msg38474/pgp0.pgp Description: PGP signature
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Wed, Dec 04, 2002 at 12:01:43PM -0600, Mike Silbersack wrote: > On Wed, 4 Dec 2002, Stijn Hoop wrote: > > With the mentioned change of /etc/sysctl.conf to /boot/loader.conf, I am > > indeed seeing much better times on this 'benchmark'. See attached log. Not > > only the _select_sleep method benefits from this. What are the reasons *not* > > to do this? > > > > > As to why Linux may appear "better"... I believe that Linux defaults to > > > hz=100, but that the default switched to hz=1000 sometime in the recent > > > past. > > > > And why don't we do the same? (I suspect this is related to the question > > above :) > > Well, it's generally believed that in the common case (around 100 > processes, and/or with well behaved processes that voluntarily give up > their timeslice) that 100 context switches per second is enough for > smooth performance. Whether this is true or not as you hit 500+ processes > on a busy server is unknown, I don't believe that anyone has done > benchmarking. One argument against more frequent context switches when > you have < 100 processes is that you will be invalidating the contents of > the various caches more often, leading to less efficient overall > performance. The same argument could also be made for the VM system if > the system is under memory pressure. OK, thanks for the explanation. This makes sense. > On the other hand, a higher HZ should create a system which runs a bit > smoother for interactive programs. And, as you point out, it is necessary > for good timing in emulators / simulators / dummynet. Wel, necessary might be an overstatement but seeing as the overhead of the syscalls decreased this much, it would mean a few more frames per second, yes. > In short, I don't think the issue has been discussed much, partially > because it's so easy for those who want hz=1000 to just edit loader.conf. > If you want to propose that we switch to hz=1000 by default: Nah, I'll leave that to someone who has some more expertise in writing benchmarks etc. --Stijn -- "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc., 1989 msg38473/pgp0.pgp Description: PGP signature
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Mon, Dec 02, 2002 at 11:49:03AM -0600, Mike Silbersack wrote: > The time select() takes should be directly related to your system's hz > setting. The default for FreeBSD is 100, which means that the interrupt > timer will fire every 10ms. If you want to play with that, edit > /etc/sysctl.conf and set kern.hz="1000", which should give you 1 ms > accuracy. With the mentioned change of /etc/sysctl.conf to /boot/loader.conf, I am indeed seeing much better times on this 'benchmark'. See attached log. Not only the _select_sleep method benefits from this. What are the reasons *not* to do this? > As to why Linux may appear "better"... I believe that Linux defaults to > hz=100, but that the default switched to hz=1000 sometime in the recent > past. And why don't we do the same? (I suspect this is related to the question above :) > To answer your final question: Sleep accuracy doesn't matter to most > applications, but I'm sure counterexamples could be found. Such as emulators :) Thanks for the responses, --Stijn -- I really hate this damned machine I wish that they would sell it. It never does quite what I want But only what I tell it. Script started on Wed Dec 4 11:46:30 2002 Testing _select_sleep (x 1000), delay 3 Total time: 4004.915000 ms; unit time: 4.004915 ms; estimated overhead: 1.004915 ms Testing _usleep_sleep (x 1000), delay 3 Total time: 4006.116000 ms; unit time: 4.006116 ms; estimated overhead: 1.006116 ms Testing _nanosleep_sleep (x 1000), delay 3 Total time: 4007.124000 ms; unit time: 4.007124 ms; estimated overhead: 1.007124 ms Testing _select_sleep (x 1000), delay 8 Total time: 9003.38 ms; unit time: 9.003380 ms; estimated overhead: 1.003380 ms Testing _usleep_sleep (x 1000), delay 8 Total time: 8998.329000 ms; unit time: 8.998329 ms; estimated overhead: 0.998329 ms Testing _nanosleep_sleep (x 1000), delay 8 Total time: 8998.352000 ms; unit time: 8.998352 ms; estimated overhead: 0.998352 ms Testing _select_sleep (x 1000), delay 13 Total time: 14010.526000 ms; unit time: 14.010526 ms; estimated overhead: 1.010526 ms Testing _usleep_sleep (x 1000), delay 13 Total time: 14011.579000 ms; unit time: 14.011579 ms; estimated overhead: 1.011579 ms Testing _nanosleep_sleep (x 1000), delay 13 Total time: 14011.588000 ms; unit time: 14.011588 ms; estimated overhead: 1.011588 ms Testing _select_sleep (x 1000), delay 18 Total time: 18999.703000 ms; unit time: 18.999703 ms; estimated overhead: 0.999703 ms Testing _usleep_sleep (x 1000), delay 18 Total time: 19000.703000 ms; unit time: 19.000703 ms; estimated overhead: 1.000703 ms Testing _nanosleep_sleep (x 1000), delay 18 Total time: 18998.785000 ms; unit time: 18.998785 ms; estimated overhead: 0.998785 ms Testing _select_sleep (x 1000), delay 23 Total time: 23997.911000 ms; unit time: 23.997911 ms; estimated overhead: 0.997911 ms Testing _usleep_sleep (x 1000), delay 23 Total time: 24007.931000 ms; unit time: 24.007931 ms; estimated overhead: 1.007931 ms Testing _nanosleep_sleep (x 1000), delay 23 Total time: 23998.212000 ms; unit time: 23.998212 ms; estimated overhead: 0.998212 ms Testing _select_sleep (x 1000), delay 28 Total time: 29074.207000 ms; unit time: 29.074207 ms; estimated overhead: 1.074207 ms Testing _usleep_sleep (x 1000), delay 28 Total time: 29000.175000 ms; unit time: 29.000175 ms; estimated overhead: 1.000175 ms Testing _nanosleep_sleep (x 1000), delay 28 Total time: 29001.373000 ms; unit time: 29.001373 ms; estimated overhead: 1.001373 ms Script done on Wed Dec 4 11:51:27 2002 msg38468/pgp0.pgp Description: PGP signature
[nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
Hi,
Summary: this is going to be a rather long email about the timing of various
_sleep functions, compared to the same on Linux.
I ran across this at the xmame mailing list, and I have seen some
interesting results.
First the original mail which Steve sent, which will explain the question:
- Forwarded message from Steve Freeland <[EMAIL PROTECTED]> -
From: Steve Freeland <[EMAIL PROTECTED]>
Date: Sun, 1 Dec 2002 23:17:18 -0500
Subject: [Xmame] Use of usleep() with -sleepidle
So in the course of testing the next release of NetMAME (Real Soon
Now!) I had a look at how -sleepidle was implemented. Turns out it works
by calling usleep() in 0.1 ms increments.
The thing is, usleep() has a (relatively) huge overhead. I did
some testing (see below) and it turns out that you can't really usleep()
for less than 20 ms, for all practical purposes, at least on my system
(i386 Linux 2.4). I assumed the difference was due to usleep() being
based on using SIGALM, but nanosleep(), which supposedly isn't,
seems to have exactly the same precision (or lack thereof), so who knows.
Anyways, one possible alternative is using select() instead (with
no fd sets, just a timeout value), which seems to have a lower overhead --
about 10 ms, which is still large but at least is less than the duration
of one emulated frame.
I don't know how much this would benefit other platforms --
I tried on an OpenBSD machine (some sort of i386, don't have details
about the hardware) and the minimum overhead is about the same (20 ms) for
both calls. I've attached the program I used to test this in case anyone
wants to try it out on their systems (I'd be especially curious to see
what the results are for people which some sort of low-latency kernel.)
So: anyone see a reason why the usleep() calls shouldn't be
replaced by select()s, for benefits where they may be found?
- End forwarded message -
Steve attached the program I also attach. Of course I was interested in
running times on FreeBSD so I ran it on my fairly -STABLE box, an
Athlon XP1700+ (I'm assuming CPU speed is the only relevant attribute
here, please correct me if I'm wrong). The result is attached, as
'sleep-bsd-1700.log'. Others on the list did the same, using their
various Linux boxes, and this is where it got interesting. Their logs
are attached as well, as sleep-lnx-*.log based on CPU speed [1].
One had an Athlon 1400XP, and got the following for the select speeds:
%%%
Testing _select_sleep (x 1000), delay 8
Total time: .906000 ms; unit time: 9.06 ms; estimated overhead: 1.06 ms
%%%
Someone else had an Athlon Thunderbird 1.2Ghz, and got the following:
%%%
Testing _select_sleep (x 1000), delay 8
Total time: 8276.96 ms; unit time: 8.276960 ms; estimated overhead: 0.276960 ms
%%%
(admittedly that person had applied some kernel patches).
Compared to my 1700XP, that's a factor 6 slower than the slowest Linux case
on a lesser processor:
%%%
Testing _select_sleep (x 1000), delay 8
Total time: 2.027000 ms; unit time: 20.27 ms; estimated overhead: 12.27 ms
%%%
What's going on here? Is our select really that much slower, or is the program
measuring the wrong values, or doesn't this speed make a difference in
'real-world' applications, or what?
--Stijn
[1] Yes I know an Athlon 1400XP isn't 1400 MHz but that's not really relevant
here. I'm doing a comparison, not a real numbercrunching benchmark.
--
SIGSIG -- signature too long (core dumped)
#include
#include
#include
static int
_tv_subtract(struct timeval *tv1, struct timeval *tv2)
{
int result;
result = (tv1->tv_sec - tv2->tv_sec) * 100;
result += (tv1->tv_usec - tv2->tv_usec);
return result;
}
void
_select_sleep(unsigned usec)
{
struct timeval delay = { usec / (1000 * 1000), usec % (1000 * 1000) };
select(0, NULL, NULL, NULL, &delay);
}
void
_usleep_sleep(unsigned usec)
{
usleep(usec);
}
void
_nanosleep_sleep(unsigned usec)
{
struct timespec delay = { (usec * 1000) / (1000 * 1000 * 1000),
(usec * 1000) % (1000 * 1000 * 1000) };
nanosleep(&delay, NULL);
}
typedef void (*sleep_fn_t)(unsigned);
#define TEST_COUNT 1000
void
main()
{
unsigned i, j, k;
unsigned delays[] = { 3, 8, 13, 18, 23, 28 }; /* milliseconds */
sleep_fn_t sleep_fn[] = { _select_sleep,
_usleep_sleep,
_nanosleep_sleep };
const char *sleep_fn_name[] = { "_select_sleep",
"_usleep_sleep",
"_nanosleep_sleep" };
struct timeval start_time, end_time;
for (i = 0; i < sizeof(delays) / sizeof(delays[0]); i++) {
for (j = 0; j < sizeof(sleep_fn) / sizeof(sleep_fn[0]); j++) {
double total_ms;
printf("Testing %s (x %d), delay %d\n",
sleep_fn_name[j],
TEST_COUNT,
de
Re: VMware 3 on FreeBSD?
On Mon, Sep 02, 2002 at 02:54:06PM +0100, Bruce M Simpson wrote: > On Mon, Sep 02, 2002 at 03:31:59PM +0200, Stijn Hoop wrote: > > You have it running?! I'm still struggling to get a vmmon module, without > [snip] > > Ah. I installed the vmware2 port, *then* the vmware3 rpm (using rpm2cpio). > This just used the existing vmmon module. I assume more tweaking will > be necessary as was the case for vmware2. I'll try that tomorrow. The sources for the vmmon-module are a bit different at least, so I'm surprised it works, but I'm ready to give it a try :) > [snip] > > Way above my head :) > > This is purely speculation as to how USB devices might be handled. Maybe someone more in the know can port the usbdevfs (as an aside, is that a Linuxism? Why not use a standard devfs?) --Stijn -- Beware of he who would deny you access to information. For in his heart he thinks himself your master. -- Sid Meyer, "Sid Meyer's Alpha Centauri" msg36678/pgp0.pgp Description: PGP signature
Re: VMware 3 on FreeBSD?
On Mon, Sep 02, 2002 at 02:23:51PM +0100, Bruce M Simpson wrote: > On Mon, Sep 02, 2002 at 12:37:47PM +0200, Mark Santcroos wrote: > > On Fri, Aug 30, 2002 at 09:20:12AM +0100, Bruce M Simpson wrote: > > > Having said that though, I have had 3.0 running as well as 2.0, under > >^^ > > Can you elaborate a bit more please? Probably your definition of 'running' > > is less strict than mine. > > As in, just dumped the executables onto the box, and had it run - I haven't > attempted to run any guest OSes yet. You have it running?! I'm still struggling to get a vmmon module, without which vmware spits out this indefinitely: VMware Workstation Error: Could not open /dev/vmmon: No such file or directory. Please make sure that the kernel module `vmmon' is loaded. Press "Enter" to continue... I've tried grabbing the sources for the 2.x vmware modules but a lot of patches fail... > The USB functionality looks like it's > going to need either a userland ELF redirection (via the LD_PRELOAD > mechanism) to 'pretend' to field Linux usdevfs requests. Either that or we're > going to need to port (hack, spit) usbdevfs. The userland solution is > probably quicker to punt out and code (map open/ioctl and other syscalls, > match by path, onto /dev/ugen*) than porting usbdevfs. Way above my head :) > Joe Karthausen is talking about making this a project (porting 3.1). Less > talk more rock? :-) Trying to, but not succeeding... --Stijn -- I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work." -- Gallagher msg36676/pgp0.pgp Description: PGP signature
VMware 3 on FreeBSD?
Hi, sent this to -questions a week ago, got no response, so I'm asking again here: is it possible to run VMware 3 on -STABLE? If so, how? I noticed there is no port like there is for VMware 2, so that's why I'm asking. Thanks, --Stijn -- Help Wanted: Telepath. You know where to apply. msg36509/pgp0.pgp Description: PGP signature
Re: FreeBSD-1.X public cvs?
On Wed, Jan 30, 2002 at 06:57:37PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Stijn Hoop writes: > >On Wed, Jan 30, 2002 at 09:41:15AM -0700, Nate Williams wrote: > >> A FreeBSD 1.X CVS tree has been found, which has it's first import as > >> 386BSD 0.1 + PK 024. There are a couple minor points that need to be > >> clarified from Caldera before it can be made public. > > > >Just curious, but will this be folded in the main CVS tree, or will it be > >available as a separate tree/cvsup dist? I'd imagine that the CVS hackery > >needed to implement the former takes a lot of time... > > It will not be folded in. > > But if somebody were into a _real_ tour de force of history, they > would try to slurp all of the "true" UNIX's into a joint tree now, > CVS is probably not up to it, but perforce might be. > > now _THAT_ would be usable history online... :-) Not to mention an incredably cool and insane job at the same time! (but I'm not applying :) Points noted, I'm anxious to see the code, whether as a port or something else. To Caldera, a compliment in advance: thanks for letting this piece of history get out! --Stijn -- Q: Why is Batman better than Bill Gates? A: Batman was able to beat the Penguin. msg31258/pgp0.pgp Description: PGP signature
Re: FreeBSD-1.X public cvs?
On Wed, Jan 30, 2002 at 09:41:15AM -0700, Nate Williams wrote: > A FreeBSD 1.X CVS tree has been found, which has it's first import as > 386BSD 0.1 + PK 024. There are a couple minor points that need to be > clarified from Caldera before it can be made public. Just curious, but will this be folded in the main CVS tree, or will it be available as a separate tree/cvsup dist? I'd imagine that the CVS hackery needed to implement the former takes a lot of time... --Stijn -- "I'm not under the alkafluence of inkahol that some thinkle peep I am. It's just the drunker I sit here the longer I get." msg31255/pgp0.pgp Description: PGP signature
Re: Oh my god, Google has a USENET archive going back to 1981!
On Tue, Jan 08, 2002 at 02:43:55PM -0800, Bruce A. Mah wrote: > ; I don't know which is more sad, the fact that I thought of doing this, > ; or the fact that I still remember how. > COUT EQU $FDED ; character output > > REPLY LDX #0 > :1LDA TEXT,X > BEQ :2 > JSR COUT > INX > BNE :1 ; blows up if string length > 255 > :2RTS > > TEXT BYT "No thanks, I've got a bunch from my Apple ][ days.", $0D, $00 That sure brings back memories... I'm not as old as most are around here I guess, but this rings a bell. /me goes off to hunt back his Apple ][ w/ 48k mem, applesoft & 2(!) floppy drives :) --Stijn -- I really hate this damned machine I wish that they would sell it. It never does quite what I want But only what I tell it. msg30844/pgp0.pgp Description: PGP signature
Re: how to make 'for' understand two words as a single argument
On Mon, Oct 01, 2001 at 08:38:35AM -0300, Daniel C. Sobral wrote: > "Eugene L. Vorokov" wrote: > > > > I have a script which is supposed to convert all filenames to lowercase > > recursively from current directory. It looks like: > > > > echo "Processing files" > > for i in `ls |grep [A-Z]`; \ > > do mv $i `echo $i |tr [A-Z] [a-z]`; echo $i;\ > > done; > > for i in `find . -name "*" -type d -maxdepth 1`;\ > > do if [ $i != "." ]; then cd $i; echo "Processing sub-dir $i"; $0; cd ..; fi \ > > done; > > > > It works fine unless some file or directory has a space in it's name. > > It this case each word is interpreted as a separate argument by 'for' > > and script doesn't find files. > > Any way using `` won't work. for i in a "b c" d works, for instance, but > there is not way that I know of that you can control the output this way > using ``. Yes there is: set IFS to only contain a newline beforehand. That's my local hack, your way is probably better :) --Stijn -- "I used to think I was indecisive, but now I'm not so sure." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recent changes to libdialog are weird
On Mon, Sep 17, 2001 at 02:00:05PM +0200, Sheldon Hearn wrote: > On Mon, 17 Sep 2001 13:50:45 +0200, Stijn Hoop wrote: > > IMHO, you just got used to it. Present the interface to a Windows user > > who hasn't seen it before and watch them getting frustrated the third > > time sysinstall asks 'Proceed?' while they tried to select the disk they > > would be installing on... > > Fine, as long as that assumption has been TESTED with "standard > non-power Windows users", i.e. the masses. Yes, that would be a good idea. > Since I come from a Windows background, and since I avoided using a > mouse like the plague, I figured I was well-qualified to comment. I think everyone is qualified - user interface isn't about qualification, it just needs to be non-intrusive and easily accessible for everyone. [1] I don't know if my opinion is shared by the majority - it just seems so to me, given that I've heard a lot of friends of mine, windowsy people who were trying to install FreeBSD, complaining about this behaviour of the space/enter combo. > I realize now that I may not have a very representative view of what > sensible dialogue behaviour is, given your comments above. So long as > you're not just saying that, and someone's actually proven it to be > true by taking a reasonably sized sample. Agreed. Maybe me and my friends are just weird :) Problem is, how do we take a sample? --Stijn [1] Yes this is an ideal which probably can't be achieved - but we can try to make things better, can't we? :) -- The right half of the brain controls the left half of the body. This means that only left handed people are in their right mind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recent changes to libdialog are weird
On Mon, Sep 17, 2001 at 01:44:20PM +0200, Sheldon Hearn wrote: > Recently, libdialog's use of tab, space and enter seems to have changed. > Now, space and enter mean the same thing. Before, enter was a > context-insensitive short-cut to the currently selected dialogue > "submit" button. Yes, and for the better; see below: > What many folks may not realize is that the new behaviour, while "safer" > than what we had before, makes libdialog behave differently from at > least Motif, Windows, JavaAWT, JavaSwing. Eh, no. While it's true that pressing in a dialog box is commonly recognized as meaning 'use the default button', that's only used if the default button is clearly focused, and when not selecting things in a subframe - in other words, not always. What was wrong in libdialog (and which I and others have been complaining about for a long time) is that while selecting items from lists in subframes you still selected the default button instead of crossing the item in the list. Ditto in other places, where people expected to select the current item. I can't count the number of times I had to restart selecting things anymore. It isn't just sysinstall either - ports/www/mod_php4, which has a nice interactive menu, also uses dialog(1) which had the same behaviour. I'd like to see the person that intuitively pressed 'space' instead of 'enter' to select an option in that menu. > So what we have now is a libdialog that protects the finger-happy, while > confounding those who expect "pretty standard behaviour". IMHO, you just got used to it. Present the interface to a Windows user who hasn't seen it before and watch them getting frustrated the third time sysinstall asks 'Proceed?' while they tried to select the disk they would be installing on... > I reckon if sysinstall needs to be weird, sysinstall should use its own > weird version of libdialog and leave the distributed libdialog alone. No - I vote to keep the current code. It's made my life easier already. --Stijn -- ] Nothing safer than a 'cat /dev/wallet | grep $price > real-person; \ ] mv $thing-to-buy $my-case I'd prefer 'mv $thing-to-buy $my-case && cat /dev/wallet | \ grep $price > real-person -- Anonymous, [EMAIL PROTECTED], in message <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
On Tue, Sep 11, 2001 at 11:44:26AM -0700, Mark D. Anderson wrote: > subversion (apache/bsd, http://subversion.tigris.org/ ) > probably the most active effort for an open source replacement for CVS. > as of a week ago it just hits its "milestone 3", of being self-hosting > (it was previously using CVS to keep its own sources). > it is still being actively worked on; now is probably not a good time to > adopt it. while it intends to supplant CVS, it is inclear to me whether > it will support a CVSup equivalent. You're right, this is not the time to adopt it, but I'm keeping an eye on this one - it's actively trying to be easy for CVS users to use, plus it tries to correct CVS's deficiencies, plus they are working on CVS -> subversion repository conversion tools. Not to mention the license. Thanks for the pointer! --Stijn -- "I'm not under the alkafluence of inkahol that some thinkle peep I am. It's just the drunker I sit here the longer I get." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: help needed, kernel autoconf gets stuck
On Thu, Aug 16, 2001 at 11:19:57AM +0300, Danny Braniss wrote: > hi, > i posted this yesterday, but no one bit, so here we go again: > > adding 'snd_ich_load="YES"' will cause the kernel autoconf to hang (sometimes) > after isa_probe_children(...) and before configure_final(...) > > when it doesn't get stuck, all systems work fine, X11/sound etc. > > so i narrowed it down, my guess it's an unexpected/unwanted interrupt. > > now i'm stuck too, since i have no idea how to figure out who/why is > interrupting. > > thanks, > danny Aha! This is what I've been seeing too - although I didn't realize it was the sound subsystem, because I compiled pcm into the kernel. It's not a guaranteed hang however, sometimes the kernel boots, sometimes it doesn't. It gets stuck more consistently when using boot -v however. I can confirm this wasn't the case in my 4.3 kernel, but that's probably because the ICH sound driver wasn't activated back then. What motherboard do you have? I have an Intel i815e (Dell Optiplex G115). Would opening a PR help? --Stijn -- Tact, n.: The unsaid part of what you're thinking. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/gnu/lib/libdialog checklist.c menubox.c radiolist.c textbox.c tree.c yesno.c
On Tue, Jul 17, 2001 at 10:43:44PM -0700, Eric Melville wrote: > > Modified files: > > gnu/lib/libdialogchecklist.c menubox.c radiolist.c > > textbox.c tree.c yesno.c > > Log: > > Improve the interface provided by libdialog. Move a cursor around over > > the components and trigger actions based on its position. This reduces > > the need to remember the functions of various keys, and makes the > > interface more consistant across library. > > This eliminates the problem where people would exit a menu when they really > wanted to select an item (the space/enter confusion), amongst other things. *THANK YOU* I can't tell any more how many times this annoying libdialog has bitten me in this regard. > I intend to MFC this sometime before 4.4-RELEASE, potentially along with > some things people from mailing lists have submitted. Even better - I take it sysinstall then uses 'sane' space/enter combo's also (it being a consumer of libdialog)? --Stijn -- I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work." -- Gallagher To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD ISOs & redistribution [was Re: FreeBSD Mall now BSDCentral]
FWIW, On Fri, Jul 06, 2001 at 09:25:41AM +0100, Nik Clayton wrote: > I think that the conclusion is that "the project" should be putting out > five ISOs and making them freely available. Four of them would > correspond with the four discs that have traditionally made up the > commercial CD sets. The fifth one would be a mini-ISO that contains > everything needed to do a complete install, but now ports or packages > (basically, the existing disc 1 with no third party apps, except, > possibly, XFree86). This ISO would only be about 200-250MB in size, and > is more useful to the people who only download the ISO to do an install, > and use the net for packages/ports. I *really* like the idea of this small ISO. I don't know if those four ISOs should all be available, but that fifth one is a great idea. I always use the net for installing ports etc., but I like to keep a copy of a -RELEASE disc for reinstalls around. Right now I always download ~400mb too much :( > Third parties can then base their commercial distributions around these > ISOs. They might simply repackage them (on CD, or DVD). Or they might > provide value-add services, such as additional documentation, more packages > and so on. Maybe the infrastructure that's required to make the 4CD set should go into the repo, but not the ISO's themselves? (and yes, I know this is hard, and it's been argued before, re: what if Jordan gets hit by a bus...) If five ISO images are available, people *will* get confused about what is the right one to install FreeBSD, not to mention that people will (try to) download all four discs when they only need one (talk about waste of bandwidth). If the infrastructure is something like 'make release' then interested third parties can easily produce those four discs themselves. The hard part is getting the release process to that point. Or am I mistaking and is this already included? > The thorny question of "What do they have to include and still call it > FreeBSD?" is resolved by saying that any FreeBSD distribution must > include, as a minimum, the contents of the "mini" ISO (including > sysinstall). Anyone that wants to include an alternative installation > routine (open or closed source) can do, as long as sysinstall is still > there. Then the FreeBSD docs can continue to refer to sysinstall, and > the project doesn't get flack if someone puts together a distribution > with a crap installer, because sysinstall will always be there as a > fallback. Like I already stated above, this is a really good idea IMHO. --Stijn -- "I'm not under the alkafluence of inkahol that some thinkle peep I am. It's just the drunker I sit here the longer I get." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree86 4.1.0 and i810
On Thu, Jun 07, 2001 at 06:59:15AM -0500, Will Andrews wrote: > On Thu, Jun 07, 2001 at 12:32:50AM -0500, Andrew Hesford ([EMAIL PROTECTED]) wrote: > > The XFree86 4.0.1 sources *did* offer a helpful hint. I have posted > > another email which includes a patch to fix the buggy i810 driver. > > Are you people talking about XFree86 4.1.0 or 4.0.1? Because > 4.0.1 is >WAY< outdated. :-) Uhm, yeah, but the problems with switching VT's weren't present in that version. Something changed between 4.0.1 and 4.0.2 that caused the problem, and I think Andrew wants to know what exactly. BTW, Andrew, I really hope you do succeed (esp. with the recent 4.1.0 troubles). Thanks for investigating this! --Stijn -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM (was: Re: MAIL set by whom?)
On Mon, Jan 22, 2001 at 09:46:47AM +, Dominic Mitchell wrote: > Would it be a good idea to start using /etc/pam.d ala RedHat, instead of > the monolithic /etc/pam.conf? > > As far as I can see the support is already there, it's just not being > used due to the presence of the /etc/pam.conf. > > This would make installing PAM entries far easier for the ports. Seconded. I don't see any reason *not* to do it this way. OTOH, ports are not supposed to install in /etc, so the best way would be to extend pam to support /usr/local/etc/pam.d *and* /etc/pam.d (if it doesn't already do this). No, I'm not sending patches, sorry :) --Stijn -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
