bge/ilo blues on Sun X2200 (fwd)
trying my luck here :-) newer kernels (after Oct. 20) are breacking bge. i've checked the cvsdiffs, but nothing seems relevant. the ilo (Integrated Lights Out) port, bge1, though not configured, gets configured to 10baseT/UTP full-duplex, and no magic will get it to 100/full-duplex, which is what the ilo was/is using. this works fine on an Oct 20 system. any ideas? cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge/ilo blues on Sun X2200 (fwd)
On Fri, Nov 09, 2007 at 10:22:42AM +0200, Danny Braniss wrote: trying my luck here :-) newer kernels (after Oct. 20) are breacking bge. i've checked the cvsdiffs, but nothing seems relevant. the ilo (Integrated Lights Out) port, bge1, though not configured, gets configured to 10baseT/UTP full-duplex, and no magic will get it to 100/full-duplex, which is what the ilo was/is using. this works fine on an Oct 20 system. any ideas? Try using the following in /boot/loader.conf and reboot: hw.bge.allow_asf=1 The default is 0. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pgk_add segmentation fault
Aharon Schkolnik wrote: Hi ! pkg_add is crashing with a segmentation fault: pkg_add -v mysql-client-5.1.22.tbz Requested space: 3809856 bytes, free space: 128323438592 bytes in /var/tmp/instmp.ND8UBU extract: Package name is mysql-client-5.1.22 extract: CWD to /usr/local extract: /usr/local/man/man1/mysql_config.1.gz extract: /usr/local/man/man1/mysql.1.gz extract: /usr/local/man/man1/mysqladmin.1.gz extract: /usr/local/man/man1/mysqlbinlog.1.gz extract: /usr/local/man/man1/mysqlcheck.1.gz extract: /usr/local/man/man1/mysqldump.1.gz extract: /usr/local/man/man1/mysqlimport.1.gz extract: /usr/local/man/man1/mysqlshow.1.gz extract: /usr/local/man/man8/mysqlmanager.8.gz . . . extract: /usr/local/lib/mysql/libmysqlclient_r.la extract: /usr/local/lib/mysql/libmysqlclient_r.so extract: /usr/local/lib/mysql/libmysqlclient_r.so.16 extract: /usr/local/share/aclocal/mysql.m4 extract: /usr/local/share/mysql/mysql_fix_privilege_tables.sql extract: execute '/sbin/ldconfig -m /usr/local/lib/mysql' extract: CWD to (null) Segmentation fault (core dumped) # uname -a FreeBSD CMXHost 5.30.0170 FreeBSD 5.30.0170 #0: Thu Apr 13 14:05:14 UTC 2006 i386 7.05.0014 Any ideas ? TIA Where did you download those sources from? Could you get a backtrace for me or point me to that package? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive
another question. in my 'dmesg' i have NIC - em0 Intel(R) PRO/1000 Network Connection Version - 6.6.6...is it support Tigon driver that need to set ZERO_COPY_SOCKETS ? thx On Fri, Nov 02, 2007 at 09:39:19AM +0700, binto wrote: I try to compile MYKERNEL to set zero_copy tigon driver in my machine with: device ti options TI_PRIVATE_JUMBOS options TI_JUMBO_HDRSPLIT but got: #error options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive what's up? %vi +/TI_JUMBO_HDRSPLIT /usr/src/sys/conf/NOTES -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge/ilo blues on Sun X2200 (fwd)
On Fri, Nov 09, 2007 at 10:22:42AM +0200, Danny Braniss wrote: trying my luck here :-) newer kernels (after Oct. 20) are breacking bge. i've checked the cvsdiffs, but nothing seems relevant. the ilo (Integrated Lights Out) port, bge1, though not configured, gets configured to 10baseT/UTP full-duplex, and no magic will get it to 100/full-duplex, which is what the ilo was/is using. this works fine on an Oct 20 system. any ideas? Try using the following in /boot/loader.conf and reboot: hw.bge.allow_asf=1 The default is 0. Yes, that works! thanks! danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround.
Roman Kurakin wrote: By the way, is there any chance to get RAID5 working with this controller? Software only. -- ./lxnt ___ 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
On Thu, 8 Nov 2007 16:52:38 -0600, Dan Nelson wrote: 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? on FreeBSD 6.2-RELEASE, it returns, dd if=/usr/include/sys/socket.h of=/dev/null ibs=1 obs=64k 18426+0 records in 0+1 records out 18426 bytes transferred in 0.070472 secs (261466 bytes/sec) -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround.
By the way, is there any chance to get RAID5 working with this controller? rik Alexander Sabourenkov wrote: Arno J. Klaassen wrote: Rather than the marginal HW part, it seems, for me, closely related to MB/BIOS (as well (Alexander apperently has about the same setup as I have for this test)): [...] I vaguely remember from another PR that the Promise card does something with PCI-bursting which fbsd does not detect and/or handle correctly (and beyond my simple skills as dumb tester, but maybe the linux-sources contain a clue about that as well). Analysis of chip initialization in vendor-supplied, Linux and FreeBSD drivers shows that FreeBSD's one: - does not enable something called 'BMR_BURST', - performs hotplug init in one write (instead of two read-modify-writes ), - does an extra write (offset 0x54) which is not done in other drivers. Analysis text: http://lxnt.info/tx4/chipinit.text Patch with ported chipinit (dangerous to use with anything from Promise other than sata300 tx4 !!): http://lxnt.info/tx4/freebsd/chipinit.patch (cumulative) http://lxnt.info/tx4/freebsd/ata-chipset.c+chipinit (patched source) Note two things: 1. I have not compiled or tested this patch. Please do. 2. I may have missed this bug because I'm frequently rebooting between Linux and FreeBSD, and what Linux driver initialized may have lasted the reboots. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
questions on development(7)
First of all I am posting to both -current and -hackers because -hackers seems to be very low volume. I just set up a master server development server using the procedure in development(7) which was fairly clear but left a few questions unanswered (and one odd behavior). I have only the master server (no clients). Just for ref my dir tree looks like this: /home/ncvs --- /FreeBSD/CVSROOT /FreeBSD/7.x (src) /FreeBSD/current (src ports doc) /usr/src --- /FreeBSD/7.x /usr/src2 --- /FreeBSD/current /usr/ports --- /FreeBSD/current/ports /usr/obj is on it's own partition My questions: 1. If I am modifing code and such should I have a local branch? 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) 3. The documentation said very little about how to generate patchs between my local code and the main branch a. Ideally I want to set it up where when I am done with a modification it automatically creates a patch (I have never used CVS for anything except through csup and cvsup so I am totally lost here) 4. Mergemaster behaves strange now: everytime I run it does a buildworld before doing the merge (even if I just did a installworld)... also it seems to default this to /usr/src2 (which is most of the time what I want)... is this normal? and if so how do I turn it off and if I can't how do I set which source tree to use? -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Hi. Kris Kennaway wrote:te: In the good case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the good and bad times, since it only provides counters and an average rate over the uptime of the system. Now I'm running 10-process lighttpd and the problem became no so big. I collected interrupt stats and it shows no relation beetween ionterrupts and slowdowns. Here is it: http://83.167.98.162/gprof/intr-graph/ Also I have similiar statistics on mutex profiling and it shows there's no problem in mutexes. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ I have no idea what else to check. With best regards, Alexey Popov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you keep a local repo, and checkout from the local repo, then your checkout will merge the changes (unless there are conflicts). Thanks the fact I know the answer you gave is quite simple but completely over my head shows I need a good tutorial on cvs where can I find one ;-) - -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHM/R1J9+1V27SttsRAhdgAJ9HVh/Zzfu1oUgnGqcLAIpGHsHOKgCfVuzL xhJ83RXcG8gVAX9KUEK5wPQ= =ADE2 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Fri, Nov 09, 2007 at 04:56:24AM +, Aryeh M. Friedman wrote: 1. If I am modifing code and such should I have a local branch? You can either maintain a local branch or keep backing up your diffs against the main source tree. Which one is better depends on the size of your changes and your workflow. I've used both. Maintaining your own local branch means much more cvs-related overhead but may be worth it if you need your changes versioned properly. 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) Just run cvsup to update your copy of the cvs repository as usual, it should not delete your branch. The development(7) man page says that it can in some cases delete your branch though, so you should regularly back up your branch as a diff against the upstream branch you are based on, and possibly back up your copy of the cvs repository before updating. 3. The documentation said very little about how to generate patchs between my local code and the main branch a. Ideally I want to set it up where when I am done with a modification it automatically creates a patch (I have never used CVS for anything except through csup and cvsup so I am totally lost here) I don't think this list is appropriate for basic CVS questions, but I give you a few hints anyway because development(7) does not mention them: You need to tag the point you are branching from in CVS, otherwise you cannot create meaningful diffs between your own branch and the upstream branch. So to create a branch you can actually use, you need to run the rtag command TWICE. For example, to branch RELENG_7, use: export CVS_LOCAL_BRANCH_NUM=424242 cvs -d $CVSROOT rtag -r RELENG_7 MY_BRANCH_BP cvs -d $CVSROOT rtag -r RELENG_7 -b MY_BRANCH You should also create descriptive tags on both branches before and after doing a merge, to make it easier to track what has been merged where and when. Otherwise continuously syncing your branch with upstream becomes a pain quickly. You can maintain several custom branches in a single repository by switching CVS_LOCAL_BRANCH_NUM. Just don't end up confusing your branches. Always use the same CVS_LOCAL_BRANCH_NUM setting for all tag and rtag commands operating on the same branch. Warning: Branching and merging in CVS is hard! Not because branching and merging in general is hard, but simply because CVS is brain damaged. You will very likely mess it up the first time. You should practise on a test repo until you feel confident that you understand it properly. For more information see http://cvsbook.red-bean.com/ and especially http://cvsbook.red-bean.com/cvsbook.html#Branches -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpJtXFRst0hc.pgp Description: PGP signature
Re: questions on development(7)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OutbackDingo wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where If I need to use an other CMS I would prefer aegis... and if that is the case I will volunteer to maintain the aegis---cvs repo... but there has to be a better way then using yet an other package - -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHM/YRJ9+1V27SttsRAvBZAJ0WyR9zsc5d+8yYniiG543+pqlfWwCgpWj/ VIlqef2f+3/W7bALCHYlXc0= =34ww -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Nov 8, 2007, at 11:36 PM, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? If you keep a local repo, and checkout from the local repo, then your checkout will merge the changes (unless there are conflicts). Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
Aryeh M. Friedman wrote: First of all I am posting to both -current and -hackers because -hackers seems to be very low volume. I just set up a master server development server using the procedure in development(7) which was fairly clear but left a few questions unanswered (and one odd behavior). I have only the master server (no clients). Just for ref my dir tree looks like this: /home/ncvs --- /FreeBSD/CVSROOT /FreeBSD/7.x (src) /FreeBSD/current (src ports doc) /usr/src --- /FreeBSD/7.x /usr/src2 --- /FreeBSD/current /usr/ports --- /FreeBSD/current/ports /usr/obj is on it's own partition My questions: 1. If I am modifing code and such should I have a local branch? 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. 3. The documentation said very little about how to generate patchs between my local code and the main branch a. Ideally I want to set it up where when I am done with a modification it automatically creates a patch (I have never used CVS for anything except through csup and cvsup so I am totally lost here) 'cvs diff' will generate a patch for the specified files or directories. Some like context diffs, I like unified with minimal context '-ud' option to diff. Use whichever you find easier to read. Submit patches in whatever format the developers prefer. Unified seems the most common format around here. Ian -- Ian Freislich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where On Fri, 2007-11-09 at 05:36 +, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Fri, 2007-11-09 at 21:49 +0800, OutbackDingo wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where On Fri, 2007-11-09 at 05:36 +, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? (Nothing like top posting to destroy the thread flow) OutbackDingo is incorrect. That is the entire purpose of CVS, otherwise they might as well call it VS.. Your /usr/src will be a checkout of a particular branch of freebsd (called a working copy). You periodically update your cvs repository (where you checkout from) with the latest freebsd commits. When you wish to, you update your working copy from your repository by issuing a 'cvs up'. This merges changes in the repository into your local copy, merging in with the local changes. When you want to see what has changed since you last did a 'cvs up', issue a 'cvs -n up'. When you want to see the local modifications in your working copy, issue a 'cvs diff'. Read the cvs red-bean book for more info. http://cvsbook.red-bean.com/cvsbook.html HTH Tom signature.asc Description: This is a digitally signed message part
Re: questions on development(7)
On Fri, 2007-11-09 at 14:43 +, Tom Evans wrote: On Fri, 2007-11-09 at 21:49 +0800, OutbackDingo wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where On Fri, 2007-11-09 at 05:36 +, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? (Nothing like top posting to destroy the thread flow) OutbackDingo is incorrect. That is the entire purpose of CVS, otherwise they might as well call it VS.. Your /usr/src will be a checkout of a particular branch of freebsd (called a working copy). You periodically update your cvs repository (where you checkout from) with the latest freebsd commits. When you wish to, you update your working copy from your repository by issuing a 'cvs up'. This merges changes in the repository into your local copy, merging in with the local changes. When you want to see what has changed since you last did a 'cvs up', issue a 'cvs -n up'. When you want to see the local modifications in your working copy, issue a 'cvs diff'. Read the cvs red-bean book for more info. http://cvsbook.red-bean.com/cvsbook.html HTH Tom Well I wouldnt say incorrect as i stated it was hard to do. Meaning its easier to complete these tasks with a different RCS, in my OWN opinion. So as not to clobber ones changes locally. I didnt say it could not be done, its simply more difficult to achieve the same result as with other RCS systems. The reason I sated as more difficult to do, Ive seen quite a number of times when tracking a vendor branch, that merges had to be more manually handled because of local changes. This is another of those preferences people get into wars over, Best OS, Browser, RCS etc etc etc... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Fri, 2007-11-09 at 05:47 +, Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you keep a local repo, and checkout from the local repo, then your checkout will merge the changes (unless there are conflicts). Thanks the fact I know the answer you gave is quite simple but completely over my head shows I need a good tutorial on cvs where can I find one ;-) O'Reilly released a good book a while back that has a free version online: http://cvsbook.red-bean.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On 2007-11-09 21:49, OutbackDingo [EMAIL PROTECTED] wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where That is cool, but it takes a bit of familiarity with both CVS *and* the target SCM, so it may be worth sticking with CVS for a while. ___ 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
You should also carefully do an strace or similar on Windows and Linux as well. You may find that you're doing a system call per byte on FreeBSD but not on those other systems. Certainly this might be possible under Windows, as I have no idea what happens once I link in one of the various kernel.dll modules. Under Linux, however, I am directly issuing the INT($80) instruction, so one system call per byte is being made. To answer a different question in the thread, I'm pretty sure I'm making only one FreeBSD call per byte, at least in one of the cases I posted. You'll note that one of the test examples made a call to bsd.read( fd, buffer, 1 );. That's just a function I wrote that rearranges parameters and sets up the stack, executes an INT( $80 ) instruction, cleans up the stack, and returns to the user. In a different test example I *was* making a couple of calls, (specifically to lseek to check to see if I'd reached EOF), but the performance difference was minimal (i.e., the time was being spent in the read call). I have to run off for an appt right now, but I'll try the dd command later today and see what that reports. I wonder if I'm only getting one character output per time slice, or something like that? Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Thursday 08 November 2007, Aryeh M. Friedman said: First of all I am posting to both -current and -hackers because -hackers seems to be very low volume. Please do not cross post. It is considered bad form and generates thousands of unnecessary emails. Beech -- --- Beech Rintoul - FreeBSD Developer - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://www.freebsd.org X - NO Word docs in e-mail | Latest Release: / \ - http://www.FreeBSD.org/releases/6.2R/announce.html --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Hi. Kris Kennaway wrote:te: In the good case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the good and bad times, since it only provides counters and an average rate over the uptime of the system. Now I'm running 10-process lighttpd and the problem became no so big. I collected interrupt stats and it shows no relation beetween ionterrupts and slowdowns. Here is it: http://83.167.98.162/gprof/intr-graph/ Also I have similiar statistics on mutex profiling and it shows there's no problem in mutexes. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ I have no idea what else to check. With best regards, Alexey Popov I don't know what this graph is showing me :) When precisely is the system behaving poorly? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
You won't be able to commit to the BSD repo from your server. Well, Aryeh wants to commit to a _local_ copy of the BSD repo. This works. See development(7). One thing the man page does not mention is that you need to change the commit hook in CVSROOT (which you only copy on first sync and never ever again) to simply 'exit 0' to allow commits. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpSKYuK7dRID.pgp Description: PGP signature
Re: questions on development(7)
OutbackDingo wrote: On Fri, 2007-11-09 at 14:43 +, Tom Evans wrote: On Fri, 2007-11-09 at 21:49 +0800, OutbackDingo wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where On Fri, 2007-11-09 at 05:36 +, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? (Nothing like top posting to destroy the thread flow) OutbackDingo is incorrect. That is the entire purpose of CVS, otherwise they might as well call it VS.. Your /usr/src will be a checkout of a particular branch of freebsd (called a working copy). You periodically update your cvs repository (where you checkout from) with the latest freebsd commits. When you wish to, you update your working copy from your repository by issuing a 'cvs up'. This merges changes in the repository into your local copy, merging in with the local changes. When you want to see what has changed since you last did a 'cvs up', issue a 'cvs -n up'. When you want to see the local modifications in your working copy, issue a 'cvs diff'. Read the cvs red-bean book for more info. http://cvsbook.red-bean.com/cvsbook.html HTH Tom Well I wouldnt say incorrect as i stated it was hard to do. Meaning its easier to complete these tasks with a different RCS, in my OWN opinion. So as not to clobber ones changes locally. I didnt say it could not be done, its simply more difficult to achieve the same result as with other RCS systems. The reason I sated as more difficult to do, Ive seen quite a number of times when tracking a vendor branch, that merges had to be more manually handled because of local changes. This is another of those preferences people get into wars over, Best OS, Browser, RCS etc etc ok having done this for years here's how it goes. If you have a private CVS repo mirroring the FreeBSD tree then you can keep your changes up to date in your checked out source tree. but you can generally not check them in anywhere. You CAN keep your own special branch (I think it was branch numbers above 10 or something, check cvsup docs) that cvsup will not over write, and you can check in your changes there but that branch will not automatically update from freebsd.org so you will need to do branch updates regularly. (and that can be tricky and time consuming in CVS) otherwise your branch will get out-of date when compaerd with -current. usually I just keep my work checked out until I'm ready to feed the changes back but I take regular diffs and stash them away as 'backups' :-) This is why we have the perforce repo in addition to CVS. it is good at doing large branch manipulations, and it is more feasible to keep your own branch in sync with the branch that is kept up to date with the CVS tree. Unfortunatly, we don't give out access to that to 'anybody', it may be possible to get mercurial to do similar, or if you could get a 'personal use' p4 server you could get the scripts from Peter and see if you could do the same. I wonder if ther is a way we could broadcast changes to the p4 'head' branch so that people could keep their own p4 servers up to date.. etc... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [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: pkg_add doesn't keep dependent pkgs
Garrett Cooper wrote: Maslan wrote: That would be great. I'll wait for the patch On Nov 6, 2007 1:01 PM, Garrett Cooper [EMAIL PROTECTED] wrote: Maslan wrote: Package dependencies may change, depending on the user settings and port maintainers configuration for the port (i.e. Makefiles). The same sort of applies to packages as well. Or were you referring to just packages instead of ports based package metadata :)? Or maybe a better question is: what are you trying to accomplish? -Garrett The problem is that i always try FreeBSD snapshots, and each time i did a fresh install, i found my self in need to install xorg gnome. so when i use pkg_add -rK xorg or pkg_add -rK gnome, it just keeps the package itself only without its dependencies, it would be better for me to keep the packages i use rather than downloading them every time. The ports has no problem with that, since it leaves all the port dependencies in /usr/ports/distfiles but i prefer packages than recompiling every time i install a fresh system something like gnome would eat my day compiling it. Hmm... that is indeed silly. Let me see if I can fire up a patch for that little issue sometime either next week or the week after to fix that. -Garrett That's assuming (IIRC) pkg_add doesn't invoke libfetch related APIs directly and extract straight to the command line. It may take a bit more work than I initially think, but a patch *should* be trivial to create. -Garrett The URL provided to this really simple patch should fix the problem for -K not being propagated down child pkg_add processes (http://students.washington.edu/youshi10/posted/pkg_add_keep_flag_prop.patch). I would test it out but my FreeBSD box is still not hooked up to the net, so no dice :(. It's simple enough though that I'm almost 100% positive that it's correct. If the behavior's wrong or slightly askew, please let me know and I'll see if I can hack around the code a bit more. You made a good point though in terms of usage and propagating / whitelisting options from parent to child (master to slave?) copies of pkg_install apps. I'll write that up for my todo list for the pkg_install rewrite (VLSI's kicking my ass this quarter along with work, so I haven't had a real chance to sit down and make a plan for developing pkg_install). Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
