FW: CVS FYI (fwd)
U website/main/dbfiles/email_ad_tools.db cvs update: cannot change mode of website/main/dbfiles/email_ad_tools.db: Stale NFS file handle anyone know how to get rid of these. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pagedaemon + vmdaemon
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root2 14.2 0.0 00 ?? DL Tue11AM 4:35.33 (pagedaemon) root3 12.7 0.0 00 ?? DL Tue11AM 1:56.25 (vmdaemon) Cpu kept hitting high load averages on machines for about 1 min periods on some machines on some apache servers. I wrote a script to catch the offending processes and it seems to be these ones. Ideas on why they would be taking that much cpu? -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: pagedaemon + vmdaemon
ya it seems it is running into swap abit. hmmm watching apache with truss i see alot of error #35's in the sys callswhat is that related to again? On Mon, 16 Jul 2001, John Baldwin wrote: > Date: Mon, 16 Jul 2001 13:03:33 -0700 (PDT) > From: John Baldwin <[EMAIL PROTECTED]> > To: Dan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: RE: pagedaemon + vmdaemon > > > On 16-Jul-01 Dan wrote: > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > > root2 14.2 0.0 00 ?? DL Tue11AM 4:35.33 (pagedaemon) > > root3 12.7 0.0 00 ?? DL Tue11AM 1:56.25 (vmdaemon) > > > > Cpu kept hitting high load averages on machines for about 1 min periods on > > some machines on some apache servers. I wrote a script to catch the > > offending processes and it seems to be these ones. Ideas on why they would > > be taking that much cpu? > > These processes manage the VM paging, so perhaps you are running low on memory > and trashing? > > -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kernel panics and ipfilter
1) Aug 3 15:41:15 www /kernel: panic: vm_page_remove(): page not found in hash Aug 3 15:41:15 www /kernel: seems box rebooted after that freebsd 4.3 release. 2) echo "starting firewall" kldload /modules/ipl.ko ipf -f /etc/ipf.rules another problems with this box is ipfilter.currently i enable the rules at startup by just kldloading the module basically and installing the ruleset.problem is when i take down ruleset and redo it, for some reason i cannot connect out anymore unless ruleset is completely removed. It is the exact same ruleset. THe only fix been this far is to just reboot the machine.i am starting to wonder if there is to much traffic to a box when you enable it right away that ipfilter maybe does not read them all. GOing to try a couple more things but if anyone has experieced this , some input would be most appreciated. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ncftpd
ncftpd-2.6.3 i found this to panic the kernel under freebsd latest releases. I simple killall ncftpd just crashed the machinegonna try upgrading it see if that helps any. -- Forwarded message -- Date: Fri, 3 Aug 2001 15:48:08 -0700 (PDT) From: Dan <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: kernel panics and ipfilter 1) Aug 3 15:41:15 www /kernel: panic: vm_page_remove(): page not found in hash Aug 3 15:41:15 www /kernel: seems box rebooted after that freebsd 4.3 release. 2) echo "starting firewall" kldload /modules/ipl.ko ipf -f /etc/ipf.rules another problems with this box is ipfilter.currently i enable the rules at startup by just kldloading the module basically and installing the ruleset.problem is when i take down ruleset and redo it, for some reason i cannot connect out anymore unless ruleset is completely removed. It is the exact same ruleset. THe only fix been this far is to just reboot the machine.i am starting to wonder if there is to much traffic to a box when you enable it right away that ipfilter maybe does not read them all. GOing to try a couple more things but if anyone has experieced this , some input would be most appreciated. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
hardware
Not sure if this is the right list for this but I am wondering if there is support for the Intel Dual 10/100BT Ethernet Adapter. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
memory + apache
i am seeing problems where apache is running into swap at times. When all is said and done...i see alot of available memory from top and alot still stuck in swap. Restarting apache at that point clears the swap space right out and memory is used properly again. These seem to be short bursting peeks which i can;t get to in time to run vmstat on. When i login i never see any paging or swapping going on maybe 2 blocked processes waiting to run seems the average under the b column in vmstat. Another thing to note is cpu sky rockets when those burts happen. How can a process go into swap really badly yet seem to not use all available memory first. Disk I/O does not seem like a factor. What I am thinking of doing is decreasing buffer cache size. Currently there is 512 megs of ram. So 512-(kernel executable size)/5 i figure decrease it to around 25 megs instead of default for the buffer cache. Currently i see it using about 61 megs of buffer cache. I see in the LINT kernel config an option to set it, how do i tell what the current default is? nbufs in not currently in the kernel i have configured. I know I will decrease I/O performance doign this but it doesn;t seem to be the factor. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: memory + apache
Yeah that is what I am thinking to. My guess is some large array allocated in the php code maybe or a sql query taking to long to finish eating up all the ram. That is kind of interesting to know. I would think the backstore would maybe be moved back to the paging system after the memory is free to use again at the very least. My understanding is once return address of memory used in swap is accessed a page fault occurs and then it would be taken out of swap space. I guess maybe what is happening is that that memory got into swap and is never used again so that is why i keep seeing those numbers in the swap space, or like you said the system just has decided to leave it there once it has gone in. I'll have to do some more research but I guess this is comming down to more of catching the offending apache process then watching vmstat for page in and page outs happening.I would say it's fairly obvious that that is happening before it hits swap. Anyone have recommendations on catching what php code it is accessing at that certian time or how to track it down. On Thu, 30 Aug 2001, mark tinguely wrote: > Date: Thu, 30 Aug 2001 09:18:42 -0500 (CDT) > From: mark tinguely <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: memory + apache > > Once a page gets backed into swap backstore, it will remain until the > application exits. The page may be brought back to physical memory > and be used from physical memory. It was decided back in the early > days that it was not worth the effort to remove the page from backstore > until the program exitted. > > Is your memory/CPU peaks periodic enough to watch with top(1) or > other diagnostic tool. Something is eating your memory (like a run-away > CGI). > > --mark tinguely. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: memory + apache
I will give it a try. touch /var/account/acct accton how long does it take for anything to get written to that file? As far as fork storms, I did noticed 1. I had the junior admin write a script to restart apache if LA got to high doing a truss on the pid i did noticed mad processes and his perl script hitting 10% cpu at times. Looking at it it was just a basic infinite while loop checking `uptime`. I have taken that script off but I don;t think that is what is causing this swap issue. Checking the hardware as well I have confirmed that the manufacter for these machines only included a heat sink and this tiny fan not big enough for these boxesso cooling of the chip may be an issue as well.gonna have to check over a bunch of things next couple days. On Thu, 30 Aug 2001, mark tinguely wrote: > Date: Thu, 30 Aug 2001 12:19:55 -0500 (CDT) > From: mark tinguely <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: memory + apache > > > > Yeah that is what I am thinking to. My guess is some large array allocated > > in the php code maybe or a sql query taking to long to finish eating up > > all the ram. That is kind of interesting to know. > > you said that the CPU usage spikes also at the time of the memory depletion? > I wonder if you have some fork storm. If you had process accounting > enabled and match it up with the web log file and vmstat activity you > may be able to narrow your search. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ide striping
Does it make sense at all to stripe primary slave, secondary master and slave together? I would imagine it is a waste of time , just looking for thoughts on this vs just a single primary master IDE. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PIO mode
ad0s1a: UDMA ICRC error reading fsbn 191 of 64-79 (ad0s1 bn 191; cn 0 tn 3 sn 2) retrying ad0s1a: UDMA ICRC error reading fsbn 191 of 64-79 (ad0s1 bn 191; cn 0 tn 3 sn 2) retrying ad0s1a: UDMA ICRC error reading fsbn 191 of 64-79 (ad0s1 bn 191; cn 0 tn 3 sn 2) retrying ad0s1a: UDMA ICRC error reading fsbn 191 of 64-79 (ad0s1 bn 191; cn 0 tn 3 sn 2) falling back to PIO mode we currently do replication on disks for mirrors of webservers. I am wondering what this PIO mode is and if this message should be any concern to me at all. we use dd to replicate complete disksbut i have been noticing fdisk bitching about wrong geometry. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PIO mode
You were completely right. I replaced the IDE cable and that fixed it. Thankyou very much. Dan. On Sat, 15 Sep 2001, Frank Nobis wrote: > Date: Sat, 15 Sep 2001 13:03:00 +0200 > From: Frank Nobis <[EMAIL PROTECTED]> > To: Stephen Hurd <[EMAIL PROTECTED]> > Cc: Dan <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: PIO mode > > > Am Samstag, 15. September 2001 um 07:33 schrieb Stephen Hurd: > > >> ad0s1a: UDMA ICRC error reading fsbn 191 of 64-79 (ad0s1 bn 191; cn 0 tn > >> 3 > >> sn 2) retrying > > > > Actually, the ICRC error IS a bit frigtening... I always got read timeouts > > when it was a bad HD/controller combo... I'd like to revise my opinion to > > say > > "Get your data off now while you still can!" But maybe dig through the ata > > source... there's probobly helpful comments in that bit. > > > > I had those problems once with a HPT370 controller. The problem was at last > bad cable. After trying three different 80 wire types I had success. I had > no more ICRC errors since then. > > Frank > > -- > Frank Nobis > Landgrafenstr. 130 > 44139 Dortmund > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
hardware chipset compat list
The Intel PRO/100 S Server Adapter contains the Intel 82550EY Fast Ethernet controller I am trying to find where i can find the chipset supported page. For future reference. All i see on the main hardware compat page is the make.if someone could point me to this page...would be most appreciated. # The `fxp' device provides support for the Intel EtherExpress Pro/100B # PCI Fast Ethernet adapters. found this in the LINT kernelcan;t tell again what chipsets. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
Subscribe Dan Gold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
power supplies
I had the stangest situation today where a new nic card was put into a machine and then the machine did not start up. Placed the old nic card back in the box and it still did not start up. Switched power supplies with an exactly equal box and both machine booted up fine. This has happened twice since we started replacing nic cards today with ones with more buffer space available on them out of about 8 machines now. Does this make any sense to anyone? -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
ya but even putting the old nic back in the machine does not still boot up. I don't think this has to do with the nic but you never know. fxp1: On Thu, 27 Sep 2001, Kent Stewart wrote: > Date: Thu, 27 Sep 2001 19:38:55 -0700 > From: Kent Stewart <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: Dan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: power supplies > > > > Dan wrote: > > > > I had the stangest situation today where a new nic card was put into a > > machine and then the machine did not start up. Placed the old nic card > > back in the box and it still did not start up. Switched power supplies > > with an exactly equal box and both machine booted up fine. This has > > happened twice since we started replacing nic cards today with ones with > > more buffer space available on them out of about 8 machines now. > > > > Does this make any sense to anyone? > > There are problems with PSes when you use NICs with wake up > capability. The NIC may exceed the capability of one of your low > amperage voltages. > > Kent > > > > > -- > > Dan > > > > +--+ > > | BRAVENET WEB SERVICES | > > | [EMAIL PROTECTED] | > > | screen;cd /usr/src;make buildworld;cd ~ | > > | cp MYKERNEL /sys/i386/conf;cd /usr/src | > > |make buildkernel KERNCONF=MYKERNEL| > > |make installkernel KERNCONF=MYKERNEL;make installworld| > > +__+ > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Kent Stewart > Richland, WA > > mailto:[EMAIL PROTECTED] > http://kstewart.urx.com/kstewart/index.html > FreeBSD News http://daily.daemonnews.org/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
no, it worked when i put it in a different machine that was exactly the same. On Thu, 27 Sep 2001, Kris Kennaway wrote: > Date: Thu, 27 Sep 2001 19:59:05 -0700 > From: Kris Kennaway <[EMAIL PROTECTED]> > To: Dan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: power supplies > > On Thu, Sep 27, 2001 at 08:04:40PM -0700, Dan wrote: > > > > ya but even putting the old nic back in the machine does not still boot > > up. I don't think this has to do with the nic but you never know. > > fxp1: > > You overloaded and burned out the power supply? > > Kris > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Realtek RTL8100B
Is this supported? Cannot seem to find this version at ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/4.5-RELEASE/HARDWARE.HTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Interactive tool for installing packages
In the last episode (Nov 10), per...@pluto.rain.com said: > Marin Atanasov Nikolov wrote: > > in order to install the program, you need to: > > > > # git clone git://git.unix-heaven.org/public/pkg_add_it > ... > > Surely, there's room for improvement, but that's a start.. :) > > Dunno about anyone else, but from my standpoint it would be a _big_ > improvement to provide a more recent snapshot than the 6-month-old > pkg_add_it-1.2.tar.gz on ftp.freebsd.org so one doesn't have to install > git, with its boatload of dependencies*, to see the recent improvements. > > * The amount of stuff downloaded by > cd /usr/ports/devel/git ; make fetch-recursive > is, shall we say, impressive. I use the devel/hg-git port to pull all the git trees I need to access using mercurial. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ugen claiming pcie device
In the last episode (Nov 13), Christopher Bowman said: > I have a Xilinx PCIe card installed in my machine and it appears that > ugen0 is claiming it. Why would a PCIe device even be offered to ugen? > > The message I get on boot up is: > ugen0 on uhub3 > Any way I can prevent this so my on kld driver can attach? > Regards If it's hanging off uhub3, it's a usb device :) Google says that is the Xilinx "USB platform cable" device. The ugen device attaches to any usb device that no other driver has claimed. Maybe the Xilinx card provides a virtual usb controller and device that you control the card with? -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Namecache lock contention?
In the last episode (Jan 28), Ivan Voras said: > I have this situation on a PHP server: > > 36623 www 1 760 237M 30600K *Name 6 0:14 47.27% php-cgi > 36638 www 1 760 237M 30600K *Name 3 0:14 46.97% php-cgi > 36628 www 1 1050 237M 30600K *Name 2 0:14 46.88% php-cgi > 36627 www 1 1050 237M 30600K *Name 0 0:14 46.78% php-cgi > 36639 www 1 1050 237M 30600K *Name 5 0:14 46.58% php-cgi > 36643 www 1 1050 237M 30600K *Name 7 0:14 46.39% php-cgi > 36629 www 1 760 237M 30600K *Name 1 0:14 46.39% php-cgi > 36642 www 1 1050 237M 30600K *Name 2 0:14 46.39% php-cgi > 36626 www 1 1050 237M 30600K *Name 5 0:14 46.19% php-cgi > 36654 www 1 1050 237M 30600K *Name 7 0:13 46.19% php-cgi > 36645 www 1 1050 237M 30600K *Name 1 0:14 45.75% php-cgi > 36625 www 1 1050 237M 30600K *Name 0 0:14 45.56% php-cgi > 36624 www 1 1050 237M 30600K *Name 6 0:14 45.56% php-cgi > 36630 www 1 760 237M 30600K *Name 7 0:14 45.17% php-cgi > 36631 www 1 1050 237M 30600K RUN 4 0:14 45.17% php-cgi > 36636 www 1 1050 237M 30600K *Name 3 0:14 44.87% php-cgi > > It looks like periodically most or all of the php-cgi processes are > blocked in "*Name" for long enough that "top" notices, then continue, > probably in a "thundering herd" way. From grepping inside /sys the most > likely suspect seems to be something in the namecache, but I can't find > exactly a symbol named "Name" or string beginning with "Name" that would > be connected to a lock. My guess would be: kern/vfs_cache.c:151 static struct rwlock cache_lock; kern/vfs_cache.c:152 RW_SYSINIT(vfscache, &cache_lock, "Name Cache"); The CACHE_*LOCK() macros.c in vfs_cache use cache_lock, so you've got lots of possible contention points. procstat -ka and/or dtrace might help you determine exactly where. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: reverse of getchar() read() open() fopen() ?
In the last episode (Feb 11), Julian H. Stacey said: > Hi hackers@, > Do we have C libraries with reverse of getchar() [ & maybe read() ] & > fopen() [ & maybe open() ] etc, to read from end of file toward beginning > ? I dont see anything in the See Also sections. I'm not looking to > write, just read. I'm looking for something that returns last char in > file as first etc, I'm not interested in wchars etc, I could write some C > functions, with seek etc & probably will, if none exist, but no point if > they already exist ? tail -r does this on a line-by-line basis. Tail does it for regular files by mmaping and then reading backwards, but you could also read the block of data at (filesize MOD buffersize) and return its bytes in reverse order, then seek back buffersize bytes, read that block and print it reversed, etc. You might even be able to write functions that could be passed to funopen(). Then you'd have a regular FILE* that you could call with regular stdio functions. Getting the buffering right for good performance might get tricky, though. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: usertime and systime
In the last episode (Mar 16), Thiago Damas said:
> Hi,
> without procfs, there is a way to get usertime and systime from a
> running process?
Try applying the attached patch to ps. I've had it for a while but never
submitted a PR.
Heh. I've had it for a very long time.
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html
--
Dan Nelson
dnel...@allantgroup.com
Index: ps.1
===
--- ps.1 (revision 219700)
+++ ps.1 (working copy)
@@ -587,6 +587,8 @@ symbolic process state (alias
saved gid from a setgid executable
.It Cm svuid
saved UID from a setuid executable
+.It Cm systime
+accumulated system CPU time
.It Cm tdaddr
thread address
.It Cm tdev
@@ -617,6 +619,8 @@ scheduling priority on return from system call (al
.Cm usrpri )
.It Cm user
user name (from UID)
+.It Cm usertime
+accumulated user CPU time
.It Cm vsz
virtual size in Kbytes (alias
.Cm vsize )
Index: keyword.c
===
--- keyword.c (revision 219700)
+++ keyword.c (working copy)
@@ -186,6 +186,7 @@ static VAR var[] = {
UINT, UIDFMT, 0},
{"svuid", "SVUID", NULL, 0, kvar, NULL, UIDLEN, KOFF(ki_svuid),
UINT, UIDFMT, 0},
+ {"systime", "SYSTIME", NULL, USER, systime, NULL, 9, 0, CHAR, NULL, 0},
{"tdaddr", "TDADDR", NULL, 0, kvar, NULL, sizeof(void *) * 2,
KOFF(ki_tdaddr), KPTR, "lx", 0},
{"tdev", "TDEV", NULL, 0, tdev, NULL, 5, 0, CHAR, NULL, 0},
@@ -207,6 +208,7 @@ static VAR var[] = {
KOFF(ki_paddr), KPTR, "lx", 0},
{"user", "USER", NULL, LJUST|DSIZ, uname, s_uname, USERLEN, 0, CHAR,
NULL, 0},
+ {"usertime", "USERTIME", NULL, USER, usertime, NULL, 9, 0, CHAR, NULL, 0},
{"usrpri", "", "upr", 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{"vsize", "", "vsz", 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{"vsz", "VSZ", NULL, 0, vsize, NULL, 5, 0, CHAR, NULL, 0},
Index: extern.h
===
--- extern.h (revision 219700)
+++ extern.h (working copy)
@@ -79,12 +79,14 @@ int s_uname(KINFO *);
void showkey(void);
void started(KINFO *, VARENT *);
void state(KINFO *, VARENT *);
+void systime(KINFO *, VARENT *);
void tdev(KINFO *, VARENT *);
void tdnam(KINFO *, VARENT *);
void tname(KINFO *, VARENT *);
void ucomm(KINFO *, VARENT *);
void uname(KINFO *, VARENT *);
void upr(KINFO *, VARENT *);
+void usertime(KINFO *, VARENT *);
void vsize(KINFO *, VARENT *);
void wchan(KINFO *, VARENT *);
__END_DECLS
Index: print.c
===
--- print.c (revision 219700)
+++ print.c (working copy)
@@ -588,6 +588,79 @@ cputime(KINFO *k, VARENT *ve)
}
void
+systime(KINFO *k, VARENT *ve)
+{
+ VAR *v;
+ long secs;
+ long psecs; /* "parts" of a second. first micro, then centi */
+ char obuff[128];
+ static char decimal_point;
+
+ if (decimal_point == '\0')
+ decimal_point = localeconv()->decimal_point[0];
+ v = ve->var;
+ if (!k->ki_valid) {
+ secs = 0;
+ psecs = 0;
+ } else {
+ /*
+ * This counts time spent handling interrupts. We could
+ * fix this, but it is not 100% trivial (and interrupt
+ * time fractions only work on the sparc anyway). XXX
+ */
+ secs = k->ki_p->ki_rusage.ru_stime.tv_sec;
+ psecs = k->ki_p->ki_rusage.ru_stime.tv_usec;
+ if (sumrusage) {
+ secs += k->ki_p->ki_childstime.tv_sec;
+ psecs += k->ki_p->ki_childstime.tv_usec;
+ }
+ /*
+ * round and scale to 100's
+ */
+ psecs = (psecs + 5000) / 1;
+ secs += psecs / 100;
+ psecs = psecs % 100;
+ }
+ (void)snprintf(obuff, sizeof(obuff), "%3ld:%02ld%c%02ld",
+ secs / 60, secs % 60, decimal_point, psecs);
+ (void)printf("%*s", v->width, obuff);
+}
+
+void
+usertime(KINFO *k, VARENT *ve)
+{
+ VAR *v;
+ long secs;
+ long psecs; /* "parts" of a second. first micro, then centi */
+ char obuff[128];
+ static char decimal_point;
+
+ if (decimal_point == '\0')
+ decimal_point = localeconv()->decimal_point[0];
+ v = ve->var;
+ if (!k->ki_valid) {
+ secs = 0;
+ psecs = 0;
+ } else {
+ secs = k->ki_p->ki_rusage.ru_utime.tv_sec;
+ psecs = k->ki_p->ki_rusage.ru_utime.tv_usec;
+ if (sumrusage) {
+ secs += k->ki_p->ki_childutime.tv_sec;
+ psecs += k->ki_p->ki_childutime.tv_usec;
+ }
+ /*
+ * round and scale to 100's
+ */
+ psecs = (psecs + 5000) / 1;
+ secs += psecs / 100;
+ psecs = psecs % 100;
+ }
+ (void)snprintf(obuff, sizeof(obuff), "%3ld:%02ld%c%02ld",
+ secs / 60, secs % 60, decimal_point, psecs);
+ (void)printf("%*s", v->width, obuff);
+}
+
+void
elapsed(KINFO *k, VARENT *ve)
{
VAR *v;
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: usertime and systime
In the last episode (Mar 16), Kostik Belousov said: > On Wed, Mar 16, 2011 at 12:56:14PM -0500, Dan Nelson wrote: > > In the last episode (Mar 16), Thiago Damas said: > > > Hi, > > > without procfs, there is a way to get usertime and systime from a > > > running process? > > > > Try applying the attached patch to ps. I've had it for a while but > > never submitted a PR. > > > > Heh. I've had it for a very long time. > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html > > Yes, apparently, this is often requested feature. > > I dislike the copying of the existing code, sincere up to the comment that > is not quite relevant (about interrupts in systime). I slightly > reorganized the patch to reduce the copy/paste part of it. > > Do you have comments ? I like it. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Why user time of the process depends on machine load?
In the last episode (Jun 15), Yuri said: > When I test performance of the code, I always observe dependency of CPU > user time on the presence of other CPU intense processes. Same CPU-only > deterministic process that on the quiet machine completes in 220 user > seconds in the presence of, for example, kde rebuild would complete in > 261, 266 or even 379 user seconds. I am talking about times shown by > time(1), not actual an execution time. It's the same time as getrusage(2) > returns in ru_utime field. > > Why time that process takes in user seconds depends on what other > processes are running? > > FreeBSD-8.2 STABLE on i7 CPU @ 9200 @ 2.67GHz. Some possible factors: o Intel Turbo Boost, which raises the clock rate of a single core if the other cores are idle. A single process on an idle system will run faster. o i7 chips have a shared L3 cache across all cores, so a single process on an idle system will tend to have more of its data in cache compared to a system with multiple processes, so it spends less time waiting for slower physical memory lookups. o Process accounting isn't exact. I may be wrong, but I don't think timestamps are taken every time a syscall is invoked and returns. Some time marked as "user" may actually be "system" time, in which case you may be seeing the effect of contention in the kernel as more processes are run. You may be able to disable Turbo Boot in your BIOS, which you can use to determine how much of the single-process speedup is due to that. Unrelated but still interesting note on your particular CPU: http://www.passmark.com/forum/showthread.php?t=2256 -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Default value for UIDs
In the last episode (Jun 28), Chris Rees said: > Hi all, > > [crees@zeus]~% tail -n 2 /usr/ports/UIDs > dbxml:*:949:949::0:0:dbXML user:/nonexistent:/sbin/nologin > nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin > [crees@zeus]~% grep crees /etc/passwd > crees:*:1001:1001:Chris Rees:/home/crees:/bin/tcsh > chris:*:1001:1001:Chris Rees:/home/crees:/bin/tcsh > [crees@zeus]~% > > I'm a little concerned at how close the ports UIDs are getting to the > username space... There are only 216 entries in UIDs, though, so if people are just using "last entry + 1" when adding new ones, they should probably start filling the gaps instead. The 100s and 200s are pretty dense, but 350-399 only has 5 entries, 400-499 has 4, 600-699 has 7, 700-799 has 3, etc. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
In the last episode (Jul 17), Julian H. Stacey said: > Hi all, > ENVIRONMENT: > Standard > gcc version 4.2.1 20070719 [FreeBSD] > that comes with > FreeBSD 7.4-RELEASE > on my 686 host with > CFLAGS += -march=i586 > in > /etc/make.conf > used with > cd /usr/src/bin/who ; make clean ; make cleandir ; make clean ; make > reports > Warning: Object directory not changed from original /usr/src/usr.bin/who > cc -O2 -fno-strict-aliasing -march=i586 -c /usr/src/usr.bin/who/who.c > cc -O2 -fno-strict-aliasing -march=i586-o who who.o > looking with > file who > reports > who: ELF 32-bit LSB executable, Intel 80386, version 1 > (FreeBSD), for FreeBSD 7.4, dynamically linked (uses shared > libs), FreeBSD-style, not stripped > > Problem: > Use it from a 586 7.4-RELEASE host (AMD+NFS) > file /host/sony/usr/src/usr.bin/who/who > /host/sony/usr/src/usr.bin/who/who: ELF 32-bit LSB executable, > Intel 80386, version 1 (FreeBSD), for FreeBSD 7.4, dynamically > linked (uses shared libs), FreeBSD-style, not stripped > /host/sony/usr/src/usr.bin/who/who > fails with > Illegal instruction Were the crt*.o files on your fast machine also compiled with -march=i586 ? If you run gdb on the core file, can you determine what function the bad instruction is in? -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Recommended amount of swap
In the last episode (Sep 05), Sean Hamilton said: > What is the state of the art for the recommended amount of swap in > FreeBSD? Both "normal" systems with 512 MB - 8 GB of RAM, and large > database systems with around 128 - 256 GB. I suggest 2x RAM for systems less than 4gb or so. Anything more than 4GB of swap is probably never going to be used, and if it is used, you're just going to thrash your swap device. If you have 128GB of RAM and need to swap to disk, you desperately need more RAM, not swap :) -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Recommended amount of swap
In the last episode (Sep 05), Eitan Adler said: > On Mon, Sep 5, 2011 at 3:48 PM, Dan Nelson wrote: > > In the last episode (Sep 05), Sean Hamilton said: > >> What is the state of the art for the recommended amount of swap in > >> FreeBSD? Both "normal" systems with 512 MB - 8 GB of RAM, and large > >> database systems with around 128 - 256 GB. > > Keep in mind that you need at least ram = swap to get a coredump. Not if debug.minidump is set to 1, which it is by default. In that case, only mapped memory gets dumped, which should ignore disk cache pages and be a lot smaller than your RAM size. Enabling ZFS may make your dumps bigger unless the minidump code is smart enough to not dump the ARC. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Does anyone use nscd?
In the last episode (Oct 04), Trond Endrestol said: > On Tue, 4 Oct 2011 18:51+0200, Dag-Erling Smorgrav wrote: > > Trond Endrestol writes: > > > It's in daily use at Gjovik Technical College (Fagskolen i Gjovik), > > > here in Norway. Both the mail and web servers authenticates our users > > > by LDAP, and nscd certainly speeds up the lookups. > > > > OK. No trouble with clients dying of SIGPIPE? I could never reproduce > > the bug, but both users who reported problems used ldap, and I don't > > have an LDAP server to test against, so I thought it might be specific > > to LDAP. > > Not in my (somewhat limited) experience. On a tangent, I also heavily recommend using the nss-pam-ldapd port instead of nss_ldap. It includes a daemon called nslcd which is the only process that links to the ldap libary. The nss module is a tiny plug that talks to nslcd using a simple protocol. It really reduces the socket count to your ldap server, and removes the potential namespace problems caused by dlopening libldap.so in every process. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Measuring memory footprint in C/C++ code on FreeBSD
In the last episode (Oct 21), Razmig K said: > Le 21.10.2011 10:44, Peter Jeremy a écrit : > > On 2011-Oct-20 19:57:31 +0200, Razmig K wrote: > > It's not clear whether the program is attempting to determine it's own > > (or a child's) memory footprint, or that of an arbitrary process. In > > the former case, getrusage() is the obvious choice. This as a portable > > interface. > > The program has to determine its own memory footprint. It has no children. > > > If you want to examine arbitrary processes, the best interface on > > FreeBSD would be kvm_getprocs(3). > > > > BTW, since you mention heap objects, I presume you are aware that > > malloc() uses mmap(), rather than sbrk() to obtain memory. > > No I wasn't aware of that. > > In few words, the program needs to obtain and report information > reported by the SIZE column of top, since it is going to be run many > times, and it is impractical to watch top for this purpose. top also uses kvm_getprocs, so you can use that as a template (see the manpage and source at usr/src/usr.bin/top/machine.c). If you call it with the KERN_PROC_PID flag, you can get the stats for a single processs by pid. If you want even more detail, you can look at the source to the procstat command, which uses some other calls to dump the vm map of processes. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value?
In the last episode (Oct 23), Christopher J. Ruwe said:
> I need to get the maximum size of an pwd-entry to determine the correct
> buffersize for calling getpwnam_r("uname",&pwd, buf, bufsize, &pwdp). I
> would like to use sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize,
> which unfornutately fails (returns -1). Currently, I used 16384, which
> seems to be too much, bit works for the time being.
>
> From recent mails I get that _SC_GETPW_R_SIZE_MAX is not available on
> FreeBSD, e.g.,
> http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2009-September/173081.html
> and http://www.redhat.com/archives/libvir-list/2011-May/msg01013.html.
> This assertion seems to be backed by /usr/srclib/libc/gen/sysconf.c, line
> 374.
>
> From Stevens & Rago, Adavanced Programming in the UNIX Environment, I can
> get that FreeBSD supports all possible members in the passwd structure,
> but where can I determine the maximum size of these so that I can
> calculate the ax size of the pwd struct therefrom? Does anybody know or
> know where to look what maximum size a pwd-entry can have?
>
> Knowing the maximum size a pwd structure can have, it seems like to be an
> idea to define the correct value in sysconf.c. As that is not done though
> suggested in the code, are there any obstacles in defining that value so
> nobody has done that so far?
>From looking at the libc/gen/getpwent.c file, it looks like a maximum size
might be 1MB. The wrapper functions that convert getpw*_r functions into
ones that simply return a pointer to malloced data all use the getpw()
helper function, which starts with a 1k buffer and keeps doubling its size
until the data fits or it hits PWD_STORAGE_MAX (1MB). PWD_STORAGE_MAX is
only checked within that getpw() function, though, so it's possible that an
nss library might return an even longer string to a get*_r call. It's up to
you to decide what your own limit is :)
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value?
In the last episode (Oct 24), Christopher J. Ruwe said:
> On Sun, 23 Oct 2011 19:10:34 -0500
> Dan Nelson wrote:
> > In the last episode (Oct 23), Christopher J. Ruwe said:
> > > I need to get the maximum size of an pwd-entry to determine the
> > > correct buffersize for calling getpwnam_r("uname",&pwd, buf, bufsize,
> > > &pwdp). I would like to use sysconf(_SC_GETPW_R_SIZE_MAX) to
> > > determine bufsize, which unfornutately fails (returns -1). Currently,
> > > I used 16384, which seems to be too much, bit works for the time
> > > being.
[..]
> > From looking at the libc/gen/getpwent.c file, it looks like a maximum
> > size might be 1MB. The wrapper functions that convert getpw*_r
> > functions into ones that simply return a pointer to malloced data all
> > use the getpw() helper function, which starts with a 1k buffer and keeps
> > doubling its size until the data fits or it hits PWD_STORAGE_MAX (1MB).
> > PWD_STORAGE_MAX is only checked within that getpw() function, though, so
> > it's possible that an nss library might return an even longer string to
> > a get*_r call. It's up to you to decide what your own limit is :)
>
> Uh ... it's just that I hoped I had not to decide ;-)
>
> However, 1M seems to be rather large to me. Let's see (pwd.h):
>
> 116 struct passwd {
> 117 char*pw_name; /* user name */
> 118 char*pw_passwd; /* encrypted password */
> 119 uid_t pw_uid; /* user uid */
> 120 gid_t pw_gid; /* user gid */
> 121 time_t pw_change; /* password change time */
> 122 char*pw_class; /* user access class */
> 123 char*pw_gecos; /* Honeywell login info */
> 124 char*pw_dir;/* home directory */
> 125 char*pw_shell; /* default shell */
> 126 time_t pw_expire; /* account expiration */
> 127 int pw_fields; /* internal: fields filled in */
> 128 };
>
> So pw_name -> MAXLOGNAME (from param.h) = 17. pw_passwd ->
> http://www.freebsd.org/doc/handbook/one-time-passwords.html = 129. pw_uid
> & pw_gid each sizeof(__uint32_t) ?= 32b. time_t -> sizeof(__int64_t) ?=
> 64b.
>
> At some point, I would just sum it up and reach some size which might be
> machine dependant, but should be somewhere (guessing/estimating now)
> between 4k and 16k. I am short on time just now, am I on the right track
> or am I missing something which should be obvious to someone with
> experience, but is not to me (lacking experience)?
The getpwnam_r function needs enough space to store the "struct passwd"
itself (which has a constant size) plus the strings pointed to by pw_name,
pw_class, pw_gecos, pw_dir, and pw_shell. If you have enough control over
your environment that you can guarantee that the sum of those strings won't
be larger than 4k, then you can just used a fixed buffer of that size. Even
1k is probably large enough for 99.999% of all systems. That's a really
long home directory or shell path :) On the other hand, the GECOS field is
theoretially free-form and could contain a lot of data. I've never see it
hold more than an office number myself, though.
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value?
In the last episode (Oct 25), Christopher J. Ruwe said:
> On Mon, 24 Oct 2011 15:42:10 -0500
> Dan Nelson wrote:
> > In the last episode (Oct 24), Christopher J. Ruwe said:
> > > On Sun, 23 Oct 2011 19:10:34 -0500
> > > Dan Nelson wrote:
> > > > In the last episode (Oct 23), Christopher J. Ruwe said:
> > > > > I need to get the maximum size of an pwd-entry to determine the
> > > > > correct buffersize for calling getpwnam_r("uname",&pwd, buf,
> > > > > bufsize, &pwdp). I would like to use
> > > > > sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize, which
> > > > > unfornutately fails (returns -1). Currently, I used 16384,
> > > > > which seems to be too much, bit works for the time being.
> > [..]
> > > > From looking at the libc/gen/getpwent.c file, it looks like a
> > > > maximum size might be 1MB. The wrapper functions that convert
> > > > getpw*_r functions into ones that simply return a pointer to
> > > > malloced data all use the getpw() helper function, which starts with
> > > > a 1k buffer and keeps doubling its size until the data fits or it
> > > > hits PWD_STORAGE_MAX (1MB). PWD_STORAGE_MAX is only checked within
> > > > that getpw() function, though, so it's possible that an nss library
> > > > might return an even longer string to a get*_r call. It's up to you
> > > > to decide what your own limit is :)
> > >
> > > Uh ... it's just that I hoped I had not to decide ;-)
> >
> > The getpwnam_r function needs enough space to store the "struct passwd"
> > itself (which has a constant size) plus the strings pointed to by
> > pw_name, pw_class, pw_gecos, pw_dir, and pw_shell. If you have enough
> > control over your environment that you can guarantee that the sum of
> > those strings won't be larger than 4k, then you can just used a fixed
> > buffer of that size. Even 1k is probably large enough for 99.999% of
> > all systems. That's a really long home directory or shell path :) On
> > the other hand, the GECOS field is theoretially free-form and could
> > contain a lot of data. I've never see it hold more than an office
> > number myself, though.
> >
>
> Thanks for your help so far. Just assuming (I am not sufficiently clear
> about myself and my own intents) I want to be precise and am afraid of
> guessing: Can I assume that the gecos field is an entry in /etc/passwd and
> can therefore never exceed LINE_MAX, i.e., 2048B (limits.h, line 72)? Or,
> more precisely, ( 2048B - sum( lenght(all fields except passwd) ) )?
> Would that be an acceptable limit to set the getpwnam_r( ... ) buffer to
> and/or would that be an acceptable value to replace the following bit from
> sysconf.c?
>
> 372 #if _POSIX_THREAD_SAFE_FUNCTIONS > -1
> 373 case _SC_GETGR_R_SIZE_MAX:
> 374 case _SC_GETPW_R_SIZE_MAX:
> 375 #error "somebody needs to implement this"
> 376#endif
If your nsswitch.conf has "passwd: files" in it, then yes, you can assume
that the 2048-byte limit applies. However, if you are using nss_ldap,
nss_mysql, nss_winbind, or some other nsswitch module that provides user
info, that backend user system may be capable of returning longer strings.
If you want to be able to handle any struct passwd that might be thrown at
you, you should implement a "retry with doubling" loop similar to the one in
libc/gen/getpwent.c:getpw() .
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: What is going on with ash / sh
In the last episode (Nov 02), Mark Saad said: > Hackers > What is going on here, if I run the following shell script, what is > the expected output . The script is named xxx > > #!/bin/sh > ps -ax | grep -v grep | grep xxx > > Here is what I see > > # sh xxx > 88318 p0 S+ 0:00.00 sh xxx > 88320 p0 R+ 0:00.00 sh xxx > 88321 p0 R+ 0:00.00 sh xxx > > Can someone explain this ? What does your script do? If it contains subshells or pipelines, the main process will fork child processes to handle those. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: What is going on with ash / sh
In the last episode (Nov 02), Dan Nelson said: > In the last episode (Nov 02), Mark Saad said: > > Hackers > > What is going on here, if I run the following shell script, what is > > the expected output . The script is named xxx > > > > #!/bin/sh > > ps -ax | grep -v grep | grep xxx > > > > Here is what I see > > > > # sh xxx > > 88318 p0 S+ 0:00.00 sh xxx > > 88320 p0 R+ 0:00.00 sh xxx > > 88321 p0 R+ 0:00.00 sh xxx > > > > Can someone explain this ? > > What does your script do? If it contains subshells or pipelines, the main > process will fork child processes to handle those. Sorry; I misread your original post. Yes, that script forks off two subshells to handle the pipeline, and the ps command caught the state where the subshells had been created but had not yet exec'ed their grep commands. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [clang] Build error on r232474 (and a few before, don't know exactly which)
In the last episode (Mar 03), Brandon Falk said:
> I'm trying to build r232474 with clang (build environment is 10.0-CURRENT
> r231589 amd64 with clang), and I fail on `make -j16 buildworld`. I've
> tried with and without threads. I've built so many builds of clang that I
> can't even count, so I'm confident my environment is set up properly. I'm
> building under a virtual machine, although I've never had issues with that
> before.
You didn't actually paste an error at all below, but the fact that the
top-level make reported an error from one of the sub-makes. You'll need to
either capture the entire build log and scroll through it from the bottom up
to find the error message, or build without -j16 so the error is at the
bottom of the output.
> error
>
> ===> gnu/usr.bin/texinfo/doc (all)
> makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
> /root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
> /root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi
> -o info.info
> makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
> /root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
> /root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi
> -o info-stnd.info
> ln -fs
> /root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi
> texinfo.texi
> makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
> /root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
> texinfo.texi -o texinfo.info
> gzip -cn info.info> info.info.gz
> gzip -cn info-stnd.info> info-stnd.info.gz
> gzip -cn texinfo.info> texinfo.info.gz
> 1 error
> *** [everything] Error code 2
> 1 error
> *** [buildworld] Error code 2
> 1 error
>
> END error
>
> Make.conf
>
> .if !defined(CC) || ${CC} == "cc"
> CC=clang
> .endif
> .if !defined(CXX) || ${CXX} == "c++"
> CXX=clang++
> .endif
> .if !defined(CPP) || ${CPP} == "cpp"
> CPP=clang-cpp
> .endif
>
> NO_WERROR=
> WERROR=
> NO_FSCHG=
>
> # added by use.perl 2012-03-03 16:12:59
> PERL_VERSION=5.12.4
>
> END Make.conf
>
> -Brandon
>
>
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Regarding core disable in FreeBSD 9
In the last episode (Apr 13), Florian Smeets said: > On 13.04.12 19:34, Alexander Best wrote: > > On Sat Apr 14 12, Mahesh Babu wrote: > >> How to disable a particular core in FreeBSD 9? How to enable it again? > > > > i don't think it's possible to do that in freebsd. what you can do is to > > disable SMP oder hyperthreading. alternatively you can assign a certain > > process to a certain core. > > > > i think there's a project to disable and enable specific cores on the > > fly. freebsd is pretty far behind regarding this feature. beos was > > able to do this anno 1998 or so afair. > > You can set the following in /boot/loader.conf > > hint.lapic.128.disabled=1 > hint.lapic.130.disabled=1 > > Where 128 and 130 are IDs of cores you want to disable, you can find the > IDs for your CPUs/cores in > > dmesg or /var/log/messages e.g. > > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 2 > cpu2 (AP): APIC ID: 4 > cpu3 (AP): APIC ID: 16 > > Enabling and disabling on the fly is not possible. You can't completely disable a core, but you can tell the scheduler not to use it, via the cpuset command. For example, "cpuset -s 1 -l 0,1" will change the mask for cpuset 1 (the default set) to only allow cpus 0 and 1. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
The ideal, long-term solution is to re-think what "The Base" is, and give users more flexibility at install time. Flexibility is double-edged sword. Feel free to replace one resolver with another resolver (but don't do it so often, please). Applications can be patched to fit new API, scripts can be modified to use other command-line utilities. It is OK for me, as long as it is rare big bang. But "right to select one from N resolvers at install time" sounds like way to hell for me. FreeBSD is known to be fast and reliable network server. Resolver is critical component. There should be ONE resolver in the base which is guaranteed to work with all other baseline utilities and script. Also, network related ports should compile against selected base resolver. No problem if someone will replace system's resolver with another one from ports, but such administrator is just on it's own. He must be ready to resolve issues related to compatibility and reliability by self. Can we maintain three (or so) resolvers to be perfectly compatible with all utilities and scripts in the base ? I don't think so. I suspect that port maintainers will not maintain their ports compatible with all "recommended" resolvers as well. I'm definitely not interested to make decisions like ... "if I will select resolver A at install time, then utility X will not work correctly with them - it work with resolver B only, unfortunately, port P can't be compiled against resolver B because it's maintainer is using A only" ... in the future. Just my $0.02 Dan P.S. English is not my native language, so look for ideas, not for grammar. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/08/12 23:55, Doug Barton: On 07/08/2012 07:41, Dan Lukes wrote: ... Sorry, you're not understanding what is being proposed. Specifically you're confusing the system stub resolver (the bit that's compiled into libc, and used by binaries) and the resolving name server (BIND). No one is proposing to replace the stub. libc stub resolver is BIND code based, so I assumed that arguments against BIND apply to it as well. I'm happy it's not true. In my humble opinion, no resolving name server need to be part of base at all. We have no DHCP, VPN, RADIUS, WWW, ... server in the base as well. Thank you for clarifying. Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Consistent use of lex flags
Hi. I was just noticing that mkcsmapper doesn't build with clang. I saw two ways to do this, the first being to #define YY_NO_INPUT, and the other to use the %option noinput lex flag. While there, I decided to explore and I changed a bunch of #defines to the standard lex way of doing things. I thought it would be good if all the code that originated in FreeBSD could be consistent. Thoughts? lex.diff Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
FreeBSD 1.x Binaries Work Except under Chroot
Hello, I'm successfully running FreeBSD 1.1.5.1 binaries from a directory on an 8.2 system. The goal is to ultimately setup a chroot build environment targeting 1.x for an old 386. However, whenever I chroot to the /freebsd-1.1.5.1 directory tree, the old binaries suddenly start failing with linker error messages such as this one: "ld.so: whereis: libc.so.1.1". I've tried to run ldconfig (static old and new versions) on clean copies of /freebsd-1.1.5.1 to correct the problem. Each copy of the tree has libc.so.1.1 under /usr/lib and the full /usr/lib/compat/aout (just in case). Running the old ldconfig with the -v flag against both library directories shows the libraries added and produces a new /var/run/ld.so.hints file. Running that same old ldconfig with -r shows "2:-lc.1.1 => /usr/lib/libc.so.1.1 (9-> -1)" but the binaries still fail in the chroot. The same process with the 8.2 ldconfig (after copying in /libexec/ld-elf.so.1 and /lib/libc.so.7 to make it work) also fails to resolve the problem after creating the aout /var/run/ld.so.hints file for /usr/lib/* and the elf /var/run/ld-elf.so.hints file for /lib. Would anyone have a suggestion please? The setup outside of the chroot works with the 1.x compat libraries combines with a kernel compiled with the compat options and PID_MAX set to 3000. Thank you, Dan Plassche -- Dan Plassche ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD 1.x Binaries Work Except under Chroot
compat.getdirentries 512/0x200 1144 basename CALL compat.getdirentries(0x5,0x20017000,0x400,0x20015154) 1144 basename RET compat.getdirentries 0 1144 basename CALL close(0x5) 1144 basename RET close 0 1144 basename CALL open(0x20015000,O_RDONLY,0x2000f060) 1144 basename NAMI "/usr/X11R6/lib" 1144 basename RET open -1 errno 2 No such file or directory 1144 basename CALL open(0x20015020,O_RDONLY,0x2000f060) 1144 basename NAMI "/usr/X386/lib" 1144 basename RET open -1 errno 2 No such file or directory 1144 basename CALL open(0x20015060,O_RDONLY,0x2000f060) 1144 basename NAMI "/usr/local/lib" 1144 basename RET open 5 1144 basename CALL fcntl(0x5,F_SETFD,FD_CLOEXEC) 1144 basename RET fcntl 0 1144 basename CALL compat.getdirentries(0x5,0x20017000,0x400,0x20015154) 1144 basename RET compat.getdirentries 512/0x200 1144 basename CALL compat.getdirentries(0x5,0x20017000,0x400,0x20015154) 1144 basename RET compat.getdirentries 0 1144 basename CALL close(0x5) 1144 basename RET close 0 1144 basename CALL open(0x20015160,O_RDONLY,0) 1144 basename NAMI "/usr/lib/libc.so.1.1" 1144 basename RET open 5 1144 basename CALL read(0x5,0xbfbfed40,0x20) 1144 basename GIO fd 5 read 32 bytes 0x cc00 8680 0070 0400 0060 b86b |.p...`...k..| 0x0010 b4b7 2000 | ...| 1144 basename RET read 32/0x20 1144 basename CALL compat.mmap(0,0x4d000,0x5,0x21,0x5,0) 1144 basename RET compat.mmap 536993792/0x2001e000 1144 basename CALL mprotect(0x20065000,0x6000,PROT_READ|PROT_WRITE|PROT_EXEC) 1144 basename RET mprotect 0 1144 basename CALL close(0x5) 1144 basename RET close 0 1144 basename CALL compat.mmap(0x2006b000,0x6bb8,0x7,0x122,0x,0x4d000) 1144 basename RET compat.mmap -1 errno 22 Invalid argument 1144 basename CALL write(0x2,0xbfbfe5fc,0x7) 1144 basename GIO fd 2 wrote 7 bytes "ld.so: " 1144 basename RET write 7 1144 basename CALL write(0x2,0xbfbfe614,0x15) 1144 basename GIO fd 2 wrote 21 bytes "basename: libc.so.1.1" 1144 basename RET write 21/0x15 1144 basename CALL write(0x2,0xbfbfe5f4,0x2) 1144 basename GIO fd 2 wrote 2 bytes ": " 1144 basename RET write 2 1144 basename CALL write(0x2,0xbfbfe5f8,0x11) 1144 basename GIO fd 2 wrote 17 bytes "Invalid argument " 1144 basename RET write 17/0x11 1144 basename CALL exit(0x1) The sources are available from the FreeBSD old releases archive now that they are under the "Ancient UNIX" license, but yeah there's no CVS history for change tracking due to the purge with the switch to 4.4 Lite. Thanks, Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD 1.x Binaries Work Except under Chroot
Konstantin, My apologies for any confusion. Your patch solved the problem on 8.2. Static and dynamic a.out binaries from 1.1.5.1 are working normally in a chroot environment now. On Sat, Aug 11, 2012 at 2:45 PM, Konstantin Belousov wrote: > Why did you stripped the public list from the Cc: ? I must have clicked on reply instead of reply all by accident. I sent a copy to the list about 10 minutes after replying to you, when I realized the mistake. > You should have mentioned that it is only _some_ binaries which are > affected, since I was not able to reproduce your issue at all with > /bin/sh or /bin/ls in chroot. It took me a while to realize that you > specifically shown the trace for basename. Sorry, I was focusing on the loader problem and left out the root binaries because they were traditionally static. Thanks for your help, Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD 1.x Binaries Work Except under Chroot
On Mon, Aug 13, 2012 at 9:28 PM, Julian Elischer wrote: > you will also have to change PID_MAX (spelling?) to be 6 > I have considered making this a tunable.. > If you don't then the shell in the 1.1.5.1 environment will not be able to > handle when a child > get s a pid of > 16 bits and it will not be able to wait on it. so it will > suspend for ever. > teh result is that you can not complete a "make world". The shell hangs as you described on "make world" when the PID hits 32768. Looks like this was the old limit and things changed around release 3. I went to recompile the kernel with "define PID_MAX 3" in /usr/src/sys/sys/proc.h and got a new build error that I'm still trying to resolve: In file included from /usr/src/sys/sys/buf.h:258, from /usr/src/sys/i386/i386/genassym.c:47: /usr/src/sys/sys/proc.h:670: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PID_MAX' /usr/src/sys/sys/proc.h:769: warning data definition has no type or storage class /usr/src/sys/sys/proc.h:769: warning: type defaults to 'int' in declaration of 'pidhashtbl' *** Error code 1 Line 670 in proc.h is the define PID_MAX line. I have the feeling I may be missing something obvious here, but I haven't been able to sort out the problem. Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD 1.x Binaries Work Except under Chroot
On Thu, Aug 16, 2012 at 9:06 AM, Konstantin Belousov wrote: > Since you did not provided exact diff of your change, I cannot comment > on what goes wrong. Anyway, just merge the r239301 locally and use > sysctl kern.pid_max. Thanks, the kern.pid_max tunable works well on 8.2. The diff to /usr/src/sys/sys/proc.h before merging in r239301 was editing PID_MAX: --- proc.h.bak 2010-12-21 12:09:25.0 -0500 +++ proc.h 2012-08-15 13:54:25.0 -0400 @@ -667,7 +667,7 @@ * We use process IDs <= PID_MAX; PID_MAX + 1 must also fit in a pid_t, * as it is used to represent "no process group". */ -#define PID_MAX 9 +define PID_MAX3 #define NO_PID 10 #define SESS_LEADER(p) ((p)->p_session->s_leader == (p)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Build 32 bit binaries on amd64
Hi.
I've been working on porting compiler-rt/clang's support for address
sanitization (asan) to FreeBSD. So far I have it building and it
appears to work properly, however the build system expects to be able
to build 32 bit binaries on amd64.
amd64 doesn't include i386's machine/foo headers. The included patch
is my proposed solution:
Add i386 headers to /usr/include/i386, and in machine/foo.h, check if
it's a 32 bit build and include the appropriate header from i386.
For example machine/ucontext.h will include i386/ucontext.h if
compiled with -m32.
Thoughts?
If anyone's curious about the compiler_rt port, I have it at
github.com/dannomac/compiler-rt on the branch named freebsd.
Dan
diff --git a/include/Makefile b/include/Makefile
index d2f6d7f..8e29a35 100644
--- a/include/Makefile
+++ b/include/Makefile
@@ -125,6 +125,9 @@ _MARCHS= ${MACHINE_CPUARCH}
.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
_MARCHS+= x86
.endif
+.if ${MACHINE_CPUARCH} == "amd64"
+_MARCHS+= i386
+.endif
.include
diff --git a/sys/amd64/include/acpica_machdep.h b/sys/amd64/include/acpica_machdep.h
index 9943af7..393cd2b 100644
--- a/sys/amd64/include/acpica_machdep.h
+++ b/sys/amd64/include/acpica_machdep.h
@@ -33,6 +33,12 @@
*
*/
+#ifdef __i386__
+
+#include
+
+#else /* __i386__ */
+
#ifndef __ACPICA_MACHDEP_H__
#define __ACPICA_MACHDEP_H__
@@ -82,3 +88,5 @@ void acpi_unmap_table(void *table);
vm_paddr_t acpi_find_table(const char *sig);
#endif /* __ACPICA_MACHDEP_H__ */
+
+#endif /* __i386__ */
diff --git a/sys/amd64/include/apicvar.h b/sys/amd64/include/apicvar.h
index ae2f5b9..3369fa1 100644
--- a/sys/amd64/include/apicvar.h
+++ b/sys/amd64/include/apicvar.h
@@ -29,8 +29,10 @@
* $FreeBSD$
*/
-#ifndef _MACHINE_APICVAR_H_
-#define _MACHINE_APICVAR_H_
+#ifndef _AMD64_APICVAR_H_
+#define _AMD64_APICVAR_H_
+
+#ifdef __x86_64__
#include
@@ -229,4 +231,10 @@ void lapic_set_tpr(u_int vector);
void lapic_setup(int boot);
#endif /* !LOCORE */
-#endif /* _MACHINE_APICVAR_H_ */
+
+#else /* __x86_64__ */
+
+#include
+
+#endif /* __x86_64__ */
+#endif /* _AMD64_APICVAR_H_ */
diff --git a/sys/amd64/include/asm.h b/sys/amd64/include/asm.h
index 7efd642..b1dd8ba 100644
--- a/sys/amd64/include/asm.h
+++ b/sys/amd64/include/asm.h
@@ -33,8 +33,10 @@
* $FreeBSD$
*/
-#ifndef _MACHINE_ASM_H_
-#define _MACHINE_ASM_H_
+#ifndef _AMD64_ASM_H_
+#define _AMD64_ASM_H_
+
+#ifdef __x86_64__
#include
@@ -88,4 +90,9 @@
#define __FBSDID(s) /* nothing */
#endif /* not lint and not STRIP_FBSDID */
-#endif /* !_MACHINE_ASM_H_ */
+#else /* __x86_64__ */
+
+#include
+
+#endif /* __x86_64__ */
+#endif /* !_AMD64_ASM_H_ */
diff --git a/sys/amd64/include/asmacros.h b/sys/amd64/include/asmacros.h
index 1fb592a..385e16e 100644
--- a/sys/amd64/include/asmacros.h
+++ b/sys/amd64/include/asmacros.h
@@ -29,8 +29,10 @@
* $FreeBSD$
*/
-#ifndef _MACHINE_ASMACROS_H_
-#define _MACHINE_ASMACROS_H_
+#ifndef _AMD64_ASMACROS_H_
+#define _AMD64_ASMACROS_H_
+
+#ifdef __x86_64__
#include
@@ -201,4 +203,9 @@
#endif /* LOCORE */
-#endif /* !_MACHINE_ASMACROS_H_ */
+#else
+
+#include
+
+#endif /* __x86_64__ */
+#endif /* !_AMD64_ASMACROS_H_ */
diff --git a/sys/amd64/include/atomic.h b/sys/amd64/include/atomic.h
index 99a94b7..31fd8ee 100644
--- a/sys/amd64/include/atomic.h
+++ b/sys/amd64/include/atomic.h
@@ -25,8 +25,10 @@
*
* $FreeBSD$
*/
-#ifndef _MACHINE_ATOMIC_H_
-#define _MACHINE_ATOMIC_H_
+#ifndef _AMD64_ATOMIC_H_
+#define _AMD64_ATOMIC_H_
+
+#ifdef __x86_64__
#ifndef _SYS_CDEFS_H_
#error this file needs sys/cdefs.h as a prerequisite
@@ -480,4 +482,9 @@ u_long atomic_readandclear_long(volatile u_long *addr);
#endif /* !WANT_FUNCTIONS */
-#endif /* !_MACHINE_ATOMIC_H_ */
+#else /* __x86_64__ */
+
+#include
+
+#endif /* __x86_64__ */
+#endif /* !_AMD64_ATOMIC_H_ */
diff --git a/sys/amd64/include/clock.h b/sys/amd64/include/clock.h
index d2602d8..9f0db6e 100644
--- a/sys/amd64/include/clock.h
+++ b/sys/amd64/include/clock.h
@@ -6,8 +6,10 @@
* $FreeBSD$
*/
-#ifndef _MACHINE_CLOCK_H_
-#define _MACHINE_CLOCK_H_
+#ifndef _AMD64_CLOCK_H_
+#define _AMD64_CLOCK_H_
+
+#ifdef __x86_64__
#ifdef _KERNEL
/*
@@ -37,4 +39,9 @@ void timer_spkr_setfreq(int freq);
#endif /* _KERNEL */
-#endif /* !_MACHINE_CLOCK_H_ */
+#else /* __x86_64__ */
+
+#include
+
+#endif /* __x86_64__ */
+#endif /* !_AMD64_CLOCK_H_ */
diff --git a/sys/amd64/include/cpu.h b/sys/amd64/include/cpu.h
index 1c2871f..0cfcb03 100644
--- a/sys/amd64/include/cpu.h
+++ b/sys/amd64/include/cpu.h
@@ -33,8 +33,10 @@
* $FreeBSD$
*/
-#ifndef _MACHINE_CPU_H_
-#define _MACHINE_CPU_H_
+#ifndef _AMD64_CPU_H_
+#define _AMD64_CPU_H_
+
+#ifdef __x86_64__
/*
* Definitions unique to i386 cpu support.
@@ -75,4 +77,9 @@ get_cyclecount(void)
#endif
-#endif /* !_MACH
Re: Build 32 bit binaries on amd64
My solution is certainly fairly hacky, I just took inspiration from NetBSD. I wanted to see if it could be done. While I was there I did identify several files that should be common between i386 and amd64, such as exec.h. Since reading your email I started looking at the x86 common code, and have made some more code common; specifically asm.h ans ucontext.h. I'll be putting that on github shortly. Since it does look like tijl hasn't committed anything since March, I would like to co-operate and see what his plans were. The idea of merging the i386 and amd64 headers into a common area seems like a better idea to me. Dan On 21 August 2012 02:49, Konstantin Belousov wrote: > On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: >> Hi. >> >> I've been working on porting compiler-rt/clang's support for address >> sanitization (asan) to FreeBSD. So far I have it building and it >> appears to work properly, however the build system expects to be able >> to build 32 bit binaries on amd64. >> >> amd64 doesn't include i386's machine/foo headers. The included patch >> is my proposed solution: >> >> Add i386 headers to /usr/include/i386, and in machine/foo.h, check if >> it's a 32 bit build and include the appropriate header from i386. >> >> For example machine/ucontext.h will include i386/ucontext.h if >> compiled with -m32. >> >> Thoughts? >> >> If anyone's curious about the compiler_rt port, I have it at >> github.com/dannomac/compiler-rt on the branch named freebsd. > > There was a work by Tijl Coosemans in the similar, but somewhat less hacky > direction. The headers are moved into sys/x86/include and unified as much > as possible, while machine/ counterpart includes corresponding header > from x86/include. > > I even lost track of how much more headers is left to convert. In fact, > not all headers are equal, some are only useful for kernel or base system. > Also, parts of the critically important headers do not live in machine/ > at all, e.g. the headers from libm. > > The work seems to be stale, do you want to cooperate with Tijl or continue ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Build 32 bit binaries on amd64
I think I agree now. The more code shared between archtectures the better. I've committed some patches to my github freebsd fork that merge exec.h, asm.h and ucontex.h into x86. I'll probably do more later tonight. On 21 August 2012 07:44, John Baldwin wrote: > On Tuesday, August 21, 2012 4:49:30 am Konstantin Belousov wrote: >> On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: >> > Hi. >> > >> > I've been working on porting compiler-rt/clang's support for address >> > sanitization (asan) to FreeBSD. So far I have it building and it >> > appears to work properly, however the build system expects to be able >> > to build 32 bit binaries on amd64. >> > >> > amd64 doesn't include i386's machine/foo headers. The included patch >> > is my proposed solution: >> > >> > Add i386 headers to /usr/include/i386, and in machine/foo.h, check if >> > it's a 32 bit build and include the appropriate header from i386. >> > >> > For example machine/ucontext.h will include i386/ucontext.h if >> > compiled with -m32. >> > >> > Thoughts? >> > >> > If anyone's curious about the compiler_rt port, I have it at >> > github.com/dannomac/compiler-rt on the branch named freebsd. >> >> There was a work by Tijl Coosemans in the similar, but somewhat less hacky >> direction. The headers are moved into sys/x86/include and unified as much >> as possible, while machine/ counterpart includes corresponding header >> from x86/include. >> >> I even lost track of how much more headers is left to convert. In fact, >> not all headers are equal, some are only useful for kernel or base system. >> Also, parts of the critically important headers do not live in machine/ >> at all, e.g. the headers from libm. >> >> The work seems to be stale, do you want to cooperate with Tijl or continue ? > > I think we should probably follow Tijl's model since we are on that path. > I originally preferred the /usr/include/i386 approach, but have come around > to Tjil's approach instead. > > -- > John Baldwin > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Build 32 bit binaries on amd64
How do the unified powerpc headers work? Is it just one architecture for both PowerPC and 64 bit PowerPC? If so, was that tijl's ultimate goal? One architecture for i386 and AMD64? On the unifying headers front, I've make a bunch of progress towards merging i386 and amd64 headers into x86; also available on github. Dan On 21 August 2012 10:34, Nathan Whitehorn wrote: > On 08/21/12 08:44, John Baldwin wrote: >> >> On Tuesday, August 21, 2012 4:49:30 am Konstantin Belousov wrote: >>> >>> On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: >>>> >>>> Hi. >>>> >>>> I've been working on porting compiler-rt/clang's support for address >>>> sanitization (asan) to FreeBSD. So far I have it building and it >>>> appears to work properly, however the build system expects to be able >>>> to build 32 bit binaries on amd64. >>>> >>>> amd64 doesn't include i386's machine/foo headers. The included patch >>>> is my proposed solution: >>>> >>>> Add i386 headers to /usr/include/i386, and in machine/foo.h, check if >>>> it's a 32 bit build and include the appropriate header from i386. >>>> >>>> For example machine/ucontext.h will include i386/ucontext.h if >>>> compiled with -m32. >>>> >>>> Thoughts? >>>> >>>> If anyone's curious about the compiler_rt port, I have it at >>>> github.com/dannomac/compiler-rt on the branch named freebsd. >>> >>> There was a work by Tijl Coosemans in the similar, but somewhat less >>> hacky >>> direction. The headers are moved into sys/x86/include and unified as much >>> as possible, while machine/ counterpart includes corresponding header >>> from x86/include. >>> >>> I even lost track of how much more headers is left to convert. In fact, >>> not all headers are equal, some are only useful for kernel or base >>> system. >>> Also, parts of the critically important headers do not live in machine/ >>> at all, e.g. the headers from libm. >>> >>> The work seems to be stale, do you want to cooperate with Tijl or >>> continue ? >> >> I think we should probably follow Tijl's model since we are on that path. >> I originally preferred the /usr/include/i386 approach, but have come >> around >> to Tjil's approach instead. >> > > I just wanted to add that the unified 32/64 header route is where we went on > PowerPC (and MIPS?) and it works very well for -m32. > -Nathan > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Build 32 bit binaries on amd64
On 22 August 2012 14:09, Tijl Coosemans wrote: > On 21-08-2012 17:04, Dan McGregor wrote: >> My solution is certainly fairly hacky, I just took inspiration from >> NetBSD. I wanted to see if it could be done. While I was there I did >> identify several files that should be common between i386 and amd64, >> such as exec.h. >> >> Since reading your email I started looking at the x86 common code, >> and have made some more code common; specifically asm.h ans >> ucontext.h. I'll be putting that on github shortly. >> >> Since it does look like tijl hasn't committed anything since March, >> I would like to co-operate and see what his plans were. The idea of >> merging the i386 and amd64 headers into a common area seems like a >> better idea to me. > > For now my goal was to merge headers that can be used by user code so > it can be compiled with -m32. Eventually, I think it would be nice to > merge all headers and install x86/ as machine/ for both i386 and amd64. > That would make the x86 headers similar to powerpc and mips headers > (and arm when 64bit support is added there). > > I think I still have one or two (untested) patches. I'll have a look at > it during the weekend. > That sounds very handy. I didn't know where you got to, so I've been plugging away at the same goal for the last couple of days. Is there anything specific I could help you with? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Build 32 bit binaries on amd64
I can't speak for Tijl, but being able to build anything simply by passing -m32 to the compiler is my goal. Did your Intel EFI work involve #defining _KERNEL anywhere? On 22 August 2012 16:04, Eric McCorkle wrote: > I ran into some bugs compiling things with -m32 in the intel EFI work. As > things stand now, there's a lot more involved in setting up a 32 bit build > environment. I'm not sure if it's possible to reduce this down to passing > -m32 to the compiler, though it would certainly be nice. > > Sent from my iPhone > > On Aug 22, 2012, at 4:09 PM, Tijl Coosemans wrote: > >> On 21-08-2012 17:04, Dan McGregor wrote: >>> My solution is certainly fairly hacky, I just took inspiration from >>> NetBSD. I wanted to see if it could be done. While I was there I did >>> identify several files that should be common between i386 and amd64, >>> such as exec.h. >>> >>> Since reading your email I started looking at the x86 common code, >>> and have made some more code common; specifically asm.h ans >>> ucontext.h. I'll be putting that on github shortly. >>> >>> Since it does look like tijl hasn't committed anything since March, >>> I would like to co-operate and see what his plans were. The idea of >>> merging the i386 and amd64 headers into a common area seems like a >>> better idea to me. >> >> For now my goal was to merge headers that can be used by user code so >> it can be compiled with -m32. Eventually, I think it would be nice to >> merge all headers and install x86/ as machine/ for both i386 and amd64. >> That would make the x86 headers similar to powerpc and mips headers >> (and arm when 64bit support is added there). >> >> I think I still have one or two (untested) patches. I'll have a look at >> it during the weekend. >> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
In the last episode (Oct 31), Karl Pielorz said: > --On 31 October 2012 16:06 +0200 Konstantin Belousov > wrote: > > Since you neglected to provide the verbatim output of procstat, nothing > > conclusive can be said. Obviously, you can make an investigation on > > your own. > > Sorry - when I ran it this morning the output was several hundred lines - > I didn't want to post all of that to the list 99% of the lines are very > similar. I can email it you off-list if having the whole lot will help? > > >> Then there's a bunch of 'large' blocks e.g.. > >> > >> PID STARTEND PRT RES PRES REF SHD FL TP > >> PATH 20100x801c00x80280 rw- 28690 4 0 > >> df 20100x802800x80340 rw- 18800 1 0 > > > > Most likely, these are malloc arenas. > > Ok, that's the heaviest usage. > > >> Then lots of 'little' blocks, > >> > >> 2010 0x70161000 0x70181000 rw- 160 1 0 ---D df > > > > And those are thread stacks. > > Ok, lots of those (lots of threads going on) - but they're all pretty > small. > > My code only has a single call to malloc, which allocates around 20k per > thread. > > Obviously there's other libraries and stuff running with the code - so > would I be correct in guessing that they are more than likely for most of > these large blocks? Note that libmilter may do a lot of mallocs on its own, especially if you are examining the message body. There are also jemalloc tuning options that may lower total meory usage if you are using a lot of threads. I'd take a look at the G and R flags first. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: lib for working with graphs
In the last episode (Nov 28), Andriy Gapon said: > on 28/11/2012 16:31 David Wolfskill said the following: > > On Wed, Nov 28, 2012 at 04:20:28PM +0200, Andriy Gapon wrote: > >> > >> Does anyone know a light-weight BSD-licensed (or analogous) library / > >> piece of code for doing useful things with graphs? Thank you. > >> > > > > Errr "graphs" is fairly ambiguous, and "things with graphs" covers a > > very wide range of activities. > > Graphs as in vertices, edges, etc :) And things like graph basics: BFS, > DFS, connected components, topological sort, etc Graphviz would be the most popular package for stuff like this, I think, and it includes a C API. It's licensed under the Eclipse Public License. http://www.graphviz.org/ http://www.graphviz.org/Gallery.php http://www.graphviz.org/doc/libguide/libguide.pdf -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Some improvements to rm(1)
On Thu, Apr 25, 2013 at 9:50 PM, Brooks Davis wrote: > I think the -x option seems a bit odd. What is the use case? At a > first thought, it seems to raise more questions than it resolves. > I was cleaning up a system a year ago and I had an "rm -rf" traverse into a production NFS mountpoint.. oops. I only realized it when it was taking longer than I expected so I stopped it to investigate. Had to restore a bunch of data from backups. Thank you for proposing the patch, I hope it gets committed. Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /bin/sh => STDIN & functions, var scope messing
In the last episode (May 31), Reid Linnemann said: > On Fri, May 31, 2013 at 1:12 PM, Teske, Devin > wrote: > > If you're arguing we have to change sh's behavior to be more compliant, > > jilles already quoted XCU 2.12 (our shell is well within its right to > > run any/all lvalue/rvalue operands of a pipe in a sub-shell without > > contradicting the guidelines). > > > > But if you're arguing that it has to change to make things better or > > easier... I don't know about that. Might just make people lulled into > > using a style that's non-portable. I'd like to keep things the way they > > are so that if you program for FreeBSD, you're inherently going to > > program in a fashion that is more portable. > > FWIW bash (invoked as sh) on RHEL-based linux systems exhibits the same > behavior- > > sh-3.2$ var=1 > sh-3.2$ yes|var=2 > sh-3.2$ echo $var > 1 > sh-3.2$ > > If my opinion matters at all, I would agree that for the sake of > portability that behavior be consistent with the majority of sh > implementations rather than "right" according to arbitrary ruling. On the other hand, zsh runs the last component of a pipeline in the parent shell. The usual model is "do work in pipeline, process results in final component", and being able to simply set variables there that can be used in the rest of the script is very elegant. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS based /usr prevents normal startup due to slow net init
In the last episode (Mar 02), Steven Hartland said: > Another observation from my recent dealings with using > NFS based /usr is that the remote critical mounts via > nfs dont always give the network enough time to > initialise before running. The first error displayed > is: > Mounting NFS file systems:mount_nfs: nfs1: hostname nor servname provided, > or not known > > This is particularly noticeable when the machine is > connected to Cisco equipment as they take quite a > while link to the connected host after initialisation. That can usually be fixed by making sure you have portfast enabled on the Cisco for any non-switch ports, btw. Takes the port setup time down from 30 seconds to under 5. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with test(1)
In the last episode (Apr 05), Joe Marcus Clarke said: > I noticed something weird with test(1) when I ran across a problem port > Makefile. Our test(1) doesn't properly check to make sure there is an > operand argument to unary operators like -f. For example: > > test -f > > Will print "TRUE" on FreeBSD. On Solaris, it will die: > > /usr/bin/test[8]: test: argument expected > > I think this patch is correct in that it does fix the problem, and the > TEST.sh and TEST.csh regression scripts report the same results pre and > post-patch. Comments? If you follow POSIX's description of test, FreeBSD's current behaviour is valid and Solaris isn't: http://www.opengroup.org/onlinepubs/009695399/utilities/test.html The algorithm for determining the precedence of the operators and the return value that shall be generated is based on the number of arguments presented to test. (However, when using the "[...]" form, the right-bracket final argument shall not be counted in this algorithm.) In the following list, $1, $2, $3, and $4 represent the arguments presented to test: 0 arguments: Exit false (1). 1 argument: Exit true (0) if $1 is not null; otherwise, exit false. ... Unary operators shouldn't get parsed as such unless there are two arguments. > http://www.marcuscom.com/downloads/test.c.diff -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Discovering list of open files from "kernel level" without using utils like lsof
In the last episode (Apr 08), Garrett Cooper said: > I'm trying to see whether it's possible to grab the list of > files open from a kernel level on FreeBSD, using a userland library > interface as opposed to lsof. > I'm trying to see if there's a simple tool that I could code in > C/C++ if necessary to spin down disks automatically to save power and > disk life. Plus, I think that lsof actually would probe the devices > and 'wake them up' instead of keeping them as-is. However, I could be > wrong so if I am please let me know. Take a look at how /usr/bin/fstat does it. There is apparently a "kern.file" sysctl that holds the open file table, but fstat digs through kernel memory. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: More questions about BDB
In the last episode (May 20), Sean Bryant said: > Just a personal curiosity. Is there a particular reason why FreeBSD > is holding on to BDB 1.85? All later versions have a non-BSD license (a source redistribution requirement was added), which means it can't go in the base system. BDB is built into libc and is used for the hashed passwd & termcap databases. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PAM exec patch to allow PAM_AUTHTOK to be exported.
Zane C.B. napsal/wrote, On 05/21/07 04:33: In advance, you need catch not only pam_sm_session_open but pam_sm_session_close (i assume you plan to umount resource also). Unfortunately (unless I miss something) pam_exec has no way to pass about 'direction' to called program. You can't use simple heuristic "when not mounted mount it and vice versa" also because the same user can have more than one simultaneous active session. True. That would be another issue. Regardless, it is going to need a daemon to run in the background or something. In the fact, you are in trouble because the OS doesn't know "user session" so it didn't help you to maintain the information. User session is PAM category. You are true - you need a system-wide persistent object that hold information "a session for user X remain active". You can create a daemon, you can create a file in the filesystem or so. But it's not solution of your main problem - where to catch information the session start/ends. At the first, you have with session start whenever PAM not used for authentication. It's not only telnetd which doesn't use PAM at all. There are many daemons that can start user-scripts but not as part of (PAM) user session. For example CRON, SENDMAIL (when "| script.sh" used in .forward) and so on. Even worse is catching of session-end. At the first, it's application responsibility to call PAM's session close and the close may not be called in some cases of abnormal end. Even if we ignore those abnormal cases, regular exit of the application authenticating the user into system constitute end of PAM's session, but it doesn't mean that no user proces is running in the system. There are may be tenths of proceses started during session that run in the background, detached from terminal and owned by INIT as parent process. To make things more complicated, a process can have more than one effective user during lifetime. If euid chages - are you ready to remap directories accordingly ? I don't think using PAM to figure out if it should be unmounted is a good idea In the fact, I don't thing the PAM is good place to figure out the directory needs to be mounted as well. PAM may be the place where you can stealth the user name and password an store it somewhere for later use. You can create kernel module monitoring process creation and EUID changes. It can map/unmap user's directories. Unfortunately, you need secure persistent storage of every user name and password (user processes may be started shortly after the start of system - before the user log-in first time, so in-memory only storage is not sufficient). By the way, we still speak about "name+password" authentication only. Your system can't work when user authenticate itself by other system (digital signature, OTP, challenge-response, magnetic or chip card, a biometric based authentication and so on). If your system allow access via ssh and a user will use authentication wia key, then you have no way to do what you want automagicaly. Even if we forget other authentication system than "name+pwd", persistent password database is security risk. Persistent storage of user credentials without it's approval may have law consequences also. If we speak about proprietary solutions (for your only) it may not be problem. If we speak about "standard distribution solution" we can't forged about it. unless you kill all processes owned by that user upon session close. Insufficient. Process with effective rights as a user can be started later, not as a part of a session. You need global knowledge about all processes and their efective UIDs. IMO it would be best to check if there are any processes running owned by that user before unmounting it and if there are, leave it for the cleanup daemon. "Cleanup daemon" is "end-session" solution. Not "start-session". You need kernel module for "is a process runing for a user" tracking. PAM may help with creating persistent system password database used by this module for real mounting. Or you can reevaluate what you want. If you need "automagic mouting" avaiable during interactive user sessions only then things become simpler. Yup. Moving to hackers. :) I'm not a member. Dan -- Dan Lukes SISAL MFF UK AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nss_ldap without nscd or cached ?
In the last episode (May 24), Mohacsi Janos said: > I think there is a some architectural issues with the current > implementation of nsswitch or nsdispatch(3). Let's assume you want > to authenticate against an LDAP database. You will install nss_ldap > from port. You configure nss_ldap.conf with binddn and its bindpw. > Here comes the problem: > > 1. If permission of nss_ldap.conf is 0400 since it contains the > clear text password of the binddn, then an ordinary user cannot bind > to the database and cannot get UID->name information from LDAP > database. See output: > > [EMAIL PROTECTED]> ls -l /home > total 6 > drwxr-xr-x 3 9027 wheel 512 May 23 17:57 user1 > drwxrwxr-x 3 root 9030 512 May 23 15:14 documents > drwxr-xr-x 2 9013 9013 512 May 23 15:13 user2 > You should be able to grant the anonymous user read access to user/group names and group membership attributes. That way you can do simple things like name->uid lookups without having to bind at all. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using userland library in Kernel
In the last episode (Aug 08), Biks N said: > I am new to FreeBSD kernel programming and I am trying to use > userland library (zlib) in FreeBSD kernel. But I am not sure if zlib > library is linkable from the kernel. It isn't. However, there is a zlib implementation in the kernel already. It's hidden under the PPP_DEFLATE kernel option (the source is in sys/net/ppp_deflate.c). The functions are all prefixed with z_, but apart from that it works the same as userland zlib. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] newsyslog - archive logs with a timestamp
On Sun, Aug 12, 2007 at 02:24:20PM +0200, Ulrich Spoerlein wrote: > I'd rather see an extension for newsyslog which would rotate foo to > foo.2007-08-12.gz, iff rotation is done every day at midnight. Sorry to hijack the thread, but this is something that I've been looking for for a long time as well. There's even a patch that's been sitting in purgatory since 2001. http://www.freebsd.org/cgi/query-pr.cgi?pr=30654&cat= Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory pool, rfc
In the last episode (Nov 01), Eduardo Morras said: > I have some free time and want to do an memory pool. The idea is to > have a memory zone of N KB (or several MB) compressed in memory. I > have fast compression algorithms now that can release under BSD > licence that are faster than hd i/o, so it take less > compress/decompress a memory zone than read/write it to disk. I don't > know if it already exist for FreeBSD, so if it's already done i'll > try to improve it. [...] > For what can be used? > > - Memory pools in applications (like malloc) > - Ram disks > - Disk Cache (permit bigger disk cache) > - 'On the fly' filesystem compression (and it takes less read/write > compressed data than non-compressed) zfs already has modular compression algorithms; it would be rather easy to add a mozule for your method and compare it to the existing gzip and lzjb algorithms. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some FreeBSD performance Issues
In the last episode (Nov 08), Randall Hyde said: > It appears that character-at-a-time file I/O is *exceptionally* slow. > Yes, I realize that when processing large files I really ought to be > doing block/buffered I/O to get the best performance, but for certain > library routines I've written it's been far more convenient to do > character-at-a-time I/O rather than deal with all the buffering > issues. In the past, while slower, this character-at-a-time paradigm > has provided reasonable, though not stellar, performance under > Windows and Linux. However, with the port to FreeBSD I'm seeing a > three-orders-of-magnitude performance loss. Here's my little test > program: [...] > The "fileio.open" call is basically a bsd.open( "socket.h", bsd.O_RDONLY ); > API call. The socket.h file is about 19K long (it's from the FreeBSD > include file set). In particular, I would draw your attention to the first > two tests that do character-at-a-time I/O. The difference in performance What timings does "dd if=/usr/include/sys/socket.h of=/dev/null ibs=1 obs=64k" report? It takes about .4 sec on my non-idle dual pIII-900 system. Try truss'ing your program as it runs; maybe the program is doing some extra syscalls you aren't aware of? -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: select
In the last episode (Jan 03), Metin KAYA said: > Hi all, > > How select(2) will behave if I give the "utimeout" parameter as > NULL? >From the man page: If timeout is a null pointer, the select blocks indefinitely. http://www.freebsd.org/cgi/man.cgi?query=select -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A (perhaps silly) kqueue question
In the last episode (Mar 14), Vlad GALU said:
> On 3/14/08, Vlad GALU <[EMAIL PROTECTED]> wrote:
> > On 3/8/08, Vlad GALU <[EMAIL PROTECTED]> wrote:
> > > On 3/8/08, Robert Watson <[EMAIL PROTECTED]> wrote:
> > > > On Fri, 7 Mar 2008, Vlad GALU wrote:
> > > > > I see an unusual symptom with one of our in-house
> > > > > applications. The main I/O loop calls kevent(), which in turn
> > > > > returns two events with EV_EOF error set, always for the same
> > > > > descriptors (they're both socket descriptors). As the man
> > > > > page is not pretty clear about it and I don't have my UNP
> > > > > copy at hand, I would like to ask the list whether the error
> > > > > events are supposed to be one-shot or not.
> > > >
> > > > I wonder if it's returning one event for the read socket
> > > > buffer, and one event for the write socket buffer, since there
> > > > are really two event sources for each socket? Not that this
> > > > is desirable behavior, but it might explain it. If you
> > > > shutdown() only read, do you get back one EOF kevent and one
> > > > writable kevent?
> > >
> > > I'll try that and see. The only issue being the low frequency
> > > this symptom appears at. I'll get back to the list once I have
> > > more info.
> >
> > Haven't gotten to the point of testing shutdown() behavior, but
> > here's a truss excerpt of the symptom:
> >
> > -- cut here --
> > kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
> > 0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
> > kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
> > 0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
> > kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
> > 0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
> > -- and here --
> >
> > So two EOF are returrned for descriptor 7, and errno would be
> > ECONNRESET. The question is now, why isn't it oneshot?
>
> Ah one more thing. When EOF is caught, a handler which forcibly
> removes the event is called, but it keeps poping up again and again.
Are you sure the event is being removed? I used to have a hack that
made the kernel return its current eventlist for a kqueue when you
called kevent() with nchanges set to -1 (handy for placing in a program
and using truss to print the result), but it has rotted. I'm attaching
it in case anyone wants to make it work again.
Since you got EOF status for both the read and write halves of the
socket, why not just close the fd? From my reading of the manpages,
unless you specified EV_ONESHOT when you added the event, events will
fire until you remove them or the condition that triggers them stops.
--
Dan Nelson
[EMAIL PROTECTED]
Index: kern_event.c
===
RCS file: /home/ncvs/src/sys/kern/kern_event.c,v
retrieving revision 1.113
diff -u -r1.113 kern_event.c
--- kern_event.c 14 Jul 2007 21:23:30 - 1.113
+++ kern_event.c 17 Jul 2007 18:10:47 -
@@ -659,6 +659,41 @@
nerrors = 0;
+#if 0 /* 1.92 broke this */
+ if (nchanges == -1) {
+ /* dump our eventlist into k_ops->arg */
+ int i;
+ int count = 0;
+ struct knote *kn;
+ error = 0;
+ KQ_LOCK(kq);
+
+ /* Walk our filedescriptor lists */
+ for (i = 0; i < kq->kq_knlistsize && count < nevents; i++) {
+ SLIST_FOREACH(kn, &kq->kq_knlist[i], kn_link) {
+copyout(&kn->kn_kevent, &(struct kevent)k_ops->arg[count], sizeof(kn->kn_kevent));
+count++;
+if (count >= nevents)
+ break;
+ }
+ }
+
+ /* Walk our hash tables */
+ if (kq->kq_knhashmask != 0) {
+ for (i = 0; i <= kq->kq_knhashmask && count < nevents; i++) {
+SLIST_FOREACH(kn, &kq->kq_knhash[i], kn_link) {
+ copyout(&kn->kn_kevent, &(struct kevent)k_ops->arg[count], sizeof(kn->kn_kevent));
+ count++;
+ if (count >= nevents)
+ break;
+}
+ }
+ }
+ KQ_UNLOCK(kq);
+ td->td_retval[0] = count;
+ goto done;
+ }
+#endif
while (nchanges > 0) {
n = nchanges > KQ_NEVENTS ? KQ_NEVENTS : nchanges;
error = k_ops->k_copyin(k_ops->arg, keva, n);
@@ -961,10 +996,12 @@
if ((kev->flags & EV_DISABLE) &&
((kn->kn_status & KN_DISABLED) == 0)) {
kn->kn_status |= KN_DISABLED;
+ kn->kn_kevent.flags |= EV_DISABLE;
}
if ((kev->flags & EV_ENABLE) && (kn->kn_status & KN_DISABLED)) {
kn->kn_status &= ~KN_DISABLED;
+ kn->kn_kevent.flags &= ~EV_DISABLE;
if ((kn->kn_status & KN_ACTIVE) &&
((kn->kn_status & KN_QUEUED) == 0))
knote_enqueue(kn);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OpenBSD sdiff Question
In the last episode (Mar 17), Steven Kreuzer said: > On Sat, Mar 15, 2008 at 11:29:19PM -0700, David O'Brien wrote: > > On Sat, Mar 15, 2008 at 03:21:01PM -0700, Bert JW Regeer wrote: > > > Even if BSD has no tradition to keep a separate program version, it is > > > still very handy to be able to give this data to other developers if > > > something is failing. > > > > $ ident failing-binary is the output that means something. A version > > string will not. > > > > > > > Programs that don't have a -v or --version switch are frustrating to > > > > Anyone used to working on BSD will not expect a -v switch. It > > isn't part of BSD tradition. The simple fact there is no obivous > > "version" to print just shows that in a OS that is developed and > > built as a whole, having a version on the util is meaningless. > > > > > Dropping -v would be a bad thing, and make the tools not > > > compatible, thus breaking many scripts that do expect a -v. > > > > Come on, how many scripts do you write that do "sdiff -v" today? > > I have to agree with this. > > I will submit the port without -v/--version > and worse comes to worse, add it in later if enough people complain. On the other hand, some programs that are contributed sources or are developed outside the FreeBSD cvs tree do have versions of their own. awk and tar, for example both recognize the --version flag (but not -v since that is already used). -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bug in /bin/sh?!?
Julian Elischer writes:
| dino wrote:
| > Hello,
| >
| > on my FreeBSD 7.0-STABLE the line:
| >
| >> sh -c 'set -- ${HOME+A B C}; echo "1:$1"; echo "2:$2:"; echo "3:$3:"'
| >
| > prints
| >
| > 1:A B C:
| > 2::
| > 3::
| >
| > I would rather expect:
| >
| > 1:A:
| > 2:B:
| > 3:C:
| >
| > Is it correct that field splitting isn't performed on default/alternate
| > expanded values?
| >
|
| "A B C" is a single value tha thappens to contain spaces.
| so, yes there is no splitting at that point.
This is one place where bash and ash disagree:
~ redhat-linux-box[2]> /bin/bash
bash-3.00$ sh -c 'set -- ${HOME+A B C}; echo "1:$1"; echo "2:$2:"; echo "3:$3:"'
1:A
2:B:
3:C:
bash-3.00$ bash --version
GNU bash, version 3.00.15(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
--Dan
--
Dan Grillo [EMAIL PROTECTED] 650-299-1470
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: binary file within a shell script
In the last episode (May 08), Mathieu Prevot said: > Hi there, > > I would like to use one exec file from a shellscript but I would like > it to be incorporated in the same file, like Nvidia do for its FreeBSD > drivers. How can I do this in a convenient way ? Take a look at the file generated by /usr/bin/gzexe; that's one way to do it (basically, determine the number of lines in your shell script, append your binary file to the end of the script, and use tail to extract only the binary file to a tempfile). -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overcommit and calloc()
In the last episode (Jul 19), Dag-Erling Smorgrav said: > "Kelly Yancey" writes: > > Ahh...but wouldn't the bzero() touch all of the memory just > > allocated functionally making it non-overcommit? > > No. If it were an "non-overcomitting malloc", it would return NULL > and set errno to ENOMEM, instead of dumping core. It should be possible to modify calloc to trap signals, then bzero. If bzero faults, you free the memory and return NULL. No, wait. You can't trap SIGKILL. How about this. mmap() some anonymous memory MAP_SHARED, fork a child to bzero it. If the child dies, unmmap and return NULL. If the child succeeds, use the memory. This memory won't be freeable with malloc(), though. -Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
In the last episode (Jul 26), Sheldon Hearn said: > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > You could start with "WinEXE". > > Save game file formats, not game executables. You think WinEXE tops > my pcgames suggestion? What about multi-OS games, like Quake? How about just calling it "games" ? -- Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
gethostbyaddr() and threads.
Greetings, After quite an exhausting night (of all the ways I didn't want to spend my Sunday...) I've managed to track down a problem that has been frustrating me all night. The problem exists with multiple threads calling gethostbyaddr() (not necessarily at the same time). Here's a debug output from my program: Thread 134978048 sleeping... Thread 134978560 sleeping... Thread 134978048 awakened! Thread 134978048 checking status of 162.18.75.91 Thread 134978048 looking up 162.18.75.91 Thread 134978048 calling gethostbyaddr() Thread 134978560 awakened! Thread 134978560 checking status of 162.18.75.91 Thread 134978560 sleeping... Thread 134978560 awakened! Thread 134978560 checking status of 202.188.127.2 Thread 134978560 looking up 202.188.127.2 Thread 134978560 calling gethostbyaddr() Thread 134978560 finished gethostbyaddr() Thread 134978560 checking status of 200.231.47.8 Thread 134978560 looking up 200.231.47.8 Thread 134978560 calling gethostbyaddr() As you can see, gethostbyaddr() when called from the first thread never returns, while the last thread continues on. This happens no matter how many threads I create. Creating 200 threads produces much longer debug output, but the result is the same, the first 199 threads created never return from gethostbyaddr(), while the last one continues on its merry way. I am hoping someone can shed a little more light on this subject, and possibly explain why this is happening and perhaps how to fix it. I've tested this on both -stable and -current branches. Regards, Dan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| >After quite an exhausting night (of all the ways I didn't want to spend my | >Sunday...) I've managed to track down a problem that has been frustrating me | >all night. The problem exists with multiple threads calling gethostbyaddr() | >(not necessarily at the same time). | | src/lib/libc/net/gethostbydns.c seems to use a load of static | variables in a non-thread-safe fashion. Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked "less" than gethostbyaddr did (the result was that all threads ended up thrashing each other, and not of them continued on). I was going to use res_query, but noticed that it too used static buffers (although it looks pretty easy to fix). Would anyone be offended if I were to produce a few patches to fix up these routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs or try full blown routines (gethostbyaddr_r, res_query_r)? Thanks, Dan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| Well, I guess we might as well change the API, since everyone else does. Unless | someone comes up with a bettter idea, of course :) | | -Joe The API should not change. There is already enough descrepency between UNIXs to warrant programs like autoconf, we should not introduce another. We should introduce a gethostbyaddr_r function, which shouldn't be all that though to implement.
Re: gethostbyaddr() and threads.
| > Yeah, that IS a horrible idea of mine. :) Changing the API should be a last | > resort, though, since we don't want to introduce to many FreeBSDisms into the | > already-fragmented-enough Unix world. | > | > Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| } If no one has any objections, I'd like to start on this tomorrow. | | You might want to grab the latest BIND release from ftp.isc.org. One | of the comments in the CHANGES file from a while ago is: | | 384. [feature] there is now a nearly-thread-safe resolver API, with | the old non-thread-safe API being a set of stubs on | top of this. it is possible to program without _res. | note: the documentation has not been updated. also | note: IRS is a thread-ready API, get*by*() is not. | (see ../contrib/manyhosts for an example application.) | | There's no sense re-inventing any more wheels than necessary. Great! This makes my job even easier! Does anyone have any issues with merging the new bind resolver API into libc? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: bftp(1)
In the last episode (Aug 17), Alexey M. Zelkin said: > Man page for telnetd(8) references to bftp(1) which will be installed > into /usr/ucb/bftp and of course does not exists. Can someone > describe in few words is this staff still supported ? If so, there > bftp(1) staff can be received/downloaded ? Otherwise I think it's > good idea to remove this staff from manpage and probably from source > code. I did an Altavista search for bftp and it looks like it's a background FTP client. Original source is at http://astro.temple.edu/~yxue , and a '97 paper re-implementing it is at http://renoir.vill.edu/~yhang . It looks like ports/ftp/ncftp3 has all the features of bftp (scheduled background transfers, auto-resume, multiple file xfers) except it doens't email the user then the transfer is done. -- Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: font edit tools
In the last episode (Aug 22), Sergey Babkin said: > Alexey M. Zelkin wrote: > > > > hi, > > > > Which tools can be used to edit syscons fonts ? > > Any of the tools you use to edit the DOS fonts. > My favorite one it Evafont by Pete Kvitek. But > there were a lot of tools floating around. I like one called Font Mania!; the author doesn't seem to have a web presence, but an URL is http://jconroy.dragonfire.net/zzt/utilities/Fm.zip -- Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Struct user
Can somebody tell me where to find the defintion for struct user that's contained in struct proc? I've grep'ed to no avail. Thanks. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [freebsdcon] radisson reservation
On Tue, 24 Aug 1999, Jun-ichiro itojun Hagino wrote: > (I believe it got bounced due to my mistake in To: line. > sorry if you got it multiple times) > > Hello, if this mailing list is inappropriate please tell me so. > > I contacted radisson hotels for FreeBSDCon reservation with > special discount, to get the following email - they don't know > about special rate code "FreeBSDCon". What is the exact code for > reservation? Do any of you have success experience with it? > I booked a room yesterday, and got the group rate by mentioning the FreeBSDCon. Looks like they've been updated. Dan Seguin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [freebsdcon] radisson reservation
On Wed, 25 Aug 1999, Jordan K. Hubbard wrote: > > Actually, what needed to get updated was the hotel, not our web pages. :) > > I just called them and they had apparently listed this under "Walnut > Creek CDROM", not the most obvious thing to ask for. That's why > queries have been either bouncing or meeting with general > incomprehension with the reservations staff. I'm not sure how this > got screwed up, but I apologise for the error and the hotel has promised > to update all their records ASAP. > > - Jordan > Actually, I booked my room on Monday, the 23rd, at about 11:00 AM EST, mentioning the FreeBSDCon. The clerk knew what I was talking about right away. I guess she was the only one on the ball. Dan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
In the last episode (Sep 10), Andrew Reilly said: > On Thu, Sep 09, 1999 at 01:21:09PM +0200, Markus Stumpf wrote: > > On Thu, Sep 09, 1999 at 12:08:01PM +1000, Andrew Reilly wrote: > > > really easy, with a shell script that's just a case $SENDER > > > > It's even "easier" :-) > > I subscribe new mailing lists (and resubscribed old ones) as > > maex-listn...@space.net > > Well, that's arguably the way qmail wants it to be, but not helpful > if you want your mailing list traffic to come through the one > ISP-provided pop account. (Costs less that way, with my current > ISP.) If your ISP runs sendmail (possibly other MTAs), you can use the user+det...@host.com syntax. All mail is sent to the "user" mailbox, but filters like procmail see the "detail" portion too, and can filter on it. -- Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Bug in dd seeking beyond 2G
In the last episode (Sep 15), Bakul Shah said: > PR bin/6509 (submitted in May 1998) already has a patch to fix this > but it was rejected because off_t was assumed by the bug > fixer/submitter to be a quat (int64_t). I can't even get an IDE disk > below 2G byte easily! And we are still years away from zettabyte > disks. So I don't see the point of blocking a _useful_ change that > *considerably* improves the situation just because it is not done the > `right way'. RCS file: /home/ncvs/src/bin/dd/dd.c,v revision 1.17 date: 1999/06/19 19:49:32; author: green; state: Exp; lines: +25 -21 Miscellaneous dd(1) changes: mainly fixing variable types (size_t, ssize_t, off_t, int, u_int64_t, etc.). dd(1) should now work properly with REALLY big amounts of data. Should be a -stable candidate by now (3 months of testing?) -- Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Efficient way to determine when a child process forks or calls exec
Hi all, I have been experimenting with ptrace to determine when a child process forks or calls exec. Particularly, I have explored tracing every system call entry and exit similar to what the truss utility does, and for my case, the performance impact of tracing every system call is too great. Is there a more efficient way than tracing every system call entry and exit to determine when a child process forks, calls exec, or creates a new LWP? Thanks a lot for your help! -Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Efficient way to determine when a child process forks or calls exec
Thanks for all the great suggestions! It looks like the kevent system call is the closest to what I need. However, I didn't mention this, but I would like the process being traced to be stopped on entrance to fork, exec, etc. This would be similar to Linux's ptrace interface which sends a SIGTRAP to the traced process on exec, fork, etc. From what I could tell so far, kevent doesn't provide this functionality. Am I missing something? Is there a way to get kevent to stop the process when events occur? Thanks again for your help, -Dan On Tue, May 18, 2010 at 2:40 AM, Alfred Perlstein wrote: > * Dan McNulty [100517 08:02] wrote: >> Hi all, >> >> I have been experimenting with ptrace to determine when a child >> process forks or calls exec. Particularly, I have explored tracing >> every system call entry and exit similar to what the truss utility >> does, and for my case, the performance impact of tracing every system >> call is too great. >> >> Is there a more efficient way than tracing every system call entry and >> exit to determine when a child process forks, calls exec, or creates a >> new LWP? >> >> Thanks a lot for your help! > > kevent has some hooks, have you looked at that? > > -- > - Alfred Perlstein > .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 > .- FreeBSD committer > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Efficient way to determine when a child process forks or calls exec
On Wed, May 19, 2010 at 4:51 PM, Alfred Perlstein wrote: > * Dan McNulty [100519 07:13] wrote: >> Thanks for all the great suggestions! >> >> It looks like the kevent system call is the closest to what I need. >> However, I didn't mention this, but I would like the process being >> traced to be stopped on entrance to fork, exec, etc. This would be >> similar to Linux's ptrace interface which sends a SIGTRAP to the >> traced process on exec, fork, etc. From what I could tell so far, >> kevent doesn't provide this functionality. >> >> Am I missing something? Is there a way to get kevent to stop the >> process when events occur? > > Not that I know of off the top of my head. > > Although if you want to contrib the code I can help get it in. :) > > -Alfred Unfortunately, writing a patch for the FreeBSD kernel may be beyond the scope of my current work. Although I wouldn't mind working on it in my spare time outside of my job. Maybe in some free time this summer. I think the ideal fix for my problem would be to implement a mechanism similar to the Linux ptrace interface that sends a SIGTRAP for events such as fork, exec, thread create, etc. Maybe I will poke around in the FreeBSD kernel source and see what I can figure out. Thanks for the help! -Dan >> >> Thanks again for your help, >> -Dan >> >> On Tue, May 18, 2010 at 2:40 AM, Alfred Perlstein wrote: >> > * Dan McNulty [100517 08:02] wrote: >> >> Hi all, >> >> >> >> I have been experimenting with ptrace to determine when a child >> >> process forks or calls exec. Particularly, I have explored tracing >> >> every system call entry and exit similar to what the truss utility >> >> does, and for my case, the performance impact of tracing every system >> >> call is too great. >> >> >> >> Is there a more efficient way than tracing every system call entry and >> >> exit to determine when a child process forks, calls exec, or creates a >> >> new LWP? >> >> >> >> Thanks a lot for your help! >> > >> > kevent has some hooks, have you looked at that? >> > >> > -- >> > - Alfred Perlstein >> > .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 >> > .- FreeBSD committer >> > > > -- > - Alfred Perlstein > .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 > .- FreeBSD committer > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to get a thread ID?
In the last episode (Jun 03), Václav Haisman said: > is it possible to obtain some sort of a thread ID that identifies a thread > within a process other than pthread_self()? Something like gettid() on > Linux? Apparently, on FreeBSD the pthread_t is a pointer type and does > not identify the thread well enough. GDB on FreeBSD seems to know about > threads and does not seem to use the same ID as is pthread_t. The return value of pthread_self() is a pointer to the (private) "struct pthread" for the current thread, and should uniquely identify a thread. Do you have a testcase that shows otherwise? GDB might just enumerate the currently active threads starting from 1. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysctl way too slow
In the last episode (Jul 14), Joerg Sonnenberger said: > On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: > > the same info is available on linux via /sys and /proc and on comparable > > hardware, i can get the info about 100x faster. > > Are you sure that Linux is not just caching the data? I know of at least > one system where it takes more than 100ms to query the battery state due > to extremely slow hardware, I wouldn't be surprised if you can do worse. I have an old Dell laptop where it takes almost a full second to fetch battery data via ACPI. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
8.1-STABLE amd64 machine check
I am encountering a situation similar to one reported by Andrew Heybey at http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D This morning I found this in my /var/log/messages: Aug 11 01:59:48 kraken kernel: MCA: Bank 4, Status 0x94614c62001c011b Aug 11 01:59:48 kraken kernel: MCA: Global Cap 0x0106, Status 0x Aug 11 01:59:48 kraken kernel: MCA: Vendor "AuthenticAMD", ID 0x100f42, APIC ID 0 Aug 11 01:59:48 kraken kernel: MCA: CPU 0 COR GCACHE LG RD error Aug 11 01:59:48 kraken kernel: MCA: Address 0x5d0fe8c from /var/run/dmesg.boot Copyright (c) 1992-2010 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-STABLE #0: Sun Jul 25 19:18:56 EDT 2010 d...@kraken.example.org:/usr/obj/usr/src/sys/KRAKEN amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) II X4 945 Processor (3010.17-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Family = 10 Model = 4 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4100710400 (3910 MB) ACPI APIC Table: <111909 APIC1708> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 Andrew: You posted about this on July 14. Anything new since then? John: Is it time for me to get a new CPU? thanks -- Dan Langille - http://langille.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 8.1-STABLE amd64 machine check
On Wed, August 11, 2010 7:31 am, Andrew Heybey wrote: > On Aug 11, 2010, at 6:47 AM, Dan Langille wrote: > >> I am encountering a situation similar to one reported by Andrew Heybey >> at >> http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D >> >> This morning I found this in my /var/log/messages: >> >> Aug 11 01:59:48 kraken kernel: MCA: Bank 4, Status 0x94614c62001c011b >> Aug 11 01:59:48 kraken kernel: MCA: Global Cap 0x0106, >> Status 0x >> Aug 11 01:59:48 kraken kernel: MCA: Vendor "AuthenticAMD", ID 0x100f42, >> APIC ID 0 >> Aug 11 01:59:48 kraken kernel: MCA: CPU 0 COR GCACHE LG RD error >> Aug 11 01:59:48 kraken kernel: MCA: Address 0x5d0fe8c >> >> Andrew: You posted about this on July 14. Anything new since then? > > I took jkim's advice and RMAed the CPU to newegg since it was only a week > old. No machine checks from the new one yet. Thanks. My CPU is 6 months old, and now out of Newegg's warranty period (Replacement period: 30 days from original invoice date). -- Dan Langille -- http://langille.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: adding sysctls
In the last episode (Jun 18), Zane C.B. said:
> Any one know of any recent documentation for adding a sysctl to a
> kernel module for FreeBSD 6 and 7?
man 9 sysctl
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Securelevels
In the last episode (Jun 29), Ivaylo Mateev said:
> I think I found a bug.
>
> [EMAIL PROTECTED] /usr/home/strato]$ sudo sysctl kern.securelevel
> kern.securelevel: 2
> [EMAIL PROTECTED] /usr/home/strato]$ kgdb
> kgdb: /dev/mem: Permission denied
> [EMAIL PROTECTED] /usr/home/strato]$ sudo kgdb
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
>
> I am running in securelevel 2. That means nithing can have direct access
> to /dev/mem, acording to man security:
>
> 1 Secure mode - the system immutable and system append-only flags may
> not be turned off; disks for mounted file systems, /dev/mem and
> /dev/kmem may not be opened for writing; /dev/io (if your platform
> has it) may not be opened at all; kernel modules (see kld(4)) may
> not be loaded or unloaded.
>
> 2 Highly secure mode - same as secure mode, plus disks may not be
> opened for writing (except by mount(2)) whether mounted or not.
> This level precludes tampering with file systems by unmounting
> them, but also inhibits running newfs(8) while the system is multi-
> user.
# truss kgdb < /dev/null |& grep /dev/mem
open("/dev/mem",O_RDONLY,00) = 4 (0x4)
#
Read-only opens of /dev/mem are allowed. "kgdb -w" should fail,
however.
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW uid logging...
In the last episode (Sep 08), Dan Mahoney, System Admin said: > I have the following rule set up in ipfw to limit the exposure of bad > php scripts and trojans that try to send mail directly. > > allow tcp from any to any dst-port 25 uid root > deny log tcp from any to any dst-port 25 out > > However, the log messages I get look like this: > > Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP > 72.9.101.130:58117 209.85.133.114:25 out via em0 > Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP > 72.9.101.130:56672 202.12.31.144:25 out via em0 > > Which is to say, they don't include the UID -- and I have several hundred > sites, each with its own UID. > > Yes, I could go ahead and set up a thousand "deny" rules, one for > each UID -- but being able to log this info (since it IS being > checked) would be great. It should be possible to add a couple more arguments to ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of that struct if ugid_lookup==1. That would result in the logging of uid for any failed packet that had to go through a uid check on the way to the deny rule. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW uid logging...
In the last episode (Sep 09), Daan Vreeken said: > On Monday 08 September 2008 22:03:29 Dan Mahoney, System Admin wrote: > > On Mon, 8 Sep 2008, Dan Nelson wrote: > > > In the last episode (Sep 08), Dan Mahoney, System Admin said: > > >> I have the following rule set up in ipfw to limit the exposure > > >> of bad php scripts and trojans that try to send mail directly. > > >> > > >> allow tcp from any to any dst-port 25 uid root > > >> deny log tcp from any to any dst-port 25 out > > >> > > >> However, the log messages I get look like this: > > >> > > >> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP > > >> 72.9.101.130:58117 209.85.133.114:25 out via em0 > > >> Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP > > >> 72.9.101.130:56672 202.12.31.144:25 out via em0 > > >> > > >> Which is to say, they don't include the UID -- and I have > > >> several hundred sites, each with its own UID. > > >> > > >> Yes, I could go ahead and set up a thousand "deny" rules, one > > >> for each UID -- but being able to log this info (since it IS > > >> being checked) would be great. > > > > > > It should be possible to add a couple more arguments to > > > ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag > > > and a pointer to the fw_ugid_cache struct. Then you can edit > > > ipfw_log to print the contents of that struct if ugid_lookup==1. > > > That would result in the logging of uid for any failed packet > > > that had to go through a uid check on the way to the deny rule. > > > > Okay, so if it's fairly easy to do, the question would be "since I > > don't feel right hacking in this change myself -- how could I > > propose this as a feature?" It's not a BUG per-se, but I think it > > could be useful to others as well. > > Hi Dan, Dan and the list, > > I own a webhosting company and here too every domain gets it's own > user, so I like this proposal. I've hacked together a first try, > which seems to be working. A patch (against -HEAD) can be found here: > > http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff > > Improvements / tips / comments are welcome ;-) I like it. Maybe print gid as well, since there's an ipfw rule for that too. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Error: Can't find libjava.so
In the last episode (Sep 14), Marcel Grandemange said: > I do realize this is probably better suited for freebsd-questions , > however haven't received any response and was simply hoping someone > would be kind enough. > > I recently obtained a very decent ups, however it is not supported by > NUT. > > It does however come with winpower software that does run on FreeBSD. > > However it rewuired java. > > So installed from ports > > And was presented with following error: > > Error: can't find libjava.so > > This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so Are you running an amd64 winpower binary? If not, you'll probably need to install an x86 java. You can't mix libraries for different architectures. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and ISCSI, Strange Problem
In the last episode (Oct 17), Daniel Dias Gonçalves said: > Thanks Danny, > > The patch work fine, but i have new problem: > > Have two servers 7.0R with iscsi-2.1. > They are mounted the same directory way iSCSI. When I create an archive > inside of this directory in the server A, the server B don't show the > archive, if in the server B to unmount and mount the directory again, > the archive created in the server A appears It. > > Where it is the problem? You can't mount the same UFS filesystem on two servers at once. You'll end up with a horribly-corrupted filesystem, since neither one is aware of changes the other makes. You would need a shared-storage cluster filessytem to be able to do that (or mount the volume read-only on both servers). Mount the filesystem on one server only, then access it via NFS from the other. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pipes, cat buffer size
In the last episode (Oct 18), Ivan Voras said: > I'm working on a program that's intended to be used as a "filter", as > in "something | myprogram > file". I'm trying it with cat and I'm > seeing my read()s return small blocks, 64 kB in size. I suppose this > is because cat writes in 64 kB blocks. So: > > a) Is there a way to programatically, per-process, set the pipe buffer > size? The program in question is a compressor and it's particularly > inefficient when given small blocks and I'm wondering if the system can > buffer enough data for it. Why not keep reading until you reach your desired compression block size? Bzip2's default blocksize is 900k, for example. > b) Is there any objection to the following patch to cat: It might be simpler to just use "dd if=myfile obs=1m" instead of patching cat. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pipes, cat buffer size
In the last episode (Oct 19), Ivan Voras said: > Dan Nelson wrote: > > In the last episode (Oct 18), Ivan Voras said: > >> I'm working on a program that's intended to be used as a "filter", > >> as in "something | myprogram > file". I'm trying it with cat and > >> I'm seeing my read()s return small blocks, 64 kB in size. I > >> suppose this is because cat writes in 64 kB blocks. So: > >> > >> a) Is there a way to programatically, per-process, set the pipe buffer > >> size? The program in question is a compressor and it's particularly > >> inefficient when given small blocks and I'm wondering if the system can > >> buffer enough data for it. > > > > Why not keep reading until you reach your desired compression block > > size? Bzip2's default blocksize is 900k, for example. > > Of course. But that's not the point :) From what I see (didn't look at > the code), Linux for example does some kind of internal buffering that > decouples how the reader and the writer interact. I think that with > FreeBSD's current behaviour the writer could write 1-byte buffers and > the reader will be forced to read each byte individually. I don't know > if there's some ulterior reason for this. No; take a look at /sys/kern/sys_pipe.c . Depending on how much data is in the pipe, it switches between async in-kernel buffering (<8192 bytes), and direct page wiring between sender and receiver (basically zero-copy). > >> b) Is there any objection to the following patch to cat: > > > > It might be simpler to just use "dd if=myfile obs=1m" instead of > > patching cat. > > I believe patching cat to bring its block size into the century of the > fruitbat has its own benefits. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
