RE: First (easy) td_ucred patch
I can't look at it till tomorrow. But I've been watching. I'd be surprised if anything broke with what I've seen. I'll look at it then if you haven;t commited by then. On Sat, 23 Feb 2002, John Baldwin wrote: > > On 23-Feb-02 John Baldwin wrote: > > I'm currently testing the following patch whcih is a subset of the td_ucred > > changes. It involves no API changes, but only contains 2 basic changes: > > > > 1) We still need Giant when doing the crhold() to set td_ucred in > >cred_update_thread(). This is an old bug that is my fault. I knew that > >PROC_LOCK was sufficient yet which was my reason for not using td_ucred. > >However, we could still be derferencing a stale p_ucred and doing very bad > >things, so this needs to be fixed until p_ucred is fully protected by the > >PROC_LOCK. This also means that td_ucred is now safe to use. As such: > > > > 2) All the "easy" p->p_ucred -> td->td_ucred changes that don't involve the > >changes to API's such as suser() and p_canfoo(). The next patch in this > >series will most likely be the suser() API change. > > > > http://www.FreeBSD.org/~jhb/patches/ucred.patch > > To apply this patch, use -p6 like so: > > cd work/my/kernel/tree/sys > patch -p6 < path/to/patch/file/ucred.patch > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: First (easy) td_ucred patch
please feel free to commit. If you break something so be it. I've been watching your P4 commits, and have not seen any obvious problems I assume that your "easy" changes are those you;ve been doing on P4. On Fri, 22 Feb 2002, John Baldwin wrote: > I'm currently testing the following patch whcih is a subset of the td_ucred > changes. It involves no API changes, but only contains 2 basic changes: > > 1) We still need Giant when doing the crhold() to set td_ucred in >cred_update_thread(). This is an old bug that is my fault. I knew that >PROC_LOCK was sufficient yet which was my reason for not using td_ucred. >However, we could still be derferencing a stale p_ucred and doing very bad >things, so this needs to be fixed until p_ucred is fully protected by the >PROC_LOCK. This also means that td_ucred is now safe to use. As such: > > 2) All the "easy" p->p_ucred -> td->td_ucred changes that don't involve the >changes to API's such as suser() and p_canfoo(). The next patch in this >series will most likely be the suser() API change. > > http://www.FreeBSD.org/~jhb/patches/ucred.patch > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CA updated
* Mike Smith <[EMAIL PROTECTED]> [020222 21:56] wrote: > > I've finally updated the ACPI CA codebase with Intel's 20020214 drop > (yes, I tagged it 0217, my bad). Woo! Go Mike! -- -Alfred Perlstein [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: First (easy) td_ucred patch
:> as found in getgroups(). Some of these changes, for example return()ing :> in the middle of a procedure, are highly dependant on the removal of :> Giant. goto's are questionable but replacing them with return()s in :> the middle of a procedure isn't too hot an idea either. : :It's how the code is going to look as the final rendition. It also restores :the code more to its 4.x flow making a diff to see what actual changes SMPng :made easier to read. This makes no sense whatsoever. We aren't trying to make the code look like 4.x. We are trying to make it MP safe. :- kern.giant.proc as you would have it now is far too broad. Most of the proc : locking currently in the tree and in my work tree is not safe yet. This is : because certain fields are only locked in certain places. For a field to be : safe outside of Giant, it needs to be locked everywhere. You include both : code that contains partially locked fields and fully locked fields under the : same sysctl. This means I can't actually turn the sysctl on to do the : testing safely, so I might as well just leave Giant in there rahter than : bother with a useless sysctl. One solution might be to split ths sysctl up. : Well then, how many are we going to have, one sysctl for each field in proc? : This won't scale in my opinion. It may be useful for covering fields that : aren't fully locked, but for stuff that is done, I don't think you need it. :- How many various locking systems do syscalls like read() going call into? : Are we going to eventually need to check 8, 10, or 16 sysctl's? Trying to : keep all that straight will be a major pain. This is another reason I don't : think they scale well. :- We eventually have to go and remove all this stuff anyways. :- As another note specific to td_ucred: there is no other lock that you are : "covering up" for. It is a private per-thread pointer to a read-only : structure. I can see needing to turn Giant back on around a lock done : wrong, but there is no lock in this instance. I don't think you quite understand the purpose of instrumenting Giant. You are synthesizing problems where none exist, and you are making assumptions that are simply not true. You are exaggerating the issues to ridiculous extremes. You seem hell bent on taking parts of PROC out from under Giant. Well, where's the documentation? In your head? How the hell are other people supposed to be able to work on the system when the only person who knows what is safe and what is not is you? One of the things Giant instrumentation gives us is the ability to show people, very clearly in the code, what we believe to be safe and what we believe not to be safe, or in beta, simply by changing the giant globals in kern_mutex.c. It allows other developers to see, very clearly, *EXACTLY* where we are in the Giant pushdown work. The way you are doing it nobody will know what the hell is going on except you! :We need to people to test stuff as it comes out from under Giant so we can find The instrumented Giant does not in any way prevent this from occuring. It does not in any way prevent you from finding bugs. :Maybe if you want SMPng to take 5 times as long... : I think it's going to take 5 times as long if you make mass commits from P4 with no way to at least partially turn off the MP functionality you added and we wind up with dozens of impossible-to-find bugs a year down the line. I think it is going to take 5 times as long if there is no clear documentation or indication in the code showing developers what is safe, what is under test, and what is not safe. What I am doing is trying to prevent that from happening. You are treating each subsystem separately and assuming that bugs will be found on a per-subsystem basis, regardless of the complexity of the interactions between subsystems. Well, I know better. When you have a dozen subsystems interacting in an MP system and you have a race or MP-related bug, good fucking luck find it! How long do you want it to take to get a stable 5.x release? Because the way you are going it isn't going to happen until we hit 5.3 or so. -Matt Matthew Dillon <[EMAIL PROTECTED]> :John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: First (easy) td_ucred patch
On 23-Feb-02 Matthew Dillon wrote: >:> I'm currently testing the following patch whcih is a subset of the td_ucred >:> changes. It involves no API changes, but only contains 2 basic changes: >:> >:> 1) We still need Giant when doing the crhold() to set td_ucred in >:>cred_update_thread(). This is an old bug that is my fault. I knew that >:>PROC_LOCK was sufficient yet which was my reason for not using td_ucred. >:>However, we could still be derferencing a stale p_ucred and doing very >:>bad >:>things, so this needs to be fixed until p_ucred is fully protected by >:>the >:>PROC_LOCK. This also means that td_ucred is now safe to use. As such: >:> >:> 2) All the "easy" p->p_ucred -> td->td_ucred changes that don't involve the >:>changes to API's such as suser() and p_canfoo(). The next patch in this >:>series will most likely be the suser() API change. >:> >:> http://www.FreeBSD.org/~jhb/patches/ucred.patch > > Well, I have some issues with this patch. It seems to include > a number of structural changes ranging from the removal of braces > (syntactical changes) to straightforward but major flow changes such > as found in getgroups(). Some of these changes, for example return()ing > in the middle of a procedure, are highly dependant on the removal of > Giant. goto's are questionable but replacing them with return()s in > the middle of a procedure isn't too hot an idea either. It's how the code is going to look as the final rendition. It also restores the code more to its 4.x flow making a diff to see what actual changes SMPng made easier to read. > * I do not think it is a good idea to mix these changes with the > ucred changes, even if they appear to be straightforward. > You are making a large number of changes to the system all at once. > The changes should focus only on what is absolutely necessary in > this round. Leave syntactical (cleanup?) to a later round. They weren't committed separately from adding Giant to the functions when they went in. :) > * I strongly, *strongly* disagree with the removal of Giant at this > time, even in 'read-only' functions. I would much rather see a > methodology whereby Giant is replaced with an instrumented Giant > such as found in the patches I was working on. If you are really > worried about the 10ns of call overhead I believe Peter has been > interested in making the instrumentation optionable at compile > time (and I am not against that provided it is done correctly). I don't care about whatever time it takes to do teh check. I don't make decisions about debugging code based on clock cycles. Here are my concerns: - kern.giant.proc as you would have it now is far too broad. Most of the proc locking currently in the tree and in my work tree is not safe yet. This is because certain fields are only locked in certain places. For a field to be safe outside of Giant, it needs to be locked everywhere. You include both code that contains partially locked fields and fully locked fields under the same sysctl. This means I can't actually turn the sysctl on to do the testing safely, so I might as well just leave Giant in there rahter than bother with a useless sysctl. One solution might be to split ths sysctl up. Well then, how many are we going to have, one sysctl for each field in proc? This won't scale in my opinion. It may be useful for covering fields that aren't fully locked, but for stuff that is done, I don't think you need it. - How many various locking systems do syscalls like read() going call into? Are we going to eventually need to check 8, 10, or 16 sysctl's? Trying to keep all that straight will be a major pain. This is another reason I don't think they scale well. - We eventually have to go and remove all this stuff anyways. - As another note specific to td_ucred: there is no other lock that you are "covering up" for. It is a private per-thread pointer to a read-only structure. I can see needing to turn Giant back on around a lock done wrong, but there is no lock in this instance. We need to people to test stuff as it comes out from under Giant so we can find the bugs sooner rather than later, the current way these things work is far too coarse grained and I think I'll be spending more time figuring out how to split them up to make them useful and then figure out where they need to be acquired. For example, assuming I used kern.giant.proc.ucred for just the td_ucred stuff, since I've changed just about every VOP in the system, I now need to add instrumentation around every single syscall that might call a VOP, or that might call any of the other functions I changed. Maybe if you want SMPng to take 5 times as long... -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To U
HEADS UP: ACPI CA updated
I've finally updated the ACPI CA codebase with Intel's 20020214 drop (yes, I tagged it 0217, my bad). This is the first drop that Intel haven't asked me not to commit since the 20011120 version, so there are a large number of changes and bugfixes. See Intel's logs at http://developer.intel.com/technology/iapc/acpi for more details. There aren't many changes in the FreeBSD-specific code, this is just catching up with major improvements in the interpreter. As usual, please report any problems or success to the list. Regards, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: First (easy) td_ucred patch
:> I'm currently testing the following patch whcih is a subset of the td_ucred :> changes. It involves no API changes, but only contains 2 basic changes: :> :> 1) We still need Giant when doing the crhold() to set td_ucred in :>cred_update_thread(). This is an old bug that is my fault. I knew that :>PROC_LOCK was sufficient yet which was my reason for not using td_ucred. :>However, we could still be derferencing a stale p_ucred and doing very bad :>things, so this needs to be fixed until p_ucred is fully protected by the :>PROC_LOCK. This also means that td_ucred is now safe to use. As such: :> :> 2) All the "easy" p->p_ucred -> td->td_ucred changes that don't involve the :>changes to API's such as suser() and p_canfoo(). The next patch in this :>series will most likely be the suser() API change. :> :> http://www.FreeBSD.org/~jhb/patches/ucred.patch Well, I have some issues with this patch. It seems to include a number of structural changes ranging from the removal of braces (syntactical changes) to straightforward but major flow changes such as found in getgroups(). Some of these changes, for example return()ing in the middle of a procedure, are highly dependant on the removal of Giant. goto's are questionable but replacing them with return()s in the middle of a procedure isn't too hot an idea either. * I do not think it is a good idea to mix these changes with the ucred changes, even if they appear to be straightforward. You are making a large number of changes to the system all at once. The changes should focus only on what is absolutely necessary in this round. Leave syntactical (cleanup?) to a later round. * I strongly, *strongly* disagree with the removal of Giant at this time, even in 'read-only' functions. I would much rather see a methodology whereby Giant is replaced with an instrumented Giant such as found in the patches I was working on. If you are really worried about the 10ns of call overhead I believe Peter has been interested in making the instrumentation optionable at compile time (and I am not against that provided it is done correctly). The reason I am strongly opposed to the removal of Giant is several fold: - Giant serves to mark where we were essentially single threading the kernel before and this will be important in understanding and tracking down bugs we find in the future. And make no mistake, there will be many. - Giant is going to be pushed down into many subsystems in coming months. It is highly likely that many hard-to-find bugs are going to come out of the woodwork, no matter how conservative we are or how well we believe we understand the code. Without instrumentation tracking down the less obvious bugs is going to be difficult. - It's a bad idea to second-guess the code, even if a piece of code looks like Giant can simply be removed (i.e. due to being a read-only function like getuid()). The removal of Giant creates all sorts of side effects, from something as simple as a difference in performance to something more complex such as creating memory sync points and removing (pseudo giant-enforced) atomicy that was previously depended upon. We are almost certainly going to face hard-to-find races in the code as Giant is unwound, even if we are extremely conservative in our commits. It's going to happen. The code was never designed for MP operation. Instrumenting Giant unconditionally at this early stage will make our jobs a whole lot easier. If you are completely against doing Giant instrumentation in your own patch sets then I would like both a head's up (like you just did) of patch sets you intend to commit to the main tree, and also permission to add Giant instrumentation in a secondary commit after you make the initial commit (which also means I would request that you not make code flow changes if at all possible). I think it's *that* important. I would much prefer that you do it yourself but if you won't I feel strongly enough about the issue to want to do it myself. --- on cred_update_thread() -- I suggested this same thing to Julian so I agree with adding Giant back in. Again, I would instrument it instead of just adding back in, i.e.: s = mtx_lock_giant(kern_giant_proc); PROC_LOCK(p); td->td_ucred = crhold(p->p_ucred); PROC_UNLOCK(p); mtx_unlock_giant(s); Instead of: mtx_lock(&Giant); PROC_LOCK(p); td->td_ucred = crhold(p->p_ucred); PROC_UNLOCK(p); mtx_unlock(&Giant); In anycase, if you are willing to either instrument Giant or allow me to then I am willing to do full reviews of reasonably-chunked patch sets (the URL you
RE: First (easy) td_ucred patch
On 23-Feb-02 John Baldwin wrote: > I'm currently testing the following patch whcih is a subset of the td_ucred > changes. It involves no API changes, but only contains 2 basic changes: > > 1) We still need Giant when doing the crhold() to set td_ucred in >cred_update_thread(). This is an old bug that is my fault. I knew that >PROC_LOCK was sufficient yet which was my reason for not using td_ucred. >However, we could still be derferencing a stale p_ucred and doing very bad >things, so this needs to be fixed until p_ucred is fully protected by the >PROC_LOCK. This also means that td_ucred is now safe to use. As such: > > 2) All the "easy" p->p_ucred -> td->td_ucred changes that don't involve the >changes to API's such as suser() and p_canfoo(). The next patch in this >series will most likely be the suser() API change. > > http://www.FreeBSD.org/~jhb/patches/ucred.patch To apply this patch, use -p6 like so: cd work/my/kernel/tree/sys patch -p6 < path/to/patch/file/ucred.patch -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: device figlet for the kernel
On 23-Feb-02 Kris Kennaway wrote: > On Fri, Feb 22, 2002 at 05:17:05AM -0500, John Baldwin wrote: > >> Currently figlet isn't a kernel module, but one could make it so without too >> much additional work. To play with this, first download and apply the patch >> at >> >> http://www.FreeBSD.org/~jhb/patches/figlet.patch > > I think this should be committed ASAP. Well, the supprot for kernel console filters needs to be fleshed out a bit more so that figlet could be a KLD before it would really be worth considering. Also, a better method of sending commands to a filter is needed. > Kris -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: device figlet for the kernel
On Fri, Feb 22, 2002 at 05:17:05AM -0500, John Baldwin wrote: > Currently figlet isn't a kernel module, but one could make it so without too > much additional work. To play with this, first download and apply the patch at > > http://www.FreeBSD.org/~jhb/patches/figlet.patch I think this should be committed ASAP. Kris msg35092/pgp0.pgp Description: PGP signature
First (easy) td_ucred patch
I'm currently testing the following patch whcih is a subset of the td_ucred changes. It involves no API changes, but only contains 2 basic changes: 1) We still need Giant when doing the crhold() to set td_ucred in cred_update_thread(). This is an old bug that is my fault. I knew that PROC_LOCK was sufficient yet which was my reason for not using td_ucred. However, we could still be derferencing a stale p_ucred and doing very bad things, so this needs to be fixed until p_ucred is fully protected by the PROC_LOCK. This also means that td_ucred is now safe to use. As such: 2) All the "easy" p->p_ucred -> td->td_ucred changes that don't involve the changes to API's such as suser() and p_canfoo(). The next patch in this series will most likely be the suser() API change. http://www.FreeBSD.org/~jhb/patches/ucred.patch -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Install World fails in -Current
On 23-Feb-02 Dag-Erling Smorgrav wrote: > David Wolfskill <[EMAIL PROTECTED]> writes: >> Sounds like a botched (or not run) "mergemaster" execution: > > No - mergemaster will croak because it runs mtree to build its temp > directory, so if you're trying to update a pre-smmsp system you have > to add the smmsp user and group manually. I think this is a bug but can't think of a clean way to work around it. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Install World fails in -Current
David Wolfskill <[EMAIL PROTECTED]> writes: > Sounds like a botched (or not run) "mergemaster" execution: No - mergemaster will croak because it runs mtree to build its temp directory, so if you're trying to update a pre-smmsp system you have to add the smmsp user and group manually. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: changes to rc.diskless*
On Fri, Feb 22, 2002 at 02:13:22PM -0500, Jake Burkholder wrote:
> > echo "+++ mount_md of /var"
> > -mount_md ${varsize:=65536} /var 1
> > +mount_md ${varsize:=32m} /var 1
>
> One problem with making the mds so big is that it uses type malloc
> which afaict uses malloc(9) to get the backing store.
I only changed the syntax for the size to something easier to read, but
not the size itself.
> much with M_WAITOK you might go to sleep and never be woken up. It
> might be better to use type vnode with file or swap based backing
> store.
No opinion :-)
> sparc64 machines tend to have more ram than older pcs that
> this might also be used on :)
one can set varsize=2m in /etc/rc.conf is they need to. :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Install World fails in -Current
On Fri, 22 Feb 2002, Glenn Gombert wrote: > All I did was to add a 'smmsp' user in via the sysisntall utility, ran > 'installworld/mergemaster' again and things worked fine, adding a not to > the Updating file might be a good idea for others thought :) Section 19.4.3 of the FreeBSD handbook does mention this type of problem, however only suggests comparing /etc/group with the new file. "There have been occasions when the installation part of ``make world'' has expected certain usernames or groups to exist. When performing an upgrade it is likely that these groups did not exist. This caused problems when upgrading." It might be worth including explicit mention about checking changes in master.passwd as well. I'll submit a patch tomorrow if nobody beats me to it... Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: changes to rc.diskless*
The rc.diskless1/2 scripts *do* need some work, I finally got my diskless
kernel booting (with help from Matt and Robert Watson) but it was a lot of
'trial and error' to do so"...but well worthwhile to boot diskless
(test/experimental) kernels for developmental purposes .
At 08:00 PM 2/21/2002 -0800, David O'Brien wrote:
>The existing very bazaar and local policy in rc.diskless1 is Just Wrong;
>and looks like no other Unix diskless configuration I've ever seen. I
>plan on committing this patch to negate this.
>
>The use of an MFS /var should also be settable. Otherwise installing
>ports(packages) is just a total PITA.
>
>
>Index: rc.diskless1
>===
>RCS file: /home/ncvs/src/etc/rc.diskless1,v
>retrieving revision 1.13
>diff -u -r1.13 rc.diskless1
>--- rc.diskless1 17 Jan 2002 00:10:28 - 1.13
>+++ rc.diskless1 22 Feb 2002 03:52:41 -
>@@ -92,13 +92,14 @@
> done
> echo "Interface ${bootp_ifc} IP-Address ${bootp_ipa} Broadcast
${bootp_ipbca}"
>
>+if [ -d /conf/default/etc ]; then
>+ mount_md 4096 /etc 0
>+ chkerr $? "MFS mount on /etc"
>+ /bin/chmod 755 /etc
>
>-mount_md 4096 /etc 0
>-chkerr $? "MFS mount on /etc"
>-/bin/chmod 755 /etc
>-
>-/bin/cp -Rp /conf/default/etc/* /etc
>-chkerr $? "cp /conf/default/etc to /etc MFS"
>+ /bin/cp -Rp /conf/default/etc/* /etc
>+ chkerr $? "cp /conf/default/etc to /etc MFS"
>+fi
>
> # Allow for override files to replace files in /etc. Use /conf/*/etc to
find
> # the override files. First choice is default files that # always override,
>@@ -113,6 +114,11 @@
> cp -Rp /conf/${i}/etc/* /etc
> fi
> done
>+
>+# Since we are starting with a very fresh /etc on an MFS:
>+if [ -d /conf/default/etc ]; then
>+ newaliases
>+if
>
> # Tell /etc/rc to run the specified script after it does its mounts but
> # before it does anything else.
>Index: rc.diskless2
>===
>RCS file: /home/ncvs/src/etc/rc.diskless2,v
>retrieving revision 1.15
>diff -u -r1.15 rc.diskless2
>--- rc.diskless2 26 Dec 2001 17:18:39 - 1.15
>+++ rc.diskless2 22 Feb 2002 03:56:18 -
>@@ -56,7 +56,7 @@
> fi
>
> echo "+++ mount_md of /var"
>-mount_md ${varsize:=65536} /var 1
>+mount_md ${varsize:=32m} /var 1
>
> echo "+++ populate /var using /etc/mtree/BSD.var.dist"
> /usr/sbin/mtree -deU -f /etc/mtree/BSD.var.dist -p /var
>@@ -83,7 +83,7 @@
> # so if /var/tmp == /tmp, then you don't get a vi.recover.
> #
> if [ ! -h /tmp ]; then
>- mount_md ${tmpsize:=20480} /tmp 2
>+ mount_md ${tmpsize:=64m} /tmp 2
> chmod 01777 /tmp
> fi
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
Glenn Gombert
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Install World fails in -Current
All I did was to add a 'smmsp' user in via the sysisntall utility, ran 'installworld/mergemaster' again and things worked fine, adding a not to the Updating file might be a good idea for others thought :) At 11:35 AM 2/22/2002 -0500, John Baldwin wrote: > >On 22-Feb-02 David Wolfskill wrote: >>>Date: Fri, 22 Feb 2002 08:33:01 -0500 >>>From: Glenn Gombert <[EMAIL PROTECTED]> >> >>>I have tried to re-cvsup and a clean rebuild the alst couple of days, and I >>>keep getting this error when I try and do an 'installworld' ..after a clean >>>build...does anyone know what might be causing this?? >> >>>... >>> >>>mtree -deU -f /usr/src/etc/mtree/BSD.var -p /var >>>mtree: line 67: unknown user smmsp >> >> >> Sounds like a botched (or not run) "mergemaster" execution: > >Sort of. The problem is we have added a new user that installworld depends on. >Imagine a 4.x to 5.0 upgrade right now. 4.x doesn't have this user IIRC, and >you are supposed to run installworld before mergemaster. Sounds like a nice >catch 22 to me. :-/ > >-- > >John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ >"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OpenPAM
OpenPAM Cantaloupe is now available at http://sourceforge.net/project/showfiles.php?group_id=45677> along with an integration patch for FreeBSD-CURRENT. Since the two previous releases have solicited absolutely no feedback other than to point out a broken link on the project's web page, I assume that everybody is happy with the code, and that nobody will object when I import it into CVS and ditch Linux-PAM later this weekend. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TWiki as promised...
> Hmm cute > > I added a comment as an experiment.. > really quite easy to use after the first 5 minute learning curve. > Well, you're the only one to use it thus far so let's see what others think as well. Thanks for checking it out though. Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TWiki as promised...
Hmm cute I added a comment as an experiment.. really quite easy to use after the first 5 minute learning curve. On Fri, 22 Feb 2002, George V. Neville-Neil wrote: > 2) What do I have to do to use this? > > To read the stuff just go to: > > http://www.neville-neil.com/twiki/bin/view/Main/WebHome > > and click on the Freebsd label. > > To update you must register. Go to the main page and register yourself. > The passwords are encrypted but I WOULD NOT use my system password > here. Actually, I'd like it if you didn't use any important password there, I > don't want to be responsible for y'all in that way. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
TWiki as promised...
Hi Folks, In an attempt to help out with coordination on projects I've put up a TWiki (see www.twiki.org for info on TWiki) site on my web server. As a guest you can read but not update, you have to register to update content. There is a Freebsd web and it has 1 topic which is the SMP project. I have put the entire page from http://www.freebsd.org/smp/ into TWiki. The local references on that page (i.e. the href:./foo.txt stuff) are now external references but we could fix that. A few notes might be helpful. 1) Why did you do this? TWiki (and Wiki's in general) allow people to easily update centralized web content without haveing to have real logins on the web serving computer. This makes keeping things like worklists trivial. The language used by TWiki is NOT HTML but a clever subset that requires a lot less work. For instance a table looks like this: | Task | Responsible | Date| | Task 1| GeorgeNevilleNeil| 2 March 2002 | This will get translated into a nice, simple HTML table by the TWiki stuff. 2) What do I have to do to use this? To read the stuff just go to: http://www.neville-neil.com/twiki/bin/view/Main/WebHome and click on the Freebsd label. To update you must register. Go to the main page and register yourself. The passwords are encrypted but I WOULD NOT use my system password here. Actually, I'd like it if you didn't use any important password there, I don't want to be responsible for y'all in that way. 3) How do I learn more about TWiki? Go to www.twiki.org In particular check out: http://TWiki.org/cgi-bin/view/Main/TWikiPresentation s to see why and how we should be using TWiki. ONE FINAL NOTE. TWiki uses WordsLikeThis to denote automatic links. This means that FreeBSD is an automatic link. If you MUST type FreeBSD then put a before it on the page. I'm working with the author to come up with a way to make it so that FreeBSD never gets converted within our TWiki Web. Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build Failure (libkvm)
On Fri, 22 Feb 2002, John Hay wrote: > > > > > > >Date: Fri, 22 Feb 2002 08:09:28 -0900 > > > > > > > >Last night's build for -current failed with the following: > > > > > > I got -CURRENT built today without problem. Recent CVSup history: > > > > > (snip history) > > > > > > Might try updating again > > > > Already did that. The update was about 15 minutes prior to that last build > > attempt. Interesting, the last change to that file was about 2 weeks ago and > > I have done several builds since then. I'm clueless as to why it picked today > > to fail rather than immediately following the commit. > > The type of p_runtime in sys/proc.h changed today, but ki_runtime in > sys/user.h hasn't changed yet. Or maybe it shouldn't change and there > should rather be a conversion? Who knows. :-) phk? > it must not change in ki_runtime (unless it's binary compatible on all platforms). the aim of ki_runtime is to keep exporting a STABLE interface (i.e. one that doesn't change). a simple conversion in libkvm is enough. I'll be going through that file with a rototiller in a few months anyhow. > John > -- > John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build Failure (libkvm)
the probkem is that phk didn't test a buildworld before making the following change to proc.h: revision 1.204 date: 2002/02/22 13:32:01; author: phk; state: Exp; lines: +1 -1 Convert p->p_runtime and PCPU(switchtime) to bintime format. Any change to proc.h needs an appropriate change to /usr/src/lib/libkvm/kvm_proc.c to convert the new value to th old stable type. (we will continue to export the old type so that ps doesn't need to be recompiled all the time). Slightly humourous because this is EXACTLY the same breakage (same file , about 10 lines away) that he was ragging me about doing last week :-) On Fri, 22 Feb 2002, Beech Rintoul wrote: > Last night's build for -current failed with the following: > > mkdep -f .depend -a-DLIBC_SCCS -I/usr/src/lib/libkvm > /usr/src/lib/libkvm/kvm.c /usr/src/lib/libkvm/kvm_i386.c > /usr/src/lib/libkvm/kvm_file.c /usr/src/lib/libkvm/kvm_getloadavg.c > /usr/src/lib/libkvm/kvm_getswapinfo.c /usr/src/lib/libkvm/kvm_proc.c > cd /usr/src/lib/libkvm; make _EXTRADEPEND > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm.c > -o kvm.o > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_i386.c -o kvm_i386.o > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_file.c -o kvm_file.o > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_getloadavg.c -o kvm_getloadavg.o > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_getswapinfo.c -o kvm_getswapinfo.o > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o > /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': > /usr/src/lib/libkvm/kvm_proc.c:316: incompatible types in assignment > *** Error code 1 > > Stop in /usr/src/lib/libkvm. > *** Error code 1 > > Tried all the usual, rm -R /usr/obj, fresh cvsup etc > > Beech > -- > --- > Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] > /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission > \ / - NO HTML/RTF in e-mail | P.O. Box 230510 > X - NO Word docs in e-mail | Anchorage, AK 99523-0510 > / \ - > > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent USB problems
I had no problem with kernel from February 14, but failed ums probes are happening very consistently with kernel from Feb 18. Kernels from dates earlier than Feb 14 failed to attach USB mouse most of the time but sometimes misteriously managed to work. No configuration was changing between successfull and unsuccessful boots, and there was no pattern whatsoever to hint why was that happening. By the way, the problem is related to the ums driver only, apparently. While I am having problems with the mouse, my USB scanner works absolutely reliably. > with current of yesterday everything seems to be ok for me again. But > I do not see any reason for this (code has not changed inbetween). I > will upgrade today and To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: changes to rc.diskless*
Apparently, On Thu, Feb 21, 2002 at 08:00:51PM -0800,
David O'Brien said words to the effect of;
> The existing very bazaar and local policy in rc.diskless1 is Just Wrong;
> and looks like no other Unix diskless configuration I've ever seen. I
> plan on committing this patch to negate this.
Yay!
>
> The use of an MFS /var should also be settable. Otherwise installing
> ports(packages) is just a total PITA.
>
>
> Index: rc.diskless2
> ===
> RCS file: /home/ncvs/src/etc/rc.diskless2,v
> retrieving revision 1.15
> diff -u -r1.15 rc.diskless2
> --- rc.diskless2 26 Dec 2001 17:18:39 - 1.15
> +++ rc.diskless2 22 Feb 2002 03:56:18 -
> @@ -56,7 +56,7 @@
> fi
>
> echo "+++ mount_md of /var"
> -mount_md ${varsize:=65536} /var 1
> +mount_md ${varsize:=32m} /var 1
One problem with making the mds so big is that it uses type malloc
which afaict uses malloc(9) to get the backing store. This was the
point of the M_SHORTWAIT patch posted a while ago, if you ask for too
much with M_WAITOK you might go to sleep and never be woken up. It
might be better to use type vnode with file or swap based backing
store. sparc64 machines tend to have more ram than older pcs that
this might also be used on :)
my $0.02.
Jake
>
> echo "+++ populate /var using /etc/mtree/BSD.var.dist"
> /usr/sbin/mtree -deU -f /etc/mtree/BSD.var.dist -p /var
> @@ -83,7 +83,7 @@
> # so if /var/tmp == /tmp, then you don't get a vi.recover.
> #
> if [ ! -h /tmp ]; then
> - mount_md ${tmpsize:=20480} /tmp 2
> + mount_md ${tmpsize:=64m} /tmp 2
> chmod 01777 /tmp
> fi
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Recent USB problems
Hello, with current of yesterday everything seems to be ok for me again. But I do not see any reason for this (code has not changed inbetween). Michael Alexander Kabaev wrote: >>Sorry, no hint by my side, but I can report exactly the same problem >>on an Athlon-C System equipped with a VIA-KT133A chipset. >>(actually it has the same USB controller, so it was expectable) >> >>Riggs >> > I am seeing the same symptoms while using Microsoft USB mouse with >KT133A-based computer. In my case, initial probe for ums, uhid and then >ugen fails. This is not consistent, though. Sometimes, probe will report >failing ums attach, sometimes it will not even detect device as mouse >and will start probing uhid or even ugen instead. Later in the boot >process, right after the "Waiting for SCSI messages to settle" message, >ums gets probed again and this time it attaches and works flawlessly >100% of the time. > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent USB problems
> > Sorry, no hint by my side, but I can report exactly the same problem > on an Athlon-C System equipped with a VIA-KT133A chipset. > (actually it has the same USB controller, so it was expectable) > > Riggs I am seeing the same symptoms while using Microsoft USB mouse with KT133A-based computer. In my case, initial probe for ums, uhid and then ugen fails. This is not consistent, though. Sometimes, probe will report failing ums attach, sometimes it will not even detect device as mouse and will start probing uhid or even ugen instead. Later in the boot process, right after the "Waiting for SCSI messages to settle" message, ums gets probed again and this time it attaches and works flawlessly 100% of the time. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: changes to rc.diskless*
On Fri, Feb 22, 2002 at 01:23:12PM -0500, Robert Watson wrote: > > One of the problems I have with a similar configuration is that the file > system checker never runs for local filesystems mounted on writable disks. > I tend to mount everything nfs and mfs, except for a scratch drive and > swap, which are from the local hard disk. Hmm, that's odd. They are definatly getting fsck'd on my test machine. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35074/pgp0.pgp Description: PGP signature
Re: changes to rc.diskless*
On Fri, 22 Feb 2002, Brooks Davis wrote: > On Thu, Feb 21, 2002 at 08:00:51PM -0800, David O'Brien wrote: > > The use of an MFS /var should also be settable. Otherwise installing > > ports(packages) is just a total PITA. > > I had issues with the MFS /var and /tmp[0] a couple days ago and changed > the code to move the "mount -a" up before /var and /tmp creation and > then actually test to be sure they are not writable before attempting to > create MFS versions. The logic was basicly: > > if touch /var/_writable_test; then > rm /var/_writable_test > else > #create MFS var > fi > > -- Brooks > > [0] I've got a slightly strange configuration with network booting > cluster nodes which have a disk for /tmp, /var, and swap. One of the problems I have with a similar configuration is that the file system checker never runs for local filesystems mounted on writable disks. I tend to mount everything nfs and mfs, except for a scratch drive and swap, which are from the local hard disk. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build Failure (libkvm)
> > > > >Date: Fri, 22 Feb 2002 08:09:28 -0900 > > > > > >Last night's build for -current failed with the following: > > > > I got -CURRENT built today without problem. Recent CVSup history: > > > (snip history) > > > > Might try updating again > > Already did that. The update was about 15 minutes prior to that last build > attempt. Interesting, the last change to that file was about 2 weeks ago and > I have done several builds since then. I'm clueless as to why it picked today > to fail rather than immediately following the commit. The type of p_runtime in sys/proc.h changed today, but ki_runtime in sys/user.h hasn't changed yet. Or maybe it shouldn't change and there should rather be a conversion? Who knows. :-) phk? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent USB problems
On Sun, 17. Feb 2002, at 9:53 +0100, Michael Class wrote according to [Recent USB problems]: > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > > The system is a dual PIII Gigabyte system with VIA-Chipset. > > Any hints? Sorry, no hint by my side, but I can report exactly the same problem on an Athlon-C System equipped with a VIA-KT133A chipset. (actually it has the same USB controller, so it was expectable) Riggs -- - "[...] I talked to the computer at great length and -- explained my view of the Universe to it" said Marvin. --- And what happened?" pressed Ford. "It committed suicide." said Marvin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: changes to rc.diskless*
On Thu, Feb 21, 2002 at 08:00:51PM -0800, David O'Brien wrote: > The use of an MFS /var should also be settable. Otherwise installing > ports(packages) is just a total PITA. I had issues with the MFS /var and /tmp[0] a couple days ago and changed the code to move the "mount -a" up before /var and /tmp creation and then actually test to be sure they are not writable before attempting to create MFS versions. The logic was basicly: if touch /var/_writable_test; then rm /var/_writable_test else #create MFS var fi -- Brooks [0] I've got a slightly strange configuration with network booting cluster nodes which have a disk for /tmp, /var, and swap. -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35070/pgp0.pgp Description: PGP signature
Re: Build Failure (libkvm)
On Friday 22 February 2002 08:14 am, David Wolfskill wrote: > From: Beech Rintoul <[EMAIL PROTECTED]> > > >Date: Fri, 22 Feb 2002 08:09:28 -0900 > > > >Last night's build for -current failed with the following: > > I got -CURRENT built today without problem. Recent CVSup history: > (snip history) > > Might try updating again Already did that. The update was about 15 minutes prior to that last build attempt. Interesting, the last change to that file was about 2 weeks ago and I have done several builds since then. I'm clueless as to why it picked today to fail rather than immediately following the commit. Beech -- --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build Failure (libkvm)
>From: Beech Rintoul <[EMAIL PROTECTED]> >Date: Fri, 22 Feb 2002 08:09:28 -0900 >Last night's build for -current failed with the following: I got -CURRENT built today without problem. Recent CVSup history: freebeast(5.0-C)[1] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Mon Feb 18 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Mon Feb 18 03:54:22 PST 2002 CVSup begin from cvsup14.freebsd.org at Tue Feb 19 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Tue Feb 19 03:53:36 PST 2002 CVSup begin from cvsup14.freebsd.org at Wed Feb 20 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Wed Feb 20 04:00:08 PST 2002 CVSup begin from cvsup14.freebsd.org at Thu Feb 21 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Thu Feb 21 03:53:29 PST 2002 CVSup begin from cvsup14.freebsd.org at Fri Feb 22 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Fri Feb 22 03:54:26 PST 2002 freebeast(5.0-C)[2] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #86: Fri Feb 22 07:07:23 PST 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast(5.0-C)[3] Might try updating again Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Build Failure (libkvm)
Last night's build for -current failed with the following: mkdep -f .depend -a-DLIBC_SCCS -I/usr/src/lib/libkvm /usr/src/lib/libkvm/kvm.c /usr/src/lib/libkvm/kvm_i386.c /usr/src/lib/libkvm/kvm_file.c /usr/src/lib/libkvm/kvm_getloadavg.c /usr/src/lib/libkvm/kvm_getswapinfo.c /usr/src/lib/libkvm/kvm_proc.c cd /usr/src/lib/libkvm; make _EXTRADEPEND cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm.c -o kvm.o cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_i386.c -o kvm_i386.o cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_file.c -o kvm_file.o cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_getloadavg.c -o kvm_getloadavg.o cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_getswapinfo.c -o kvm_getswapinfo.o cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /usr/src/lib/libkvm/kvm_proc.c:316: incompatible types in assignment *** Error code 1 Stop in /usr/src/lib/libkvm. *** Error code 1 Tried all the usual, rm -R /usr/obj, fresh cvsup etc Beech -- --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Install World fails in -Current
On 22-Feb-02 David Wolfskill wrote: >>Date: Fri, 22 Feb 2002 08:33:01 -0500 >>From: Glenn Gombert <[EMAIL PROTECTED]> > >>I have tried to re-cvsup and a clean rebuild the alst couple of days, and I >>keep getting this error when I try and do an 'installworld' ..after a clean >>build...does anyone know what might be causing this?? > >>... >> >>mtree -deU -f /usr/src/etc/mtree/BSD.var -p /var >>mtree: line 67: unknown user smmsp > > > Sounds like a botched (or not run) "mergemaster" execution: Sort of. The problem is we have added a new user that installworld depends on. Imagine a 4.x to 5.0 upgrade right now. 4.x doesn't have this user IIRC, and you are supposed to run installworld before mergemaster. Sounds like a nice catch 22 to me. :-/ -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ports problem: where to start
I just upgraded everything on my system and I'm still having trouble with vim, AbiWord, and open-motif-devel. The problem with vim is one I can fix by changing the install.sh script it comes with by forcing it to link against the X11 library. For some reason it does not pick up that it's required: $ gvim /usr/libexec/ld-elf.so.1: Shared object "libXThrStub.XmbResetIC" not found The other two are executing `mkdir /' at install time. This fails: ===> Installing for AbiWord-0.99.1_1 ===> AbiWord-0.99.1_1 depends on shared library: png.5 - found ===> AbiWord-0.99.1_1 depends on shared library: giconv.2 - found ===> AbiWord-0.99.1_1 depends on shared library: psiconv.7 - found ===> AbiWord-0.99.1_1 depends on shared library: X11.6 - found ===> AbiWord-0.99.1_1 depends on shared library: glib12.3 - found ===> AbiWord-0.99.1_1 depends on shared library: gtk12.2 - found Making install in src gmake[1]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src' Making install in tools gmake[2]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools' Making install in cdump gmake[3]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump' Making install in xp gmake[4]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump/xp' gmake[5]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump/xp' gmake[5]: Nothing to be done for `install-exec-am'. gmake[5]: Nothing to be done for `install-data-am'. gmake[5]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump/xp' gmake[4]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump/xp' gmake[4]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump' gmake[5]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump' gmake[5]: Nothing to be done for `install-exec-am'. gmake[5]: Nothing to be done for `install-data-am'. gmake[5]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump' gmake[4]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump' gmake[3]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/cdump' Making install in pfa2afm gmake[3]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm' Making install in unix gmake[4]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm/unix' gmake[5]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm/unix' gmake[5]: Nothing to be done for `install-exec-am'. gmake[5]: Nothing to be done for `install-data-am'. gmake[5]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm/unix' gmake[4]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm/unix' gmake[4]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm' gmake[5]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm' gmake[5]: Nothing to be done for `install-exec-am'. gmake[5]: Nothing to be done for `install-data-am'. gmake[5]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm' gmake[4]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm' gmake[3]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/pfa2afm' Making install in ttftool gmake[3]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/ttftool' Making install in unix gmake[4]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/ttftool/unix' gmake[5]: Entering directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/ttftool/unix' mkdir: /: Is a directory gmake[5]: *** [install-exec-local] Error 1 gmake[5]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/ttftool/unix' gmake[4]: *** [install-am] Error 2 gmake[4]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/ttftool/unix' gmake[3]: *** [install-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools/ttftool' gmake[2]: *** [install-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src/tools' gmake[1]: *** [install-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/editors/AbiWord/work/abiword/abi/src' gmake: *** [install-recursive] Error 1 *** Error code 2 Stop in /usr/ports/editors/AbiWord. *** Error code 1 Stop in /usr/ports/editors/AbiWord. *** Error code 1 Stop in /usr/ports/editors/AbiWord. *** Error code 1 Stop in /usr/ports/editors/AbiWord. ===> Installing for open-motif-devel-2.1.30 ===> open-motif-devel-2.1.30 depends on shared library: X11.6 - found mkdir: /: Is a directory *** Error code 1 Stop in /usr/ports/x11-toolkits/open-motif-devel. *** Error
Re: Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
Alfred Perlstein wrote: > * Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020221 16:19] wrote: > > Luigi Rizzo <[EMAIL PROTECTED]> writes: > > > i think Al's solution (make -V ... | xargs .. ) > > > wins both in terms of simplicity and efficiency > > > > Ah, of course! now why didn't I think of that? :) > > My first thought was: > "If make(1) doesn't have that functionality I will beat it into it >with a lead pipe..." > > Luckly I can across the option. :) Alfred, an hour later: "Wow, there's a lot of code in here that almost does exactly what I want!". 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[no subject]
>From [EMAIL PROTECTED] Fri Feb 22 15:33:26 2002 Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.2/8.12.2) with ESMTP id g1MEXQ0L002228 for <[EMAIL PROTECTED]>; Fri, 22 Feb 2002 15:33:26 +0100 (CET) (envelope-from [EMAIL PROTECTED]) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.12.2/8.12.2/Submit) id g1MEXQ2T002227 for [EMAIL PROTECTED]; Fri, 22 Feb 2002 15:33:26 +0100 (CET) (envelope-from mailnull) From: [EMAIL PROTECTED] (Christian Weisgerber) Subject: Re: HEADS UP: sendmail 8.12.2 imported Date: Fri, 22 Feb 2002 14:33:26 + (UTC) Message-ID: References: <[EMAIL PROTECTED]> Originator: [EMAIL PROTECTED] (Christian Weisgerber) To: [EMAIL PROTECTED] Gregory Neil Shapiro <[EMAIL PROTECTED]> wrote: > sendmail 8.12.2 has been imported into -CURRENT. Users of ports/mail/bsmtp beware, this breaks address rewriting in the bsmtp mailer, because it still references the rewriting rules by number. I'll update the port shortly. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Install World fails in -Current
>Date: Fri, 22 Feb 2002 08:33:01 -0500 >From: Glenn Gombert <[EMAIL PROTECTED]> >I have tried to re-cvsup and a clean rebuild the alst couple of days, and I >keep getting this error when I try and do an 'installworld' ..after a clean >build...does anyone know what might be causing this?? >... > >mtree -deU -f /usr/src/etc/mtree/BSD.var -p /var >mtree: line 67: unknown user smmsp Sounds like a botched (or not run) "mergemaster" execution: freebeast(5.0-C)[2] grep smmsp /usr/src/etc/master.passwd smmsp:*:25:25::0:0:Sendmail Submission User:/var/spool/clientmqueue:/sbin/nologin freebeast(5.0-C)[3] Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Install World fails in -Current
I have tried to re-cvsup and a clean rebuild the alst couple of days, and I keep getting this error when I try and do an 'installworld' ..after a clean build...does anyone know what might be causing this?? ... mtree -deU -f /usr/src/etc/mtree/BSD.var -p /var mtree: line 67: unknown user smmsp Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
On Thu, Feb 21, 2002 at 10:00:29PM -0700, M. Warner Losh wrote:
> I'd love to see subversion beefed up. It looks like the most
> promising of the replacements for cvs on the horizon.
>
> One thing that it doesn't appear to have, that would be useful to the
> BSD community, is the ability to cons up a tree from multiple repos
> easily. If we had that, then we wouldn't need 5 different versions of
> cat for {Free,Net,Open}BSD, Darwin and BSD/os. :-)
This is one of the features that has been requested several times, and
is on the agenda for after we hit 1.0. Subversion is trying to limit
it's first round of functionality to 'What CVS does, minus the worst
problems'. After that, we'll get to work on the other cool features
;-)
> That reminds me, I gotta go fix FreeBSD's patch to grok patches
> properly ...
Thank You!!! It is so annoying having to install the port of
gpatch... If you could also remove the FreeBSD specific hacks to
diff, it would be quite appreciated (see
http://svn.collab.net/repos/svn/trunk/ac-helpers/gnu-diff.sh for the
script we use to ensure we have a working version of diff).
-garrett
--
garrett rooney Unix was not designed to stop you from
[EMAIL PROTECTED] doing stupid things, because that would
http://electricjellyfish.net/ stop you from doing clever things.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Is any patch to situation with bad linking library on -CURRENT?
> > I'm sorry for possible beginning of flame, but is there exist real > solution for bad linking library problem on -CURRENT? I was noticed > about this problem about two or three weeks ago, and don't see nothing > except discussions about new binutils. It looks like the import for binutils today fixed it. At least my test case of libpng does not coredump anymore. I'll see how far a release gets. It will probably not finish because I think the dhcp stuff in the crunch files are still broken. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: device figlet for the kernel
On Fri Feb 22, 2002 at 05:17:05AM -0500, John Baldwin wrote: > So who's going to do subr_jive.c next? :) subr_cowsay.c first :) -- Jonathan Perkin - BBC Internet Services - <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: device figlet for the kernel
+---[ John Baldwin ]-- | Those of you who waste large amounts of time on IRC, esp. on The Channel Which | Shall Rename Nameless will appreciate this: [snip] So the truth finally comes out. Now we discover the real reason -current was delayed for 12 months d8) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Is any patch to situation with bad linking library on -CURRENT?
Have a nice day! I'm sorry for possible beginning of flame, but is there exist real solution for bad linking library problem on -CURRENT? I was noticed about this problem about two or three weeks ago, and don't see nothing except discussions about new binutils. May be I was inattentive but can anybody tell me (may be, for us?) how to fix that problem? I haven't enough knowledge to solve this by my hand for my sorry and need assistance. I have AMD Duron, MB Epox 8KTA3+, IBM 60 Gb, Radeon 8500, and 5.0-CURRENT installed on that. The first problem was occured is coredumps any program compiled with imlib. It was come to light on gnomelibs building - on configure stage conftest program was exit with bus error message and coredumps. The second problem is mplayer exits with the same message (bus error) right after launch. Once again excuse me for anxiety and possible impoliteness. Sincerelly yours, Vladimir G. Drobyshevsky To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
device figlet for the kernel
Those of you who waste large amounts of time on IRC, esp. on The Channel Which Shall Rename Nameless will appreciate this: figlet is this nifty little ASCII art tool that Alfred likes to use a lot. He has since gotten several other people hooked on using it, and a sort of running joke has been to get figlet into the kernel. (Imagine ASCII part panic messages for example.) Mike Smith ported the figlet program as a filter on the low-level console output by taking over v_putc a while ago but it had an annoying bug where it only printed one char out at a time. During some down time tonight during which my brain was vegging, I picked up the code, tracked down the bug and added some features: - Originally, once figlet was initialized, it was turned on until you rebooted. Now it defaults to being off, but you can change that via a loader tunable (kern.figlet_enable). Also, there is an escape character that you can use to send commands to the figlet filter. Right now the only commands are to turn on figlet output; adjust the justification of the outputted text as either left, center, or right aligned; or turn off figlet output and revert to normal output. When figlet is turned off, the justification is reset to the default of left. - figlet is not a psuedo device that can be conditionally compiled into the kernel by putting 'device figlet' in your kernel config file - a spin lock has been added to protect the state machine variables so that it is SMPng safe. - a new console API function cnsetputc() has been added so that v_putc can be changed at runtime. This isn't quite right as v_putc really needs a lock now. Currently figlet isn't a kernel module, but one could make it so without too much additional work. To play with this, first download and apply the patch at http://www.FreeBSD.org/~jhb/patches/figlet.patch Then compile a kernel with 'device figlet'. You will need to load a figlet font file in the loader when you boot. You can get font files from either the figlet or figlet-fonts ports. For example, if you copy /usr/local/share/figlet/standard.flf (the default font) to /boot, then you would need to either use 'load -t figlet_font /boot/standard.flf' prior to booting the kernel or add the following to /boot/loader.conf: font_load="YES" font_name="/boot/standard.flf" font_type="figlet_font" The patch includes a sample SYSINIT at the bottom of subr_figlet.c that demonstrates sending commands to the filter. So who's going to do subr_jive.c next? :) -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
