Date: Tue, 11 Aug 98 13:21:15 GMT From: Mark Chapman <[name]@pcp.clara.net> To: hackers@FreeBSD.ORG Subject: Re: freebsd-hackers-digest V4 #215 Message-ID: <980811132115.n0002911.pcp@mail.clara.net> References: <199808102147.OAA05756@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Please please stop sending me these I don't want them any more!!!. > >freebsd-hackers-digest Monday, August 10 1998 Volume 04 : Number 215 > > > >In this issue: >Re: EXA 8200 tape drive on FreeBSD? >NPX configuration after exec() >Re: C and static initialization with unions >Yet another XL driver update >Boot code >RE: AMD-specific kernel code (was: How long a wait?) >Re: AMD-specific kernel code (was: How long a wait?) >Re: EXA 8200 tape drive on FreeBSD? >Re: Does this mean we have another breakin? >Re: cvsup.freebsd.org down for a few >can not fork... >Re: EXA 8200 tape drive on FreeBSD? >Re: can not fork... >Re: can not fork... >Re: can not fork... >Re: can not fork... >Re: can not fork... >Re: CAP vs netatalk for Appletalk/printing support >Question about routine getblk() >Re: Question about routine getblk() > >---------------------------------------------------------------------- > >Date: Sun, 9 Aug 1998 20:17:46 +0200 (CEST) >From: Wilko Bulte <wilko@yedi.iaf.nl> >Subject: Re: EXA 8200 tape drive on FreeBSD? > >As Peter van Heusden wrote... > >> I'm trying to get a EXA 8200 tape drive working on FreeBSD. It is detected >> fine by the kernel during startup, and I can do a 'mt status' on it, with >> the following results: >> >> Present Mode: Density = 0x00 Blocksize variable >> ---------available modes--------- >> Mode 0: Density = 0x00 Blocksize variable >> Mode 1: Density = X3.136-1986 Blocksize = 512 bytes >> Mode 2: Density = X3.39-1986 Blocksize variable >> Mode 3: Density = X3.54-1986 Blocksize variable >> >> However, I cannot write to it at all - even after a 'mt erase', I get the >> following: >> > >[del] > >> My system details are as follows: >> >> OS: FreeBSD 2.2.6 >> System: 486 DX 4 120, NCR 53c810 SCSI controller (with 3 disk drives - >> Conner CFP1080S, Seagate ST12400N and ST32155N as well as the tape drive >> - disks are on ids 0, 1, 4, tape is on 6), >> 24 mb RAM. > >> Is there anything else I can try to get this thing working, or should I >> just give up on it? > >Well, not that it solves your problem, but I also have a 8200 on a ncr810 >and that one works. Has done so for years. > >More specific it has firmware: > >Aug 7 22:17:20 yedi /kernel: (ncr1:3:0): "EXABYTE EXB-8200 2687" type 1 >removable SCSI 1 > >Wilko >_ ______________________________________________________________________ > | / o / / _ Bulte email: wilko @ yedi.iaf.nl > |/|/ / / /( (_) Arnhem, The Netherlands WWW: http://www.tcja.nl >______________________________________________ Powered by FreeBSD __________ > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 07:00:37 +1000 >From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> >Subject: NPX configuration after exec() > >The NPX (x87) is initialised with a configuration word of 0x1272 >(sys/i386/include/npx.h __BDE_NPXCW__). The comment associated with >this states: > * Later I will want the IEEE default of all exceptions masked. See the > * 0.0 math manpage for why this is better. The 0.1 math manpage is empty. > >Whilst I'm uncertain of the references to 0.0 and 0.1, math(3M) does >include some comments which imply that libm is designed to function >correctly with all exceptions masked. > >Are there any plans to change the configuration word to 0x127f as implied >in this comment? > >Peter >- -- >Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au >Alcatel Australia Limited >41 Mandible St Phone: +61 2 9690 5019 >ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Sun, 9 Aug 1998 22:00:22 +0000 (GMT) >From: Terry Lambert <tlambert@primenet.com> >Subject: Re: C and static initialization with unions > >> I've had (several) run-ins with const poisoning trying to port a large >> third-party codebase. It's sufficiently bogus to require -traditional >> to build, and I expect not too novel in that regard. > >I have a number of programs which I like to use, but which I do not >want to become the maintainer of (for one thing, I don't have a >huge FTP server and can't offer cvsup, etc.). > >These programs do things like modify declared strings (on the assumption >that they will be stored in data section, not code section, what with >them being data, and all...). > >They also do things like modify variables in signal handlers and in >subfunctions of functions that also use the variable. Without the >- -traditional flag, this would require the use of the "volatile" >keyword. > >Other examples exist, including the use of int arguments to >implement varaddic functions, and casting to char * instead >of void * for opaque conversion. > >Sure, it's be nice if there were three of me (;-)) and I could >do all this and the stuff that I want to do as well, but there >aren't, and I can't. > > >> If we support compilation of K&R application code, we should attempt to >> make sure that system headers function correctly in that regard. > >Yes, please. > > > Terry Lambert > terry@lambert.org >- --- >Any opinions in this posting are my own and not those of my present >or previous employers. > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Sun, 9 Aug 1998 18:05:12 -0400 (EDT) >From: Bill Paul <wpaul@skynet.ctr.columbia.edu> >Subject: Yet another XL driver update > >Today I put yet another update of the 3Com Etherlink XL driver at >www.freebsd.org/~wpaul/3Com. This version has changes to fix support >for 100baseT4 cards and fixes a small bug in the TX error recovery. > >I'm hoping to commit the 3.0 driver to -current by the end of next >week, but I'm still concerned that there may be problems in some >configurations. I've have a couple people report problems with >performance but lack of followups has made it hard to me to know >if these problems are still present. I'm interested mainly in the >following: > >- - I have received some reports of spotty transmission performance > or 'transmission error' messages. I made a mistake in the code > that tries to recover from some of these errors (I wasn't resetting > the upload list pointer correctly) which should be fixed now. > I'm interested to know if transmission problems persist, > particularly with 10Mbps links on slow machines. This applies > to all supported cards (3c900, 905 and 905B). > >- - I haven't yet been able to fix the problem with one particular > 3c900 COMBO card. This card appears to initialize correctly > but refuses to do DMA. The 3c900 card that I have works properly > and I haven't been able to remotely debug the problem. If you > have a 3c900 card that probes correctly but doesn't appear to > transmit and receive, and which does work corretly with the > vx driver (which doesn't use DMA), then I'd like to know. > Without any other evidence, I'm nearly convinced that this is > a hardware problem with this one card. > >If you have a problem, please let me know. Tell me the type of >system you're using, the type of card you have, the version of FreeBSD, >and a _DETAILED_ description of the problem, along with a way to >reproduce the failure, if at all possible. > >- -Bill > >- -- >============================================================================= >- -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu >Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research >Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City >============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" >============================================================================= > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Sun, 9 Aug 1998 18:36:54 -0500 (CDT) >From: Joel Ray Holveck <joelh@gnu.org> >Subject: Boot code > >From /sys/i386/boot/biosboot/boot.c: > > /* > * Be paranoid and make doubly sure that the input buffer is empty. > */ > if (loadflags & (RB_DUAL | RB_SERIAL)) > init_serial(); > >Is this worth the bytes? (The only thing that would have frobbed >loadflags at this point is getbootdev, and it calls init_serial() if >it sets either flag. This is what I see, but more eyes checking me >would be welcome.) > >Are we even concerned about saving bytes in boot2, or is that no >longer a concern? While I'm at it, the stack is reset when the kernel >is loaded, so I don't need to worry about adding variables to boot(), >do I? > >While I'm at it, I'm adding code to allow all flags to be specified in >boot.config. The idea is that if flags are specified from the >keyboard, they override everything (except RB_SERIAL, RB_DUAL, and >RB_PROBEKBD) from boot.config. Anybody have a problem with this? > >Happy hacking, >joelh > >- -- >Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan > Fourth law of programming: > Anything that can go wrong wi >sendmail: segmentation violation - core dumped > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Sun, 09 Aug 1998 23:00:24 -0400 (EDT) >From: John Baldwin <jobaldwi@vt.edu> >Subject: RE: AMD-specific kernel code (was: How long a wait?) > >On 08-Aug-98 Greg Lehey wrote: >> (following up to -hackers) >> >> On Thursday, 6 August 1998 at 23:44:39 -0700, David Greenman wrote: >>> >>> I just looked at the patch. Other than some KNF style bugs, it seems >>> okay. >>> I don't have any AMD K5/K6 machines, however, so I can't test it and won't >>> be committing it. >>> If it could get wider circulation - perhaps by posting a note to hackers >>> asking for testers, then I think there would be less hesitation in getting >>> it committed. >> >> I've grabbed the code and will try it out and report. >> >> Greg > >One note, I just found out that this will only work on on certain chipsets (I >think Intel Triton TX, but I could be wrong, so don't quote me on that.) > >John Baldwin >- -- jobaldwi@vt.edu -- jbaldwin@freedomnet.com -- > ---- http://www.freedomnet.com/~jbaldwin/ ---- >"I waited for the Lord on high/I waited and He heard my cry." - Petra > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 12:33:41 +0930 >From: Greg Lehey <grog@lemis.com> >Subject: Re: AMD-specific kernel code (was: How long a wait?) > >On Sunday, 9 August 1998 at 23:00:24 -0400, John Baldwin wrote: >> On 08-Aug-98 Greg Lehey wrote: >>> (following up to -hackers) >>> On Thursday, 6 August 1998 at 23:44:39 -0700, David Greenman wrote: >>>> >>>> I just looked at the patch. Other than some KNF style bugs, it seems >>>> okay. >>>> I don't have any AMD K5/K6 machines, however, so I can't test it and won't >>>> be committing it. >>>> If it could get wider circulation - perhaps by posting a note to hackers >>>> asking for testers, then I think there would be less hesitation in getting >>>> it committed. >>> >>> I've grabbed the code and will try it out and report. >> >> One note, I just found out that this will only work on on certain chipsets (I >> think Intel Triton TX, but I could be wrong, so don't quote me on that.) > >As the title indicates, this specific tweak only works on AMD K5 >stepping 4 and above, and all AMD K6s. > >I've posted a followup. > >Greg >- -- >See complete headers for address and phone numbers >finger grog@lemis.com for PGP public key > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 10:18:00 +0200 (SAT) >From: Peter van Heusden <pvh@leftside.wcape.school.za> >Subject: Re: EXA 8200 tape drive on FreeBSD? > >On Sun, 9 Aug 1998, Wilko Bulte wrote: > >> >> Well, not that it solves your problem, but I also have a 8200 on a ncr810 >> and that one works. Has done so for years. >> >> More specific it has firmware: >> >> Aug 7 22:17:20 yedi /kernel: (ncr1:3:0): "EXABYTE EXB-8200 2687" type 1 >> removable SCSI 1 > >Thanks for the info. Mine gives a slightly different dmesg output: > >(ncr0:6:0): "EXABYTE EXB-8200 253G" type 1 removable SCSI 1 > >So, its a slightly different model, maybe with an older firmware >(are firmware upgrades possible on these drives?) However, since it is a >similar model, I was wondering what you do to use a tape. The tape I'm >trying to use is an Exabyte 112m tape, and as I said before, I tried a 'mt >erase' before using the tape. > >Peter >- -- >Peter van Heusden | Its the 90's, and collective action is STILL cool! >pvh@leftside.wcape.school.za | Get active in your union today! > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: 10 Aug 1998 10:55:18 +0200 >From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) >Subject: Re: Does this mean we have another breakin? > >"Matthew D. Fuller" <fullermd@futuresouth.com> writes: >> On sendmail on one machine (sendmail -q run out of cron) and on > >Why do you do that? Doesn't 'sendmail -bd -qxx' do the job? > >DES >- -- >Dag-Erling Smørgrav - dag-erli@ifi.uio.no > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: 10 Aug 1998 10:56:50 +0200 >From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) >Subject: Re: cvsup.freebsd.org down for a few > >Chris Timmons <skynyrd@opus.cts.cwu.edu> writes: >> ... site power outage. > >"Use the mirror, Luke" ;) > >DES >- -- >Dag-Erling Smørgrav - dag-erli@ifi.uio.no > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 02:03:04 -0700 >From: Amancio Hasty <hasty@rah.star-gate.com> >Subject: can not fork... > >Plenty of swap space: >{hasty} swapinfo >Device 512-blocks Used Avail Capacity Type >/dev/sd0s1b 262144 94096 167792 36% Interleaved >{hasty} sysctl kern.maxproc >kern.maxproc: 500 > > >{root} telnet rah >Trying 209.133.7.234... >Connected to rah.star-gate.com. >Escape character is '^]'. > >FreeBSD (rah.star-gate.com) (ttyp3) > >login: hasty >Password: >Last login: Mon Aug 10 00:02:45 from 192.100.81.124 >Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 > The Regents of the University of California. All rights reserved. > >FreeBSD 3.0-CURRENT (STAR-GATE) #28: Wed Jul 29 01:01:13 PDT 1998 >Justice, n.: > A decision in your favor. >{hasty} man vi >Formatting page, please wait...Cannot fork >Failed. >Error executing formatting or display command. >system command exited with status 512 >Cannot fork >Error executing formatting or display command. >system command exited with status 512 >No manual entry for vi >{hasty} setenv DISPLAY :0.0 >{hasty} man vi >Formatting page, please wait...Cannot fork >/usr/bin/groff:fatal error: fork: Resource temporarily unavailable >Failed. >Error executing formatting or display command. >system command exited with status 512 >Cannot fork >/usr/bin/groff:fatal error: fork: Resource temporarily unavailable >Error executing formatting or display command. >system command exited with status 512 >No manual entry for vi > >============================ > >vmstat -m >Memory statistics by bucket size >Size In Use Free Requests HighWater Couldfree > 16 69 187 48283 1280 0 > 32 273 9839 119520 640 4777 > 64 5020 1636 3806591 320 205 > 128 1312 14208 133289 160 12387 > 256 141 51 1856 80 0 > 512 4273 47 384705 40 318 > 1K 264 148 23053 20 862 > 2K 48 22 610 10 250 > 4K 14 2 3328 5 0 > 8K 9 10 367 5 199 > 16K 9 0 9 5 0 > 32K 1 0 2 5 0 >128K 0 0 37 5 0 > >Memory usage type by bucket size >Size Type(s) > 16 shm, sysctl, soname, ether_multi, routetbl, pcb, proc, devbuf, > DEVFS mount, temp > 32 mkdir, freefile, dirrem, indirdep, freefrag, sysctl, diradd, > bmsafemap, soname, in_multi, ether_multi, pgrp, subproc, routetbl, > pcb, newblk, vnodes, ifaddr, devbuf, temp, kld > 64 allocindir, shm, allocdirect, lockf, file, session, routetbl, pcb, > pagedep, namecache, proc, ifaddr, devbuf, DEVFS name, temp > 128 VM pgdata, freeblks, soname, zombie, file desc, routetbl, inodedep, > namecache, vnodes, cred, ZONE, ttys, ifaddr, DEVFS node, temp > 256 VM pgdata, Export Host, file desc, subproc, routetbl, newblk, > NFS daemon, NFS srvsock, vnodes, proc, devbuf > 512 VM pgdata, ioctlops, FFS node, UFS mount, BIO buffer, NFS daemon, > devbuf, mount, temp > 1K VM pgdata, BIO buffer, NQNFS Lease, devbuf, temp > 2K VM pgdata, UFS mount, BIO buffer, pcb, ttys, devbuf, mbuf > 4K VM pgdata, ioctlops, UFS mount, pagedep, devbuf, temp > 8K indirdep, VM pgdata, MSDOSFS mount, devbuf, temp > 16K UFS ihash, inodedep, NFS hash, ISOFS mount, devbuf > 32K VM pgdata, namecache >128K VM pgdata > >Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > mkdir 0 0K 9K 15768K 1748 0 0 32 > freefile 0 0K 231K 15768K 11001 0 0 32 > dirrem 0 0K 271K 15768K 11641 0 0 32 > indirdep 0 0K 105K 15768K 626 0 0 32,8K > allocindir 0 0K 28K 15768K 7986 0 0 64 > freefrag 0 0K 9K 15768K 7109 0 0 32 > shm 1 1K 1K 15768K 8 0 0 16,64 > VM pgdata 568 137K 420K 15768K 1039 0 0 >128,256,512,1K,2K,4K,8K,32K,128K > sysctl 0 0K 1K 15768K 5020 0 0 16,32 > allocdirect 1 1K 112K 15768K 27559 0 0 64 > freeblks 1 1K 919K 15768K 11156 0 0 128 > diradd 0 0K 71K 15768K 11777 0 0 32 > bmsafemap 1 1K 2K 15768K 1907 0 0 32 > lockf 2 1K 1K 15768K 12252 0 0 64 > Export Host 2 1K 1K 15768K 2 0 0 256 > soname 18 1K 1K 15768K 16495 0 0 16,32,128 > in_multi 4 1K 1K 15768K 4 0 0 32 > ether_multi 14 1K 1K 15768K 14 0 0 16,32 > ioctlops 0 0K 4K 15768K 6 0 0 512,4K > zombie 0 0K 1K 15768K 34000 0 0 128 > file 204 13K 16K 15768K 2826917 0 0 64 > session 27 2K 2K 15768K 1026 0 0 64 > pgrp 35 2K 2K 15768K 1963 0 0 32 > file desc 63 9K 10K 15768K 34069 0 0 128,256 > subproc 73 6K 7K 15768K 35517 0 0 32,256 > FFS node 4226 2113K 2144K 15768K 384515 0 0 512 > UFS mount 15 29K 29K 15768K 15 0 0 512,2K,4K > BIO buffer 282 309K 419K 15768K 13807 0 0 512,1K,2K > routetbl 51 7K 14K 15768K 378 0 0 16,32,64,128,256 > pcb 37 5K 5K 15768K 2774 0 0 16,32,64,2K > UFS ihash 1 16K 16K 15768K 1 0 0 16K > newblk 1 1K 1K 15768K 35546 0 0 32,256 > inodedep 2 17K 1192K 15768K 41251 0 0 128,16K > pagedep 1 4K 52K 15768K 2781 0 0 64,4K > NQNFS Lease 1 1K 1K 15768K 1 0 0 1K > NFS daemon 5 3K 3K 15768K 5 0 0 256,512 > NFS srvsock 2 1K 1K 15768K 2 0 0 256 > NFS hash 1 16K 16K 15768K 1 0 0 16K >MSDOSFS mount 1 8K 8K 15768K 1 0 0 8K > ISOFS mount 1 16K 16K 15768K 1 0 0 16K > namecache 4493 313K 414K 15768K 934003 0 0 64,128,32K > vnodes 56 7K 24K 15768K 1271 0 0 32,128,256 > cred 22 3K 5K 15768K 4027 0 0 128 > ZONE 17 3K 3K 15768K 17 0 0 128 > proc 7 1K 1K 15768K 8 0 0 16,64,256 > ttys 481 64K 64K 15768K 1339 0 0 128,2K > ifaddr 17 2K 2K 15768K 17 0 0 32,64,128 > devbuf 101 166K 166K 15768K 161 0 0 >16,32,64,256,512,1K,2K,4K,8K,16K > DEVFS mount 1 1K 1K 15768K 1 0 0 16 > mount 7 4K 4K 15768K 7 0 0 512 > DEVFS name 265 17K 17K 15768K 305 0 0 64 > DEVFS node 243 31K 31K 15768K 283 0 0 128 > mbuf 1 2K 2K 15768K 1 0 0 2K > temp 80 6K 15K 15768K 38288 0 0 >16,32,64,128,512,1K,4K,8K > kld 1 1K 1K 15768K 1 0 0 32 > >Memory Totals: In Use Free Requests > 3324K 2505K 4521650 > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 12:06:08 +0200 (MET DST) >From: Nick Hibma <nick.hibma@jrc.it> >Subject: Re: EXA 8200 tape drive on FreeBSD? > > > So, its a slightly different model, maybe with an older firmware > > (are firmware upgrades possible on these drives?) However, since it is a > > similar model, I was wondering what you do to use a tape. The tape I'm > > trying to use is an Exabyte 112m tape, and as I said before, I tried a 'mt > > erase' before using the tape. > >Take a safe bet and use a 90m tape before anything else. I know that >160m tapes are aproblem in anything before the 8505XL drives and after >that they were still not very reliable. > >The update of the EPROM involves opening it up and being able to burn an >EPROM. > >I'll send you the web page of exabyte separately: > > http://www.exabyte.com/suppserv/techsupp/8mm/fullhigh/ >Nick > > >- -- >building: 27A >address: STA-ISIS, T.P.270, Joint Research Centre, 21020 Ispra, Italy >tel.: +39 332 78 9549 >fax.: +39 332 78 9185 > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 12:20:53 +0200 >From: sthaug@nethelp.no >Subject: Re: can not fork... > >> Plenty of swap space: >> {hasty} swapinfo >> Device 512-blocks Used Avail Capacity Type >> /dev/sd0s1b 262144 94096 167792 36% Interleaved >> {hasty} sysctl kern.maxproc >> kern.maxproc: 500 > >You haven't given enough info - you could still be bumping against >login.conf limits. > >I ended up having to increase maxproc-cur for the "root" and "default" >entries quite a bit, on a 2.2.6 system. > >Steinar Haug, Nethelp consulting, sthaug@nethelp.no > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 13:25:34 +0300 >From: Ruslan Shevchenko <Ruslan@Shevchenko.Kiev.UA> >Subject: Re: can not fork... > >Amancio Hasty wrote: >> >> .... >> FreeBSD 3.0-CURRENT (STAR-GATE) #28: Wed Jul 29 01:01:13 PDT 1998 >> Justice, n.: >> A decision in your favor. >> {hasty} man vi >> Formatting page, please wait...Cannot fork >> Failed. >> Error executing formatting or display command. >> system command exited with status 512 >> Cannot fork >> > > login.conf > > what is you ulimit ? > > >- -- > @= > //RSSH >mailto:Ruslan@Shevchenko.Kiev.UA > >CORBA in Ukraine & ex-USSR: http://www.corbadev.kiev.ua > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 08:45:54 -0700 >From: Mike Smith <mike@smith.net.au> >Subject: Re: can not fork... > >> >> {root} telnet rah >> Trying 209.133.7.234... >> Connected to rah.star-gate.com. >> Escape character is '^]'. > >No problem forking for telnetd. > >> >> FreeBSD (rah.star-gate.com) (ttyp3) >> >> login: hasty >> Password: >> Last login: Mon Aug 10 00:02:45 from 192.100.81.124 >> Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> >> FreeBSD 3.0-CURRENT (STAR-GATE) #28: Wed Jul 29 01:01:13 PDT 1998 > >No problem forking for login. > >> Justice, n.: >> A decision in your favor. > >No problem forking for your shell, or fortune. > >> {hasty} man vi >> Formatting page, please wait...Cannot fork > >No problem forking for man, but problems with the pager. > >At this point, 'limit' and 'ps x | wc -l' would be educational. > >> vmstat -m >... > >Nothing suspicious in here. > >- -- >\\ Sometimes you're ahead, \\ Mike Smith >\\ sometimes you're behind. \\ mike@smith.net.au >\\ The race is long, and in the \\ msmith@freebsd.org >\\ end it's only with yourself. \\ msmith@cdrom.com > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 09:25:29 -0700 >From: Amancio Hasty <hasty@rah.star-gate.com> >Subject: Re: can not fork... > >My old limits: > >{hasty} limit >cputime unlimited >filesize unlimited >datasize 32768 kbytes >stacksize 16384 kbytes >coredumpsize unlimited >memoryuse unlimited >descriptors 256 >memorylocked 20480 kbytes >maxproc 32 >{hasty} ps -x | wc -l > 24 > >My new limits: >{hasty} limit >cputime unlimited >filesize unlimited >datasize 524288 kbytes >stacksize 49152 kbytes >coredumpsize unlimited >memoryuse unlimited >descriptors 256 >memorylocked 20480 kbytes >maxproc 64 > > >I just bumped up my login class xuser: > >xuser:\ > :manpath=/usr/share/man /usr/X11R6/man /usr/local/man:\ > :cputime=4h:\ > :datasize=64M:\ > :stacksize=32M:\ > :filesize=32M:\ > :memoryuse=120M:\ > :openfiles=256:\ > :maxproc=64:\ > :tc=standard: >and increased maxusers to 64 in my kernel config file. > >I think what I will do next is decreased my limits and repeat the >same experiment . > >I usually don't run much in my system > >USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND >hasty 1703 0.0 0.0 404 280 p4 R+ 9:19AM 0:00.00 ps -xuaw >root 1 0.0 0.0 496 180 ?? Is 7:18PM 0:00.13 /sbin/init -- >root 2 0.0 0.0 0 0 ?? DL 7:18PM 0:00.05 (pagedaemon) >root 3 0.0 0.0 0 0 ?? DL 7:18PM 0:00.00 (vmdaemon) >root 4 0.0 0.0 0 0 ?? DL 7:18PM 0:01.95 (syncer) >root 28 0.0 0.0 204 68 ?? Is 7:18PM 0:00.00 adjkerntz -i >root 83 0.0 0.0 796 396 ?? Ss 2:18AM 0:00.25 syslogd >root 89 0.0 0.0 1756 1292 ?? Is 2:18AM 0:00.46 named -b >/etc/namedb/named.conf >daemon 94 0.0 0.0 780 304 ?? Is 2:18AM 0:00.00 portmap >root 102 0.0 0.0 460 228 ?? Is 2:18AM 0:00.00 mountd >root 105 0.0 0.0 316 140 ?? Is 2:18AM 0:00.01 nfsd: master >(nfsd) >root 109 0.0 0.0 296 88 ?? I 2:18AM 0:00.00 nfsd: server >(nfsd) >root 110 0.0 0.0 296 88 ?? I 2:18AM 0:00.00 nfsd: server >(nfsd) >root 111 0.0 0.0 296 88 ?? I 2:18AM 0:00.00 nfsd: server >(nfsd) >root 112 0.0 0.0 296 88 ?? I 2:18AM 0:00.00 nfsd: server >(nfsd) >root 113 0.0 0.0 262944 316 ?? Is 2:18AM 0:00.00 rpc.statd >root 128 0.0 0.0 836 380 ?? Is 2:18AM 0:00.13 inetd >root 130 0.0 0.0 952 380 ?? Is 2:18AM 0:00.81 cron >root 134 0.0 0.0 808 420 ?? Is 2:18AM 0:00.01 lpd >root 137 0.0 0.0 1192 576 ?? Ss 2:18AM 0:00.28 sendmail: >accepting connections on port 25 (sendmail) >root 158 0.0 0.0 760 340 ?? Ss 2:18AM 0:01.89 moused -p >/dev/mouse -t x10mouseremote >msql 172 0.0 0.0 1048 464 con- I+ 2:18AM 0:01.54 >/usr/local/bin/msql2d >root 186 0.0 0.0 1296 640 ?? Is 2:18AM 0:00.00 >/usr/local/sbin/smbd -D >root 188 0.0 0.0 1160 684 ?? Ss 2:18AM 0:00.46 >/usr/local/sbin/nmbd -D >root 193 0.0 0.0 1152 576 ?? Is 2:18AM 0:00.74 >/usr/local/sbin/sshd >hasty 217 0.0 0.0 1360 940 v0 Is 2:18AM 0:00.13 -tcsh (tcsh) >root 218 0.0 0.0 796 416 v1 Is+ 2:18AM 0:00.01 >/usr/libexec/getty Pc ttyv1 >root 219 0.0 0.0 796 416 v2 Is+ 2:18AM 0:00.01 >/usr/libexec/getty Pc ttyv2 >hasty 223 0.0 0.0 456 236 v0 I+ 2:18AM 0:00.02 /bin/csh >/usr/local/bin/sx 16 >hasty 224 0.0 0.0 1688 600 v0 I+ 2:18AM 0:00.02 >/usr/X11R6/bin/xinit -- /usr/X11R6/bin/Xwrapper :0 -gamma 1.5 -bpp 16 >root 225 0.0 0.0 14152 12384 ?? S 2:18AM 5:12.93 >/usr/X11R6/bin/Xwrapper :0 -gamma 1.5 -bpp 16 (XF86_SVGA) >hasty 228 0.0 0.0 492 156 v0 I 2:18AM 0:00.01 sh >/home/hasty/.xinitrc >hasty 229 0.0 0.0 2044 1148 v0 I 2:18AM 0:00.06 xconsole >root 231 0.0 0.0 3052 2184 v0 S 2:18AM 0:02.64 xterm -e tcsh >hasty 233 0.0 0.0 1720 984 v0 S 2:18AM 0:00.87 fvwm95-2 >hasty 234 0.0 0.0 1376 440 v0 S 2:18AM 0:00.03 >/usr/X11R6/lib/X11/fvwm95-2/FvwmAuto 9 6 .fvwm2rc95 0 8 300 >hasty 237 0.0 0.0 1496 696 v0 S 2:18AM 0:00.08 >/usr/X11R6/lib/X11/fvwm95-2//FvwmButtons 10 5 .fvwm2rc95 0 8 >hasty 238 0.0 0.0 1564 776 v0 S 2:18AM 0:00.27 >/usr/X11R6/lib/X11/fvwm95-2//FvwmTaskBar 12 5 .fvwm2rc95 0 8 >hasty 240 0.0 0.0 2036 1172 v0 S 2:18AM 0:04.82 xclock >hasty 241 0.0 0.0 500 160 v0 I 2:18AM 0:00.00 /bin/sh -c nice >- -16 xload -fg red -nolabel -bg grey60 -update 5 -geom >hasty 242 0.0 0.0 2148 1292 v0 SN 2:18AM 0:01.10 xload >hasty 243 0.0 0.0 1492 688 v0 S 2:18AM 0:00.11 >/usr/X11R6/lib/X11/fvwm95-2//FvwmPager 14 5 .fvwm2rc95 0 8 0 0 >hasty 244 0.0 0.0 1344 920 p0 Is 2:18AM 0:00.10 -csh (tcsh) >hasty 246 0.0 0.0 32176 27064 p0 S 2:18AM 31:41.40 netscape >hasty 247 0.0 0.0 13424 3084 p0 I 2:18AM 0:00.22 (dns helper) >(netscape) >hasty 263 0.0 0.0 920 512 p0 I+ 2:28AM 0:00.84 telnet rah >root 264 0.0 0.0 864 456 ?? Is 2:28AM 0:00.62 telnetd >hasty 265 0.0 0.0 1364 1008 p2 Is 2:28AM 0:00.22 -tcsh (tcsh) >hasty 1041 0.0 0.0 8916 8380 v0 S 8:31AM 0:34.78 >/usr/local/bin/wish8.0 -f /usr/local/bin/exmh >hasty 1424 0.0 0.0 3828 2988 v0 I 8:32AM 0:01.00 >/usr/local/bin/wish8.0 -f /usr/local/bin/exmh-bg exmh /usr/local/lib/ >root 1686 0.0 0.0 2436 1748 v0 S 9:12AM 0:00.17 xterm >hasty 1687 0.0 0.0 1348 976 p4 Ss 9:12AM 0:00.11 -tcsh (tcsh) >hasty 1695 0.0 0.0 5444 4992 v0 S 9:14AM 0:00.26 ispell -a -S >hasty 1699 0.0 0.0 820 556 p2 I+ 9:16AM 0:00.02 more -e >/etc/login.conf >root 0 0.0 0.0 0 0 ?? DLs 7:18PM 0:00.02 (swapper) > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 09:55:37 -0700 >From: Amancio Hasty <hasty@rah.star-gate.com> >Subject: Re: can not fork... > >Tnks Mike , I think it was a limit problem in my system. I can't >seem to reproduce the problem after switching from the default >login class to my modified "xuser" class. > >xuser:\ > :manpath=/usr/share/man /usr/X11R6/man /usr/local/man:\ > :cputime=4h:\ > :datasize=64M:\ > :stacksize=32M:\ > :filesize=32M:\ > :memoryuse=120M:\ > :openfiles=256:\ > :maxproc=64:\ > :tc=standard: > > Amancio > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 10:14:24 -0700 (PDT) >From: David Wolfskill <dhw@whistle.com> >Subject: Re: CAP vs netatalk for Appletalk/printing support > >>Date: Fri, 7 Aug 1998 15:53:39 -0400 >>From: Garance A Drosihn <drosih@rpi.edu> > >>I notice the ports collection includes both CAP and netatalk, and >>that kernel changes have been made for netatalk to take advantage >>of. I was wondering if most FreeBSD'ers prefer netatalk over CAP. > >Not sure about FreeBSDers, but I'll mention that a fairly large company >I did some consulting sysadmin work for uses CAP for access to printers. >(The company in question was moving its Mountain View Facility to >downtown San Jose; I participated in part of that move near the >beginning of my tenure there. They use *lots* of printers....) > >Thus, it's conceivable that keeping CAP functional would make FreeBSD >more attractive to such a company than failing to keep it functional >would. (During the time I was there, they did not make any use of >FreeBSD that I know of; I mostly did Solaris 2 & SunOS administration, >with the occasional IRIX, AIX, Digital UNIX, or HPUX system.) > >One datum, >david >- -- >David Wolfskill UNIX System Administrator >dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 15:28:03 -0400 (EDT) >From: zhihuizhang <bf20761@binghamton.edu> >Subject: Question about routine getblk() > >Hi, getblk() tries to get a buffer with specified size >of physical memory allocated to it. I got two questions >about this routine: > >(1) The given size could be greater than the optimial size contained in >the mount structure. The comment says "this happens on mount points". >Why is the case? > >(2) If the buffer is in the core, we check for size inconsistancies. Why >should this happen and why should we be conservative on metadata. > >Any help is appreciated. > > >- -------------------------------------------------- >| Zhihui Zhang, http://cs.binghamton.edu/~zzhang | >| Dept. of Computer Science, SUNY at Binghamton | >- -------------------------------------------------- > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >Date: Mon, 10 Aug 1998 17:46:19 -0400 (EDT) >From: Luoqi Chen <luoqi@watermarkgroup.com> >Subject: Re: Question about routine getblk() > >> Hi, getblk() tries to get a buffer with specified size >> of physical memory allocated to it. I got two questions >> about this routine: >> >> (1) The given size could be greater than the optimial size contained in >> the mount structure. The comment says "this happens on mount points". >> Why is the case? >The size you were talking about was the block size of the file system, >it is used to translate starting blkno to a vm offset. For a mount point >covered by another file system, the correct block size should be coming >from the fs that is covering this vnode, but vp->v_mount still points to >the fs being covered, and block size for these two fs could be different. > >> >> (2) If the buffer is in the core, we check for size inconsistancies. Why >> should this happen and why should we be conservative on metadata. >I'm not sure about this one. Maybe it happens when a frag is extended to >a full block? >> >> Any help is appreciated. >> >> >> -------------------------------------------------- >> | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | >> | Dept. of Computer Science, SUNY at Binghamton | >> -------------------------------------------------- >> >- -lq > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > >------------------------------ > >End of freebsd-hackers-digest V4 #215 >************************************* > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?980811132115.n0002911.pcp>