Re: FreeBSD Status Report for Oct-Dec 2003
very nice, but what is Perforce? danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Status Report for Oct-Dec 2003
Danny Braniss wrote: very nice, but what is Perforce? danny www.perforce.com Simply put, Perforce is a source control management tool that makes that is very oriented towards easily managing multiple development streams and easily integrating changes between them. Whereas branching in CVS is expensive and hard to manage, Perforce makes it very, very easy. So it's an ideal tool for managing lots of parallel projects that may or may not be related. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Status Report for Oct-Dec 2003
thanks! with so much garbage/software/noise around it's difficult to see the gems. and hearing from first hand is very important. true also that google hit it first, but you provided the missing link. danny www.perforce.com Simply put, Perforce is a source control management tool that makes that is very oriented towards easily managing multiple development streams and easily integrating changes between them. Whereas branching in CVS is expensive and hard to manage, Perforce makes it very, very easy. So it's an ideal tool for managing lots of parallel projects that may or may not be related. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
experience with 4way smp
hi all, im trying to gather info on 4way smp systems running FreeBSD, the bigger the better. thanks, danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2 Panic, first shot at backtrace and info, next step?
I am interested in using FreeBSD 5.2 on an Ultra 60 with a PCI qfe card. I
want to use the bridging and dummynet functionality.
I installed FreeBSD 5.2 with not problems. I added options BRIDGE to a
custom kernel conf file and rebuilt/installed the kernel according to
procedure 1 at:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-build
ing.html
I then reboot and do the following:
test60# sysctl -w net.link.ether.bridge.enable=1
net.link.ether.bridge.enable: 0 - 1
test60# ifconfig hme1 up
test60# ifconfig -a
hme0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 192.168.234.208 netmask 0xff00 broadcast 192.168.234.255
inet6 fe80::a00:20ff:fe9a:e692%hme0 prefixlen 64 scopeid 0x1
ether 08:00:20:9a:e6:92
media: Ethernet autoselect (100baseTX)
status: active
hme1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet6 fe80::a00:20ff:fe9a:e692%hme1 prefixlen 64 scopeid 0x2
ether 08:00:20:9a:e6:92
media: Ethernet autoselect (100baseTX full-duplex)
status: active
(rest cut...)
test60# sysctl -w net.link.ether.bridge.config=hme0,hme1
net.link.ether.bridge.config: - hme0,hme1
Consistently within a few seconds I see the following while watching on
Serial Port A:
FreeBSD/sparc64 (test60) (ttya)
login: Jan 28 15:28:58 test60 kernel: hme0: promiscuous mode enabled
Jan 28 15:28:58 test60 kernel: hme1: promiscuous mode enabled
panic: trap: memory address not aligned
cpuid = 0;
syncing disks, buffers remaining... 563 563 563 563 563 563 563 563 563 563
563 563 563 563 563 563 563 563 563 563
giving up on 455 buffers
So I thought instead of blindly asking for help I'd try to provide more
useful information. I read the following articles on kernel debugging:
http://www.onlamp.com/pub/a/bsd/2002/03/21/Big_Scary_Daemons.html
http://www.onlamp.com/pub/a/bsd/2002/04/04/Big_Scary_Daemons.html
So:
test60# ./gdb53 -k kernel.debug vmcore.0
GNU gdb 5.3 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as sparc64-portbld-freebsd5.2...
panic: trap: memory address not aligned
panic messages:
---
panic: trap: memory address not aligned
cpuid = 0;
syncing disks, buffers remaining... 4103 4103 4096 4096 4091 4090 4090 4090
4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090
4090 4090
giving up on 3987 buffers
Uptime: 2m23s
Dumping 2048 MB (4 chunks)
chunk at 0: 536870912 bytes |\^H/\^H
---
#0 0xc0139b08 in doadump () at ../../../kern/kern_shutdown.c:239
239 savectx(dumppcb);
(kgdb) where
#0 0xc0139b08 in doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc013a124 in boot (howto=256) at
../../../kern/kern_shutdown.c:370
#2 0xc013a54c in panic (fmt=0xc0341790 trap: %s) at
../../../kern/kern_shutdown.c:548
#3 0xc02939e0 in trap (tf=0xeeb891a0) at
../../../sparc64/sparc64/trap.c:364
#4 0xc01b8c34 in igmp_input (m=0xf8c19bc0, off=0) at
../../../netinet/igmp.c:224
#5 0xc01b8bbc in igmp_input (m=0xc081c500, off=20) at
../../../netinet/igmp.c:202
#6 0xc01c17c0 in ip_input (m=0xc081c500) at
../../../netinet/ip_input.c:983
#7 0xc01aefbc in netisr_processqueue (ni=0xc039b7b0) at
../../../net/netisr.c:152
#8 0xc01af4a0 in swi_net (dummy=0x0) at ../../../net/netisr.c:255
#9 0xc0128a7c in ithread_loop (arg=0xf882b200) at
../../../kern/kern_intr.c:544
#10 0xc0127a7c in fork_exit (callout=0xc0128900 ithread_loop,
arg=0xf882b200, frame=0xeeb89880)
at ../../../kern/kern_fork.c:793
(kgdb) up 4
#4 0xc01b8c34 in igmp_input (m=0xf8c19bc0, off=0) at
../../../netinet/igmp.c:224
224 if (igmp-igmp_code == 0) {
(kgdb) p igmp
$1 = (struct igmp *) 0xc01b8c8c
(kgdb) p *igmp
$2 = {igmp_type = 128 '\200', igmp_code = 160 ' ', igmp_cksum = 40960,
igmp_group = {s_addr = 38273038}}
(kgdb) p igmp-igmp_code
$3 = 160 ' '
(kgdb)
So I'm hoping this helps. What is the next step? Can I provide more
information? I would be happy to try fixes.
I would appreciate any help someone could offer.
Thanks,
Jim
I am also providing the following in case it's helpful:
uname -a output:
test60# uname -a
FreeBSD test60 5.2-RELEASE FreeBSD 5.2-RELEASE #0: Wed Jan 28 14:59:57 EST
2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERN sparc64
dmesg:
Copyright (c) 1992-2004 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.2-RELEASE #0: Wed Jan 28 14:59:57 EST 2004
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERN
Call for testers: New PID allocator patch for -CURRENT
Greetings, everyone A friend of mine has ported NetBSD's new PID allocation[1] code to FreeBSD, you can obtain the patch here: http://www.arbornet.org/~junsu/pid.diff Some of you may be already aware of this for he has posted[2] this to both current@ and hackers@ last September. Currently the patchset has been updated to make it applicable to -HEAD. A number of problems were found and fixed after the first post with many from the FreeBSD community, and we think it's time to post it again and, if you are interested, please give it a chance to run on your own (test) box. Feedbacks and comments are welcome. Thanks in advance! [1] http://mail-index.netbsd.org/tech-kern/2003/03/11/0005.html [2] http://lists.freebsd.org/pipermail/freebsd-current/2003-October/011508.html Cheers, -- Xin LI delphij frontfree net http://www.delphij.net/ See complete headers for GPG key and other information. pgp0.pgp Description: PGP signature Scanned by evaluation version of Dr.Web antivirus Daemon http://drweb.ru/unix/
Re: kernel threads
On Wed, 28 Jan 2004, Julian Elischer wrote: the KSE stuff requires too much assistance from teh Userland Thread scheduler. HOWEVER it is possible that kthreads may one day be implemented as multiple threads of a single kernel process.. (but not yet) John has been talking about doing this for a while -- clustering the kernel threads into a smaller number of kernel processes or a single kernel process. This is the approach Darwin takes as well, FWIW -- they have a kernel_task in which all the various kernel threads hang out, which avoids the overhead of full processes, as well as the emotional baggage. I think I saw John put it on his TODO list in Perforce, so maybe it's coming soon :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Status Report for Oct-Dec 2003
On Thu, 29 Jan 2004, Danny Braniss wrote: thanks! with so much garbage/software/noise around it's difficult to see the gems. and hearing from first hand is very important. true also that google hit it first, but you provided the missing link. If you want to peruse the FreeBSD perforce server, you can visit: http://perforce.freebsd.org/ Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research danny www.perforce.com Simply put, Perforce is a source control management tool that makes that is very oriented towards easily managing multiple development streams and easily integrating changes between them. Whereas branching in CVS is expensive and hard to manage, Perforce makes it very, very easy. So it's an ideal tool for managing lots of parallel projects that may or may not be related. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Realtime signal
FreeBSD 5.1 have a realtime signal support (signal queue)? Regards, Aliaxandr. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freeBSD bootup sequence.
On Wed, Jan 28, 2004 at 10:28:35AM -0500, Sridhar Chellappa wrote: # Hi, # # Iam a kernel hacker trying to venture into the freeBSD world for the # first time. I would like to know if there is some doc which describes # the FreeBSD bootup sequence Try the archictecture handbook, http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/index.html Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testers: New PID allocator patch for -CURRENT
On Thu, Jan 29, 2004, Xin LI wrote: Greetings, everyone A friend of mine has ported NetBSD's new PID allocation[1] code to FreeBSD, you can obtain the patch here: http://www.arbornet.org/~junsu/pid.diff Some of you may be already aware of this for he has posted[2] this to both current@ and hackers@ last September. Currently the patchset has been updated to make it applicable to -HEAD. A number of problems were found and fixed after the first post with many from the FreeBSD community, and we think it's time to post it again and, if you are interested, please give it a chance to run on your own (test) box. Thanks for the reminder. Your patch uses a very clever idea. I messed around with the original patch in your PR a few months ago. It would take more work to prove that your proposed patch improves performance[1] and is a good approach, and to review and clean up the implementation. For instance, it isn't immediately obvious that the accelerated pid reuse is acceptable, so that needs to be looked into further[2]. I don't have the time at the moment to go over the patch with a fine-toothed comb, and jhb@ could do a better job than me anyway if he has time, but I wanted to let you know that it's floating around on at least one person's TODO list. Some low-hanging fruit: The patch needs to be cleaned up to conform to style(9). It also changes the meaning of PID_MAX and fails to enforce a 5-digit limit on pids. [1] That shouldn't be hard, given that the present algorithm takes O(N) amortized time in the worst case, and can examine as many as PID_MAX^2 pids if the number of processes in the system is close to PID_MAX. [2] Many systems have a high enough fork rate that pids recycle every few minutes or hours with the present algorithm. These systems don't necessarily have lots of processes running at any given time, so the table (and thus the cycle length) in your patch could remain relatively small if I'm interpreting the code correctly. I think the code would have to be changed to prevent reuse from happening too quickly in wall time. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel Virtual Address Space
As part of the Bootup sequence, I see create_pagetables allocate only 30 Pages for Page Table entries in non-PAE mode and 120 pages in PAE mode. Does this mean that all the kernel mode entities get only 4 * 30 * 1024 * 1024 = 120 MB worth of Address Space ? Can I tune the kernel virtual address space by just changing the NKPT define in pmap.h ? Also, I heard that the BSD kernel(atleast from 5.1 onward) itself is pre-emptible and none of the kernel threads have a cpu affinity. How do I change the behaviour to make the kernel non-preemptible and tie kernel-threads to a particular CPU ? Sridhar. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
SCM - local tree ?
Hi, how do you all sync your local tree with HEAD ? How do you store your changes locally ? cvs ? directory of patches ? Up to now I have copied a clean src and applied my patchset. This way I always have a clean src and a working copy here. But apart from the IO when copying I do not feel too lucky with this solution. Some best practice examples - or did I miss an article ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Build System Doc
hi, is there any doc available describing how the fbsd build process / system for /usr/src and /usr/src/sys works ? i googled a bit but have not found any useful doc. i had a short look to /usr/share/mk but i guess reading makefiles could be a bit difficult to get the big picture. regards, seb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testers: New PID allocator patch for -CURRENT
On Thu, 29 Jan 2004, David Schultz wrote: On Thu, Jan 29, 2004, Xin LI wrote: Greetings, everyone A friend of mine has ported NetBSD's new PID allocation[1] code to FreeBSD, you can obtain the patch here: http://www.arbornet.org/~junsu/pid.diff Some of you may be already aware of this for he has posted[2] this to both current@ and hackers@ last September. Currently the patchset has been updated to make it applicable to -HEAD. A number of problems were found and fixed after the first post with many from the FreeBSD community, and we think it's time to post it again and, if you are interested, please give it a chance to run on your own (test) box. Thanks for the reminder. Your patch uses a very clever idea. I messed around with the original patch in your PR a few months ago. It would take more work to prove that your proposed patch improves performance[1] and is a good approach, and to review and clean up the implementation. For instance, it isn't immediately obvious that the accelerated pid reuse is acceptable, so that needs to be looked into further[2]. I don't have the time at the moment to go over the patch with a fine-toothed comb, and jhb@ could do a better job than me anyway if he has time, but I wanted to let you know that it's floating around on at least one person's TODO list. Some low-hanging fruit: The patch needs to be cleaned up to conform to style(9). It also changes the meaning of PID_MAX and fails to enforce a 5-digit limit on pids. I don't know if it is in the patch but we need a sysctl for pid_max because it needs to be set back to 6 if yuo want to run a FreeBSD 1.x environment.. (you should see a make world fly on a 3GHz machine in a FreeBSD 1.1 chroot) [1] That shouldn't be hard, given that the present algorithm takes O(N) amortized time in the worst case, and can examine as many as PID_MAX^2 pids if the number of processes in the system is close to PID_MAX. [2] Many systems have a high enough fork rate that pids recycle every few minutes or hours with the present algorithm. These systems don't necessarily have lots of processes running at any given time, so the table (and thus the cycle length) in your patch could remain relatively small if I'm interpreting the code correctly. I think the code would have to be changed to prevent reuse from happening too quickly in wall time. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel Virtual Address Space
On Thu, 29 Jan 2004, Sridhar Chellappa wrote: As part of the Bootup sequence, I see create_pagetables allocate only 30 Pages for Page Table entries in non-PAE mode and 120 pages in PAE mode. Does this mean that all the kernel mode entities get only 4 * 30 * 1024 * 1024 = 120 MB worth of Address Space ? Can I tune the kernel virtual address space by just changing the NKPT define in pmap.h ? I don't believe so ... on our servers, we set the KVA_PAGES value: jupiter# grep KVA /etc/make.conf CFLAGS= -O -mpentium -pipe -g -DKVA_PAGES=512 COPTFLAGS= -O -mpentium -pipe -DKVA_PAGES=512 we do it in make.conf, since doing it into the kernel config itself doesn't propogate to various userland binaries that also need to know of the change ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM - local tree ?
On Thursday 29 January 2004 03:49 pm, Bjoern A. Zeeb wrote: Hi, how do you all sync your local tree with HEAD ? How do you store your changes locally ? cvs ? directory of patches ? Up to now I have copied a clean src and applied my patchset. This way I always have a clean src and a working copy here. But apart from the IO when copying I do not feel too lucky with this solution. Some best practice examples - or did I miss an article ? I always cvsup the entire repo rather than just a checkout of src and then use cvs to checkout /usr/src from my repo on all my boxes. As long as the changes are simple, cvs will merge changes in w/o any major problems. For bigger projects I have been using branches in the FreeBSD p4 depot to maintain changes for the past few years. p4 does a much better job than CVS of mergning in changes from HEAD into my work branches as well as letting me merge things between work branches. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
cons25 and xterm
Hello, when I ssh to my school Unix account (unfortunately solaris) from my local host's command line and when I attempt to clear the screen, I get an error message from the remote host: `cons25`: unknown terminal type. The remote host is $TERM=xterm. My local machine is FreeBSD's default $TERM=cons25. My question is: how can I switch my local terminal type so that it works correctly with the remote machine? I don't want to install X, but if that is the only option then I'll reconsider. Thank you, -zh __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cons25 and xterm
On Thu, Jan 29, 2004 at 03:16:37PM -0800, zera holladay wrote: Hello, when I ssh to my school Unix account (unfortunately solaris) from my local host's command line and when I attempt to clear the screen, I get an error message from the remote host: `cons25`: unknown terminal type. The remote host is $TERM=xterm. My local machine is FreeBSD's default $TERM=cons25. My question is: how can I switch my local terminal type so that it works correctly with the remote machine? I don't want to install X, but if that is the only option then I'll reconsider. The way I handle that problem is to run screen(1) (from the sysutils/screen port) locally, and set TERM=vt102 on the remote machine. Works perfectly. The correct solution is of course to upgrade the terminal descriptions on the remote machine to include 'cons25', but that might not be practical in this case. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Build System Doc
On Thu, Jan 29, 2004 at 11:02:19PM +0100, sebastian ssmoller wrote: hi, is there any doc available describing how the fbsd build process / system for /usr/src and /usr/src/sys works ? i googled a bit but have not found any useful doc. i had a short look to /usr/share/mk but i guess reading makefiles could be a bit difficult to get the big picture. man 7 build Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Call for testers: New PID allocator patch for -CURRENT
On Thu, Jan 29, 2004 at 12:04:42PM -0800, David Schultz wrote: On Thu, Jan 29, 2004, Xin LI wrote: Greetings, everyone A friend of mine has ported NetBSD's new PID allocation[1] code to FreeBSD, you can obtain the patch here: http://www.arbornet.org/~junsu/pid.diff Some of you may be already aware of this for he has posted[2] this to both current@ and hackers@ last September. Currently the patchset has been updated to make it applicable to -HEAD. A number of problems were found and fixed after the first post with many from the FreeBSD community, and we think it's time to post it again and, if you are interested, please give it a chance to run on your own (test) box. Thanks for the reminder. Your patch uses a very clever idea. I messed around with the original patch in your PR a few months ago. It would take more work to prove that your proposed patch improves performance[1] and is a good approach, and to review and clean up the implementation. [...] [1] That shouldn't be hard, given that the present algorithm takes O(N) amortized time in the worst case, and can examine as many as PID_MAX^2 pids if the number of processes in the system is close to PID_MAX. [...] In my testing, the current pid allocator turned out to be more efficient than I had expected. Even after reducing PID_MAX to 10,000 and fragmenting the pid-space by having sleeping processes at every N'th pid, it didn't run much slower than the hash-based alternative I was testing it against. This is the hash-based pid allocator, if anyone's interested: Change 43361 by [EMAIL PROTECTED] on 2003/12/03 01:30:24 Improve scalability of process ID allocation: - Use hashtables to check whether a pid is in used to avoid traversing the entire allproc and zombproc lists and acquiring each item's proc lock in fork1(). - Add a hashtable for session IDs, sesshashtbl, similar to pidhashtbl and pgrphashtbl. - Keep zombies on pidhash chains. Weed them out in pfind(). Rewrite zpfind() to use pidhash. PID allocation now scales as a function of the number of used pids between lastpid+1 and the first free one, instead of the number of processes in the system. This new allocator is expected to be slightly slower than the existing one's best-case performance, but should easily outperform it when the PID space becomes fragmented. Affected files ... ... //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_exit.c#11 edit ... //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_fork.c#14 edit ... //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_proc.c#21 edit ... //depot/user/tjr/freebsd-tjr/src/sys/sys/proc.h#27 edit Differences ... //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_exit.c#11 (text+ko) @@ -391,13 +391,12 @@ crfree(td-td_ucred); /* -* Remove proc from allproc queue and pidhash chain. +* Remove proc from allproc queue. * Place onto zombproc. Unlink from parent's child list. */ sx_xlock(allproc_lock); LIST_REMOVE(p, p_list); LIST_INSERT_HEAD(zombproc, p, p_list); - LIST_REMOVE(p, p_hash); sx_xunlock(allproc_lock); sx_xlock(proctree_lock); @@ -653,6 +652,7 @@ */ sx_xlock(allproc_lock); LIST_REMOVE(p, p_list); /* off zombproc */ + LIST_REMOVE(p, p_hash); /* off pidhash chain */ sx_xunlock(allproc_lock); LIST_REMOVE(p, p_sibling); leavepgrp(p); //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_fork.c#14 (text+ko) @@ -158,9 +158,7 @@ * Random component to lastpid generation. We mix in a random factor to make * it a little harder to predict. We sanity check the modulus value to avoid * doing it in critical paths. Don't let it be too small or we pointlessly - * waste randomness entropy, and don't let it be impossibly large. Using a - * modulus that is too big causes a LOT more process table scans and slows - * down fork processing as the pidchecked caching is defeated. + * waste randomness entropy, and don't let it be impossibly large. */ static int randompid = 0; @@ -199,8 +197,8 @@ struct proc *p1, *p2, *pptr; uid_t uid; struct proc *newproc; - int ok, trypid; - static int curfail, pidchecked = 0; + int ok, trypid, wrapped; + static int curfail; static struct timeval lastfail; struct filedesc *fd; struct filedesc_to_leader *fdtol; @@ -208,6 +206,9 @@ struct kse *ke2; struct ksegrp *kg2; struct sigacts *newsigacts; + struct proc *pi; + struct pgrp *pgi; + struct session *si; int error; /* Can't copy and clear. */ @@ -323,8 +324,7 @@ nprocs++;
Re: cons25 and xterm
Erik Trulsson wrote: On Thu, Jan 29, 2004 at 03:16:37PM -0800, zera holladay wrote: Hello, when I ssh to my school Unix account (unfortunately solaris) from my local host's command line and when I attempt to clear the screen, I get an error message from the remote host: `cons25`: unknown terminal type. The remote host is $TERM=xterm. My local machine is FreeBSD's default $TERM=cons25. My question is: how can I switch my local terminal type so that it works correctly with the remote machine? I don't want to install X, but if that is the only option then I'll reconsider. The way I handle that problem is to run screen(1) (from the sysutils/screen port) locally, and set TERM=vt102 on the remote machine. Works perfectly. The correct solution is of course to upgrade the terminal descriptions on the remote machine to include 'cons25', but that might not be practical in this case. In your .profile (or equivalent file) on the remote system, set TERM=ansi. ansi terminals on Sun have full colors support, etc. -- William Michael Grim Student, Southern Illinois University at Edwardsville Unix Network Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
