From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 05:24:52 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B76BE37B401 for ; Sun, 18 May 2003 05:24:52 -0700 (PDT) Received: from mail.rdslink.ro (mail.rdslink.ro [193.231.236.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 68C6F43FB1 for ; Sun, 18 May 2003 05:24:50 -0700 (PDT) (envelope-from enache@rdslink.ro) Received: (qmail 14238 invoked from network); 18 May 2003 12:28:19 -0000 Received: from unknown (HELO ratsnest.hole) (10.100.0.30) by mail.rdslink.ro with SMTP; 18 May 2003 12:28:19 -0000 Date: Sun, 18 May 2003 15:26:19 +0300 From: Enache Adrian To: Poul-Henning Kamp Message-ID: <20030518122619.GB826@ratsnest.hole> Mail-Followup-To: Poul-Henning Kamp , Narvi , freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Marcel Moolenaar References: <20030516002105.K40030-100000@haldjas.folklore.ee> <3641.1053034682@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3641.1053034682@critter.freebsd.dk> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: Marcel Moolenaar Subject: Re: Optimizations. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 12:24:53 -0000 On Thu, May 15, 2003 at 11:38:02PM +0200, Poul-Henning Kamp wrote: > So I really think the band of merry men we are talking about, if they > can be interested, would do much more good if they would start out > building functional and regression tests for our most critical > facilities. > > I can't speak for the other heavy-duty guys in the project, but I > would personally be _really_ _REALLY_ grateful if I could "cd > /usr/src ; make test" and know that a significant fraction of our > functionality worked if it returned a zero exit code. My humble opinion on the subject: The only sane principle will probably be "no bugfix/modification without a regression test" but I guess this isn't going to happen ... My limited experience is with Perl's testsuite shaking bugs in FreeBSD's libraries: bin/51535, bin/49087. And with FreeBSD's malloc completely trashing the performance of any realloc addicted program, like Perl. Regards, Adi From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 06:02:48 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7BAA37B401 for ; Sun, 18 May 2003 06:02:48 -0700 (PDT) Received: from mwinf0302.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CB1E43F93 for ; Sun, 18 May 2003 06:02:47 -0700 (PDT) (envelope-from rmkml@wanadoo.fr) Received: from wanadoo.fr (unknown [80.15.82.22]) by mwinf0302.wanadoo.fr (SMTP Server) with ESMTP id 07AE5C00029B for ; Sun, 18 May 2003 15:02:46 +0200 (CEST) Sender: test@wanadoo.fr Message-ID: <3EC78490.532D5A75@wanadoo.fr> Date: Sun, 18 May 2003 15:03:12 +0200 From: rmkml X-Mailer: Mozilla 4.8 [en] (...; U; Linux 2.4.21-pre2 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: core with incorrect fd ... (File Descriptor) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 13:02:49 -0000 Hi, I use Freebsd 4.8 Release (with no patch/cvs) and no debug option in kernel I have a program that use libc_r Program is client / server This morning, this program have a core with signal 10, Bus error on incorrect fd : (gdb) bt ful #0 0x804b387 in select_fd (fd=-1207959548, maxtime=1275068416, writep=0) at cnx_utils.c:44 fds = {fds_bits = {0 }} exceptfds = {fds_bits = {0 , 672012529, 672321100, 3145641596, 672048692, 672321100, 1, 137907200, 0, 0, 4294967295, 3145641644, 672049282, 3087007748, 0, 0, 672040120, 672321100, 0}} #1 0x804b4ce in get_line_from_sock (fd=-1207959548, buf=0xbb7ebf
, len=503316496, timeout=1275068416) at cnx_utils.c:105 buf = 0xbb7eae9c "" len = 4096 res = -1 cur = -1140850688 ptr = 0xbb7ebfb8 "" #2 0x804c7 in ?? () No symbol table info available. Cannot access memory at address 0xe3bb7ecf. A process since to crash after a valid connection (accept()) so the fd is normally correct ... A program has run well, with an average one connexion by second, and uptime box is 13 days ... Have anyone any ideas where to look for ? Can we trust in gdb values ? (because gdb is not multi-thread) Thanks for Answers Regards. From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 13:38:25 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D13C37B401 for ; Sun, 18 May 2003 13:38:25 -0700 (PDT) Received: from sandbag.sandstorm.net (user-v3qtgdt.biz.mindspring.com [199.174.193.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id A884E43F93 for ; Sun, 18 May 2003 13:38:24 -0700 (PDT) (envelope-from cjp@sandstorm.net) Received: from innsmouth.sandstorm.net ([199.174.193.186] helo=deus) by sandbag.sandstorm.net with esmtp (Exim 3.35 #1 (Debian)) id 19HUvI-0001Gh-00 for ; Sun, 18 May 2003 16:38:24 -0400 Content-Type: text/plain; charset="us-ascii" From: Charles Peterman Organization: Sandstorm Enterprises To: hackers@freebsd.org Date: Sun, 18 May 2003 16:36:43 -0400 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200305181636.44142.cjp@sandstorm.net> Subject: Maxtor Ultra ata/133 controller, FreeBSD 4.[5,8], and the boot process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 20:38:25 -0000 As it turns out, the latest rev of the Intel SDS2 motherboard also rev's = its=20 ICH4 ide controller, turning it into a useless piece of PIO crap and=20 destroying my systems' performance and sucking down my weekend. After contacting Soren Schmidt concerning the state of the ata driver and= =20 whether a quick hack would be appropriate, I decided to venture into usin= g=20 a PCI add-on card controller, in this case the Maxtor Ultra ata/133=20 controller. There is only one disk aside from the 3ware raid, which does= not=20 show up as an ata device. The install CD for 4.5 installs to this drive without a problem, but it t= ells=20 me that the loan disk is at ad4. Upon reboot, the boot loader fails,=20 horribly, no loader found. Rebooting with the install CD, and going into= the=20 loader's command line, I find that my disk is listed as disk2s1, and not = the=20 disk4 I thought it would be.=20 Is there a variable I could set during boot to get the disk to show up as= ad0? =20 SImilar to the way removing ATA_STATIC_ID from the kernel compile does. Various attempts to massage loader.conf and the currdev, loaddev, or boot= dev variables failed to produce results. I attempted to set these to disk2s= 1a=20 with no results. If someone could point me in the right direction for how to handle this, = I=20 would be much obliged. An RTFM (with pointer to M) or a helping hand wou= ld=20 be sincerely appreciated. Thanks,=20 Charles=09 From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 13:48:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BB6B37B401 for ; Sun, 18 May 2003 13:48:40 -0700 (PDT) Received: from spider.deepcore.dk (cpe.atm2-0-56339.0x50c6aa0a.abnxx2.customer.tele.dk [80.198.170.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4557E43F75 for ; Sun, 18 May 2003 13:48:35 -0700 (PDT) (envelope-from sos@spider.deepcore.dk) Received: (from sos@localhost) by spider.deepcore.dk (8.12.8p1/8.12.8) id h4IKmQGw022276; Sun, 18 May 2003 22:48:26 +0200 (CEST) (envelope-from sos) From: Soeren Schmidt Message-Id: <200305182048.h4IKmQGw022276@spider.deepcore.dk> In-Reply-To: <200305181636.44142.cjp@sandstorm.net> To: Charles Peterman Date: Sun, 18 May 2003 22:48:26 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL98b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 cc: hackers@FreeBSD.ORG Subject: Re: Maxtor Ultra ata/133 controller, FreeBSD 4.[5,8], and the boot process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 20:48:40 -0000 It seems Charles Peterman wrote: > > As it turns out, the latest rev of the Intel SDS2 motherboard also rev's its > ICH4 ide controller, turning it into a useless piece of PIO crap and > destroying my systems' performance and sucking down my weekend. > > After contacting Soren Schmidt concerning the state of the ata driver and > whether a quick hack would be appropriate, I decided to venture into using > a PCI add-on card controller, in this case the Maxtor Ultra ata/133 > controller. There is only one disk aside from the 3ware raid, which does not > show up as an ata device. > > The install CD for 4.5 installs to this drive without a problem, but it tells > me that the loan disk is at ad4. Upon reboot, the boot loader fails, > horribly, no loader found. Rebooting with the install CD, and going into the > loader's command line, I find that my disk is listed as disk2s1, and not the > disk4 I thought it would be. That sounds very strange unless you move it physically to the other channel.. However 4.5 is way too old for this purpose, try 4.8 that has a much better chance of supporting that board (I'm not sure which Serverworks chip it has one there, the docs I found for the SDS2 didn't tell)... > Is there a variable I could set during boot to get the disk to show up as ad0? > SImilar to the way removing ATA_STATIC_ID from the kernel compile does. no. -Søren From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 23:50:47 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 267F137B401; Sun, 18 May 2003 23:50:47 -0700 (PDT) Received: from smtp2.home.se (smtp2.home.se [213.214.194.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id E647F43F93; Sun, 18 May 2003 23:50:45 -0700 (PDT) (envelope-from lasse.lindgren@home.se) Received: from lasse.lindgren@home.se [194.237.142.7] by home.se with NetMail ModWeb Module; Mon, 19 May 2003 08:50:04 +0200 From: "lars lindgren" To: dwhite@gumbysoft.com Date: Mon, 19 May 2003 08:50:04 +0200 X-Mailer: NetMail ModWeb Module X-Sender: lasse.lindgren@home.se MIME-Version: 1.0 Message-ID: <1053327004.4ea07cc0lasse.lindgren@home.se> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable cc: freebsd-hackers@freebsd.org cc: freebsd-hackers-request@freebsd.org Subject: Re: Re: Pxe install freebsd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2003 06:50:47 -0000 the standard installation.=20 Now its up and running, the problem was that took out the whole stucture fr= om a .iso file, and the struckure did not match.. but its case solved now= . -----Original Message----- From: Doug White To: lars lindgren Date: Fri, 16 May 2003 18:50:36 -0700 (PDT) Subject: Re: Pxe install freebsd On Thu, 15 May 2003, lars lindgren wrote: > Its capable of pxebooting, (im from the linux world) hda is a 16M cf > Hdb is a standard harddrive. User interface is a serialport, running > @38400,8n1. NIC is a eepro100 > > The computer is currently installed with linux, but since i have many > computers like this one, i thought about migrating into freebsd. > > I guess in linuxterm's i need a kernel and a rootdisk with the install > package. I tried the ones from the cd, it didn't give me any output on > the serial port. (that i know workes, since before it loads the kernel i > have to type what it should boot ...) Serial port is running @38400,8n1 the default serial console speed for FreeBSD is 9600, for starters. The BIOS is doing some sort of vga to serial redirection? This sounds like the soekris equipment, although for mine I loaded the CF with a laptop. So exactly what are you trying to start? sysinstall? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org Lars Lindgren ---------------------------------------------------------------------------= ------------- "I'm on the path, he thought. I don't have to know where it leads. I just h= ave to follow." From owner-freebsd-hackers@FreeBSD.ORG Mon May 19 10:16:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4B6737B401 for ; Mon, 19 May 2003 10:16:12 -0700 (PDT) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E55243F75 for ; Mon, 19 May 2003 10:16:12 -0700 (PDT) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (mail [198.78.66.163])h4JHGSeq030974 for ; Mon, 19 May 2003 10:16:28 -0700 (PDT) (envelope-from user@mail.econolodgetulsa.com) Date: Mon, 19 May 2003 10:16:28 -0700 (PDT) From: Josh Brooks To: freebsd-hackers@freebsd.org Message-ID: <20030519100216.S46314-100000@mail.econolodgetulsa.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: ssh pty alloc broken in 4.8, just like it was in 4.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2003 17:16:13 -0000 Folks, In FreeBSD 4.4, if you set up a system with say ... 10-12 jails on it, and every jail user started 2-3 ssh logins, or a few screen sessions, etc., you would start to see people refused their logins - that is, they could not longer ssh into their server OR create additional screen windows. Even if you the following in the kernel: maxusers 512 pseudo-device pty 256 # Pseudo-ttys (telnet etc) and, _did_ the following in the base system /dev _and_ in the /dev of all the jailed systems: cd /dev for i in 1 2 3 4 5 6 7 ; do sh MAKEDEV pty$i ; done You would still see this problem. After a few discussions on -hackers, I was told that there was actually a bug in the sshd/ssh in 4.4 that affected its pty/tty allocation, and it seems as if this was true, because since 4.4 I have never seen this again. ----- Now it is back in 4.8. Maybe slightly different, but here is what I am seeing: With appropriate lines set in the kernel: maxusers 512 pseudo-device pty 256 # Pseudo-ttys (telnet etc) and with every pty created in /dev of the base system _and_ inside every jail: cd /dev for i in 1 2 3 4 5 6 7 ; do sh MAKEDEV pty$i ; done I now have jail users that cannot log in at all. When they attempt to ssh to their system they see: Warning: Remote host failed or refused to allocate a pseudo tty. and in /var/log/messages they see: May 10 10:38:18 jail sshd[455]: error: openpty: No such file or directory May 10 10:38:18 jail sshd[456]: error: session_pty_req: session 4 alloc failed So that's that. Again, identical machine, identical configuration, and _fewer_ jails than an identical 4.7 system I have running - haven't seen this happen since 4.4 and am very disappointed to see the error reintroduced now. a) what can I do to fix this, and what further troubleshooting can I do to help you solve this problem ? b) On the outside chance that this problem really does not occur in 4.8, and in reality I have some third issue that just ate up a ton of ptys in some weird way that is easy to reset, what is a good way to see all the ptys in use and their uses ? Any help it appreciated - as you can imagine, this is a fairly serious issue. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 01:04:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A61C937B401 for ; Tue, 20 May 2003 01:04:00 -0700 (PDT) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FE4243F85 for ; Tue, 20 May 2003 01:03:57 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.9/8.12.6) with ESMTP id h4K83iIW082443; Tue, 20 May 2003 17:33:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Scott Long , Garrett Wollman Date: Tue, 20 May 2003 17:33:43 +0930 User-Agent: KMail/1.5 References: <20030518005055.GG12759@sunbay.com> <200305192355.h4JNtx4e076037@khavrinen.lcs.mit.edu> <3EC986C6.5050800@btc.adaptec.com> In-Reply-To: <3EC986C6.5050800@btc.adaptec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305201733.43619.doconnor@gsoft.com.au> X-Spam-Score: -1.2 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: freebsd-hackers@freebsd.org Subject: Re: cvs commit: src/release/alpha dokern.sh drivers.conf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 08:04:00 -0000 [moved to -hackers] On Tue, 20 May 2003 11:07, Scott Long wrote: > The third step is to make the installer actually install the > user-supplied drivers. Right now sysinstall has an option for loading > KLD's from floppy, but that is all that it does. It doesn't help much > when the driver you are loading is the storage driver for your > installtion, and once you reboot the driver is not loaded automatically. You'd need some way of knowing whether it's worth trying to load the module - IMHO that is the difficult bit - it requires the most change to existing code and is more likely to break things. > I've wanted to work on this for quite a while, but I'm not sure I want > to further the viability of sysinstall. However, others with less of a > dislike of sysinstall are welcome to take this proposal and run with it. If you tell me how to work out whether it's worth loading a given module from a floppy I will quite happily write the code to implement it. Currently there is no special section which tells you whether you should try and load something because a known PCI ID is present (for example - and yes I know some modules use other criteria, but IMHO checking PCI ID's is a good start) You could just trying loading every module on a disk but that is slow and you can't really tell if the loaded module actually did anything useful without kludgery. IMHO the module itself should hold descriptions and lists of ID's, but if they have to be in a separate file then so be it. Currently I don't see a way of extracting PCI IDs from module source in a standard way which means the lists would have to be maintained manually and that would _suck_. Perhaps some standard struct array could be used, and if it isn't present then you can't do a guess about whether to load the module or not, so you just prompt the user. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 01:04:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8037B37B432 for ; Tue, 20 May 2003 01:04:08 -0700 (PDT) Received: from mail.icomag.de (ns.icomag.de [195.227.115.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 645DC43FB1 for ; Tue, 20 May 2003 01:04:07 -0700 (PDT) (envelope-from bgd@icomag.de) Received: by mail.icomag.de (Postfix, from userid 1019) id 478E823041; Tue, 20 May 2003 10:04:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.icomag.de (Postfix) with ESMTP id 450A223040; Tue, 20 May 2003 10:04:05 +0200 (CEST) Date: Tue, 20 May 2003 10:04:05 +0200 (CEST) From: Bogdan TARU X-X-Sender: To: Dag-Erling Smorgrav In-Reply-To: Message-ID: <20030520094427.K78063-100000@fw.office.icom> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@FreeBSD.ORG cc: Dan Nelson Subject: Re: linux binary blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 08:04:08 -0000 Hi Hackers, So, I have installed linux_kdump package, tried to run 'ktrace' on my binary and then analyze the ktrace.out with 'linux_kdump'. This is the point where it ain't working no more on the 4.7 jail system: 73506 engine NAMI "/var/run/engine.pid" 73506 engine RET linux_open 3 73506 engine CALL linux_fcntl64(0x3,0x6,0xbfbfe7b0) 73506 engine RET linux_fcntl64 -1 errno 22 Invalid argument And it works on the 4.8 jail system: 31291 engine NAMI "/var/run/engine.pid" 31291 engine RET linux_open 3 31291 engine CALL linux_fcntl64(0x3,0x6,0xbfbfe820) 31291 engine RET linux_fcntl64 0 31291 engine CALL linux_getpid 31291 engine RET linux_getpid 31291/0x7a3b 31291 engine CALL oftruncate(0x3,0) 31291 engine RET oftruncate 0 31291 engine CALL write(0x3,0x864c304,0x6) 31291 engine GIO fd 3 wrote 6 bytes So, again, any ideas why this linux binary can get a lock on the '/var/run/engine.pid' file under a freebsd 4.8 jail, and cannot on a 4.7 jail? Thank you, bogdan On Thu, 15 May 2003, Dag-Erling Smorgrav wrote: > Bogdan TARU writes: > > As about the third parameter to semget, as > > far as I can read in semget(2) the third parameter (flag) is an integer, > > not a pointer? > > 0xbfsomething is definitely a pointer to a stack variable. You're > probably using kdump instead of linux_kdump; syscall 221 is semget in > FreeBSD but fcntl64 in Linux. The first argument is the fd (notice > that it's 3 which is the result of the preceding open call; open is > syscall 5 in both FreeBSD and Linux, so this one is correct), the > second is the operation (6 == F_SETLK in Linux), and the third is the > argument (for F_SETLK, a pointer to a struct flock). > > I recommend 'pkg_add -r linux_kdump'. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 01:57:56 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A4D937B401 for ; Tue, 20 May 2003 01:57:56 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADAE343F93 for ; Tue, 20 May 2003 01:57:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc0ps.dialup.mindspring.com ([209.86.3.60] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19I2wA-0003DD-00; Tue, 20 May 2003 01:57:35 -0700 Message-ID: <3EC9ED56.56E9B12@mindspring.com> Date: Tue, 20 May 2003 01:54:46 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel O'Connor References: <20030518005055.GG12759@sunbay.com> <200305192355.h4JNtx4e076037@khavrinen.lcs.mit.edu> <200305201733.43619.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a40ae10a08791af2ca7c3b70df4e6d7065666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c cc: Garrett Wollman cc: Scott Long cc: freebsd-hackers@freebsd.org Subject: Re: cvs commit: src/release/alpha dokern.sh drivers.conf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 08:57:56 -0000 Daniel O'Connor wrote: > Currently I don't see a way of extracting PCI IDs from module source in a > standard way which means the lists would have to be maintained manually and > that would _suck_. Perhaps some standard struct array could be used, and if > it isn't present then you can't do a guess about whether to load the module > or not, so you just prompt the user. Add a seperate section for it. See the "--remove-section" and the "--add-section" and "--change-section" arguments to the "objcopy" program for how to maintain the lists seperate from the driver (even works with binary-only drivers for which you don't have source, so long as there's a defined structure that's a known type for the ID list sources, and has a NULL terminator on the list and/or uses a linker set type construct). You could even have a program that you "objcopy" the section from the module into, which could then spit out source code by printing out the ID table by direct reference to the table itself; tack your new IDs to the end of the ID list that gets spit out, recompile it, and drop it; or just link against the same "bfd" library "objcopy" links against, and make a small edit program ("vielf" or whatever). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 03:44:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F27F37B401 for ; Tue, 20 May 2003 03:44:18 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCF8943FAF for ; Tue, 20 May 2003 03:44:17 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 6CD2E530E; Tue, 20 May 2003 12:44:16 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bogdan TARU References: <20030520094427.K78063-100000@fw.office.icom> From: Dag-Erling Smorgrav Date: Tue, 20 May 2003 12:44:15 +0200 In-Reply-To: <20030520094427.K78063-100000@fw.office.icom> (Bogdan TARU's message of "Tue, 20 May 2003 10:04:05 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@FreeBSD.ORG cc: Dan Nelson Subject: Re: linux binary blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 10:44:18 -0000 Bogdan TARU writes: > So, again, any ideas why this linux binary can get a lock on the > '/var/run/engine.pid' file under a freebsd 4.8 jail, and cannot on a 4.7 > jail? Check that the /var/run permissions are the same on both; delete the pid file before starting the process. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 04:06:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8288A37B401 for ; Tue, 20 May 2003 04:06:06 -0700 (PDT) Received: from mail.icomag.de (ns.icomag.de [195.227.115.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FE5B43F85 for ; Tue, 20 May 2003 04:06:05 -0700 (PDT) (envelope-from bgd@icomag.de) Received: by mail.icomag.de (Postfix, from userid 1019) id 6B85823043; Tue, 20 May 2003 13:06:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.icomag.de (Postfix) with ESMTP id 6A8AB23042; Tue, 20 May 2003 13:06:04 +0200 (CEST) Date: Tue, 20 May 2003 13:06:04 +0200 (CEST) From: Bogdan TARU X-X-Sender: To: Dag-Erling Smorgrav In-Reply-To: Message-ID: <20030520130318.T78526-100000@fw.office.icom> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@FreeBSD.ORG Subject: Re: linux binary blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 11:06:06 -0000 Hi, The /var/run directory has the same permissions (engine.pid file is created, after all). Not the opening of the file, but rather the call to 'semget' (when trying to lock the pid file). bogdan ---------------------------- iCom Media AG Kirchweg 36 Koln, 50858 Germany Phone: +49-(0)221-485-689-16 Fax : +49-(0)221-485-689-20 Mobile:+49-(0)173-269-76-62 On Tue, 20 May 2003, Dag-Erling Smorgrav wrote: > Bogdan TARU writes: > > So, again, any ideas why this linux binary can get a lock on the > > '/var/run/engine.pid' file under a freebsd 4.8 jail, and cannot on a 4.7 > > jail? > > Check that the /var/run permissions are the same on both; delete the > pid file before starting the process. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 06:15:42 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E63737B401 for ; Tue, 20 May 2003 06:15:42 -0700 (PDT) Received: from honolulu.procergs.com.br (honolulu.procergs.com.br [200.198.128.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD6C143F85 for ; Tue, 20 May 2003 06:15:40 -0700 (PDT) (envelope-from marcelo-leal@procergs.rs.gov.br) Received: from ws-tor-0004.procergs (unknown [172.28.5.20]) by honolulu.procergs.com.br (Postfix) with ESMTP id D963AAAC1 for ; Tue, 20 May 2003 10:15:37 -0300 (BRT) Received: by ws-tor-0004.procergs (Postfix, from userid 1000) id 3395210214; Tue, 20 May 2003 10:15:37 -0300 (BRT) Received: from procergs.rs.gov.br (localhost [127.0.0.1]) by ws-tor-0004.procergs (Postfix) with ESMTP id 1D42210213 for ; Tue, 20 May 2003 10:15:37 -0300 (BRT) From: omestre@freeshell.org To: freebsd-hackers@freebsd.org Date: Tue, 20 May 2003 10:15:31 -0300 Sender: marcelo-leal@procergs.rs.gov.br Message-Id: <20030520131537.3395210214@ws-tor-0004.procergs> Subject: production... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 13:15:42 -0000 Hello, Many of us must have problems with unix like production servers, many services running, and administrative jobs. Where i'm working, there are the experiences with Mainframes and his controlled environment. All tasks were defined, and well defined. The operator tasks were defided too, without talk about security level... Well, what i want? So, i want to know, if somebody knows about projects (sourceforge), or comercial ones, that are trying fix that problem in unix plataform. Production scheduler. i guess that many aspects about this problem, can be resolved using scripts, and dialogs (menus). But, we have the internet, and nothing is created... is changed and shared. We are thinking about implement some (bash, tcl or perl) scripts to give to unix like operating sistems, the face of a trust environment. No, no... i know that the unix is stable, and i trust it... i talk about "operation". A environment to "add" sites, mana- ging mail, dns and so on... I am not talking about "webmin". I'm talking about, "maybe", scripts to "jail" the operator in his job. I'm talking about administration tasks that we are making every day, but without a environment to this. A framework to be changed, shared, and no more command prompt. "Imagine" a server managed by menus, in diferent levels, but well structured. With functions, chances to edit file... Sorry by the english, and i hope that you can understand what i mean. Any answers will be cool. thanks, and sorry again. --- From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 06:35:10 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BB3437B401 for ; Tue, 20 May 2003 06:35:10 -0700 (PDT) Received: from memphis.mephi.ru (memphis.mephi.ru [194.67.67.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 629C443FAF for ; Tue, 20 May 2003 06:35:05 -0700 (PDT) (envelope-from timon@memphis.mephi.ru) Received: from [81.195.8.124] (ppp8-124.pppoe.mtu-net.ru [81.195.8.124]) (authenticated bits=0) by memphis.mephi.ru (8.12.6p2/8.12.6) with ESMTP id h4KDYlh6050712 for ; Tue, 20 May 2003 17:34:53 +0400 (MSD) (envelope-from timon@memphis.mephi.ru) From: "Artem 'Zazoobr' Ignatjev" To: freebsd-hackers@freebsd.org In-Reply-To: <20030520131537.3395210214@ws-tor-0004.procergs> References: <20030520131537.3395210214@ws-tor-0004.procergs> Content-Type: text/plain Organization: Message-Id: <1053437797.1444.5.camel@hx.nist> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 20 May 2003 17:36:39 +0400 Content-Transfer-Encoding: 7bit Subject: Re: production... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 13:35:10 -0000 In Tue, 20.05.2003, at 17:15, omestre@freeshell.org wrote: > I'm talking about, "maybe", scripts to "jail" the operator > in his job. I'm talking about administration tasks that we > are making every day, but without a environment to this. A > framework to be changed, shared, and no more command prompt. > "Imagine" a server managed by menus, in diferent levels, but > well structured. With functions, chances to edit file... > Sorry by the english, and i hope that you can understand > what i mean. > Any answers will be cool. Instead of image of such server i remembered a linuxconf... Nah, that's not the thing I want on my server. I really love shell, since absence of all this windows `Click-n-go' fuss makes me really think, what and how should be done to get a really Good Things(TM) as result. From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 06:56:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBAC037B401 for ; Tue, 20 May 2003 06:56:37 -0700 (PDT) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 191CB43F93 for ; Tue, 20 May 2003 06:56:37 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h4KDuacL012230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 May 2003 09:56:36 -0400 (EDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id h4KDuamA012229 for freebsd-hackers@freebsd.org; Tue, 20 May 2003 09:56:36 -0400 (EDT) Date: Tue, 20 May 2003 09:56:36 -0400 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20030520135636.GA12088@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20030520131537.3395210214@ws-tor-0004.procergs> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <20030520131537.3395210214@ws-tor-0004.procergs> Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: Re: production... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 13:56:38 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Tue, May 20, 2003 at 10:15:31AM -0300, omestre@free= shell.org wrote: > "Imagine" a server managed by menus, in diferent levels, but > well structured. With functions, chances to edit file... You don't have to imagine. I believe Windows Server 2003 is a server managed by menus. :) --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+yjQUNh6mMG5yMTYRAmGMAJ485CnNHC80QuXd13KjPp08LFoWcwCfaqid oCDwkxELkwVYW5ydSxBXyfk= =/Veb -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 07:36:43 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15BCA37B401 for ; Tue, 20 May 2003 07:36:43 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 624A143F93 for ; Tue, 20 May 2003 07:36:42 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h4KEaeeX069123; Tue, 20 May 2003 09:36:40 -0500 (CDT) (envelope-from dan) Date: Tue, 20 May 2003 09:36:40 -0500 From: Dan Nelson To: Bogdan TARU Message-ID: <20030520143639.GA26422@dan.emsphone.com> References: <20030520094427.K78063-100000@fw.office.icom> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030520094427.K78063-100000@fw.office.icom> X-OS: FreeBSD 5.1-BETA X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-hackers@FreeBSD.ORG cc: Dag-Erling Smorgrav Subject: Re: linux binary blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 14:36:43 -0000 In the last episode (May 20), Bogdan TARU said: > So, I have installed linux_kdump package, tried to run 'ktrace' on my > binary and then analyze the ktrace.out with 'linux_kdump'. This is > the point where it ain't working no more on the 4.7 jail system: > > 73506 engine NAMI "/var/run/engine.pid" > 73506 engine RET linux_open 3 > 73506 engine CALL linux_fcntl64(0x3,0x6,0xbfbfe7b0) > 73506 engine RET linux_fcntl64 -1 errno 22 Invalid argument > > And it works on the 4.8 jail system: > > 31291 engine NAMI "/var/run/engine.pid" > 31291 engine RET linux_open 3 > 31291 engine CALL linux_fcntl64(0x3,0x6,0xbfbfe820) > 31291 engine RET linux_fcntl64 0 > > So, again, any ideas why this linux binary can get a lock on the > '/var/run/engine.pid' file under a freebsd 4.8 jail, and cannot on a > 4.7 jail? There were fixes to the linux_fcntl64 syscall that went in between 4.7 and 4.8: revision 1.72 date: 2002/12/08 18:30:44; author: iedowse; state: Exp; lines: +33 -39 Fix emulation of the fcntl64() syscall. In Linux, this is exactly the same as fcntl() except that it supports the new 64-bit file locking commands (LINUX_F_GETLK64 etc) that use the `flock64' structure. We had been interpreting all flock structures passed to fcntl64() as `struct flock64' instead of only the ones from F_*64 commands. The glibc in linux_base-7 uses fcntl64() by default, but the bug was often non-fatal since the misinterpretation typically only causes junk to appear in the `l_len' field and most junk values are accepted as valid range lengths. The result is occasional EINVAL errors from F_SETLK and a few bytes after the supplied `struct flock' getting clobbered during F_GETLK. revision 1.41.2.6 date: 2003/01/06 09:19:43; author: fjoe; state: Exp; lines: +43 -47 MFC: fcntl64 fixes -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 08:11:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EA5137B404 for ; Tue, 20 May 2003 08:11:44 -0700 (PDT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF59243FB1 for ; Tue, 20 May 2003 08:11:42 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay.macomnet.ru (8.11.6/8.11.6) with ESMTP id h4KFBdl5662923; Tue, 20 May 2003 19:11:39 +0400 (MSD) Date: Tue, 20 May 2003 19:11:38 +0400 (MSD) From: Maxim Konovalov To: Marco Wertejuk In-Reply-To: <20030516153333.GA29165@maeko> Message-ID: <20030520190746.P6042@news1.macomnet.ru> References: <20030514184845.GA7573@maeko> <20030515114239.Y95792@news1.macomnet.ru> <20030516153333.GA29165@maeko> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: vlan/bridging broken in 4.8-release? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 15:11:44 -0000 On 17:33+0200, May 16, 2003, Marco Wertejuk wrote: > Hello Maxim, > > | I am trying to solve some bugs in bridging code in -current. I > | believe we have the same bugs in -stable as well. First of all, do > | not use bridge.ko, use 'options BRIDGE' in your kernel config file > | instead. Second, try to play with net.inet.ip.check_interface sysctl. > > the bridge option is statically compiled into the kernel and > I could not see any change when playing around with > net.inet.ip.check_interface. > > Any other ideas? Try this patch^Whack. Index: if_ethersubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v retrieving revision 1.147 diff -u -r1.147 if_ethersubr.c --- if_ethersubr.c 5 May 2003 09:15:50 -0000 1.147 +++ if_ethersubr.c 20 May 2003 15:06:50 -0000 @@ -625,6 +625,7 @@ if (rule) /* packet was already bridged */ goto post_stats; +#if 0 if (!(BDG_ACTIVE(ifp))) { /* * Discard packet if upper layers shouldn't see it because it @@ -641,6 +642,7 @@ return; } } +#endif /* Discard packet if interface is not up */ if ((ifp->if_flags & IFF_UP) == 0) { %%% Btw http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46961 looks similar. -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 08:51:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AA4D37B405 for ; Tue, 20 May 2003 08:51:53 -0700 (PDT) Received: from honolulu.procergs.com.br (honolulu.procergs.com.br [200.198.128.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4074943FB1 for ; Tue, 20 May 2003 08:51:51 -0700 (PDT) (envelope-from marcelo-leal@procergs.rs.gov.br) Received: from ws-tor-0004.procergs (unknown [172.28.5.20]) by honolulu.procergs.com.br (Postfix) with ESMTP id 2CFF8A9A0; Tue, 20 May 2003 12:51:49 -0300 (BRT) Received: by ws-tor-0004.procergs (Postfix, from userid 1000) id 7A21E10214; Tue, 20 May 2003 12:51:48 -0300 (BRT) Received: from procergs.rs.gov.br (localhost [127.0.0.1]) by ws-tor-0004.procergs (Postfix) with ESMTP id 7516A10213; Tue, 20 May 2003 12:51:48 -0300 (BRT) From: omestre@freeshell.org To: "Sparrevohn, Thomas" In-Reply-To: Message from "Sparrevohn, Thomas" <2946E9F05C8DD511A7DC0002A5608CE4BEC420@GBCHM201> References: <2946E9F05C8DD511A7DC0002A5608CE4BEC420@GBCHM201> Date: Tue, 20 May 2003 12:51:43 -0300 Sender: marcelo-leal@procergs.rs.gov.br Message-Id: <20030520155148.7A21E10214@ws-tor-0004.procergs> cc: freebsd-hackers@freebsd.org Subject: Re: production... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 15:51:53 -0000 Thanks, very much! Many ideas and i will see each one... About Windows 2003, the another answer to this list, i will think that the "guy" do not understand my "terrible" english. :) Thanks again. From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 08:59:16 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BC3937B410 for ; Tue, 20 May 2003 08:59:16 -0700 (PDT) Received: from jet.kar.net (jet.kar.net [195.178.131.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 005AB43FB1 for ; Tue, 20 May 2003 08:59:13 -0700 (PDT) (envelope-from r0land@r0land.kiev.ua) Received: from pepelac (developex.kar.net [195.178.133.26]) by jet.kar.net (8.11.6p2/8.11.6) with SMTP id h4KFwvg62005; Tue, 20 May 2003 18:58:58 +0300 (EEST) (envelope-from r0land@r0land.kiev.ua) Message-ID: <034601c31ee9$0d4cdc20$8300a8c0@pepelac> From: "Maksym Shevchenko" To: References: <20030520131537.3395210214@ws-tor-0004.procergs> <1053437797.1444.5.camel@hx.nist> Date: Tue, 20 May 2003 19:01:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 FL-Build: Fidolook Express 2000 UIExt. BuildID: 3BC00FAD (7/10/2001 11:17:49). cc: freebsd-hackers@freebsd.org Subject: Re: production... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Maksym Shevchenko List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 15:59:17 -0000 Hello, Artem! You wrote to on 20 May 2003 17:36:39 +0400: AZI> In Tue, 20.05.2003, at 17:15, omestre@freeshell.org wrote: >> I'm talking about, "maybe", scripts to "jail" the operator in his >> job. I'm talking about administration tasks that we are making every >> day, but without a environment to this. A framework to be changed, >> shared, and no more command prompt. >> "Imagine" a server managed by menus, in diferent levels, but well >> structured. With functions, chances to edit file... >> Sorry by the english, and i hope that you can understand what i mean. >> Any answers will be cool. AZI> Instead of image of such server i remembered a linuxconf... Nah, AZI> that's not the thing I want on my server. AZI> I really love shell, since absence of all this windows `Click-n-go' AZI> fuss makes me really think, what and how should be done to get a AZI> really Good AZI> Things(TM) as result. It is possible that he means other thing useful. As example, in hosting solutions with a numbers of hosting on each server, keeping configuration of each service (as usual - dns, mail, http (dynamic & static content), ftp, telnet/ssh, some kind of sql) in decentralized files are not too simply. I never seen systems (but had try to build) that will keep configuration for such hosting centralized database (possible with simply export to usual configuration files). For instance in such tree: ----------------------[begin of instance]--------------------------- 1) Agreement information a. Contact information b. Agreement number c. Expire date d. ... 2) DNS a. Allowed b. Primary "superns1.superhosting.com" c. Secondary "superns2.superhosting.com" d. Name zone 1 (SOA entry) i. Entry ii. ... e. Name zone 2 i. Entry (MX) ii. Entry (IN A) iii. ... 3) Mail a. SMTP i. Disallowed ii. ... b. POP3 i. Allowed ii. ... 4) Web Hosting a. Allowed server "apache043.superhosting.com" i. Root dir "$HOME_APACHE043/user/htdocs" ii. CGI dir "$HOME_APACHE043/user/cgi-bin" iii. ... 5) Ftp a. Allowed server "apache043.superhosting.com" b. ... 6) Telnet/SSH a. Disallowed 7) SQL a. PostgreSQL i. Disallowed b. MySQL i. Allowed server apache043.superhosting.com" 1. Data dir "/home/user/sql/data" 2. Used local socket "/home/user/sql/sock.tmp" 3. Network socket "disallowed" 4. Bin dir 5. ... ----------------------[end of instance]---------------------- What about such centralized configuration systems? -- With best regards, Maksym Shevchenko. E-mail: r0land@r0land.kiev.ua From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 09:23:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40D3637B401 for ; Tue, 20 May 2003 09:23:46 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58C7343F3F for ; Tue, 20 May 2003 09:23:43 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h4KGNgkA004545 for ; Tue, 20 May 2003 10:23:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 20 May 2003 10:20:06 -0600 (MDT) Message-Id: <20030520.102006.08403290.imp@bsdimp.com> To: freebsd-hackers@freebsd.org From: "M. Warner Losh" In-Reply-To: <200305201733.43619.doconnor@gsoft.com.au> References: <200305192355.h4JNtx4e076037@khavrinen.lcs.mit.edu> <3EC986C6.5050800@btc.adaptec.com> <200305201733.43619.doconnor@gsoft.com.au> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: cvs commit: src/release/alpha dokern.sh drivers.conf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 16:23:46 -0000 In message: <200305201733.43619.doconnor@gsoft.com.au> "Daniel O'Connor" writes: : Currently I don't see a way of extracting PCI IDs from module source in a : standard way which means the lists would have to be maintained manually and : that would _suck_. Perhaps some standard struct array could be used, and if : it isn't present then you can't do a guess about whether to load the module : or not, so you just prompt the user. One of things on my list is to make it possible to have more than just PCI id's extractable from drivers. It is needed for devd so it can load the right things when it encounters devices for which there are no drivers. If the loader wants to do it too, that would be fine, but the only thing that I can think of that doing it in the loader would buy you that doing it in devd wouldn't is the ability to kldload the driver(s) necessary for the root device and not have them hard coded in your /boot/loader.conf file. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 10:11:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A0BF37B401 for ; Tue, 20 May 2003 10:11:02 -0700 (PDT) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id F215B43FAF for ; Tue, 20 May 2003 10:11:00 -0700 (PDT) (envelope-from babolo@aaz.links.ru) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by aaz.links.ru (8.12.7/8.12.6) with ESMTP id h4KHHRJN095380; Tue, 20 May 2003 21:17:27 +0400 (MSD) (envelope-from babolo@aaz.links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.12.7/8.12.6/Submit) id h4KHHPIK095379; Tue, 20 May 2003 21:17:25 +0400 (MSD) Message-Id: <200305201717.h4KHHPIK095379@aaz.links.ru> X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <034601c31ee9$0d4cdc20$8300a8c0@pepelac> To: Maksym Shevchenko Date: Tue, 20 May 2003 21:17:25 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 cc: freebsd-hackers@freebsd.org cc: omestre@freeshell.org Subject: Re: production... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 17:11:02 -0000 > Hello, Artem! > > It is possible that he means other thing useful. As example, in hosting > solutions with a numbers of hosting on each server, keeping configuration of > each service (as usual - dns, mail, http (dynamic & static content), ftp, > telnet/ssh, some kind of sql) in decentralized files are not too simply. I > never seen systems (but had try to build) that will keep configuration for > such hosting centralized database (possible with simply export to usual > configuration files). > For instance in such tree: > ----------------------[begin of instance]--------------------------- > 1) Agreement information > a. Contact information > b. Agreement number > c. Expire date > d. ... > 2) DNS > a. Allowed > b. Primary "superns1.superhosting.com" > c. Secondary "superns2.superhosting.com" > d. Name zone 1 (SOA entry) > i. Entry > ii. ... > e. Name zone 2 > i. Entry (MX) > ii. Entry (IN A) > iii. ... > 3) Mail > a. SMTP > i. Disallowed > ii. ... > b. POP3 > i. Allowed > ii. ... > 4) Web Hosting > a. Allowed server "apache043.superhosting.com" > i. Root dir "$HOME_APACHE043/user/htdocs" > ii. CGI dir "$HOME_APACHE043/user/cgi-bin" > iii. ... > 5) Ftp > a. Allowed server "apache043.superhosting.com" > b. ... > 6) Telnet/SSH > a. Disallowed > 7) SQL > a. PostgreSQL > i. Disallowed > b. MySQL > i. Allowed server apache043.superhosting.com" > 1. Data dir "/home/user/sql/data" > 2. Used local socket "/home/user/sql/sock.tmp" > 3. Network socket "disallowed" > 4. Bin dir > 5. ... > ----------------------[end of instance]---------------------- > > What about such centralized configuration systems? Part of this work is http://free.babolo.ru/ports/jailup/ (BSD license) and some is ISPMS/ISPDB (restricted), very old version for evaluation is http://free.babolo.ru/ports/ispms/ Yes, not all needs done yet. -- @BABOLO http://links.ru/ From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 13:40:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08D8E37B401 for ; Tue, 20 May 2003 13:40:34 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F73B43F3F for ; Tue, 20 May 2003 13:40:33 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h4KKaKZ26172; Tue, 20 May 2003 13:36:20 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id NAA27444; Tue, 20 May 2003 13:40:15 -0700 (PDT) Message-ID: <3ECA91FD.1090509@btc.adaptec.com> Date: Tue, 20 May 2003 14:37:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <20030518005055.GG12759@sunbay.com> <200305192355.h4JNtx4e076037@khavrinen.lcs.mit.edu> <3EC986C6.5050800@btc.adaptec.com> <200305201733.43619.doconnor@gsoft.com.au> In-Reply-To: <200305201733.43619.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Garrett Wollman cc: freebsd-hackers@freebsd.org Subject: Re: cvs commit: src/release/alpha dokern.sh drivers.conf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 20:40:34 -0000 Daniel O'Connor wrote: > [moved to -hackers] > > On Tue, 20 May 2003 11:07, Scott Long wrote: > >>The third step is to make the installer actually install the >>user-supplied drivers. Right now sysinstall has an option for loading >>KLD's from floppy, but that is all that it does. It doesn't help much >>when the driver you are loading is the storage driver for your >>installtion, and once you reboot the driver is not loaded automatically. > > > You'd need some way of knowing whether it's worth trying to load the module - > IMHO that is the difficult bit - it requires the most change to existing code > and is more likely to break things. > > >>I've wanted to work on this for quite a while, but I'm not sure I want >>to further the viability of sysinstall. However, others with less of a >>dislike of sysinstall are welcome to take this proposal and run with it. > > > If you tell me how to work out whether it's worth loading a given module from > a floppy I will quite happily write the code to implement it. > > Currently there is no special section which tells you whether you should try > and load something because a known PCI ID is present (for example - and yes I > know some modules use other criteria, but IMHO checking PCI ID's is a good > start) > > You could just trying loading every module on a disk but that is slow and you > can't really tell if the loaded module actually did anything useful without > kludgery. > > IMHO the module itself should hold descriptions and lists of ID's, but if they > have to be in a separate file then so be it. > > Currently I don't see a way of extracting PCI IDs from module source in a > standard way which means the lists would have to be maintained manually and > that would _suck_. Perhaps some standard struct array could be used, and if > it isn't present then you can't do a guess about whether to load the module > or not, so you just prompt the user. > Having dealt with it in FreeBSD, SuSE, and RedHat, I see four possibilities. 1. The RedHat way: driver floppies carry a pci-id table file of id's that the driver supports. RedHat of course is a bit silly about this since their table only covers the Device and Vendor ID's and leaves out the sub-* Id's. It also doesn't have any wildcard matching capabilities. Also, it requires a separate effort to keep this table in sync with the driver. Certain scripting magic might be employed to help with this. 2. The SuSE way: driver disks contain only modules, and are loaded in a brute-force manner. I'm not really sure if they know that a driver succeeded/failed to load, and I think they just blindly install whatever drivers the user supplied. 3. Update the driver API to include requirements to give a PCI ID table in a certain format, and then update the module building framework to take this table and turn it into an elf section or something similar. 4. Update the kldload semantics so that the kldload syscall returns an indication of the driver's attach success/failure. This will allow the brute-force method to intelligently work. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 14:22:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAEA337B401 for ; Tue, 20 May 2003 14:22:28 -0700 (PDT) Received: from newman.nssi.telus.com (newman.nssi.telus.com [208.38.59.87]) by mx1.FreeBSD.org (Postfix) with SMTP id D30C543FAF for ; Tue, 20 May 2003 14:22:27 -0700 (PDT) (envelope-from nader.atoofi@telus.com) Received: (qmail 10229 invoked from network); 20 May 2003 21:22:27 -0000 Received: from unknown (HELO abmsg003.corp.ads) (142.178.61.86) by 142.178.52.235 with SMTP; 20 May 2003 21:22:27 -0000 Received: from 142.178.232.46 by abmsg003.corp.ads with ESMTP ( (MMS v4.7);); Tue, 20 May 2003 15:22:26 -0600 X-Server-Uuid: 62333db7-76d7-4c1e-8695-ae6a73d58b85 Received: from abmsg005.corp.ads ([142.178.232.33]) by abmsg009.corp.ads with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 May 2003 15:22:26 -0600 Received: from abmsg010.corp.ads ([142.178.232.79]) by abmsg005.corp.ads with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 May 2003 15:22:26 -0600 Received: from bcmsg011.corp.ads ([142.174.11.177]) by abmsg010.corp.ads with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 May 2003 15:22:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2003 14:22:24 -0700 Message-ID: <0DC2A4733C6E8A42A66702B4B7B862DF510BBC@bcmsg011.corp.ads> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A utility to retrieve system configuration Thread-Index: AcMfFef7ICZgcMobRPSX7x1cYfKjsA== From: "Nader Atoofi" To: freebsd-hackers@freebsd.org X-OriginalArrivalTime: 20 May 2003 21:22:26.0328 (UTC) FILETIME=[E92C6180:01C31F15] X-WSS-ID: 12D443183291854-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: A utility to retrieve system configuration X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 21:22:29 -0000 Hi All, Is there any utility/script in FreeBSD to collect system configuration = information from the system for recovery purposes. I'm looking for = something like Sun Explorer in Solaris or Snap in AIX. Thanks, Nader Atoofi Senior Solaris Admin email: nader.atoofi@telus.com TELUS Enterprise Solutions Unix SERVICES - Sun Team From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 14:35:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E402137B401 for ; Tue, 20 May 2003 14:35:14 -0700 (PDT) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 270B443FA3 for ; Tue, 20 May 2003 14:35:14 -0700 (PDT) (envelope-from schweikh@schweikhardt.net) Received: from bremen.shuttle.de (localhost [127.0.0.1]) by bremen.shuttle.de (Postfix) with ESMTP id AC790182EB for ; Tue, 20 May 2003 22:35:25 +0200 (CEST) Received: (from uucp@localhost)h4KKZPi3016612 for freebsd-hackers@freebsd.org; Tue, 20 May 2003 22:35:25 +0200 Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.12.9/8.12.9) id h4KKZCT3003060 for freebsd-hackers@freebsd.org; Tue, 20 May 2003 22:35:12 +0200 (CEST) (envelope-from schweikh) Date: Tue, 20 May 2003 22:35:12 +0200 From: Jens Schweikhardt To: freebsd-hackers@freebsd.org Message-ID: <20030520203512.GB99242@schweikhardt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Converting /usr/bin/vgrind from csh to sh X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 21:35:15 -0000 hello, world\n currently vgrind is apparently the only csh script we have: schweikh@hal9000:~ $ file /bin/* /sbin/* /usr/bin/* /usr/sbin/* | grep C.shell /usr/bin/vgrind: C shell script text executable I've tried to build a system with NO_TCSH in /etc/make.conf. This does work, but if you then remove /bin/csh or if you installworld with DESTDIR somewhere else than the default, you have a system that's no longer able to *build* the world. So what we have here is delayed system snafu due to a supported(?) buildworld option. The failure mode of buildworld on a system without /bin/csh (with NO_TCSH) is ===> share/doc/papers/kernmalloc touch _stamp.extraobjs (cd /src/current/share/doc/papers/kernmalloc; soelim kernmalloc.t) > kernmalloc.ms vgrind -f < /src/current/share/doc/papers/kernmalloc/appendix.t > appendix.ms vgrind: not found <-- misleading message; it is /bin/csh that is not found *** Error code 127 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error So I rewrote vgrind as a /bin/sh script, appended below. I've tested it and it produces the same file during the one use in our buildworld (i.e. /usr/obj/usr/src/share/doc/papers/kernmalloc/appendix.ms) Please give it some more hammering and report any bogons you find. If nobody jumps up and down, I'll commit as soon as 5.1 is out the door. Thanks! Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) #!/bin/sh # # Copyright (c) 1980, 1993 # The Regents of the University of California. All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # 3. All advertising materials mentioning features or use of this software # must display the following acknowledgement: # This product includes software developed by the University of # California, Berkeley and its contributors. # 4. Neither the name of the University nor the names of its contributors # may be used to endorse or promote products derived from this software # without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # @(#)vgrind.sh 8.1 (Berkeley) 6/6/93 # # $FreeBSD: src/usr.bin/vgrind/vgrind.sh,v 1.3 2002/09/24 19:05:40 ache Exp $ # voptions="" options="" files="" f="" head="" vf="/usr/libexec/vfontedpr" tm="/usr/share/tmac" postproc="psroff" # Parse args while test $# -gt 0; do case $1 in -f) f="filter" options="$options -f" ;; -t) voptions="$voptions -t" ;; -o*) voptions="$voptions $1" ;; -W) voptions="$voptions -W" ;; -d) if test $# -lt 2; then echo "$0: option $1 must have argument" >&2 exit 1 fi options="$options $1 $2" shift ;; -h) if test $# -lt 2; then echo "$0: option $1 must have argument" >&2 exit 1 fi head="$2" shift ;; -p) if test $# -lt 2; then echo "$0: option $1 must have argument" >&2 exit 1 fi postproc="$2" shift ;; -*) options="$options $1" ;; *) files="$files $1" ;; esac shift done if test -r index; then : > nindex for i in $files; do # make up a sed delete command for filenames # being careful about slashes. echo "? $i ?d" | sed -e "s:/:\\/:g" -e "s:?:/:g" >> nindex done sed -f nindex index > xindex if test "x$f" = xfilter; then if test "x$head" != x; then $vf $options -h "$head" $files else $vf $options $files fi | cat $tm/tmac.vgrind - else if test "x$head" != x; then $vf $options -h "$head" $files else $vf $options $files fi | sh -c "$postproc -rx1 $voptions -i -mvgrind 2>> xindex" fi sort -df -k 1,2 xindex > index rm nindex xindex else if test "x$f" = xfilter; then if test "x$head" != x; then $vf $options -h "$head" $files else $vf $options $files fi | cat $tm/tmac.vgrind - else if test "x$head" != x; then $vf $options -h "$head" $files else $vf $options $files fi | $postproc -i $voptions -mvgrind fi fi From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 15:31:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4507537B401 for ; Tue, 20 May 2003 15:31:12 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 112CB43F93 for ; Tue, 20 May 2003 15:31:09 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h4KMV5Ed058006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2003 01:31:05 +0300 (EEST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h4KMV4Oq058001; Wed, 21 May 2003 01:31:05 +0300 (EEST) (envelope-from ru) Date: Wed, 21 May 2003 01:31:04 +0300 From: Ruslan Ermilov To: Jens Schweikhardt Message-ID: <20030520223104.GC40964@sunbay.com> References: <20030520203512.GB99242@schweikhardt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m51xatjYGsM+13rf" Content-Disposition: inline In-Reply-To: <20030520203512.GB99242@schweikhardt.net> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: Converting /usr/bin/vgrind from csh to sh X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 22:31:12 -0000 --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 20, 2003 at 10:35:12PM +0200, Jens Schweikhardt wrote: [...] > So I rewrote vgrind as a /bin/sh script, appended below. I've tested it > and it produces the same file during the one use in our buildworld (i.e. > /usr/obj/usr/src/share/doc/papers/kernmalloc/appendix.ms) Please give it > some more hammering and report any bogons you find. If nobody jumps up > and down, I'll commit as soon as 5.1 is out the door. Thanks! >=20 I've reviewed your script; it has only one bogon -- it changes the tab to a sequence of spaces in the SCCS ID string, but then it's maybe due to an email software. Other than that, the script is good, and I'd like to see it committed. Thanks for working on this! Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --m51xatjYGsM+13rf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+yqyoUkv4P6juNwoRAtAAAJ9R9Efx4roy+vYHES71pWxYzbBjwACggIiT 0p0ybxW94YR8JouTXQ5oDqY= =xmyT -----END PGP SIGNATURE----- --m51xatjYGsM+13rf-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 16:13:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AD9E37B401 for ; Tue, 20 May 2003 16:13:09 -0700 (PDT) Received: from viper.evilrealms.net (evilrealms.demon.co.uk [62.49.12.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD53643F3F for ; Tue, 20 May 2003 16:13:07 -0700 (PDT) (envelope-from jay@viper.evilrealms.net) Received: from viper.evilrealms.net (jay@localhost [127.0.0.1]) by viper.evilrealms.net (8.12.8/8.12.8) with ESMTP id h4KNDAFi007346 for ; Wed, 21 May 2003 00:13:10 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by viper.evilrealms.net (8.12.8/8.12.8/Submit) id h4KNDAE6007345 for freebsd-hackers@freebsd.org; Wed, 21 May 2003 00:13:10 +0100 From: Jay Cornwall To: freebsd-hackers@freebsd.org Date: Wed, 21 May 2003 00:13:07 +0100 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200305210013.09834.jay@evilrealms.net> Subject: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 23:13:09 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I've been trying (unsuccessfully) to make the thread-based pppoa3 program=20 (from http://speedtouch.sf.net/) able to work correctly under FreeBSD. Near= =20 identical code works fine under Linux, but the threading doesn't work at al= l=20 in FreeBSD. The problem seems to be a result of reading from a USB endpoint file=20 descriptor, which invokes tsleep() within the kernel=20 (/sys/dev/usb/usbdi_util.c:432) while it waits for data to read. This has t= he=20 effect of blocking the whole process, rather than just the thread which=20 called the read. I'm sure there are good reasons for implementing it in this way, but I'd be= =20 interested to hear what they are, and if any alternative approaches had=20 been/are being considered. =46orgive my lack of knowledge with the FreeBSD kernel, I've only been usin= g it=20 for a couple of weeks. :( Cheers, Jay =2D --=20 http://www.evilrealms.net/ - Systems Administrator & Developer http://www.ic.ac.uk/ - Imperial College, 2nd year CS student =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+yraFfJLn3O/2GbERAsFGAJ947XIElRiR0sz7U7O1nq73N0ccMACcD0bT fWLxgfMSx9n4/1ktz+kOclU=3D =3D1SjD =2D----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 16:40:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D251E37B401 for ; Tue, 20 May 2003 16:40:18 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2164643FA3 for ; Tue, 20 May 2003 16:40:18 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc03) with ESMTP id <200305202340170030095eu3e>; Tue, 20 May 2003 23:40:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA67020; Tue, 20 May 2003 16:40:15 -0700 (PDT) Date: Tue, 20 May 2003 16:40:14 -0700 (PDT) From: Julian Elischer To: Jay Cornwall In-Reply-To: <200305210013.09834.jay@evilrealms.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 23:40:19 -0000 You should load teh "linuxthreads" port and link with that.. under 5.x you will be able to use the native threads (we will have several to choose from :-) under 4.x (I presume that's what you are using) the threading is all in one process and if a device decides to return "data waiting" in select() but keeps the reader waiting, it will block the entire process. On Wed, 21 May 2003, Jay Cornwall wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi > > I've been trying (unsuccessfully) to make the thread-based pppoa3 program > (from http://speedtouch.sf.net/) able to work correctly under FreeBSD. Near > identical code works fine under Linux, but the threading doesn't work at all > in FreeBSD. > > The problem seems to be a result of reading from a USB endpoint file > descriptor, which invokes tsleep() within the kernel > (/sys/dev/usb/usbdi_util.c:432) while it waits for data to read. This has the > effect of blocking the whole process, rather than just the thread which > called the read. > > I'm sure there are good reasons for implementing it in this way, but I'd be > interested to hear what they are, and if any alternative approaches had > been/are being considered. > > Forgive my lack of knowledge with the FreeBSD kernel, I've only been using it > for a couple of weeks. :( > > Cheers, > Jay > > - -- > http://www.evilrealms.net/ - Systems Administrator & Developer > http://www.ic.ac.uk/ - Imperial College, 2nd year CS student > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQE+yraFfJLn3O/2GbERAsFGAJ947XIElRiR0sz7U7O1nq73N0ccMACcD0bT > fWLxgfMSx9n4/1ktz+kOclU= > =1SjD > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 16:49:43 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7CAD37B404 for ; Tue, 20 May 2003 16:49:43 -0700 (PDT) Received: from ms-smtp-01.texas.rr.com (ms-smtp-01.texas.rr.com [24.93.36.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3B5E43FB1 for ; Tue, 20 May 2003 16:49:42 -0700 (PDT) (envelope-from mattb@houston.rr.com) Received: from henbane (cs6710132-244.houston.rr.com [67.10.132.244]) h4KNne8b027269; Tue, 20 May 2003 18:49:41 -0500 (CDT) Date: Tue, 20 May 2003 18:50:02 -0500 From: Matt Bettinger To: "Artem 'Zazoobr' Ignatjev" Message-Id: <20030520185002.4c59035f.mattb@houston.rr.com> In-Reply-To: <1053437797.1444.5.camel@hx.nist> References: <20030520131537.3395210214@ws-tor-0004.procergs> <1053437797.1444.5.camel@hx.nist> X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i386-portbld-freebsd4.8) X-Face: henbane.homeunix.org X-Operating-System: www.freebsd.org User-Agent: I found love thru an GRE Rainbow Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: production... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 23:49:44 -0000 On 20 May 2003 17:36:39 +0400 "Artem 'Zazoobr' Ignatjev" wrote: > In Tue, 20.05.2003, at 17:15, omestre@freeshell.org wrote: > > I'm talking about, "maybe", scripts to "jail" the operator > > in his job. I'm talking about administration tasks that we > > are making every day, but without a environment to this. A > > framework to be changed, shared, and no more command prompt. > > "Imagine" a server managed by menus, in diferent levels, but > > well structured. With functions, chances to edit file... You mean 'like' SAM or SMIt or 'sushi' ;-D From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 17:48:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B297737B401; Tue, 20 May 2003 17:48:32 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7640643F3F; Tue, 20 May 2003 17:48:31 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h4L0mPh0003693; Wed, 21 May 2003 02:48:25 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Wed, 21 May 2003 02:48:25 +0200 (CEST) From: Martin Blapp To: Marcin Dalecki , "Matthew N. Dodd" , "" In-Reply-To: <20030419011446.J95995@cvs.imp.ch> Message-ID: <20030521024232.P7348@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> <20030418144504.B99028@sasami.jurai.net> <20030419011446.J95995@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: dhcp-client@isc.org cc: hackers@FreeBSD.ORG Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 00:48:33 -0000 Hi Folks, I've updated this patch and now it also works at startup time. This means you can start your laptop, plug the cable 10 mins later and you'll get immediatly a IP. The previous patch did only work if 1. The interface was initialized already 2. dhclient was started after a cable was plugged into the nic. These important bugs have now been fixed. URL is still the same. > http://people.freebsd.org/~mbr/patches/dhclient-interfacepolling.diff Martin From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 21:45:33 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AB4837B401 for ; Tue, 20 May 2003 21:45:33 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0933A43F75 for ; Tue, 20 May 2003 21:45:33 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-uinj8tt.dialup.mindspring.com ([165.121.163.189] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19ILTg-0007G2-00; Tue, 20 May 2003 21:45:25 -0700 Message-ID: <3ECB041D.4FE961D@mindspring.com> Date: Tue, 20 May 2003 21:44:13 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47eb7876021f40d912a895b9f5f43022ca8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Jay Cornwall Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 04:45:33 -0000 Julian Elischer wrote: > On Wed, 21 May 2003, Jay Cornwall wrote: > > The problem seems to be a result of reading from a USB endpoint file > > descriptor, which invokes tsleep() within the kernel > > (/sys/dev/usb/usbdi_util.c:432) while it waits for data to read. This has the > > effect of blocking the whole process, rather than just the thread which > > called the read. > > You should load teh "linuxthreads" port > and link with that.. > > under 5.x you will be able to use the native threads (we will have > several to choose from :-) > > under 4.x (I presume that's what you are using) the threading is all in > one process and if a device decides to return "data waiting" in select() > but keeps the reader waiting, it will block the entire process. Or it's a bug in the USB driver, not honoring non-blocking I/O. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 00:35:52 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1BCE37B401 for ; Wed, 21 May 2003 00:35:52 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 75A5943F75 for ; Wed, 21 May 2003 00:35:51 -0700 (PDT) (envelope-from mdcki@gmx.net) Received: (qmail 22886 invoked by uid 65534); 21 May 2003 07:35:50 -0000 Received: from pD9E2DC57.dip.t-dialin.net (EHLO gmx.net) (217.226.220.87) by mail.gmx.net (mp003-rz3) with SMTP; 21 May 2003 09:35:50 +0200 Message-ID: <3ECB2C97.5050508@gmx.net> Date: Wed, 21 May 2003 09:36:55 +0200 From: Marcin Dalecki User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030517 X-Accept-Language: en-us, en, pl, ru MIME-Version: 1.0 To: Jens Schweikhardt References: <20030520203512.GB99242@schweikhardt.net> In-Reply-To: <20030520203512.GB99242@schweikhardt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Converting /usr/bin/vgrind from csh to sh X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 07:35:53 -0000 Jens Schweikhardt wrote: > > So I rewrote vgrind as a /bin/sh script, appended below. I've tested it > and it produces the same file during the one use in our buildworld (i.e. > /usr/obj/usr/src/share/doc/papers/kernmalloc/appendix.ms) Please give it > some more hammering and report any bogons you find. If nobody jumps up > and down, I'll commit as soon as 5.1 is out the door. Thanks! Jump up jump down jump up jump down jump up hurra! jump down hurra! jump up ... Is this enough of jumping? BTW> I allways intendid but never really got around to replace the font-encoding converter in XFree86 with something reasonable... From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 02:20:52 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C39A37B404 for ; Wed, 21 May 2003 02:20:52 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49D7E43FBF for ; Wed, 21 May 2003 02:20:51 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 091F9530E; Wed, 21 May 2003 11:20:49 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: hackers@freebsd.org From: Dag-Erling Smorgrav Date: Wed, 21 May 2003 11:20:49 +0200 Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: elf disassembler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 09:20:52 -0000 Does anyone know of a disassembler that understands 32-bit elf and IA32 machine code and can produce output suitable for feeding back to gas? I know about objdump(1), but it doesn't meet the third criterion. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 03:37:31 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F01237B401 for ; Wed, 21 May 2003 03:37:31 -0700 (PDT) Received: from mindfields.energyhq.es.eu.org (213-97-200-73.uc.nombres.ttd.es [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 520C343FAF for ; Wed, 21 May 2003 03:37:27 -0700 (PDT) (envelope-from flynn@energyhq.es.eu.org) Received: from scienide.energyhq.es.eu.org (scienide.energyhq.es.eu.org [192.168.100.1]) by mindfields.energyhq.es.eu.org (Postfix) with SMTP id E913B2B96C; Wed, 21 May 2003 12:37:22 +0200 (CEST) Date: Wed, 21 May 2003 12:37:04 +0200 From: Miguel Mendez To: Dag-Erling Smorgrav Message-Id: <20030521123704.62ec857d.flynn@energyhq.es.eu.org> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) X-Face: 1j}k*2E>Y\+C~E|/wehi[:dCM,{N7/uE3o# P,{t7gA/qnovFDDuyQV.1hdT7&#d)q"xY33}{_GS>kk'S{O]nE$A`T|\4&p\&mQyexOLb8}FO List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 10:37:31 -0000 --=.a8RF7hA9sGu6aJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 21 May 2003 11:20:49 +0200 Dag-Erling Smorgrav wrote: > Does anyone know of a disassembler that understands 32-bit elf and > IA32 machine code and can produce output suitable for feeding back to > gas? I know about objdump(1), but it doesn't meet the third > criterion. I've used dasm for years. Unfortunately, feeding the resulting code back to an assembler is not immediate. It's still a very useful tool for reverse engineering, tho. I know it doesn't meet the requirement but maybe you find it interesting anyway: http://packetstormsecurity.nl/linux/reverse-engineering/dasm With that and the help of some awk/grep magic you should be able to end up with compilable file. Cheers, -- Miguel Mendez - flynn@energyhq.es.eu.org EnergyHQ :: http://www.energyhq.tk Tired of Spam? -> http://www.trustic.com --=.a8RF7hA9sGu6aJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+y1bUnLctrNyFFPERApLwAJ0SceDKt7uepJmOgOsNMxmbq0MEBACfa9CR zvph0yw+Orrv0DjrDtP9Bwc= =iZL3 -----END PGP SIGNATURE----- --=.a8RF7hA9sGu6aJ-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 05:23:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D71637B401; Wed, 21 May 2003 05:23:09 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2439C43F75; Wed, 21 May 2003 05:23:08 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h4LCN1RE047760; Wed, 21 May 2003 14:23:01 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Wed, 21 May 2003 14:23:01 +0200 (CEST) From: Martin Blapp To: Bruce M Simpson In-Reply-To: <20030521010903.GA23471@spc.org> Message-ID: <20030521141810.C7348@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> <20030418144504.B99028@sasami.jurai.net> <20030419011446.J95995@cvs.imp.ch> <20030521024232.P7348@cvs.imp.ch> <20030521010903.GA23471@spc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: dhcp-client@isc.org cc: imp@imp.com cc: "Matthew N. Dodd" cc: hackers@FreeBSD.ORG Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 12:23:09 -0000 Hi, > > Excellent work. However - we may wish to think about modifying it for > use wiht 802.11 interfaces. Yesterday I got 4.7-RELEASE working on a > friend's machine which is now acting as wireless backhaul from a building > in Bow, East London with an antenna pointed at Hackney; from reboot, > the machine associates with the AP in Hackney and invokes dhclient > to get an IP from the AP once associated. > > But in order to get things to happen in the right order, I had to create > a script /etc/start_if.wi0, and write a little program called 'waitforap'. > > I've attached it. It's not perfect, but it does the job; rather than > attempting to perform a DHCPREQUEST broadcast before the interface is > ready, it waits until wi0's status is 'associated'. Hi, Ehm. You should just use my dhclient patch and not need any furter scripts and patches. I do just the same as you. All you have to do is : dhclient -nw wi0 Can you confirm that my patch works here too ? + if (ioctl(sock, SIOCGIFMEDIA, (caddr_t)&ifmr) < 0) { + /* + * Interface doesn't support SIOCGIFMEDIA, presume okay + */ + close(sock); + return (1); + } + close(sock); + + if (ifmr.ifm_count == 0) { + /* + * this is unexpected (to me), but we'll just assume + * that this means interface does not support SIOCGIFMEDIA + */ + return (1); + } + + if (ifmr.ifm_status & IFM_AVALID) { + if (ifmr.ifm_status & IFM_ACTIVE) + return (1); + } else + return (0); + + return (0); Martin From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 07:57:05 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2580D37B401 for ; Wed, 21 May 2003 07:57:05 -0700 (PDT) Received: from smtp12.mail.yahoo.co.jp (smtp12.mail.yahoo.co.jp [211.14.15.235]) by mx1.FreeBSD.org (Postfix) with SMTP id BBE5643FA3 for ; Wed, 21 May 2003 07:57:03 -0700 (PDT) (envelope-from tokyo15@yahoo.co.jp) Received: from unknown (HELO aladdinvaio) (210.253.214.207) by smtp12.mail.yahoo.co.jp with SMTP; 21 May 2003 14:57:00 -0000 X-Apparently-From: Message-ID: <06b601c31fa8$a5ddd010$0201a8c0@aladdinvaio> From: "tokyo15" To: , , , , Date: Wed, 21 May 2003 23:52:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: =?iso-2022-jp?b?Rnc6IFthcmd1ZTo4NTI3XSAbJEI+cEpzOCY1ZhsoQg==?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 14:57:05 -0000 > > Google Search Term Demonstration > We've stressed in several places on this site that the search term information > present in standard logs kept by webmasters all over the world is potentially a > violation of your privacy. This is a demo of two pieces of information from the > standard logs of two of PIR's sites. The phenomenon demonstrated here is not > unique to Google, but is typical of almost all search engines. > There are two methods for collecting your search terms, GET and POST. Search > engines use GET because you can bookmark the search, link the search, and pass > data inside the link. However, your search terms end up on the same line as your > IP address in standard web logs all over the world with the GET method. This is > "referrer" information, which is available to the distant webmaster every time > you click on a link from a search results page.The webmaster knows that someone > at your IP address accessed his page, and also knows what you were thinking from > your search terms. That is why we use the POST method in our search proxy. You > cannot bookmark the search, but neither can anyone see your terms. The search > engine sees them, but all they know is that someone used those terms on our > proxy at a certain time. > > Only two items are shown below, the remote address and the "referrer" > information. Not shown are these pieces of information, which would be on the > same log line: > > a.. the date and time stamp > b.. the name of the file that was accessed on our site > c.. the status code (whether the request succeeded) > d.. the number of bytes transferred > e.. the type of browser used > Below we show some recent information from our Google Watch log, to demonstrate > how some Internet addresses come close to qualifying as "personally identifiable > information." Then we took recent entries that were referred from searchers at > Google who clicked on our CIA on Campus site. The fact that the user clicked on > a link from the Google search results page caused their Google search terms to > appear in this other log of ours. > > The portion in green is the IP block owner for the IP number on that line. We > found this using our search at the bottom of this page. This information doesn't > appear in standard logs, but the data is widely available. Another database > allowed an IP-to-country lookup (not always accurate) to show where that > Internet surfer is located. The top list is current (refresh your browser > periodically), while the bottom list of referrers updates every 30 minutes. > Those who use our proxy without landing on other pages of our site are excluded > from the top list. > > By the way, the top line is you. > > > > > List of Internet addresses: > nttfis2-207.246.ne.jp 210.253.214.207 JAPAN NETWORK INFORMATION CENTER JAPAN > p3e9be737.dip.t-dialin.net 62.155.231.55 DEUTSCHE TELEKOM AG GERMANY > lns-p19-18-82-65-126-18.adsl.proxad.net 82.65.126.18 RIPE NCC > hwc20.trin.cam.ac.uk 131.111.231.75 CAMBRIDGE UNIVERSITY LOCAL AREA NETWORK > UNITED KINGDOM > 54.112.dialup.srt.com 216.221.112.54 SRT COMMUNICATIONS, INC. UNITED STATES > 195-23-77-36.nr.ip.pt 195.23.77.36 PROVIDER PORTUGAL > dsl-217-155-47-235.zen.co.uk 217.155.47.235 ZEN INTERNET UNITED KINGDOM > modem-205-50-60-62.vip.uk.com 62.60.50.205 WESTFIELDS HOUSE UNITED KINGDOM > willydobbe.xs4all.nl 213.84.158.14 PROVIDER LOCAL INTERNET REGISTRY NETHERLANDS > 0-1pool68-5.nas20.oakbrook1.il.us.da.qwest.net 63.155.68.5 QWEST COMMUNICATIONS > UNITED STATES > zone-7.jesus.cam.ac.uk 131.111.243.37 CAMBRIDGE UNIVERSITY LOCAL AREA NETWORK > UNITED KINGDOM > host-216-90-69-8.royell.net 216.90.69.8 HANSON INFORMATION SYSTEMS UNITED STATES > host9.audit-commission.gov.uk 193.128.236.219 AUDIT COMMISSION UNITED KINGDOM > yahoobb219017109146.bbtec.net 219.17.109.146 BB TECHNOLOGY CORP. JAPAN > pd9e54be8.dip.t-dialin.net 217.229.75.232 DEUTSCHE TELEKOM AG GERMANY > hse-toronto-ppp177672.sympatico.ca 64.229.80.23 HSE CANADA > webport-cl6-cache2.ilford.mdip.bt.net 213.120.56.37 BT-CLICK UNITED KINGDOM > 2cust130.tnt2.penrith.au.da.uu.net 210.84.120.130 OZEMAIL PTY LTD AUSTRALIA > mcf1.wc.optusnet.com.au 211.28.96.68 OPTUS INTERNET - RETAIL AUSTRALIA > afontenayssb-111-1-1-192.w80-13.abo.wanadoo.fr 80.13.0.192 WANADOO INTERACTIVE > FRANCE > 12-237-223-111.client.attbi.com 12.237.223.111 AT&T WORLDNET SERVICES UNITED > STATES > pd9e2799e.dip.t-dialin.net 217.226.121.158 DEUTSCHE TELEKOM AG GERMANY > ip68-3-10-201.ph.ph.cox.net 68.3.10.201 COX COMMUNICATIONS UNITED STATES > acb056c2.ipt.aol.com 172.176.86.194 AMERICA ONLINE UNITED STATES > 216.239.37.5 216.239.37.5 GOOGLE UNITED STATES > 140.186.149.97 140.186.149.97 GLOBALNET INTERNET SERVICES UNITED STATES > vagabondo.wise-guys.nl 212.19.205.147 WEGENER ELECTRONIC MEDIA NETHERLANDS > www.readware.com 216.155.111.251 ACCELERATED DATA WORKS, INC UNITED STATES > athe530-m012.otenet.gr 212.205.248.12 OTENET S.A. GREECE > h002018dac575.ne.client2.attbi.com 24.60.138.194 AT&T BROADBAND NORTHEAST UNITED > STATES > d38.as1.lkgn.wi.voyager.net 169.207.101.166 EXECUTIVE PC, INC. UNITED STATES > 80.58.51.235.proxycache.rima-tde.net 80.58.51.235 TELEFONICA DE ESPANA SAU SPAIN > chello080110104197.508.15.tuwien.teleweb.at 80.110.104.197 CHELLO BROADBAND GMBH > AUSTRIA > avelizy-115-1-9-12.w81-53.abo.wanadoo.fr 81.53.194.12 FRANCE TELECOM FRANCE > 12-210-34-222.client.attbi.com 12.210.34.222 AT&T WORLDNET SERVICES UNITED > STATES > p62.246.103.32.tisdip.tiscali.de 62.246.103.32 TISCALI BUSINESS GMBH GERMANY > cache01.flow.com.au 202.129.95.21 FLOW CACHING DOMAIN AUSTRALIA > ip68-100-19-73.nv.nv.cox.net 68.100.19.73 COX COMMUNICATIONS UNITED STATES > ppp-6-90.30-151.libero.it 151.30.90.6 IUNET > dabug.com 62.212.96.199 IP BLOCS FOR INDIVIDUAL ADSL ACCESSES VIA FRANCE > host195.10.103.238.manx.net 195.10.103.238 LICENSED PROVIDER UNITED KINGDOM > h68-147-212-32.cg.shawcable.net 68.147.212.32 SHAW FIBERLINK LTD. CANADA > m195-mp1.cvx1-b.big.dial.ntli.net 213.104.112.195 NTL INTERNET - LUTON SITE > UNITED KINGDOM > client5.sumoto.gr.jp 210.199.221.57 JAPAN NETWORK INFORMATION CENTER JAPAN > as15-4-2.sp.m.bonet.se 194.237.47.201 BOSTREAM AB SWEDEN > 213-140-17-155.fastres.net 213.140.17.155 ITALY ITALY > wc13.wlfdle.rnc.net.cable.rogers.com 66.185.84.80 ROGERS@HOME CANADA > adsl-157-226-167.jax.bellsouth.net 66.157.226.167 BELLSOUTH.NET, INC. UNITED > STATES > ntgnma015070.gnma.nt.adsl.ppp.infoweb.ne.jp 219.97.117.70 JAPAN NETWORK > INFORMATION CENTER JAPAN > user-1121o3f.dialup.mindspring.com 66.32.224.111 EARTHLINK NETWORK UNITED STATES > inktomi2-ren.server.ntl.com 62.252.128.5 NTL INTERNET UNITED KINGDOM > > > > > > > List of Google referrers: > > > www.google.be/search?q=%22george+bush%2BCIA&hl=nl&lr=&ie=UTF-8&start=50&sa=N > www.google.ca/search?q=cia+world+fact+bok&ie=UTF-8&oe=UTF-8&hl=en&meta= > www.google.co.uk/search?hl=en&ie=UTF-8&oe=UTF-8&q=economic+factors+of+Camelot&me > ta= > www.google.co.uk/search?q=The+Sovereign+State%3A+The+Secret+History+of+ITT&ie=UT > F-8&oe=UTF-8&hl=en&btnG=Google+Search&meta= > www.google.com.ar/search?q=CIA+spies+in+brazil&hl=es&lr=&ie=UTF-8&oe=UTF-8&start > =10&sa=N > www.google.com.sg/search?hl=en&ie=UTF-8&oe=UTF-8&q=invader+cia+indonesia > www.google.com/search?hl=da&ie=UTF-8&oe=UTF-8&q=edgar+schein+funnel&btnG=Google- > s%C3%B8gning&lr= > www.google.com/search?hl=en&ie=ISO-8859-1&q=foreign+thesis+about+retail+outlet&b > tnG=Google+Search > www.google.com/search?hl=en&ie=ISO-8859-1&q=ramparts+cia+nsa&btnG=Google+Search > www.google.com/search?hl=en&ie=ISO-8859-1&q=who+is+Dr.+Val+Lorwin+&btnG=Google+S > earch > www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22Lingua+Franca%22+Chronicle&bt > nG=Google+Search > www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=CIA+involvement+in+the+overthrow > +of+the+Allende+government > www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=Operation+CHAOS > www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=church+committee+cia > www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=psychological+warfare+%2B+public > +relations+%2Bpropaganda&btnG=Google+Search > www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=ss+officers+in+the+cia > www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=rochester+cia > www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=%22church+committee%22+cia > www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=%22national+security%22+univ > ersity+cia > www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=Short+biography+of+CIA+direc > tor+John+McCone&spell=1 > www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=cia+academics > www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=is+the+use+of+behavior+modif > ication+unethical+control+of+human+behavior&btnG=Google+Search > www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=mccone+cia > www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&q=Operation+CHAOS > www.google.com/search?q=%22pir.org%22&hl=en&lr=&ie=UTF-8&start=10&sa=N > www.google.com/search?q=%22reputation%22%2B%22johns+hopkins%22%2B%22stanford%22% > 2B%22harvard&hl=en&lr=&ie=UTF-8&start=80&sa=N > www.google.com/search?q=Biography+of+CIA+Director+John+McCone+&hl=en&lr=&ie=UTF- > 8&oe=UTF-8&start=0&sa=N > www.google.com/search?q=CIA&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&start=10&sa=N > www.google.com/search?q=CIA&hl=en&lr=&ie=UTF-8&oe=UTF-8&start=20&sa=N > www.google.com/search?q=CIA+METHODS&hl=en&lr=&ie=UTF-8&start=100&sa=N > www.google.com/search?q=CIA+and+operations+officers&hl=en&lr=&ie=UTF-8&oe=UTF-8& > start=40&sa=N > www.google.com/search?q=CIA+and+operations+officers&hl=en&lr=&ie=UTF-8&oe=UTF-8& > start=90&sa=N > www.google.com/search?q=CIA+recruitment+post+board&btnG=Google+Search&hl=en&lr=& > ie=UTF-8&oe=UTF-8 > www.google.com/search?q=Cornell+Alumni+AND+CIA+AND+Intelligence&hl=en&lr=&ie=UTF > -8&oe=UTF-8&start=20&sa=N > www.google.com/search?q=LINGUA-FRANCA&hl=en&lr=&ie=UTF-8&inlang=ar&lr=&start=110 > &sa=N > www.google.com/search?q=Massachusetts+Institute+of+Technology+&hl=en&lr=&ie=UTF- > 8&start=130&sa=N > www.google.com/search?q=Oss+history&ie=UTF-8&oe=UTF-8 > www.google.com/search?q=Richard+Bissell+--+role+in+cold+war+espionage&hl=en&lr=& > ie=UTF-8&oe=UTF-8&start=10&sa=N > www.google.com/search?q=Rochester+Institute+of+Technology+CIA&btnG=Google+Search > &hl=en&lr=&ie=UTF-8&oe=utf-8 > www.google.com/search?q=US+intelligence+positions&hl=en&lr=&ie=UTF-8&start=10&sa > =N > www.google.com/search?q=Vietnam+protests+at+UMass&hl=en&lr=&ie=UTF-8&oe=UTF-8&st > art=10&sa=N > www.google.com/search?q=after+campus+activities+and+its+effects&hl=en&lr=&ie=UTF > -8&oe=UTF-8 > www.google.com/search?q=cia+recruiters+angry&hl=en&lr=&ie=ISO-8859-1 > www.google.com/search?q=work+for+the+CIA&hl=en&lr=&ie=UTF-8&oe=UTF-8&start=10&sa > =N > www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=Radio+Free+Europe%2 > C+US+propaganda > www.google.com/search?sourceid=navclient&q=co%2Dopt > www.google.com/search?sourceid=navclient&q=german+ties+rutgers > www.google.com/search?sourceid=navclient&q=operation+chaos > www.google.it/search?q=c.i.a.&hl=it&lr=&ie=UTF-8&oe=UTF-8&start=20&sa=N > www.google.nl/search?q=interrogation+techniques+cia+psychology&ie=UTF-8&oe=UTF-8 > &hl=nl&lr= > > > Who owns that IP number? > Below you can enter a single IP number to find the name of the owner. This demo > also allows you to use one or two keywords for a corporation or organization > that may own IP blocks, and it will show you up to 500 matches. Try entering > "china province" (without the quotes) -- or, for that matter, "intelligence > ----- Original Message ----- > > $B<+A3:R32$N$h$&$KBg=0M}2r$5$l$F$$$k(B > > $B?M:RIT7J5$!":#8=Be$O>pJs$NA*JLCj=PAO@8(B > > $B$,=EMW$J80$H$J$C$F$$$k!#(B > > $B#M#L08@h!!(Bjyohocyushistu@freeml.com > > $B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B > > $B?M:RIT7J5$!"<+;& > $BA4;:6HGK;:798~$r?d?J$7!"2~0-E*9=B$2~3W$N(B > > $BLdBj$N860x$N9M;!(B > > $B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B > > $B%8%?%s$G$9!#(B > > > $B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B > > > $B<+A3:R32$N$h$&$KBg=0M}2r$5$l$F$$$k(B > > > $B?M:RIT7J5$!":#8=Be$O>pJs$NA*JLCj=PAO@8(B > > > $B$,=EMW$J80$H$J$C$F$$$k!#(B > > > $B#M#L08@h!!(Bjyohocyushistu@freeml.com > > > $B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B > > > $B?M:RIT7J5$!"<+;& > > $BA4;:6HGK;:798~$r?d?J$7!"2~0-E*9=B$2~3W$N(B > > > $BLdBj$N860x$N9M;!(B > > > $B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B > > $BGrAuB+JsF;$NGX8e$K$"$k%"!<%-%F%/%A%c!<$KCmL\$;$h!*(B > > http://www.miyadai.com/message/?msg_date=20030516 > > $B!ZMWLs![7Y;!D#$N$"$k0U?^$K$h$C$FGrAuB+=8CD$,%/%m!<%:%"%C%W$5$l$k$3$H$K$J$C$?(B > $B$,!"(B > > $B2aG.$7$?JsF;$,=EMWK!0F$N?3M}$+$i9qL1$NL\$r0o$i$5$;$k$J$IM=A[30$N7k2L$r$b$?$i(B $B$7(B > > $B$?!#$3$N$h$&$JB>$N>pJs$r=8Cf9k1+E*$KN.$5$;$F!V>pJs%O%l!<%7%g%s!W$r0z$-5/$3$9(B $B@o(B > $BN,(B > > $B$,!"C1$K>pJs$r $B@o(B > > $BAh$G$O!V%"%a!W$H!V%`%A!W$H!V%O%l!<%7%g%s!W$N#3$D$N $B$?!#(B > > $B$3$&$7$?J}K!$O?M!9$r6<$9$3$H$J$/<+J,$,<+M3$G$"$k$H;W$o$;$J$,$i!"%7%9%F%`@_7W(B $B $B$N(B > > $B;W$$DL$j$KA`:n$9$k!#$H$3$m$G!"%+%k%H=8CD$O!"JW:_$9$kHs2D;kJ*$K61$(!"2J3XE*Au(B $B$$(B > $B$r(B > > $BH<$C$?@bL@$r;n$_$kE@$KFCD'$,$"$k$,!"$3$&$7$?LQA[$K$O9bEY5;=Q $B%/(B > > $B%\%C%/%92=!W$N?JE8$H$$$&GX7J$,$"$k!# $BJ,(B > > $B2=$r0UL#$7IT2DHr$J$3$H$G$"$j!"AX$N?<2=$OLQA[$r$H$b$J$C$?C& > $B$k!#AX$r?<$/$7$9$.$J$$@oN,$r:N$k$Y$-$G$"$k!#(B > > > > > $B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B > > > $BD+$^$G@/<#%H!<%/!!(BHttp://tokyo.cool.ne.jp/aladdin/ > > > $B#M#L!!Ej9F@h!!(BSeijisay@freeml.com > > > $B<+A3:R32$N$h$&$KBg=0$KM}2r$5$l$F$$$k(B > > > $B?M:RIT7J5$!":#8=Be$O>pJs$NA*JLCj=PAO@8(B > > > $B$,=EMW$J80$H$J$C$F$$$k!#(B > > > $B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B > > $B$3$A$i$+$i"M(B http://ad.freeml.com/cgi-bin/ad.cgi?id=bPGHs > > ------------------------------------------------------------------[PR]-- > > Global Media Online www.gmo.jp > > > > $B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B > > $BD+$^$G@/<#%H!<%/!!(BHttp://tokyo.cool.ne.jp/aladdin/ > > $B#M#L!!Ej9F@h!!(BSeijisay@freeml.com > > $B<+A3:R32$N$h$&$KBg=0$KM}2r$5$l$F$$$k(B > > $B?M:RIT7J5$!":#8=Be$O>pJs$NA*JLCj=PAO@8(B > > $B$,=EMW$J80$H$J$C$F$$$k!#(B > > $B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B > > __________________________________________________ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/ From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 08:04:47 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6007A37B401; Wed, 21 May 2003 08:04:47 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAE0343F75; Wed, 21 May 2003 08:04:45 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h4LF4WRE095032; Wed, 21 May 2003 17:04:33 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Wed, 21 May 2003 17:04:32 +0200 (CEST) From: Martin Blapp To: dhcp-client@isc.org In-Reply-To: <20030521141810.C7348@cvs.imp.ch> Message-ID: <20030521170142.Y7348@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> <20030418144504.B99028@sasami.jurai.net> <20030419011446.J95995@cvs.imp.ch> <20030521024232.P7348@cvs.imp.ch> <20030521010903.GA23471@spc.org> <20030521141810.C7348@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@FreeBSD.ORG cc: imp@imp.com cc: "Matthew N. Dodd" Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 15:04:47 -0000 Hi, Ok, after looking at it it seems that I missed one part. > > Excellent work. However - we may wish to think about modifying it for > > use wiht 802.11 interfaces. Yesterday I got 4.7-RELEASE working on a > > friend's machine which is now acting as wireless backhaul from a building > > in Bow, East London with an antenna pointed at Hackney; from reboot, > > the machine associates with the AP in Hackney and invokes dhclient > > to get an IP from the AP once associated. I've modified the patch to check all the interfaces for 802.11 support and added a check to do only send packets if the device is associated. It should work in theorie. I'm glad to hear if it works for you, if any of you use FreeBSD and has a 802.11 device around. Martin From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 08:20:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB8C137B401 for ; Wed, 21 May 2003 08:20:55 -0700 (PDT) Received: from honolulu.procergs.com.br (honolulu.procergs.com.br [200.198.128.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18E7443F93 for ; Wed, 21 May 2003 08:20:55 -0700 (PDT) (envelope-from marcelo-leal@procergs.rs.gov.br) Received: from ws-tor-0004.procergs (unknown [172.28.5.20]) by honolulu.procergs.com.br (Postfix) with ESMTP id 362FDA9DB for ; Wed, 21 May 2003 12:20:54 -0300 (BRT) Received: by ws-tor-0004.procergs (Postfix, from userid 1000) id 24C7A10214; Wed, 21 May 2003 12:20:54 -0300 (BRT) Received: from procergs.rs.gov.br (localhost [127.0.0.1]) by ws-tor-0004.procergs (Postfix) with ESMTP id 16A7510213 for ; Wed, 21 May 2003 12:20:54 -0300 (BRT) From: omestre@freeshell.org To: freebsd-hackers@freebsd.org Date: Wed, 21 May 2003 12:20:49 -0300 Sender: marcelo-leal@procergs.rs.gov.br Message-Id: <20030521152054.24C7A10214@ws-tor-0004.procergs> Subject: linux emulation. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 15:20:56 -0000 Hello, The FreeBSD is great. I have my desktop running with FreeBSD 5.0 kernel, and the ROOTFS is a Debian/GNU Linux 3.0. (The filesystem is UFS2). There are only two programs in the filesystem that are FreeBSD ones: route and sysctl. I did saw the documentation (in handbook), about the emulation that are not emulation. :) But i want to know more about that. Where can i find this documentation? i know, i know... the sources. But i want to read articles about that... talking about the implementation and how it works (more deep than the handbook), so, maybe i can understand the sources. Example: In the handbook, i did read that the proc structure (now thread in 5.0), holds a pointer to the sysent[] table. (sys calls). Each process have one pointer to it. But, the FreeBSD sysent struct i have found, but the linux do not. It suppoused to be in /usr/src/sys/compat/linux tree... right? Really, the SO implementation, vm, io and etc is independent of ABI that it is running. Excelent. But i want know more. I want know if there are overhead in some point (sysent traduction?). Thanks The english? sorry... :) --- From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 08:46:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB62737B401 for ; Wed, 21 May 2003 08:46:58 -0700 (PDT) Received: from smtp01.01.246.ne.jp (smtp01.01.246.ne.jp [210.253.192.39]) by mx1.FreeBSD.org (Postfix) with SMTP id 578EE43FBD for ; Wed, 21 May 2003 08:46:57 -0700 (PDT) (envelope-from jir@01.246.ne.jp) Received: (qmail 29509 invoked by alias); 22 May 2003 00:46:55 +0900 Received: (qmail 29483 invoked from network); 22 May 2003 00:46:52 +0900 Received: from unknown (HELO aladdinvaio) (210.253.214.207) by tp01001 with SMTP; 22 May 2003 00:46:52 +0900 Message-ID: <088401c31faf$9d8060c0$0201a8c0@aladdinvaio> From: "jir" To: , "freebsd-hackers@FreeBSD.O" , "freeml@freeml.com" , "Com Argue@Freeml." , References: <332501c31405$ce47a660$0201a8c0@aladdinvaio> Date: Thu, 22 May 2003 00:41:36 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: linux_hackers@freeml.com cc: turbolinux@freeml.com cc: daitouakyoueiken@freeml.com cc: turbolinux7@freeml.com Subject: Re: [perljavaorasasch:0038] Your SAS Business Report for May 6, 2003 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 15:46:59 -0000 Your SAS Business Report ----- Original Message ----- 送信者 : jir 宛先 : perljavaorasasch@freeml.com 送信日時 : 2003幎5月7日 4:29 件名 : [perljavaorasasch:0038] Your SAS Business Report for May 6, 2003 ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆ 投皿は　perljavaorasasch@freeml.com 　　ORACLE 　 SAP　shell 構蚀語 誰でも聞ける誰でも答える。 䜕回でも聞ける。 間違っお教えおも咎めない。 過去ログ参照なし ディレク トリヌ 公開する ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆ May 6, 2003 subscribe | unsubscribe | www.sas.com • Operational Risk Intelligence Forum • SAP Certifies the SAS System • SAS Outperforms in Integrated Business Intelligence • MTS Signs with SAS for Business Intelligence • SAS Leads 2002 Marketing Automation Sales Operational Risk Intelligence Forum To help you successfully navigate the waters of operational risk management, SAS invites you to an executive forum on Tuesday, May 13. Join us at the historic Banqueting House in Whitehall, London to hear expert insights on the latest operational risk practices. Register now! Read more SAP Certifies the SAS System What do you get when you combine SAS software with your SAP enterprise resource planning system? A complete corporate picture -- and absolute assurance of future growth and adaptability. Read more SAS Outperforms in Integrated Business Intelligence A report from the UK-based Butler Group names SAS an "outperformer" for achieving commanding market position and a best-of-breed product set. Read more MTS Signs with SAS for Business Intelligence When Russia's largest cellular operator needed a solution for financial reporting, it turned to SAS for a suite of solutions that offers reporting and so much more. Read more SAS Leads 2002 Marketing Automation Sales With SAS Marketing Automation improving customer response rates by up to 400 percent, it's no wonder SAS had more 4Q 2002 sales than any other vendor in this space. Read more We hope that you enjoyed reading this e-newsletter. However, if you would rather not receive SAS e-newsletters in the future, return to our e-newsletter subscriptions site to log in and edit the subscription options in your profile. Other Subscriptions | Contact the Editor | Report Delivery Problem | Privacy Statement Copyright © 2003 SAS Institute Inc. Cary, NC, USA. All rights reserved. --[PR]------------------------------------------------------------------ アメリカンビタミンショップ ─────────────────┐ │ │今幎の倏は始たっおいるダむ゚ット、始めたせんか │　　　　　　　　　　　　 　　　　　取り扱いサプリ100皮類超　　 http://ad.freeml.com/cgi-bin/ad.cgi?id=bN3li ------------------------------------------------------------------[PR]-- Global Media Online www.gmo.jp ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆ 投皿は　perljavaorasasch@freeml.com 　 　ORACLE 　SAP　shell 構築蚀語 ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆ From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 09:24:36 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B230D37B401 for ; Wed, 21 May 2003 09:24:36 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2DFC43FAF for ; Wed, 21 May 2003 09:24:34 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h4LGO2rN018084 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 21 May 2003 18:24:20 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h4LGNqOs014901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2003 18:23:52 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h4LGNpPY089251; Wed, 21 May 2003 18:23:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h4LGNecQ089250; Wed, 21 May 2003 18:23:40 +0200 (CEST) Date: Wed, 21 May 2003 18:23:40 +0200 From: Bernd Walter To: Terry Lambert Message-ID: <20030521162339.GL21312@cicely12.cicely.de> References: <3ECB041D.4FE961D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ECB041D.4FE961D@mindspring.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-BETA alpha User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Julian Elischer cc: Jay Cornwall Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 16:24:37 -0000 On Tue, May 20, 2003 at 09:44:13PM -0700, Terry Lambert wrote: > Julian Elischer wrote: > > On Wed, 21 May 2003, Jay Cornwall wrote: > > > The problem seems to be a result of reading from a USB endpoint file > > > descriptor, which invokes tsleep() within the kernel > > > (/sys/dev/usb/usbdi_util.c:432) while it waits for data to read. This has the > > > effect of blocking the whole process, rather than just the thread which > > > called the read. > > > > You should load teh "linuxthreads" port > > and link with that.. > > > > under 5.x you will be able to use the native threads (we will have > > several to choose from :-) > > > > under 4.x (I presume that's what you are using) the threading is all in > > one process and if a device decides to return "data waiting" in select() > > but keeps the reader waiting, it will block the entire process. > > Or it's a bug in the USB driver, not honoring non-blocking I/O. ugen(4) does not support non-blocking I/O like most other driver also do not. I don't count it as a bug as noone ever told that it does. It's even documented in ugen(4): The bulk transfer mode can be in or out depending on the endpoint. To perform I/O on a bulk endpoint read(2) and write(2) should be used. All I/O operations on a bulk endpoint are unbuffered. non-blocking requires buffered I/O. The device gets regulary polled if someone has an outstanding transfer. Implementing nonblocking I/O would require always to have an outstanding read for open devices - similar is done in ucom(4). -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 09:32:52 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EBF537B401 for ; Wed, 21 May 2003 09:32:52 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00CF343F3F for ; Wed, 21 May 2003 09:32:51 -0700 (PDT) (envelope-from Vijay.Singh@nokia.com) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h4LGWnD02502 for ; Wed, 21 May 2003 19:32:49 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com for ; Wed, 21 May 2003 19:32:48 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 19:32:48 +0300 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 11:32:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 May 2003 09:32:26 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE02C08E36@mvebe001.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: USB bulk read & pthreads Thread-Index: AcMfU/Ssqv1ZzrwXTlaI1Th7uGWLuQAYoIcw From: To: X-OriginalArrivalTime: 21 May 2003 16:32:27.0222 (UTC) FILETIME=[90E93F60:01C31FB6] Subject: sendfile in FreeBSD 2.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 16:32:52 -0000 Hello. Would it be possible to port the sendfile system call to a = FreeBSD 2.2 based system? Has anyone done this? I am trying to port the = code from a later FreeBSD release and I have been unable to find out = what the VOP_GETVOBJECT() macro does and how/what should it be replaced = with for my case. Any help is appreciated. Thanks vijay From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 10:52:16 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D4B137B404 for ; Wed, 21 May 2003 10:52:16 -0700 (PDT) Received: from peedub.jennejohn.org (p213.54.194.157.tisdip.tiscali.de [213.54.194.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2BE543FA3 for ; Wed, 21 May 2003 10:52:14 -0700 (PDT) (envelope-from garyj@jennejohn.org) Received: from peedub.jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.12.9/8.11.6) with ESMTP id h4LHqAC9037284; Wed, 21 May 2003 19:52:11 +0200 (CEST) (envelope-from garyj@peedub.jennejohn.org) Message-Id: <200305211752.h4LHqAC9037284@peedub.jennejohn.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: omestre@freeshell.org In-Reply-To: Message from omestre@freeshell.org <20030521152054.24C7A10214@ws-tor-0004.procergs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 May 2003 19:52:10 +0200 From: Gary Jennejohn cc: freebsd-hackers@freebsd.org Subject: Re: linux emulation. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 17:52:16 -0000 omestre@freeshell.org writes: > I did saw the documentation (in handbook), about the emulation that > are not emulation. :) But i want to know more about that. Where can > i find this documentation? > i know, i know... the sources. But i want to read articles about > that... talking about the implementation and how it works (more > deep than the handbook), so, maybe i can understand the sources. > Try searching for +freebsd +linuxulator on google. You might find something usefull. But I suspect that you'll have to read the sources. > Really, the SO implementation, vm, io and etc is independent of ABI that > it is running. Excelent. But i want know more. I want know if there are > overhead in some point (sysent traduction?). > Of course there's overhead. The FreeBSD kernel has to map the Linux syscalls into FreeBSD syscalls, which is a layer of indirection. And be aware that not all Linux syscalls are handled by FreeBSD. --- Gary Jennejohn / garyj@jennejohn.org gj@freebsd.org gj@denx.de From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 11:02:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BC2937B401 for ; Wed, 21 May 2003 11:02:23 -0700 (PDT) Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FA3343F3F for ; Wed, 21 May 2003 11:02:22 -0700 (PDT) (envelope-from pmedwards@eircom.net) Received: (qmail 92201 messnum 36971 invoked from network[159.134.237.77/webmail00.eircom.net]); 21 May 2003 18:02:20 -0000 Received: from webmail00.eircom.net (HELO webmail.eircom.net) (159.134.237.77) by mail02.svc.cra.dublin.eircom.net (qp 92201) with SMTP; 21 May 2003 18:02:20 -0000 From: "Peter Edwards" To: hackers@freebsd.org Date: Wed, 21 May 2003 17:47:10 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 62.17.151.61 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20030521180222.0FA3343F3F@mx1.FreeBSD.org> Subject: Question on (ab)using the swap pager and VM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 18:02:23 -0000 Hi All, As a programming exercise, I'm trying to write what is in essence a synthetic filesystem where the synthetic files contain large amounts of data I want to use a swap pager as a cached store for the data I'm providing. (ie, it'll be generated in the kernel) I'm aware that this is probably almost criminal, but I just want to understand if what I'm doing is "correct", even if it is stupid. I'm happy enough with the VFS stuff (vnops, vfsops, etc), and I think I've pretty much worked out how to get the data in pages from the swap-pager and accessable in the kernel's address space, using vm_pager_get_pages() or vm_page_grab(), then vm_page_wire() to get the page in physical ram, and then kmem_malloc() and pmap_qenter() to get them into the kernel's memory map. What I'm less sure about is how to write to the swap pager. My best guess is that I can modify the page with impunity once it's wired, then do something like what vm_proc_swapout() does, calling vm_page_dirty() and vm_page_unwire() to put it back on to the correct queue, where the swapper can launder it if neccessary. Overall, can I do something like this to allocate and write a single page to the swap pager? (modulo locking stuff) pager = swap_pager_alloc(...); kmem = kmem_alloc_wait(kernel_map, PAGE_SIZE); page = vm_page_grab(pager, 0, ...); vm_page_wire(page); pmap_qenter(kmem, page); strcpy(kmem, "hello world"); pmap_qremove(); kmem_free_wakeup(kernel_map, kmem); vm_page_dirty(page); vm_page_unwire(page); And, at an arbitrary point in the future, possibly after the page is swapped out, bring it back in and find my "hello world" message intact. What I'm even less sure about is dealing with copy-on-write mappings from the swap pager I allocate. It's not a concern in the sense that it's a read-only file system, and the data will be in the swap pager, and immutable once there's a possibility of such a mapping happening, but it just leaves me with the feeling I'm missing something (probably quite big) I just want to get an idea if I'm in the right ballpark before hacking away. -- Peter Edwards. From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 12:12:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 807FA37B401 for ; Wed, 21 May 2003 12:12:03 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA73043F75 for ; Wed, 21 May 2003 12:12:02 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc02) with ESMTP id <20030521191201002002leqoe>; Wed, 21 May 2003 19:12:02 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA74265; Wed, 21 May 2003 12:12:01 -0700 (PDT) Date: Wed, 21 May 2003 12:11:59 -0700 (PDT) From: Julian Elischer To: Vijay.Singh@nokia.com In-Reply-To: <4D7B558499107545BB45044C63822DDE02C08E36@mvebe001.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: sendfile in FreeBSD 2.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 19:12:03 -0000 > Hello. Would it be possible to port the sendfile system call to a FreeBSD 2.2 based system? Has anyone done this? I am trying to port the code from a later FreeBSD release and I have been unable to find out what the VOP_GETVOBJECT() macro does and how/what should it be replaced with for my case. Any help is appreciated. > > Thanks > vijay > It's not impossible that you could do it. sendfile was introduced just after 3.0 and quite a bit before 3.1 I don't know however how much vm hacking was required to get it to work.. here is the actual commit message.. this will tell you what was changed.. and at what revision.. What are the chances Nokia would move to a newer version? :-) good luck dg 1998/11/05 06:28:27 PST Modified files: sys/conf options param.c sys/kern init_sysent.c syscalls.c syscalls.master uipc_syscalls.c sys/sys mbuf.h socket.h socketvar.h syscall-hide.h syscall.h syscall.mk sysproto.h sys/vm vm_object.c Log: Implemented zero-copy TCP/IP extensions via sendfile(2) - send a file to a stream socket. sendfile(2) is similar to implementations in HP-UX, Linux, and other systems, but the API is more extensive and addresses many of the complaints that the Apache Group and others have had with those other implementations. Thanks to Marc Slemko of the Apache Group for helping me work out the best API for this. Anyway, this has the "net" result of speeding up sends of files over TCP/IP sockets by about 10X (that is to say, uses 1/10th of the CPU cycles) when compared to a traditional read/write loop. Revision Changes Path 1.107 +2 -1 src/sys/conf/options 1.31 +7 -1 src/sys/conf/param.c 1.61 +1 -0 src/sys/kern/init_sysent.c 1.54 +1 -0 src/sys/kern/syscalls.c 1.54 +3 -1 src/sys/kern/syscalls.master 1.42 +403 -1 src/sys/kern/uipc_syscalls.c 1.30 +2 -1 src/sys/sys/mbuf.h 1.27 +12 -1 src/sys/sys/socket.h 1.30 +8 -1 src/sys/sys/socketvar.h 1.48 +1 -0 src/sys/sys/syscall-hide.h 1.52 +2 -1 src/sys/sys/syscall.h 1.7 +2 -1 src/sys/sys/syscall.mk 1.42 +10 -0 src/sys/sys/sysproto.h 1.135 +1 -3 src/sys/vm/vm_object.c dg 1998/11/05 06:36:38 PST Modified files: sys/i386/conf LINT Log: Document the new NSFBUFS option. Revision Changes Path 1.498 +8 -1 src/sys/i386/conf/LINT On Wed, 21 May 2003 Vijay.Singh@nokia.com wrote: From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 12:45:27 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C437B37B401 for ; Wed, 21 May 2003 12:45:27 -0700 (PDT) Received: from Princeton.EDU (postoffice01.Princeton.EDU [128.112.129.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DADE343FB1 for ; Wed, 21 May 2003 12:45:26 -0700 (PDT) (envelope-from yruan@cs.princeton.edu) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by Princeton.EDU (8.12.9/8.12.9) with ESMTP id h4LJjPiQ025825; Wed, 21 May 2003 15:45:25 -0400 (EDT) Received: from cs.princeton.edu (targe.CS.Princeton.EDU [128.112.139.194]) (authenticated bits=0)h4LJjOGe017772 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 May 2003 15:45:24 -0400 (EDT) Message-ID: <3ECBD681.699F5A4C@cs.princeton.edu> Date: Wed, 21 May 2003 15:41:53 -0400 From: Yaoping Ruan X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay.Singh@nokia.com References: <20030521190346.BDB3737B407@hub.freebsd.org> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: sendfile in FreeBSD 2.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 19:45:28 -0000 Hi, VOP_GETVOBJECT() macro is created by kern/vnode_if.pl and vnode_if.src. By running them you should be able to get vnode_if.c and vnode_if.h file. In vnode_if.h, you will get the macro defined as follow: (From FreeBsd 4.6) static __inline int VOP_GETVOBJECT __P(( struct vnode *vp, struct vm_object **objpp)); static __inline int VOP_GETVOBJECT(vp, objpp) struct vnode *vp; struct vm_object **objpp; { struct vop_getvobject_args a; int rc; a.a_desc = VDESC(vop_getvobject); a.a_vp = vp; a.a_objpp = objpp; rc = VCALL(vp, VOFFSET(vop_getvobject), &a); return (rc); } Hope this helps. - Yaoping > Message: 19 > Date: Wed, 21 May 2003 09:32:26 -0700 > From: > Subject: sendfile in FreeBSD 2.2 > To: > Message-ID: > > Hello. Would it be possible to port the sendfile system call to a FreeBSD 2.2 based system? Has anyone done this? I am trying to port the code from a later FreeBSD release and I have been unable to find out what the VOP_GETVOBJECT() macro does and how/what should it be replaced with for my case. Any help is appreciated. > > Thanks > vijay From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 14:28:11 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3760D37B401; Wed, 21 May 2003 14:28:11 -0700 (PDT) Received: from mail.rdstm.ro (mail.rdstm.ro [193.231.233.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10A4D43FA3; Wed, 21 May 2003 14:28:06 -0700 (PDT) (envelope-from aanton@reversedhell.net) Received: from beast.rdstm.ro (casa_auto [81.196.32.25]) by mail.rdstm.ro (8.12.9/8.12.1) with ESMTP id h4LLS3ba031320; Thu, 22 May 2003 00:28:03 +0300 Content-Type: text/plain; charset="us-ascii" From: Alin-Adrian Anton Organization: Reversed Hell Networks To: freebsd-questions@freebsd.org Date: Tue, 20 May 2003 14:31:14 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200305201431.14692.aanton@reversedhell.net> cc: freebsd-hackers@freebsd.org cc: rofug@rofug.ro Subject: SONY CDRW CRX 120E *solved* X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 21:28:11 -0000 Original problem:=20 Freebsd with Sony CDRW CRX 120E locks on boot. Fix: Disabling auto-detection from BIOS for the device worked out fine, but on= ly on=20 4.x series, on 5.x is still not working. I removed 5.0 and put 4.7 back, and it works just fine. Thanks to Mr. Ghe= orghe=20 for the advice. Appologise: As I removed the 5 and installed 4.7, I lost the mails and I do not remem= ber=20 on what list did I get the solution, and I am sorry for an aproximate sub= ject=20 which may force most of you look at this. I appologise to all of you, sorry, I just could not skip thanking. Alin. From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 15:45:24 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB07D37B401 for ; Wed, 21 May 2003 15:45:24 -0700 (PDT) Received: from viper.evilrealms.net (evilrealms.demon.co.uk [62.49.12.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id D31C143F85 for ; Wed, 21 May 2003 15:45:23 -0700 (PDT) (envelope-from jay@viper.evilrealms.net) Received: from viper.evilrealms.net (jay@localhost [127.0.0.1]) by viper.evilrealms.net (8.12.8/8.12.8) with ESMTP id h4LMjEbh006251; Wed, 21 May 2003 23:45:14 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by viper.evilrealms.net (8.12.8/8.12.8/Submit) id h4LMjEGm006250; Wed, 21 May 2003 23:45:14 +0100 Message-Id: <200305212245.h4LMjEGm006250@viper.evilrealms.net> From: Jay Cornwall To: ticso@cicely.de Date: Wed, 21 May 2003 23:44:46 +0100 User-Agent: KMail/1.5.1 References: <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de> In-Reply-To: <20030521162339.GL21312@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline cc: freebsd-hackers@freebsd.org Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 22:45:25 -0000 X-List-Received-Date: Wed, 21 May 2003 22:45:25 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 May 2003 17:23 pm, you wrote: > > Or it's a bug in the USB driver, not honoring non-blocking I/O. > ugen(4) does not support non-blocking I/O like most other driver also do > not. > > I don't count it as a bug as noone ever told that it does. > It's even documented in ugen(4): > The bulk transfer mode can be in or out depending on the endpoint. = To > perform I/O on a bulk endpoint read(2) and write(2) should be used.= =20 > All I/O operations on a bulk endpoint are unbuffered. > non-blocking requires buffered I/O. Yes, blocking I/O isn't a problem for this application (as it's thread-base= d). The problem arises from ugen blocking the entire process, rather than j= ust the thread which invoked the blocking read. This isn't consistent with normal blocking read behaviour AFAIK, and I just= wondered if there was a reason it was implemented in this way, or if it wa= s simply an oversight on the use of threading with the ugen device. But thanks for your comments, all are welcome. :) Cheers, Jay =2D --=20 http://www.evilrealms.net/ - Systems Administrator & Developer http://www.ic.ac.uk/ - Imperial College, 2nd year CS student =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+zAFgfJLn3O/2GbERArPzAKCAUyHVaVmN7PK38x3v0LJA5mkiqwCfQdOI mzY9GtSfHsk6lzXEm1kASsw=3D =3DBAhJ =2D----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 15:45:48 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA69F37B401 for ; Wed, 21 May 2003 15:45:48 -0700 (PDT) Received: from viper.evilrealms.net (evilrealms.demon.co.uk [62.49.12.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97F0D43F93 for ; Wed, 21 May 2003 15:45:47 -0700 (PDT) (envelope-from jay@viper.evilrealms.net) Received: from viper.evilrealms.net (jay@localhost [127.0.0.1]) by viper.evilrealms.net (8.12.8/8.12.8) with ESMTP id h4LMjEbh006240; Wed, 21 May 2003 23:45:14 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by viper.evilrealms.net (8.12.8/8.12.8/Submit) id h4LMjEVv006239; Wed, 21 May 2003 23:45:14 +0100 Message-Id: <200305212245.h4LMjEVv006239@viper.evilrealms.net> From: Jay Cornwall To: Julian Elischer Date: Wed, 21 May 2003 23:44:16 +0100 User-Agent: KMail/1.5.1 References: In-Reply-To: MIME-Version: 1.0 Content-Description: clearsigned data Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 22:45:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 May 2003 00:40 am, Julian Elischer wrote: > You should load teh "linuxthreads" port > and link with that.. Ah, I hadn't noticed there was a port of this for FreeBSD. I'll give it a try, thanks. :) > under 5.x you will be able to use the native threads (we will have > several to choose from :-) > > under 4.x (I presume that's what you are using) the threading is all in > one process and if a device decides to return "data waiting" in select() > but keeps the reader waiting, it will block the entire process. Hmm, actually this is with a FreeBSD 5.0 (RELENG_5_0) system. The pppoa3 application uses libpthread for its threading implementation; does FreeBSD 5.0 (5.x?) have a different system for threading as well? We currently have a non-threaded application pppoa2 which performs the task very well, but the newer version pppoa3 uses pthreads (which works fine under Linux, but not under FreeBSD). Thanks for your help. :) Cheers, Jay - -- http://www.evilrealms.net/ - Systems Administrator & Developer http://www.ic.ac.uk/ - Imperial College, 2nd year CS student -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+zAFCfJLn3O/2GbERAv8HAKDjLC8nx2BBSMgbjhutpOBddlDaJQCfUGsx CkBPYdXUOMPeGilEbUB4OMI= =Ag0m -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 15:55:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CEB137B401 for ; Wed, 21 May 2003 15:55:19 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 710FE43F85 for ; Wed, 21 May 2003 15:55:18 -0700 (PDT) (envelope-from rooneg@electricjellyfish.net) Received: (qmail 6819 invoked from network); 21 May 2003 22:55:17 -0000 Received: from ool-435713c1.dyn.optonline.net (HELO electricjellyfish.net) (67.87.19.193) by relay.pair.com with SMTP; 21 May 2003 22:55:17 -0000 X-pair-Authenticated: 67.87.19.193 Date: Wed, 21 May 2003 18:55:18 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Jay Cornwall From: Garrett Rooney In-Reply-To: <200305212245.h4LMjEVv006239@viper.evilrealms.net> Message-Id: <4B357E41-8BDF-11D7-88B0-000393CE23F4@electricjellyfish.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: freebsd-hackers@freebsd.org cc: Julian Elischer Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 22:55:19 -0000 On Wednesday, May 21, 2003, at 06:44 PM, Jay Cornwall wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 21 May 2003 00:40 am, Julian Elischer wrote: > >> You should load teh "linuxthreads" port >> and link with that.. > > Ah, I hadn't noticed there was a port of this for FreeBSD. I'll give > it a try, thanks. :) > >> under 5.x you will be able to use the native threads (we will have >> several to choose from :-) >> >> under 4.x (I presume that's what you are using) the threading is all >> in >> one process and if a device decides to return "data waiting" in >> select() >> but keeps the reader waiting, it will block the entire process. > > Hmm, actually this is with a FreeBSD 5.0 (RELENG_5_0) system. The > pppoa3 application uses libpthread for its threading implementation; > does FreeBSD 5.0 (5.x?) have a different system for threading as well? Under 5.0 you would be using libc_r, which is a userland threading implementation. A blocking call (like this one) will cause the whole process to block. There are two new threading libraries (libthr, which gives you basic 1-1 kernel threads, and libpthread, which gives you M-N threading) which will be available in later releases of 5.x. -garrett From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 16:00:29 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E371637B401 for ; Wed, 21 May 2003 16:00:29 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CFA243F3F for ; Wed, 21 May 2003 16:00:26 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h4LN0GrN023522 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 22 May 2003 01:00:23 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.1.10]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h4LN0COs016804 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 22 May 2003 01:00:13 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (localhost [127.0.0.1]) by cicely8.cicely.de (8.12.6/8.12.6) with ESMTP id h4LN0BFP031066; Thu, 22 May 2003 01:00:11 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: (from ticso@localhost) by cicely8.cicely.de (8.12.6/8.12.6/Submit) id h4LN0BJp031065; Thu, 22 May 2003 01:00:11 +0200 (CEST) Date: Thu, 22 May 2003 01:00:11 +0200 From: Bernd Walter To: Jay Cornwall Message-ID: <20030521230010.GD30678@cicely8.cicely.de> References: <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de> <200305212245.h4LMjEGm006250@viper.evilrealms.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305212245.h4LMjEGm006250@viper.evilrealms.net> X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 23:00:30 -0000 On Wed, May 21, 2003 at 11:44:46PM +0100, Jay Cornwall wrote: > On Wednesday 21 May 2003 17:23 pm, you wrote: > > > Or it's a bug in the USB driver, not honoring non-blocking I/O. > > > ugen(4) does not support non-blocking I/O like most other driver also do > > not. > > > > I don't count it as a bug as noone ever told that it does. > > It's even documented in ugen(4): > > The bulk transfer mode can be in or out depending on the endpoint. To > > perform I/O on a bulk endpoint read(2) and write(2) should be used. > > All I/O operations on a bulk endpoint are unbuffered. > > non-blocking requires buffered I/O. > > Yes, blocking I/O isn't a problem for this application (as it's thread-based). The problem arises from ugen blocking the entire process, rather than just the thread which invoked the blocking read. It is a problem as non-blocking I/O is the only way for a userland scheduler to handle I/O based wait conditions. The scheduler silently converts blocking I/O to non blocking so it can reschedule instead of block. If instead the kernel blocks then the userland scheduler is just out of business. > This isn't consistent with normal blocking read behaviour AFAIK, and I just wondered if there was a reason it was implemented in this way, or if it was simply an oversight on the use of threading with the ugen device. Both parts are handled that way for good reasons. As others already wrote - you have to use a thread implementation which is not entirely based on userland scheduling. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 16:03:33 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B3EF37B401 for ; Wed, 21 May 2003 16:03:33 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C64F43F3F for ; Wed, 21 May 2003 16:03:32 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4LN3NwQ023417; Wed, 21 May 2003 19:03:23 -0400 (EDT) Received: from localhost (eischen@localhost)h4LN3Mx0023410; Wed, 21 May 2003 19:03:22 -0400 (EDT) Date: Wed, 21 May 2003 19:03:22 -0400 (EDT) From: Daniel Eischen To: Garrett Rooney In-Reply-To: <4B357E41-8BDF-11D7-88B0-000393CE23F4@electricjellyfish.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Julian Elischer cc: Jay Cornwall Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 23:03:33 -0000 On Wed, 21 May 2003, Garrett Rooney wrote: > On Wednesday, May 21, 2003, at 06:44 PM, Jay Cornwall wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Wednesday 21 May 2003 00:40 am, Julian Elischer wrote: > > > >> You should load teh "linuxthreads" port > >> and link with that.. > > > > Ah, I hadn't noticed there was a port of this for FreeBSD. I'll give > > it a try, thanks. :) > > > >> under 5.x you will be able to use the native threads (we will have > >> several to choose from :-) > >> > >> under 4.x (I presume that's what you are using) the threading is all > >> in > >> one process and if a device decides to return "data waiting" in > >> select() > >> but keeps the reader waiting, it will block the entire process. > > > > Hmm, actually this is with a FreeBSD 5.0 (RELENG_5_0) system. The > > pppoa3 application uses libpthread for its threading implementation; > > does FreeBSD 5.0 (5.x?) have a different system for threading as well? > > Under 5.0 you would be using libc_r, which is a userland threading > implementation. A blocking call (like this one) will cause the whole > process to block. There are two new threading libraries (libthr, which > gives you basic 1-1 kernel threads, and libpthread, which gives you M-N > threading) which will be available in later releases of 5.x. FYI, libpthread is now being installed (for x86 archs) by default in -current and will be in 5.1-release. It's currently installed as libkse (use -lkse, not -pthread) and will be changed to libpthread (-lpthread) for 5.2-release. -- Dan Eischen From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 21:06:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 879CE37B401 for ; Wed, 21 May 2003 21:06:46 -0700 (PDT) Received: from backmaster.cdsnet.net (backmaster.cdsnet.net [63.163.68.2]) by mx1.FreeBSD.org (Postfix) with SMTP id B5B9D43F85 for ; Wed, 21 May 2003 21:06:45 -0700 (PDT) (envelope-from mrcpu@backmaster.cdsnet.net) Received: (qmail 83662 invoked by uid 29999); 22 May 2003 04:06:43 -0000 Date: Wed, 21 May 2003 21:06:43 -0700 From: Jaye Mathisen To: hackers@freebsd.org Message-ID: <20030522040643.GS75453@backmaster.cdsnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: Abysmal mly Extreme RAID performance in 5.0-p7? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 04:06:46 -0000 Have a p2-450 with a mylex 3000 fibre channel RAID card. Configured a few different kind of arrays on it, however, the one I'm interested in right now is this one: da1 at mly0 bus 3 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 135.168MB/s transfers da1: 274656MB (562495488 512 byte sectors: 255H 63S/T 35013C) It's 16 10kRPM seagates striped in a RAID0. This is the best # I've gotten so far with this controller combo. 206438400 bytes transferred in 27.405360 secs (7532775 bytes/sec) mly0: port 0xc800-0xc87f mem 0xd8000000-0xdfffffff,0xd4000000-0xd5ffffff irq 12 at device 8.0 on pci2 mly0: controller initialisation started mly0: eXtremeRAID 3000, 3 channels, firmware 7.00-3-00 (20011219), 128MB RAM da0 at mly0 bus 3 target 0 lun 0 da1 at mly0 bus 3 target 1 lun 0 da2 at mly0 bus 3 target 2 lun 0 Interestingly enougn, I haven't tried any plain SCSI disks on a 5.0 box, but I notice the lack of a "tagged" scsi device entry anywhere for those disks... So I"m thinking the no TAGGED QUEUEING or whatever it used to be under 4.x might be related to the issue... The arrays were all initialized in the BIOS, and the drives were idle before starting the test. No background stuff going on. ANy tips appreciated. From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 21:29:27 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBFEE37B401 for ; Wed, 21 May 2003 21:29:27 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30D6D43F93 for ; Wed, 21 May 2003 21:29:27 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h4M4TMu1003462; Wed, 21 May 2003 23:29:22 -0500 (CDT) (envelope-from dan) Date: Wed, 21 May 2003 23:29:22 -0500 From: Dan Nelson To: Daniel Eischen Message-ID: <20030522042922.GC13024@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OS: FreeBSD 5.1-BETA X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Julian Elischer Subject: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 04:29:28 -0000 In the last episode (May 21), Daniel Eischen said: > FYI, libpthread is now being installed (for x86 archs) by default > in -current and will be in 5.1-release. It's currently installed > as libkse (use -lkse, not -pthread) and will be changed to libpthread > (-lpthread) for 5.2-release. I've not had luck with either libkse or libthr on my SMP machine. The apps either hang or the system locks hard (can't even break into DDB from serial console). Are you just concentrating on UP first, or should libkse work on SMP too? The last time I tried was the end of April. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 21:44:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E27837B401 for ; Wed, 21 May 2003 21:44:04 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id E510243F93 for ; Wed, 21 May 2003 21:44:03 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc53) with ESMTP id <2003052204440105300p5urte>; Thu, 22 May 2003 04:44:01 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA77760; Wed, 21 May 2003 21:44:01 -0700 (PDT) Date: Wed, 21 May 2003 21:43:59 -0700 (PDT) From: Julian Elischer To: Dan Nelson In-Reply-To: <20030522042922.GC13024@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Daniel Eischen Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 04:44:04 -0000 On Wed, 21 May 2003, Dan Nelson wrote: > In the last episode (May 21), Daniel Eischen said: > > FYI, libpthread is now being installed (for x86 archs) by default > > in -current and will be in 5.1-release. It's currently installed > > as libkse (use -lkse, not -pthread) and will be changed to libpthread > > (-lpthread) for 5.2-release. > > I've not had luck with either libkse or libthr on my SMP machine. The > apps either hang or the system locks hard (can't even break into DDB > from serial console). Are you just concentrating on UP first, or > should libkse work on SMP too? The last time I tried was the end of > April. We have SMP systems running > > -- > Dan Nelson > dnelson@allantgroup.com > From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 22:14:39 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AEE837B401 for ; Wed, 21 May 2003 22:14:39 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6137B43FBF for ; Wed, 21 May 2003 22:14:38 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4M5EJwQ022685; Thu, 22 May 2003 01:14:19 -0400 (EDT) Received: from localhost (eischen@localhost)h4M5EIZs022682; Thu, 22 May 2003 01:14:18 -0400 (EDT) Date: Thu, 22 May 2003 01:14:18 -0400 (EDT) From: Daniel Eischen To: Dan Nelson In-Reply-To: <20030522042922.GC13024@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 05:14:39 -0000 On Wed, 21 May 2003, Dan Nelson wrote: > In the last episode (May 21), Daniel Eischen said: > > FYI, libpthread is now being installed (for x86 archs) by default > > in -current and will be in 5.1-release. It's currently installed > > as libkse (use -lkse, not -pthread) and will be changed to libpthread > > (-lpthread) for 5.2-release. > > I've not had luck with either libkse or libthr on my SMP machine. The > apps either hang or the system locks hard (can't even break into DDB > from serial console). Are you just concentrating on UP first, or > should libkse work on SMP too? The last time I tried was the end of > April. I've gotten the kernel to lock up hard when running one of the ACE tests (MT_SOCK_Test), but I don't think it's KSE related. I'm on a UP system. Most of the time that specific test works fine, though. All of the ACE tests have been tested with libkse on both SMP and UP systems. KDE and even mozilla work fine with libkse (although libkse needs a patch to work around rtld-elf not being thread-safe for mozilla to work). -- Dan Eischen From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 01:21:15 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53C3937B401 for ; Thu, 22 May 2003 01:21:15 -0700 (PDT) Received: from bastix.tunix.nl (bastix.tunix.nl [193.79.201.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13CB843F75 for ; Thu, 22 May 2003 01:21:14 -0700 (PDT) (envelope-from rene@canyon.xs4all.nl) Received: (from root@localhost) by bastix.tunix.nl (8.9.3c/8.6.12) id KAA30266 for ; Thu, 22 May 2003 10:21:41 +0200 (CEST) Received: by bastix.tunix.nl (TUNIX txp2/smap) for id sma029916; Thu, 22 May 03 10:20:51 +0200 Date: Thu, 22 May 2003 10:20:30 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Rene de Vries To: hackers@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <406B3072-8C2E-11D7-A0FF-00039357FA7A@canyon.xs4all.nl> X-Mailer: Apple Mail (2.552) Subject: Hardware crypto support, ubsec RSA performance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 08:21:15 -0000 Hello, I've been testing with an "Broadcom CryptoNetX SSL800" card and the performance (when testing with openssl) is a bit disapointing. I would expect about 800 (or nearly 800) sign/s, but in stead the card+openssl only do about 94 sign/s (with 1024 bit RSA keys). This is less than one eigth of what I expected. Am I doing something wrong or is there some magic that I need to perform? Rene Measurements done on FreeBSD 4.8. System: Pentium III 930Mhz (256Mb memory). Using "Openssl speed rsa -elapsed" (version 0.9.7a). With Broadcom CryptoNetX SSL800 (BM5820/ubsec): sign verify sign/s verify/s rsa 512 bits 0.0027s 0.0001s 369.9 8541.5 rsa 1024 bits 0.0106s 0.0002s 94.7 5392.2 rsa 2048 bits 0.1586s 0.0010s 6.3 1014.4 rsa 4096 bits 2.2629s 0.0105s 0.4 95.1 Without hardware encryption: sign verify sign/s verify/s rsa 512 bits 0.0031s 0.0003s 324.7 3599.0 rsa 1024 bits 0.0170s 0.0009s 59.0 1172.5 rsa 2048 bits 0.1026s 0.0029s 9.8 350.6 rsa 4096 bits 0.6629s 0.0098s 1.5 101.8 -- Rene de Vries TUNIX Internet Security & Training From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 03:41:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19EB837B401 for ; Thu, 22 May 2003 03:41:14 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77E0643F75 for ; Thu, 22 May 2003 03:41:13 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h4MAfCXD001018; Thu, 22 May 2003 03:41:12 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h4MAfCeo001017; Thu, 22 May 2003 03:41:12 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 22 May 2003 03:41:12 -0700 From: David Schultz To: Nader Atoofi Message-ID: <20030522104112.GA931@HAL9000.homeunix.com> Mail-Followup-To: Nader Atoofi , freebsd-hackers@FreeBSD.org References: <0DC2A4733C6E8A42A66702B4B7B862DF510BBC@bcmsg011.corp.ads> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DC2A4733C6E8A42A66702B4B7B862DF510BBC@bcmsg011.corp.ads> cc: freebsd-hackers@FreeBSD.ORG Subject: Re: A utility to retrieve system configuration X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 10:41:14 -0000 On Tue, May 20, 2003, Nader Atoofi wrote: > Hi All, > > Is there any utility/script in FreeBSD to collect system > configuration information from the system for recovery > purposes. I'm looking for something like Sun Explorer in Solaris > or Snap in AIX. I'm not aware of any such tool, but the base system maintains everything interesting configuration-wise in /etc, which you can simply tar up. If you use a custom kernel config or custom /boot/loader.conf, you will want to back those up as well, but this is easily done by putting these two files in /etc and making symlinks. For third-party packages installed through ports, you probably want /usr/local/etc plus the output of pkg_info(1). From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 03:50:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A2D837B401 for ; Thu, 22 May 2003 03:50:26 -0700 (PDT) Received: from shrike.submonkey.net (pc1-cdif2-5-cust38.cdif.cable.ntl.com [81.101.150.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 765A243F75 for ; Thu, 22 May 2003 03:50:25 -0700 (PDT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.12) id 19IneM-0002wz-00; Thu, 22 May 2003 11:50:18 +0100 Date: Thu, 22 May 2003 11:50:18 +0100 From: Ceri Davies To: Nader Atoofi , freebsd-hackers@FreeBSD.org Message-ID: <20030522105018.GA11303@submonkey.net> References: <0DC2A4733C6E8A42A66702B4B7B862DF510BBC@bcmsg011.corp.ads> <20030522104112.GA931@HAL9000.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030522104112.GA931@HAL9000.homeunix.com> User-Agent: Mutt/1.5.4i Sender: Ceri Davies Subject: Re: A utility to retrieve system configuration X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 10:50:26 -0000 On Thu, May 22, 2003 at 03:41:12AM -0700, David Schultz wrote: > On Tue, May 20, 2003, Nader Atoofi wrote: > > Hi All, > > > > Is there any utility/script in FreeBSD to collect system > > configuration information from the system for recovery > > purposes. I'm looking for something like Sun Explorer in Solaris > > or Snap in AIX. > > I'm not aware of any such tool, but the base system maintains > everything interesting configuration-wise in /etc, which you can > simply tar up. If you use a custom kernel config or custom > /boot/loader.conf, you will want to back those up as well, but > this is easily done by putting these two files in /etc and making > symlinks. For third-party packages installed through ports, you > probably want /usr/local/etc plus the output of pkg_info(1). I also grab /var/cron in my backups; with the stuff that David has mentioned above, that's (crossed fingers) all I need to fully recover a system's configuration. Ceri -- From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 03:51:25 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D12F637B40A for ; Thu, 22 May 2003 03:51:25 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 938CE43F93 for ; Thu, 22 May 2003 03:51:22 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h4MApKXD001052; Thu, 22 May 2003 03:51:20 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h4MApJ1A001051; Thu, 22 May 2003 03:51:19 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 22 May 2003 03:51:19 -0700 From: David Schultz To: Peter Edwards Message-ID: <20030522105119.GB931@HAL9000.homeunix.com> Mail-Followup-To: Peter Edwards , hackers@freebsd.org References: <20030521180222.0FA3343F3F@mx1.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030521180222.0FA3343F3F@mx1.FreeBSD.org> cc: hackers@FreeBSD.ORG Subject: Re: Question on (ab)using the swap pager and VM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 10:51:26 -0000 On Wed, May 21, 2003, Peter Edwards wrote: > Hi All, > As a programming exercise, I'm trying to write what is in essence > a synthetic filesystem where the synthetic files contain large > amounts of data I want to use a swap pager as a cached store for > the data I'm providing. (ie, it'll be generated in the kernel) Have you taken a look at md(4)? This driver provides the swap-backed functionality you want at the block device level where it should be. If you really want to duplicate the functionality, though, take a look at how md(4) does it. Specifically, look at mdcreate_swap(). From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 08:39:50 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EA6437B401 for ; Thu, 22 May 2003 08:39:50 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9542C43F3F for ; Thu, 22 May 2003 08:39:49 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19IsAN-0003Sl-00; Thu, 22 May 2003 08:39:40 -0700 Message-ID: <3ECCEEF5.2CF956D@mindspring.com> Date: Thu, 22 May 2003 08:38:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ticso@cicely.de References: <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44cd15d84a27b0bd7cc7d52e421f937eaa8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Julian Elischer cc: Jay Cornwall Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 15:39:50 -0000 Bernd Walter wrote: > On Tue, May 20, 2003 at 09:44:13PM -0700, Terry Lambert wrote: > > Or it's a bug in the USB driver, not honoring non-blocking I/O. > > ugen(4) does not support non-blocking I/O like most other driver also do > not. > > I don't count it as a bug as noone ever told that it does. > It's even documented in ugen(4): > The bulk transfer mode can be in or out depending on the endpoint. To > perform I/O on a bulk endpoint read(2) and write(2) should be used. All > I/O operations on a bulk endpoint are unbuffered. > non-blocking requires buffered I/O. Then it should produce an error when someone tries to enable non-blocking I/O on it, and *that's* the bug. > The device gets regulary polled if someone has an outstanding transfer. > Implementing nonblocking I/O would require always to have an > outstanding read for open devices - similar is done in ucom(4). The way Vadim Antonov got around this in the BSDI ft(4) driver for tape drives on floppy controllers was to provide a buffer sufficient for the largest block of data that you could ever transfer in one read with the driver, in both the read and write directions, and decoupling them from the actual user read/write requests in the strategy routine. This avoided him needing to do the evil of an outstanding read for open devices. FWIW. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 08:46:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBCD837B404 for ; Thu, 22 May 2003 08:46:19 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 536F443F93 for ; Thu, 22 May 2003 08:46:19 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19IsGm-0006Wn-00; Thu, 22 May 2003 08:46:17 -0700 Message-ID: <3ECCF083.A6CA789F@mindspring.com> Date: Thu, 22 May 2003 08:45:07 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Edwards References: <20030521180222.0FA3343F3F@mx1.FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a48f4af97021f58dc4f89bea104193879fa7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: hackers@freebsd.org Subject: Re: Question on (ab)using the swap pager and VM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 15:46:20 -0000 Peter Edwards wrote: > What I'm less sure about is how to write to the swap pager. My best guess > is that I can modify the page with impunity once it's wired, then > do something like what vm_proc_swapout() does, calling vm_page_dirty() > and vm_page_unwire() to put it back on to the correct queue, where the > swapper can launder it if neccessary. > > Overall, can I do something like this to allocate and write a single > page to the swap pager? (modulo locking stuff) Just allocate pageable kernel memory. There's a function to do that, though it's not often used. When you want to swap something out, let the VM decide to do it for you: it's smarter than your policy enforcement routine. So just dirty the page, and let it happen automatically. You will need to make your FS able to pause in case of page faults, so you will have to be very careful, internally, about locking. And yes, it's a criminal thing to do... you will be eating KVA mappings for the pages. 8-). You are better off considering a kernel process (not thread) to give it a seperate address space from the kernel's KVA, and doing your operations in that address space instead. That will decrease KVA pressure from your evil scheme, and will increase the size of the FS you can back this way. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 08:53:20 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0132737B40A for ; Thu, 22 May 2003 08:53:20 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34A5343F75 for ; Thu, 22 May 2003 08:53:19 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19IsNQ-0007UQ-00; Thu, 22 May 2003 08:53:09 -0700 Message-ID: <3ECCF21F.A8FA576C@mindspring.com> Date: Thu, 22 May 2003 08:51:59 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jay Cornwall References: <200305212245.h4LMjEVv006239@viper.evilrealms.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a48f4af97021f58dc4a42d74457a87c738666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Julian Elischer Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 15:53:20 -0000 Jay Cornwall wrote: > Hmm, actually this is with a FreeBSD 5.0 (RELENG_5_0) system. The > pppoa3 application uses libpthread for its threading implementation; > does FreeBSD 5.0 (5.x?) have a different system for threading as well? libkse or libthr. See /usr/src/lib. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 08:59:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9E1337B401 for ; Thu, 22 May 2003 08:59:08 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DBC043F93 for ; Thu, 22 May 2003 08:59:07 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h4MFwsrN038829 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 22 May 2003 17:58:56 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h4MFwpOs021356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2003 17:58:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h4MFwp5i001407; Thu, 22 May 2003 17:58:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h4MFwoCP001406; Thu, 22 May 2003 17:58:50 +0200 (CEST) Date: Thu, 22 May 2003 17:58:50 +0200 From: Bernd Walter To: Terry Lambert Message-ID: <20030522155850.GY501@cicely12.cicely.de> References: <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de> <3ECCEEF5.2CF956D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ECCEEF5.2CF956D@mindspring.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-BETA alpha User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Jay Cornwall cc: ticso@cicely.de cc: Julian Elischer Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 15:59:09 -0000 On Thu, May 22, 2003 at 08:38:29AM -0700, Terry Lambert wrote: > Bernd Walter wrote: > > On Tue, May 20, 2003 at 09:44:13PM -0700, Terry Lambert wrote: > > > Or it's a bug in the USB driver, not honoring non-blocking I/O. > > > > ugen(4) does not support non-blocking I/O like most other driver also do > > not. > > > > I don't count it as a bug as noone ever told that it does. > > It's even documented in ugen(4): > > The bulk transfer mode can be in or out depending on the endpoint. To > > perform I/O on a bulk endpoint read(2) and write(2) should be used. All > > I/O operations on a bulk endpoint are unbuffered. > > non-blocking requires buffered I/O. > > Then it should produce an error when someone tries to enable > non-blocking I/O on it, and *that's* the bug. Who says it does not? Non-blocking I/O is used silently inside the threading library. What shall the library do with the error? refuse read/write to the application which requested blocking I/O? Or ignore this error and work with blocking I/O and potentially block the entire process? >From the pthread sematics the latter is the correct way and it is the way it's handled right now. > > The device gets regulary polled if someone has an outstanding transfer. > > Implementing nonblocking I/O would require always to have an > > outstanding read for open devices - similar is done in ucom(4). > > The way Vadim Antonov got around this in the BSDI ft(4) driver > for tape drives on floppy controllers was to provide a buffer > sufficient for the largest block of data that you could ever > transfer in one read with the driver, in both the read and write > directions, and decoupling them from the actual user read/write > requests in the strategy routine. This avoided him needing to > do the evil of an outstanding read for open devices. Yes - that works if you know what to transfer. But ugen doesn't know anything about what it transfers, therefor it can't buffer. See uftdi devices - every read contains 2 extra bytes containing addition informations - if we buffer the userland driver might get confused because it might request less data. More evil - the thread library might aggregate or split at will. In short: non-blocking I/O won't work for ugen bulk pipes. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 09:00:39 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4589737B401 for ; Thu, 22 May 2003 09:00:39 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DE0643FA3 for ; Thu, 22 May 2003 09:00:38 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19IsUL-0000iH-00; Thu, 22 May 2003 09:00:18 -0700 Message-ID: <3ECCF3CC.CB425BD4@mindspring.com> Date: Thu, 22 May 2003 08:59:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jay Cornwall References: <20030521162339.GL21312@cicely12.cicely.de> <200305212245.h4LMjEGm006250@viper.evilrealms.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4920d6112372ec1aeed6dc9a7b81754e3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 16:00:39 -0000 Jay Cornwall wrote: > > I don't count it as a bug as noone ever told that it does. > > It's even documented in ugen(4): > > The bulk transfer mode can be in or out depending on the endpoint. To > > perform I/O on a bulk endpoint read(2) and write(2) should be used. > > All I/O operations on a bulk endpoint are unbuffered. > > non-blocking requires buffered I/O. > > Yes, blocking I/O isn't a problem for this application (as it's thread-based). > The problem arises from ugen blocking the entire process, rather than just > the thread which invoked the blocking read. It's the blocking I/O. The FreeBSD default libc_r utilizes a call-conversion scheduler that converts a blocking call into a non-blocking call plus a thread context switch in a user-space scheduler. If the conversion from a blocking call to a non-blocking call fails, then it will hang waiting for the operation to complete. For fd-based operations, the conversion is done on the basis of setting the O_NDELAY flag on the descriptor, and using normal fd system calls, which return -1 and an errno of "EAGAIN" when the operation would have blocked. The underlying code is then expected to have started the entirety of the requested operation, if it's a read. Short reads and writes, if a block would occur after a partial transfer, are wrappered to allow retry at a later point, until the entire request is satisfied. NB: The page fault path in the NBIO read-from-file case fails to start the operation and then return immediately. I personally consider this a bug, but all it effectively does is add latency, not hang, like you are experiencing. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 09:18:51 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 032D137B401 for ; Thu, 22 May 2003 09:18:51 -0700 (PDT) Received: from testmail.wolves.k12.mo.us (testmail.wolves.k12.mo.us [207.160.214.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DAFB43FA3 for ; Thu, 22 May 2003 09:18:50 -0700 (PDT) (envelope-from cdillon@wolves.k12.mo.us) Received: by testmail.wolves.k12.mo.us (Postfix, from userid 1001) id 0CFFDCD1D; Thu, 22 May 2003 11:18:49 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by testmail.wolves.k12.mo.us (Postfix) with ESMTP id 08164CD1C; Thu, 22 May 2003 11:18:49 -0500 (CDT) Date: Thu, 22 May 2003 11:18:49 -0500 (CDT) From: Chris Dillon To: Jaye Mathisen In-Reply-To: <20030522040643.GS75453@backmaster.cdsnet.net> Message-ID: <20030522111408.G48288@duey.wolves.k12.mo.us> References: <20030522040643.GS75453@backmaster.cdsnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: Abysmal mly Extreme RAID performance in 5.0-p7? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 16:18:51 -0000 On Wed, 21 May 2003, Jaye Mathisen wrote: > 206438400 bytes transferred in 27.405360 secs (7532775 bytes/sec) What were the exact dd options you used for this? If you didn't specify a block size, the default block size of 512 bytes is used, and you will get dismal performance figures no matter what kind of hardware you have. Increase the block size to at _least_ 64KB. I believe 128KB is the maximum block size FreeBSD will use, so testing with block sizes above that won't matter much. -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, ARM, and S/390 under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 09:19:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 338C037B401 for ; Thu, 22 May 2003 09:19:53 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 983F543F85 for ; Thu, 22 May 2003 09:19:52 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Isn5-0004xd-00; Thu, 22 May 2003 09:19:40 -0700 Message-ID: <3ECCF855.6A0E8830@mindspring.com> Date: Thu, 22 May 2003 09:18:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Nelson References: <20030522042922.GC13024@dan.emsphone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4645a37d7fa0594f8493b4dc7a347b8303ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Daniel Eischen cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 16:19:53 -0000 Dan Nelson wrote: > In the last episode (May 21), Daniel Eischen said: > > FYI, libpthread is now being installed (for x86 archs) by default > > in -current and will be in 5.1-release. It's currently installed > > as libkse (use -lkse, not -pthread) and will be changed to libpthread > > (-lpthread) for 5.2-release. > > I've not had luck with either libkse or libthr on my SMP machine. The > apps either hang or the system locks hard (can't even break into DDB > from serial console). Are you just concentrating on UP first, or > should libkse work on SMP too? The last time I tried was the end of > April. Make sure you use SCHED_4BSD, rather than SCHED_ULE, if you are using one of the kernel threads libraries, for now. You really should read the -current archives before attempting any of this, if you don't follow -current closely enough to have caught Jeff's message on this, or which kernel threading libraries are available. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 09:25:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E3AE37B401 for ; Thu, 22 May 2003 09:25:37 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01A6E43F75 for ; Thu, 22 May 2003 09:25:37 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Isse-0006B5-00; Thu, 22 May 2003 09:25:25 -0700 Message-ID: <3ECCF9AD.362453A8@mindspring.com> Date: Thu, 22 May 2003 09:24:13 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4645a37d7fa0594f897ad7e1a2c911032a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Dan Nelson cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 16:25:37 -0000 Daniel Eischen wrote: > All of the ACE tests have been tested with libkse on both > SMP and UP systems. KDE and even mozilla work fine with > libkse (although libkse needs a patch to work around rtld-elf > not being thread-safe for mozilla to work). Note that you should probably always apply this patch, since the dl*() calls are not the only place that programs make invalid assumptions about threads rescheduling following an involuntary context switch: that's just where Mozilla has its main problems in its invalid assumptions about the threads implementation. I've been able to construct two other assumption example cases that cause lockup, even when the program is not dynamic linking anything. Of course, I'm not going to publish these, because if I did, someone would go in and put training wheels in that code, too, instead of fixing the offending threaded program's source code like they should. I'm trying to come up with an example that breaks, even if you spew locking code all over libc; when/if I do that (I'm not spending gobs of time on it), THEN I'll publish the example to prove that spewing the locks won't fix all the logic problems in the programs that use the threaded libraries. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 09:52:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DB4337B404 for ; Thu, 22 May 2003 09:52:37 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D16EE43F85 for ; Thu, 22 May 2003 09:52:36 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h4MGqU8f086751; Thu, 22 May 2003 11:52:30 -0500 (CDT) (envelope-from dan) Date: Thu, 22 May 2003 11:52:30 -0500 From: Dan Nelson To: Terry Lambert Message-ID: <20030522165229.GA1694@dan.emsphone.com> References: <20030522042922.GC13024@dan.emsphone.com> <3ECCF855.6A0E8830@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ECCF855.6A0E8830@mindspring.com> X-OS: FreeBSD 5.1-BETA X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Daniel Eischen cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 16:52:38 -0000 In the last episode (May 22), Terry Lambert said: > Make sure you use SCHED_4BSD, rather than SCHED_ULE, if you are using > one of the kernel threads libraries, for now. > > You really should read the -current archives before attempting any of > this, if you don't follow -current closely enough to have caught > Jeff's message on this, or which kernel threading libraries are > available. I do read -current, and I'm definitely not going anywhere near SCHED_ULE. I just tested both libraries with today's kernel and libraries, and was able to get a hard lockup with both libthr and libkse. Mysql seems to run okay. Starting a threaded pike process seems to be the killer. Unfortunately, pike's a pretty large app so it's not easy to get a stripped-down testcase. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 10:19:30 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7067037B404 for ; Thu, 22 May 2003 10:19:30 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id E503B43FAF for ; Thu, 22 May 2003 10:19:29 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc52) with ESMTP id <2003052217192905200nv656e>; Thu, 22 May 2003 17:19:29 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA82525; Thu, 22 May 2003 10:19:28 -0700 (PDT) Date: Thu, 22 May 2003 10:19:26 -0700 (PDT) From: Julian Elischer To: Dan Nelson In-Reply-To: <20030522165229.GA1694@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Daniel Eischen Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 17:19:30 -0000 On Thu, 22 May 2003, Dan Nelson wrote: > In the last episode (May 22), Terry Lambert said: > > Make sure you use SCHED_4BSD, rather than SCHED_ULE, if you are using > > one of the kernel threads libraries, for now. > > > > You really should read the -current archives before attempting any of > > this, if you don't follow -current closely enough to have caught > > Jeff's message on this, or which kernel threading libraries are > > available. > > I do read -current, and I'm definitely not going anywhere near > SCHED_ULE. I just tested both libraries with today's kernel and > libraries, and was able to get a hard lockup with both libthr and > libkse. Mysql seems to run okay. Starting a threaded pike process > seems to be the killer. Unfortunately, pike's a pretty large app so > it's not easy to get a stripped-down testcase. Ok so we need to get a description of this 'lockup'. 1/ does teh whole system lock up? 2/ is this SMP? (how many cpus)? 3/ does the system respond to pings? 4/ do you have teh kernel dbugger installed, and if you do, does it respond on the console to . You may have to start you app from outside X11 on a console to be able to see the console once it has frozen if it si an X app. 5/ if it DOES go into ddb, what does 'ps' show? 6/ got a serial console? > > -- > Dan Nelson > dnelson@allantgroup.com > From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 10:23:27 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52A2937B401; Thu, 22 May 2003 10:23:27 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89B0643F75; Thu, 22 May 2003 10:23:26 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc03) with ESMTP id <20030522172325003002c5pqe>; Thu, 22 May 2003 17:23:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA82565; Thu, 22 May 2003 10:23:24 -0700 (PDT) Date: Thu, 22 May 2003 10:23:23 -0700 (PDT) From: Julian Elischer To: hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: gcc bug? Openoffice port impossibel to compile on 4.8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 17:23:27 -0000 I have rebuilt my system several times and rebuilt all ports.. /usr/ports/editors/openoffice always ends up with: /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.2.3/include/g++-v3/backward/bac kward_warning.h:32:2: warning: #warning This file includes at least one deprecat ed or antiquated header. Please consider using one of the 32 headers found in se ction 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated h eader . To disable this warning use -Wno-deprecated. /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.2.3/include/g++-v3/iostream: In function `void __static_initialization_and_destruction_0(int, int)': /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.2.3/include/g++-v3/iostream:63: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[5]: *** [Names.o] Error 1 gmake[5]: Leaving directory `/usr/ports/editors/openoffice/work/mozilla/work/moz illa/extensions/transformiix/source/xslt' gmake[4]: *** [libs] Error 2 gmake[4]: Leaving directory `/usr/ports/editors/openoffice/work/mozilla/work/moz illa/extensions/transformiix/source' gmake[3]: *** [libs] Error 2 gmake[3]: Leaving directory `/usr/ports/editors/openoffice/work/mozilla/work/moz illa/extensions/transformiix' gmake[2]: *** [libs] Error 2 gmake[2]: Leaving directory `/usr/ports/editors/openoffice/work/mozilla/work/moz illa/extensions' gmake[1]: *** [tier_94] Error 2 gmake[1]: Leaving directory `/usr/ports/editors/openoffice/work/mozilla/work/moz illa' gmake: *** [default] Error 2 *** Error code 2 Stop in /usr/ports/editors/openoffice/work/mozilla. *** Error code 1 Stop in /usr/ports/editors/openoffice. *** Error code 1 Stop in /usr/ports/editors/openoffice. *** Error code 1 Stop in /usr/ports/editors/openoffice. From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 10:43:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A068337B405 for ; Thu, 22 May 2003 10:43:40 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE08543F3F for ; Thu, 22 May 2003 10:43:38 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h4MHhYK7062401; Thu, 22 May 2003 12:43:34 -0500 (CDT) (envelope-from dan) Date: Thu, 22 May 2003 12:43:34 -0500 From: Dan Nelson To: Julian Elischer Message-ID: <20030522174334.GC1694@dan.emsphone.com> References: <20030522165229.GA1694@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.1-BETA X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Daniel Eischen Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 17:43:41 -0000 In the last episode (May 22), Julian Elischer said: > On Thu, 22 May 2003, Dan Nelson wrote: > > I do read -current, and I'm definitely not going anywhere near > > SCHED_ULE. I just tested both libraries with today's kernel and > > libraries, and was able to get a hard lockup with both libthr and > > libkse. Mysql seems to run okay. Starting a threaded pike process > > seems to be the killer. Unfortunately, pike's a pretty large app so > > it's not easy to get a stripped-down testcase. > > Ok so we need to get a description of this 'lockup'. > > 1/ does teh whole system lock up? > 2/ is this SMP? (how many cpus)? > 3/ does the system respond to pings? > 4/ do you have teh kernel dbugger installed, and if you do, does it > respond on the console to . You may have to start you > app from outside X11 on a console to be able to see the console once it > has frozen if it si an X app. > 5/ if it DOES go into ddb, what does 'ps' show? > 6/ got a serial console? Yes, the entire system locks. 2-CPU system. No ping responses. CTRL-ALT-ESC doesn't do anything, and neither does ~ ^B from the serial console. No X. I don't have BREAK_TO_DEBUGGER enabled because my console is connected to a Windows machine and I don't want my Unix box to hang every time I reboot it :) Do you think a real BREAK might work where ~ ^B doesn't? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 11:08:10 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9549637B401 for ; Thu, 22 May 2003 11:08:10 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B7EC43FBD for ; Thu, 22 May 2003 11:08:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc52) with ESMTP id <2003052218080905200ns78te>; Thu, 22 May 2003 18:08:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA82887; Thu, 22 May 2003 11:08:09 -0700 (PDT) Date: Thu, 22 May 2003 11:08:07 -0700 (PDT) From: Julian Elischer To: Dan Nelson In-Reply-To: <20030522174334.GC1694@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Daniel Eischen Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 18:08:10 -0000 On Thu, 22 May 2003, Dan Nelson wrote: > In the last episode (May 22), Julian Elischer said: > > On Thu, 22 May 2003, Dan Nelson wrote: > > > I do read -current, and I'm definitely not going anywhere near > > > SCHED_ULE. I just tested both libraries with today's kernel and > > > libraries, and was able to get a hard lockup with both libthr and > > > libkse. Mysql seems to run okay. Starting a threaded pike process > > > seems to be the killer. Unfortunately, pike's a pretty large app so > > > it's not easy to get a stripped-down testcase. > > > > Ok so we need to get a description of this 'lockup'. > > Yes, the entire system locks. 2-CPU system. > > No ping responses. CTRL-ALT-ESC doesn't do anything, and neither does > ~ ^B from the serial console. No X. > > I don't have BREAK_TO_DEBUGGER enabled because my console is connected > to a Windows machine and I don't want my Unix box to hang every time I > reboot it :) Do you think a real BREAK might work where ~ ^B doesn't? no, I'd say that the lack of ping response is a very good indicator. what's 'pike'? I assume it's one of /usr/ports/lang/pike72 or /usr/ports/lang/pike74? if so what do I need to do to du0plicate the hang.. you said it is predictable.. (what you could do is run it from a serial cable under truss..) From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 12:12:38 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD1D237B401 for ; Thu, 22 May 2003 12:12:38 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08B6F43F3F for ; Thu, 22 May 2003 12:12:38 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h4MJCYpU019164; Thu, 22 May 2003 14:12:34 -0500 (CDT) (envelope-from dan) Date: Thu, 22 May 2003 14:12:34 -0500 From: Dan Nelson To: Julian Elischer Message-ID: <20030522191234.GA13498@dan.emsphone.com> References: <20030522174334.GC1694@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-OS: FreeBSD 5.1-BETA X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Daniel Eischen Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 19:12:39 -0000 In the last episode (May 22), Julian Elischer said: > what's 'pike'? > > I assume it's one of /usr/ports/lang/pike72 or /usr/ports/lang/pike74? > if so what do I need to do to du0plicate the hang.. you said it is > predictable.. Yep, that's it. After a couple more test lockups, it looks like simply running the threads configure test is enough to trigger the problem. The pike74 port hasn't been updated to the new bsd.gnome.mk style, so it doesn't build. The quickest way to reproduce the hang is: fetch ftp://pike.ida.liu.se/pub/pike/latest-stable/Pike-v7.4.20.tar.gz, extract it, run sed -i.bak -e 's/-pthread/-lkse/' src/configure, then run make. It consistently dies for me at "checking posix threads". I even get a panic now: checking if this version of FreeBSD may have working threads... yes checking for pthread-config... no checking -lkse... yes checking Initial stack limit... Bus error (core dumped) 1048576 checking for pthread_init... no checking for pthread_mutexattr_init... yes checking for pthread_kill... yes checking posix threads... panic: mtx_lock() of spin mutex └┬<▀é└B @ ../../../vm/vm_map.c:2142 cpuid = 1; lapic.id = 00000000 Stack backtrace: panic(c03e5cf4,c082e000,c03f59e2,85e,d1d21000) at panic+0x11b _mtx_lock_flags(c21a42c0,0,c03f59e2,85e,db9e8b9c) at _mtx_lock_flags+0x84 vm_map_delete(c0831000,d1d1d000,d1d21000,dfe1dda0,c3ed5e40) at vm_map_delete+0x19b vm_map_remove(c0831000,d1d1d000,d1d21000,121,c3ed5d10) at vm_map_remove+0x55 cpu_thread_clean(c3ed5d10,6ab,c3ed5d10,c3ed5e40,db9e8c3c) at cpu_thread_clean+0x66 thread_free(c3ed5d10,0,c03e7262,365,c492e000) at thread_free+0x14 thread_reap(c3e45780,ffffffff,0,28c,0) at thread_reap+0x124 wait1(c3821be0,db9e8d10,0,db9e8d40,c039b603) at wait1+0x7d6 wait4(c3821be0,db9e8d10,c03fb8ec,3fb,4) at wait4+0x20 syscall(c038002f,2f,2f,1,80ff100) at syscall+0x3a3 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (7), eip = 0x807c1eb, esp = 0xbfbff01c, ebp = 0xbfbff038 --- boot() called on cpu#1 Manually running the "checking posix threads" conftest by itself works fine, though... -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 12:21:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6886B37B401 for ; Thu, 22 May 2003 12:21:41 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95E8843F93 for ; Thu, 22 May 2003 12:21:40 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4MJLTwQ005965; Thu, 22 May 2003 15:21:29 -0400 (EDT) Received: from localhost (eischen@localhost)h4MJLTsT005961; Thu, 22 May 2003 15:21:29 -0400 (EDT) Date: Thu, 22 May 2003 15:21:29 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Dan Nelson Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 19:21:41 -0000 On Thu, 22 May 2003, Julian Elischer wrote: > > On Thu, 22 May 2003, Dan Nelson wrote: > > > In the last episode (May 22), Terry Lambert said: > > > Make sure you use SCHED_4BSD, rather than SCHED_ULE, if you are using > > > one of the kernel threads libraries, for now. > > > > > > You really should read the -current archives before attempting any of > > > this, if you don't follow -current closely enough to have caught > > > Jeff's message on this, or which kernel threading libraries are > > > available. > > > > I do read -current, and I'm definitely not going anywhere near > > SCHED_ULE. I just tested both libraries with today's kernel and > > libraries, and was able to get a hard lockup with both libthr and > > libkse. Mysql seems to run okay. Starting a threaded pike process > > seems to be the killer. Unfortunately, pike's a pretty large app so > > it's not easy to get a stripped-down testcase. > > Ok so we need to get a description of this 'lockup'. In my experience with the ACE test MT_SOCK_Test: > 1/ does teh whole system lock up? Yes. > 2/ is this SMP? (how many cpus)? No. > 3/ does the system respond to pings? No. > 4/ do you have teh kernel dbugger installed, and if you do, does it > respond on the console to . You may have to start you > app from outside X11 on a console to be able to see the console once it > has frozen if it si an X app. Haven't been able to do this. > 5/ if it DOES go into ddb, what does 'ps' show? > 6/ got a serial console? No :( You can repeat it by downloading and building the ACE tests. David and I can tell you how. It doesn't happen all the time, so it is not easily repeatable. Though, it's only been the last few weeks that I've had the problem. -- Dan Eischen From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 15:15:01 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D6D937B401 for ; Thu, 22 May 2003 15:15:01 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DA9443F93 for ; Thu, 22 May 2003 15:15:00 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h4MMEtpw018925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 22 May 2003 15:14:57 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <016f01c320af$946f65c0$52557f42@errno.com> From: "Sam Leffler" To: "Rene de Vries" , References: <406B3072-8C2E-11D7-A0FF-00039357FA7A@canyon.xs4all.nl> Date: Thu, 22 May 2003 15:14:55 -0700 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Subject: Re: Hardware crypto support, ubsec RSA performance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 22:15:01 -0000 I've made no effort to tune the asymmetric crypto ops. All the techniques I used to speedup symmetric ops (and more) should apply to asymmetric ops. Feel free to dig in. Sam ----- Original Message ----- From: "Rene de Vries" To: Sent: Thursday, May 22, 2003 1:20 AM Subject: Hardware crypto support, ubsec RSA performance > Hello, > > I've been testing with an "Broadcom CryptoNetX SSL800" card and the > performance (when testing with openssl) is a bit disapointing. I would > expect about 800 (or nearly 800) sign/s, but in stead the card+openssl > only do about 94 sign/s (with 1024 bit RSA keys). This is less than one > eigth of what I expected. Am I doing something wrong or is there some > magic that I need to perform? > > Rene > > Measurements done on FreeBSD 4.8. > System: Pentium III 930Mhz (256Mb memory). > Using "Openssl speed rsa -elapsed" (version 0.9.7a). > > With Broadcom CryptoNetX SSL800 (BM5820/ubsec): > > sign verify sign/s verify/s > rsa 512 bits 0.0027s 0.0001s 369.9 8541.5 > rsa 1024 bits 0.0106s 0.0002s 94.7 5392.2 > rsa 2048 bits 0.1586s 0.0010s 6.3 1014.4 > rsa 4096 bits 2.2629s 0.0105s 0.4 95.1 > > Without hardware encryption: > > sign verify sign/s verify/s > rsa 512 bits 0.0031s 0.0003s 324.7 3599.0 > rsa 1024 bits 0.0170s 0.0009s 59.0 1172.5 > rsa 2048 bits 0.1026s 0.0029s 9.8 350.6 > rsa 4096 bits 0.6629s 0.0098s 1.5 101.8 > > -- > Rene de Vries > TUNIX Internet Security & Training > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 16:04:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 342EB37B404 for ; Thu, 22 May 2003 16:03:58 -0700 (PDT) Received: from viper.evilrealms.net (evilrealms.demon.co.uk [62.49.12.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5E9C43F85 for ; Thu, 22 May 2003 16:03:57 -0700 (PDT) (envelope-from jay@viper.evilrealms.net) Received: from viper.evilrealms.net (jay@localhost [127.0.0.1]) by viper.evilrealms.net (8.12.8/8.12.8) with ESMTP id h4MN3xu8025985 for ; Fri, 23 May 2003 00:03:59 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by viper.evilrealms.net (8.12.9/8.12.8/Submit) id h4MN3xf8025984 for freebsd-hackers@freebsd.org; Fri, 23 May 2003 00:03:59 +0100 From: Jay Cornwall To: freebsd-hackers@freebsd.org Date: Fri, 23 May 2003 00:03:56 +0100 User-Agent: KMail/1.5.1 References: <200305210013.09834.jay@evilrealms.net> In-Reply-To: <200305210013.09834.jay@evilrealms.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200305230003.59620.jay@evilrealms.net> Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 23:04:03 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 May 2003 00:13 am, I wrote: > I'm sure there are good reasons for implementing it in this way, but I'd = be > interested to hear what they are, and if any alternative approaches had > been/are being considered. And my question has been answered, in the form of the new libkse and libthr= =20 threading libraries. :) Thank you all very much for your replies (just one reply here, to save=20 littering the thread), and for taking the time to help me out. We now have = a=20 working system for the Speedtouch USB modem (which was what I set out to do= ),=20 and plans to improve it with the new threading libraries when they've reach= ed=20 stable releases. And of course I'll continue to contribute to the FreeBSD project where I ca= n.=20 :) Cheers, Jay =2D --=20 http://www.evilrealms.net/ - Systems Administrator & Developer http://www.ic.ac.uk/ - Imperial College, 2nd year CS student =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+zVdffJLn3O/2GbERAgPyAJ4j6SrF/RAXALgnaAc6OpDQSwq/gACeLitx y+TVo1XpyhwX2sHqtSawugM=3D =3DuR9I =2D----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 17:00:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC4E737B405 for ; Thu, 22 May 2003 17:00:07 -0700 (PDT) Received: from athenas.yan.com.br (athenas.yan.com.br [200.202.253.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 70BE743FAF for ; Thu, 22 May 2003 17:00:05 -0700 (PDT) (envelope-from ddg@yan.com.br) Received: (qmail 9675 invoked by uid 1023); 22 May 2003 20:58:30 -0300 Message-ID: <20030522235830.9674.qmail@athenas.yan.com.br> To: freebsd-config@freebsd.org, freebsd-security@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org From: "ddg" Date: Thu, 22 May 2003 20:58:30 --300 X-Priority: 3 X-Mailer: Yan Internet Webmail 1.0 X-Originating-IP: [200.202.253.162] MIME-Version: 1.0 Content-Type: text/plain; charset= X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: VPN IPSEC WIRELESS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 00:00:08 -0000 I am having problems in the implementation of a VPN, below made a project of my net: INTRANET (10.0.0.0/24) | 10.0.0.5 xl0 NetBSD IPNAT ( map wi0 10.0.0.0/24 -> 192.168.213.10 ) wi0 192.168.213.10/30 | | Wireless VPN | | 192.168.213.9/30 xl2 FreeBSD NATD ( divert natd all from any to any ) xl0 200.x.x.5/24 | 200.x.x.1/24 Router | | INTERNET NetBSD Node ( ipsec.conf ): spdadd 192.168.213.10 0.0.0.0/0 any -P out ipsec esp/tunnel/192.168.213.10-192.168.213.9/require; spdadd 0.0.0.0/0 192.168.213.10 any -P in ipsec esp/tunnel/192.168.213.9-192.168.213.10/require; FreeBSD Node ( ipsec.conf ): spdadd 0.0.0.0/0 192.168.213.10 any -P out ipsec esp/tunnel/192.168.213.9-192.168.213.10/require; spdadd 192.168.213.10 0.0.0.0/0 any -P in ipsec esp/tunnel/192.168.213.10-192.168.213.9/require; The connection between the NetBSD and the FreeBSD work correctly. The problem is when I make a connection of the computer with IP 10.0.0.1 to an IP in the Internet. I do not know to make a rule for ipsec.conf that he makes with that the connections of 10.0.0.0/24 are directed for inside of tunnel. Somebody knows the solution? []s Daniel Dias Gonçalves f22@netbsd.com.br ---- From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 22:10:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B521437B404 for ; Thu, 22 May 2003 22:10:23 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id D189343F93 for ; Thu, 22 May 2003 22:10:22 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc10p.dialup.mindspring.com ([209.86.4.25] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19J4op-0006Lv-00; Thu, 22 May 2003 22:10:16 -0700 Message-ID: <3ECDACF2.CF7A637A@mindspring.com> Date: Thu, 22 May 2003 22:09:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Nelson References: <20030522042922.GC13024@dan.emsphone.com> <3ECCF855.6A0E8830@mindspring.com> <20030522165229.GA1694@dan.emsphone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a46c1befd355a0d114fe39a0160c1149f73ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Daniel Eischen cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 05:10:24 -0000 Dan Nelson wrote: > In the last episode (May 22), Terry Lambert said: > > Make sure you use SCHED_4BSD, rather than SCHED_ULE, if you are using > > one of the kernel threads libraries, for now. > > > > You really should read the -current archives before attempting any of > > this, if you don't follow -current closely enough to have caught > > Jeff's message on this, or which kernel threading libraries are > > available. > > I do read -current, and I'm definitely not going anywhere near > SCHED_ULE. I just tested both libraries with today's kernel and > libraries, and was able to get a hard lockup with both libthr and > libkse. Mysql seems to run okay. Starting a threaded pike process > seems to be the killer. Unfortunately, pike's a pretty large app so > it's not easy to get a stripped-down testcase. The philosophies behing libthr and libkse are different. For libthr, you basically have a FreeBSD version of Linux threads; for libkse, there are some issues you have to deal with. The first of these issues is that you have to add Daniel's patch to the libkse scheduler code. This is necessary because there is a lot of threads code that is not completely compliant with the POSIX standard: it makes assumptions which POSIX does not permit, about what thread gets scheduled to run after an involuntary context switch. The original Netscape (e.g. 4.7) has this same assumption, and Java interfaces that use image maps lock it up if you move the mouse over the map while the GIF is loading. If you wait for it to load, there's no problem. Mozilla has similar assumptions. The second of these is that the libkse model is M:N, with N being defaulted to 1. If you want more kernel threads, you have to ask for them (and you aren't doing that). In general, a lot of code is going to assume for M:N that M==N; to get this, you will need to create threads with an attribute other than the default of "NULL", with the scope set to PTHREAD_SCOPE_SYSTEM. You should also look at the actual scheduler code in libkse to see if there are any other requirements for creating KSEG's for KSE's for user space threads (I haven't looked at it for several weeks now, so I don't know if anything has changed, unless it was sent to one of the mailing lists). With both of these out of the way, libkse should work for you. The libthr may not work for you due to scheduling order, or it may not work for you because signals are not masked per process, or it may not work if you have threads that depend on the PTHREAD_SCOPE_PROCESS attribute (kernel threads like the Linux model are inherently incapable of supporting this scope). Basically, you'll have to play around a bit with it. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 07:43:38 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16EB237B401 for ; Fri, 23 May 2003 07:43:38 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D08F43F85 for ; Fri, 23 May 2003 07:43:37 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4NEhNwQ008104; Fri, 23 May 2003 10:43:23 -0400 (EDT) Received: from localhost (eischen@localhost)h4NEhMT0008097; Fri, 23 May 2003 10:43:22 -0400 (EDT) Date: Fri, 23 May 2003 10:43:22 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3ECDACF2.CF7A637A@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Dan Nelson cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 14:43:38 -0000 On Thu, 22 May 2003, Terry Lambert wrote: > Dan Nelson wrote: > > In the last episode (May 22), Terry Lambert said: > > > Make sure you use SCHED_4BSD, rather than SCHED_ULE, if you are using > > > one of the kernel threads libraries, for now. > > > > > > You really should read the -current archives before attempting any of > > > this, if you don't follow -current closely enough to have caught > > > Jeff's message on this, or which kernel threading libraries are > > > available. > > > > I do read -current, and I'm definitely not going anywhere near > > SCHED_ULE. I just tested both libraries with today's kernel and > > libraries, and was able to get a hard lockup with both libthr and > > libkse. Mysql seems to run okay. Starting a threaded pike process > > seems to be the killer. Unfortunately, pike's a pretty large app so > > it's not easy to get a stripped-down testcase. > > The philosophies behing libthr and libkse are different. For > libthr, you basically have a FreeBSD version of Linux threads; > for libkse, there are some issues you have to deal with. > > The first of these issues is that you have to add Daniel's patch > to the libkse scheduler code. This is necessary because there is > a lot of threads code that is not completely compliant with the > POSIX standard: it makes assumptions which POSIX does not permit, > about what thread gets scheduled to run after an involuntary > context switch. The original Netscape (e.g. 4.7) has this same > assumption, and Java interfaces that use image maps lock it up if > you move the mouse over the map while the GIF is loading. If you > wait for it to load, there's no problem. Mozilla has similar > assumptions. This is just because rtld-elf is not thread safe (or written so that locks are not needed as you claim). > The second of these is that the libkse model is M:N, with N being > defaulted to 1. If you want more kernel threads, you have to ask N is defaulted to the number of CPUs that you have. Libkse will create as many KSEs as there are CPUs (or whatever kern.threads.virtual_cpu is set to); these will be KSEs that run scope process threads. Scope system threads get their own KSE/KSEG pair without regard to number of CPUs or kern.threads.virtual_cpu. Trying to exceed the number of CPUs with kern.threads.virtual_cpu will not work unless you also set kern.threads.debug=1. You really shouldn't need to do this, but we use it for testing and debugging. > for them (and you aren't doing that). In general, a lot of code > is going to assume for M:N that M==N; to get this, you will need > to create threads with an attribute other than the default of > "NULL", with the scope set to PTHREAD_SCOPE_SYSTEM. You should > also look at the actual scheduler code in libkse to see if there > are any other requirements for creating KSEG's for KSE's for > user space threads (I haven't looked at it for several weeks now, > so I don't know if anything has changed, unless it was sent to > one of the mailing lists). > > With both of these out of the way, libkse should work for you. > > The libthr may not work for you due to scheduling order, or it > may not work for you because signals are not masked per process, > or it may not work if you have threads that depend on the > PTHREAD_SCOPE_PROCESS attribute (kernel threads like the Linux > model are inherently incapable of supporting this scope). > > Basically, you'll have to play around a bit with it. > > -- Terry > -- Dan Eischen From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 08:36:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E301837B401 for ; Fri, 23 May 2003 08:36:55 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53B6543F3F for ; Fri, 23 May 2003 08:36:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc0o6.dialup.mindspring.com ([209.86.3.6] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19JEb6-0003nV-00; Fri, 23 May 2003 08:36:45 -0700 Message-ID: <3ECE3FBE.7EBE5ED5@mindspring.com> Date: Fri, 23 May 2003 08:35:26 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d071267c8ef139432ac040cfd76a1b472601a10902912494350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Dan Nelson cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 15:36:56 -0000 Daniel Eischen wrote: > This is just because rtld-elf is not thread safe (or written > so that locks are not needed as you claim). No. There is plenty of code that falls into this category; as soon as you finish fixing rtld, you will reveal other problems. Mark my words; you cannot make user space thread safe for all eventualities, with the user process never having to know anything about mutexes that the pthreads model expects the user program to hold in order to ensure against race conditions. > > The second of these is that the libkse model is M:N, with N being > > defaulted to 1. If you want more kernel threads, you have to ask > > N is defaulted to the number of CPUs that you have. Libkse > will create as many KSEs as there are CPUs (or whatever > kern.threads.virtual_cpu is set to); these will be KSEs > that run scope process threads. Scope system threads > get their own KSE/KSEG pair without regard to number of > CPUs or kern.threads.virtual_cpu. > > Trying to exceed the number of CPUs with kern.threads.virtual_cpu > will not work unless you also set kern.threads.debug=1. You > really shouldn't need to do this, but we use it for testing > and debugging. This is handy to know; so basically, my expectation from reading the code around PTHREAD_SCOPE_SYSTEM was correct: a single CPU system with PTHREAD_SCOPE_PROCESS (the default) can still get itself blocked in the kernel by a single blocking call (as in the USB bulk read device issue). So he can avoid using the sysctl's, which would be evil, but he could test without modifying his program, if he had to. Thanks for the info! -- Terry From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 11:15:49 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C9CE37B401 for ; Fri, 23 May 2003 11:15:49 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BF7343FB1 for ; Fri, 23 May 2003 11:15:48 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc03) with ESMTP id <2003052318154700300l89dfe>; Fri, 23 May 2003 18:15:47 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA92074; Fri, 23 May 2003 11:15:46 -0700 (PDT) Date: Fri, 23 May 2003 11:15:44 -0700 (PDT) From: Julian Elischer To: Terry Lambert In-Reply-To: <3ECE3FBE.7EBE5ED5@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Dan Nelson cc: Daniel Eischen Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 18:15:49 -0000 On Fri, 23 May 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > This is handy to know; so basically, my expectation from > reading the code around PTHREAD_SCOPE_SYSTEM was correct: > a single CPU system with PTHREAD_SCOPE_PROCESS (the default) > can still get itself blocked in the kernel by a single > blocking call (as in the USB bulk read device issue). No you are completely wrong.. Each PTHREAD_SCOPE_PROCESS gets its OWN KSE to run on. that thread may block but other threads may run unimpeded. From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 12:07:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2909B37B401 for ; Fri, 23 May 2003 12:07:58 -0700 (PDT) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6381F43FD7 for ; Fri, 23 May 2003 12:07:57 -0700 (PDT) (envelope-from wayne@staff.msen.com) Received: from manor.msen.com (wayne@localhost [127.0.0.1]) by manor.msen.com (8.12.7M/8.12.7) with ESMTP id h4NJ7ubu089890 for ; Fri, 23 May 2003 15:07:56 -0400 (EDT) Message-Id: <200305231907.h4NJ7ubu089890@manor.msen.com> To: freebsd-hackers@FreeBSD.ORG Date: Fri, 23 May 2003 15:07:56 -0400 From: "Michael R. Wayne" Subject: mbuf reference? (and missing man page) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 19:07:58 -0000 Missing man page: 4.8 releasse - man netstat has a reference to mbuf(9) but man mbuf says: No manual entry for mbuf Real question: I'm seeking some additional documentation on the relationship between mbufs, mbuf clusters and network memory usage (essentially the output of netstat -m). Obviously, the number of mbuf clusters is tunable with kern.ipc.nmbclusters. The maximum number of mbufs appears to be 4 * that number (or is that 4 a tunable?) Not sure how network memory allocation is chosen (% of base memory size as default?) and, does it grow dynamically or should one be building a new kernel once, say, 80% of the mb_map is in use? Or simply ignore occasional high mb_map utilization unless requests for memorey are delayed/denied? /\/\ \/\/ From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 12:41:56 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1B3337B404 for ; Fri, 23 May 2003 12:41:56 -0700 (PDT) Received: from smtp.distributel.net (cns2.distributel.NET [66.38.181.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5935643F93 for ; Fri, 23 May 2003 12:41:55 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: from godel.mtl.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by smtp.distributel.net (8.12.6/8.12.6) with ESMTP id h4NJfrDi068144; Fri, 23 May 2003 15:41:54 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Bosko Milekic To: "Michael R. Wayne" , freebsd-hackers@FreeBSD.ORG Date: Fri, 23 May 2003 15:42:36 +0000 User-Agent: KMail/1.4.3 References: <200305231907.h4NJ7ubu089890@manor.msen.com> In-Reply-To: <200305231907.h4NJ7ubu089890@manor.msen.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200305231542.36266.bmilekic@unixdaemons.com> Subject: Re: mbuf reference? (and missing man page) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bmilekic@unixdaemons.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 19:41:57 -0000 On May 23, 2003 07:07 pm, Michael R. Wayne wrote: > Missing man page: > 4.8 releasse - man netstat has a reference to mbuf(9) but man mbuf > says: No manual entry for mbuf True. This is a bug. Someone from -doc should fix this, because mbuf(9) only exists in 5.0 and later. Try submitting a PR and filing it to -doc. Here's a link to an on-line version of the mbuf(9)=20 man page appearing in 5.x: http://www.FreeBSD.org/cgi/man.cgi?apropos=3D0&sektion=3D9& \ query=3Dmbuf&manpath=3DFreeBSD+5.0-current&format=3Dhtml > Real question: > I'm seeking some additional documentation on the relationship > between mbufs, mbuf clusters and network memory usage (essentially > the output of netstat -m). > > Obviously, the number of mbuf clusters is tunable with > kern.ipc.nmbclusters. The maximum number of mbufs appears to be 4 * > that number (or is that 4 a tunable?) kern.ipc.nmbclusters and kern.ipc.nmbufs set the number of clusters and= =20 the number of mbufs, respectively, and are tunable at boottime. > Not sure how network memory allocation is chosen (% of base memory > size as default?) and, does it grow dynamically or should one be > building a new kernel once, say, 80% of the mb_map is in use? Or > simply ignore occasional high mb_map utilization unless requests > for memorey are delayed/denied? Yeah, the last thing you said sounds correct. You don't want to be tuning for high memory usage just because you had a single spike. This is one of the advantages of having a capped virtual address space for network buffers (that does not grow dynamically); if you get hit by a sudden high usage spike (e.g., DOS, other irregularity), your system will hopefully stay alive as the network buffer usage will get capped off due to the finiteness of the address space reserved for the buffers. So, basically, you want to tune/increase NMBCLUSTERS according to how many times you've failed on the allocations over a longer period of time. If you are always hitting high usage and failing, you should consider increasing NMBCLUSTERS. If you notice that your highest cluster or mbuf usage has never actually hit the maximum, but you're still getting memory denied requests, then you're actually running out of RAM, and increasing NMBCLUSTERS is not going to help you. Adding RAM is. > /\/\ \/\/ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" --=20 Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 12:53:50 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5003C37B401 for ; Fri, 23 May 2003 12:53:50 -0700 (PDT) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABFBC43F85 for ; Fri, 23 May 2003 12:53:49 -0700 (PDT) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 7D1EE10BF81; Fri, 23 May 2003 21:53:48 +0200 (CEST) Date: Fri, 23 May 2003 21:53:48 +0200 From: "Simon L. Nielsen" To: Bosko Milekic Message-ID: <20030523195346.GA66202@nitro.dk> References: <200305231907.h4NJ7ubu089890@manor.msen.com> <200305231542.36266.bmilekic@unixdaemons.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <200305231542.36266.bmilekic@unixdaemons.com> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf reference? (and missing man page) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 19:53:50 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.05.23 15:42:36 +0000, Bosko Milekic wrote: >=20 > On May 23, 2003 07:07 pm, Michael R. Wayne wrote: > > Missing man page: > > 4.8 releasse - man netstat has a reference to mbuf(9) but man mbuf > > says: No manual entry for mbuf >=20 > True. This is a bug. Someone from -doc should fix this, because > mbuf(9) only exists in 5.0 and later. Try submitting a PR and > filing it to -doc. Here's a link to an on-line version of the mbuf(9)= =20 > man page appearing in 5.x: Actually there is a two PR's open for this already: docs/44337 and docs/50463. So it will be dealt with when someone gets around to it... --=20 Simon L. Nielsen --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+znxK8kocFXgPTRwRArufAKCguYr5mOpyyGZrCm2gIQCegVHHuACg1sCl 6kfoIhZOomkYVu0o2ytRzxs= =WRpG -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 13:08:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EE9E37B401 for ; Fri, 23 May 2003 13:08:03 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CCCC43F3F for ; Fri, 23 May 2003 13:08:02 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (big.x.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h4NK82tJ058263 for ; Fri, 23 May 2003 13:08:02 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3ECE800F.9040104@acm.org> Date: Fri, 23 May 2003 13:09:51 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: pkg_add and osreldate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 20:08:03 -0000 pkg_add currently has logic to determine which dir (under ftp://ftp.freebsd.org/pub/FreeBSD/ports) to use for downloading packages. This is driven by the following table: > { 410000, 410000, "/packages-4.1-release" }, > { 420000, 420000, "/packages-4.2-release" }, > { 430000, 430000, "/packages-4.3-release" }, > { 440000, 440000, "/packages-4.4-release" }, > { 450000, 450000, "/packages-4.5-release" }, > { 460000, 460001, "/packages-4.6-release" }, > { 460002, 460099, "/packages-4.6.2-release" }, > { 470000, 470099, "/packages-4.7-release" }, > { 300000, 399000, "/packages-3-stable" }, > { 400000, 499000, "/packages-4-stable" }, > { 510000, 599000, "/packages-5-stable" }, > { 0, 9999999, "/packages-current" }, This table is searched linearly; the first entry where osreldate falls within the indicated range is used. Problem: If someone runs this on a 4.5-STABLE system, for instance (osreldate=450100), then they will be directed to "packages-4-stable". It seems that packages-4.5-release would be more appropriate. Similarly, this logic claims that a 3.x system should be using packages from 5-stable! (Though I don't consider that a serious problem, of course. ;-) I'm considering a simpler scheme: choose the first item with version <= osreldate. > { 440000, "/packages-4.4-release" }, > { 450000, "/packages-4.5-release" }, > { 460000, "/packages-4.6-release" }, > { 460002, "/packages-4.6.2-release" }, > { 470000, "/packages-4.7-release" }, > { 480000, "/packages-4.8-release" }, > { 490000, "/packages-4-stable" }, > { 500000, "/packages-5.0-release" }, > { 510000, "/packages-5-current" }, > { 520000, "/packages-5-current" }, > { 600000, "/packages-current" }, This would seem to provide cleaner handling of the various borderline cases. Any thoughts? Tim From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 13:22:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BC1937B401 for ; Fri, 23 May 2003 13:22:32 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B784D43FA3 for ; Fri, 23 May 2003 13:22:31 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4NKMHwQ008965; Fri, 23 May 2003 16:22:17 -0400 (EDT) Received: from localhost (eischen@localhost)h4NKMH3d008962; Fri, 23 May 2003 16:22:17 -0400 (EDT) Date: Fri, 23 May 2003 16:22:17 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3ECE3FBE.7EBE5ED5@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Dan Nelson cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 20:22:32 -0000 On Fri, 23 May 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > This is just because rtld-elf is not thread safe (or written > > so that locks are not needed as you claim). > > No. There is plenty of code that falls into this category; as > soon as you finish fixing rtld, you will reveal other problems. > Mark my words; you cannot make user space thread safe for all > eventualities, with the user process never having to know > anything about mutexes that the pthreads model expects the user > program to hold in order to ensure against race conditions. We can easily correct for dlfoo() being called by different threads concurrently, so I don't include that in being "thread-safe". As it stands now, rtld-elf is not thread-safe even without calls to dlfoo(). > > > The second of these is that the libkse model is M:N, with N being > > > defaulted to 1. If you want more kernel threads, you have to ask > > > > N is defaulted to the number of CPUs that you have. Libkse > > will create as many KSEs as there are CPUs (or whatever > > kern.threads.virtual_cpu is set to); these will be KSEs > > that run scope process threads. Scope system threads > > get their own KSE/KSEG pair without regard to number of > > CPUs or kern.threads.virtual_cpu. > > > > Trying to exceed the number of CPUs with kern.threads.virtual_cpu > > will not work unless you also set kern.threads.debug=1. You > > really shouldn't need to do this, but we use it for testing > > and debugging. > > This is handy to know; so basically, my expectation from > reading the code around PTHREAD_SCOPE_SYSTEM was correct: > a single CPU system with PTHREAD_SCOPE_PROCESS (the default) > can still get itself blocked in the kernel by a single > blocking call (as in the USB bulk read device issue). If I am reading you correctly, then no. Scope process threads will block in the kernel, but upcalls will be made to the originating KSE and new threads will be scheduled. -- Dan Eischen From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 13:33:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2652137B401 for ; Fri, 23 May 2003 13:33:18 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5085A43FA3 for ; Fri, 23 May 2003 13:33:17 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4NKX7wQ010945; Fri, 23 May 2003 16:33:07 -0400 (EDT) Received: from localhost (eischen@localhost)h4NKX776010941; Fri, 23 May 2003 16:33:07 -0400 (EDT) Date: Fri, 23 May 2003 16:33:07 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Dan Nelson Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 20:33:18 -0000 On Fri, 23 May 2003, Julian Elischer wrote: > > > On Fri, 23 May 2003, Terry Lambert wrote: > > > Daniel Eischen wrote: > > > > This is handy to know; so basically, my expectation from > > reading the code around PTHREAD_SCOPE_SYSTEM was correct: > > a single CPU system with PTHREAD_SCOPE_PROCESS (the default) > > can still get itself blocked in the kernel by a single > > blocking call (as in the USB bulk read device issue). > > > No you are completely wrong.. > > Each PTHREAD_SCOPE_PROCESS gets its OWN KSE to run on. > that thread may block but other threads may run unimpeded. I'm not sure if what you meant here, but here's a (hopefully) clearer explanation. All threads that are created with PTHREAD_SCOPE_PROCESS (the default) will run in the same (initial) KSEG. The initial KSEG will have as many KSEs as CPUs by default. When a scope process thread blocks in the kernel, upcalls are made to the originating KSE and a new thread is scheduled. When scope process threads unblock in the kernel, upcalls are made to one or more of the same KSEs within the initial KSEG to notify the library that the threads can be resumed. Each scope system thread gets its own KSE/KSEG pair in which to run. -- Dan Eischen From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 13:49:29 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5316037B401 for ; Fri, 23 May 2003 13:49:29 -0700 (PDT) Received: from iole.cs.brandeis.edu (iole.cs.brandeis.edu [129.64.3.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5024643FB1 for ; Fri, 23 May 2003 13:49:28 -0700 (PDT) (envelope-from meshko@cs.brandeis.edu) Received: from localhost (meshko@localhost) by iole.cs.brandeis.edu (8.11.6/8.11.6) with ESMTP id h4NKnUY07137 for ; Fri, 23 May 2003 16:49:31 -0400 X-Authentication-Warning: iole.cs.brandeis.edu: meshko owned process doing -bs Date: Fri, 23 May 2003 16:49:30 -0400 (EDT) From: Mikhail Kruk To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1082257411-464521798-1053722970=:7062" Subject: current crashes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 20:49:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1082257411-464521798-1053722970=:7062 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I'm trying to get a Gateway laptop working on CURRENT. See dmesg.txt for hardware details. Also notice the lock order reversal complaint, but it's not my main problem. The main problem is that it crashes quite often. It always crashes in one of the acpi threads, but not always in the same. I've seen it happen in both acpi_task? and in acpi_thermal. I can run for quite a long time, but eventually it happens. The most reliable way to provoke crash is to start buildworld. As a result I'm running with 5.0-RELEASE system and 5.1-BETA kernel (took arount 10 attempts to build the kernel). Now when it crashes I get into debugger, but I couldn't figure out how to make it dump core. I tried givin 'panic' command and it seemed like it was dumping core, but it's not in /var/crash. Am I doing it wrong? Anyway, here is the trace (typed it in manually): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x80790ab0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06ea4d0 stack pointer = 0x10:0xcd10bbf0 frame pointer = 0x19:0xcd10bbf0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6 (acpi_task1) kernel: type 12 trap, code=0 Stopped at AcpiNsMapHandleToNode+0x20: cmpb $0xaa,0(%edx) trace: AcpiNsMapHandleToNode AcpiGetHandle acpi_pwer_switch_consumer acpi_tz_switch_cooler_on acpi_ForeachPackageObject acpi_tz_monitor atcpi_task_thread fork_exit fork_trampoline Please excuse me if this is wrong place to send this and thanks in avance! -m --1082257411-464521798-1053722970=:7062 Content-Type: TEXT/plain; name="dmesg.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDMgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIDUuMS1CRVRBICMwOiBGcmkgTWF5IDIzIDEyOjI4 OjE2IEdNVCAyMDAzDQogICAgcm9vdEBiZWdlbW90LmR5bmRucy5vcmc6L3Vz ci9zcmMvc3lzL2kzODYvY29tcGlsZS9HRU5FUklDDQpQcmVsb2FkZWQgZWxm IGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhjMDcxYTAwMC4N ClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvYWNwaS5rbyIg YXQgMHhjMDcxYTBhOC4NClRpbWVjb3VudGVyICJpODI1NCIgIGZyZXF1ZW5j eSAxMTkzMTgyIEh6DQpUaW1lY291bnRlciAiVFNDIiAgZnJlcXVlbmN5IDIz OTI5NTQ2ODQgSHoNCkNQVTogSW50ZWwoUikgUGVudGl1bShSKSA0IENQVSAy LjQwR0h6ICgyMzkyLjk1LU1IeiA2ODYtY2xhc3MgQ1BVKQ0KICBPcmlnaW4g PSAiR2VudWluZUludGVsIiAgSWQgPSAweGYyNyAgU3RlcHBpbmcgPSA3DQog IEZlYXR1cmVzPTB4YmZlYmY5ZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQ QUUsTUNFLENYOCxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENM RkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBC RT4NCnJlYWwgbWVtb3J5ICA9IDI2NzkxMTE2OCAoMjU1IE1CKQ0KYXZhaWwg bWVtb3J5ID0gMjUyNDg5NzI4ICgyNDAgTUIpDQpQZW50aXVtIFBybyBNVFJS IHN1cHBvcnQgZW5hYmxlZA0KbnB4MDogPG1hdGggcHJvY2Vzc29yPiBvbiBt b3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGludGVyZmFjZQ0KYWNwaTA6IDxH QVRFV0EgNDAwICAgICA+IG9uIG1vdGhlcmJvYXJkDQpwY2liaW9zOiBCSU9T IHZlcnNpb24gMi4xMA0KVXNpbmcgJFBJUiB0YWJsZSwgMTEgZW50cmllcyBh dCAweGMwMGZkZjEwDQphY3BpMDogcG93ZXIgYnV0dG9uIGlzIGhhbmRsZWQg YXMgYSBmaXhlZCBmZWF0dXJlIHByb2dyYW1taW5nIG1vZGVsLg0KVGltZWNv dW50ZXIgIkFDUEktZmFzdCIgIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6DQphY3Bp X3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAw eDEwMDgtMHgxMDBiIG9uIGFjcGkwDQphY3BpX2NwdTA6IDxDUFU+IG9uIGFj cGkwDQphY3BpX3R6MDogPHRoZXJtYWwgem9uZT4gb24gYWNwaTANCnBjaWIw OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24g YWNwaTANCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwDQphZ3AwOiA8 SW50ZWwgODI4NDUgaG9zdCB0byBBR1AgYnJpZGdlPiBtZW0gMHhlYzAwMDAw MC0weGVmZmZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMA0KcGNpYjE6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTANCnBj aTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxDQpwY2kxOiA8ZGlzcGxheSwg VkdBPiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpDQp1aGNp MDogPEludGVsIDgyODAxQ0EvQ0FNIChJQ0gzKSBVU0IgY29udHJvbGxlciBV U0ItQT4gcG9ydCAweDE4MDAtMHgxODFmIGlycSAxMCBhdCBkZXZpY2UgMjku MCBvbiBwY2kwDQp1c2IwOiA8SW50ZWwgODI4MDFDQS9DQU0gKElDSDMpIFVT QiBjb250cm9sbGVyIFVTQi1BPiBvbiB1aGNpMA0KdXNiMDogVVNCIHJldmlz aW9uIDEuMA0KdWh1YjA6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkv MCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxDQp1aHViMDogMiBwb3J0cyB3aXRo IDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnBjaWIyOiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMA0KcGNpMjogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjINCmNiYjA6IDxPMk1pY3JvIE9aNjkxMi82 OTcyIFBDSS1DYXJkQnVzIEJyaWRnZT4gaXJxIDEwIGF0IGRldmljZSAyLjAg b24gcGNpMg0KY2FyZGJ1czA6IDxDYXJkQnVzIGJ1cz4gb24gY2JiMA0KcGNj YXJkMDogPDE2LWJpdCBQQ0NhcmQgYnVzPiBvbiBjYmIwDQpwY2kyOiA8bXVs dGltZWRpYSwgYXVkaW8+IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRh Y2hlZCkNCmZ3b2hjaTA6IHZlbmRvcj0xMDRjLCBkZXY9ODAyNg0KZndvaGNp MDogPDEzOTQgT3BlbiBIb3N0IENvbnRyb2xsZXIgSW50ZXJmYWNlPiBtZW0g MHhlODIwMDAwMC0weGU4MjAzZmZmLDB4ZTgyMDYwMDAtMHhlODIwNjdmZiBp cnEgMTAgYXQgZGV2aWNlIDUuMCBvbiBwY2kyDQpmd29oY2kwOiBPSENJIHZl cnNpb24gMS4xMCAoUk9NPTEpDQpmd29oY2kwOiBOby4gb2YgSXNvY2hyb25v dXMgY2hhbm5lbCBpcyA0Lg0KZndvaGNpMDogRVVJNjQgMDA6ZTA6Yjg6MDQ6 MDE6MDE6ZWM6ZjENCmZ3b2hjaTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQw MCwgMSBwb3J0cy4NCmZ3b2hjaTA6IExpbmsgUzQwMCwgbWF4X3JlYyAyMDQ4 IGJ5dGVzLg0KZmlyZXdpcmUwOiA8SUVFRTEzOTQoRmlyZVdpcmUpIGJ1cz4g b24gZndvaGNpMA0KaWZfZndlMDogPEV0aGVybmV0IG92ZXIgRmlyZVdpcmU+ IG9uIGZpcmV3aXJlMA0KaWZfZndlMDogRmFrZSBFdGhlcm5ldCBhZGRyZXNz OiAwMjplMDpiODowMTplYzpmMQ0Kc2JwMDogPFNCUDIvU0NTSSBvdmVyIGZp cmV3aXJlPiBvbiBmaXJld2lyZTANCmZ3b2hjaTA6IEluaXRpYXRlIGJ1cyBy ZXNldA0KZnhwMDogPEludGVsIDgyODAxQ0FNIChJQ0gzKSBQcm8vMTAwIFZF IEV0aGVybmV0PiBwb3J0IDB4M2MwMC0weDNjM2YgbWVtIDB4ZTgyMDUwMDAt MHhlODIwNWZmZiBpcnEgMTAgYXQgZGV2aWNlIDguMCBvbiBwY2kyDQpmeHAw OiBFdGhlcm5ldCBhZGRyZXNzIDAwOmUwOmI4OjUwOjIzOjdiDQptaWlidXMw OiA8TUlJIGJ1cz4gb24gZnhwMA0KaW5waHkwOiA8aTgyNTYyRVQgMTAvMTAw IG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVzMA0KaW5waHkwOiAgMTBiYXNl VCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0 bw0KaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24g cGNpMA0KaXNhMDogPElTQSBidXM+IG9uIGlzYWIwDQphdGFwY2kwOiA8SW50 ZWwgSUNIMyBVRE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHgxODIwLTB4MTgy ZiwweDM3NC0weDM3NywweDE3MC0weDE3NywweDNmNC0weDNmNywweDFmMC0w eDFmNyBtZW0gMHhlODAwMDAwMC0weGU4MDAwM2ZmIGF0IGRldmljZSAzMS4x IG9uIHBjaTANCmF0YTA6IGF0IDB4MWYwIGlycSAxNCBvbiBhdGFwY2kwDQph dGExOiBhdCAweDE3MCBpcnEgMTUgb24gYXRhcGNpMA0KcGNpMDogPHNlcmlh bCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFj aGVkKQ0KcGNpMDogPHNpbXBsZSBjb21tcz4gYXQgZGV2aWNlIDMxLjYgKG5v IGRyaXZlciBhdHRhY2hlZCkNCmFjcGlfbGlkMDogPENvbnRyb2wgTWV0aG9k IExpZCBTd2l0Y2g+IG9uIGFjcGkwDQogICAgQUNQSS0xMjg3OiAqKiogRXJy b3I6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uTElEXy5fUFNX XSAoTm9kZSAweGMyNjIyZTgwKSwgQUVfTk9UX0VYSVNUDQphY3BpX2FjYWQw OiA8QUMgYWRhcHRlcj4gb24gYWNwaTANCmFjcGlfY21iYXQwOiA8Q29udHJv bCBtZXRob2QgQmF0dGVyeT4gb24gYWNwaTANCmFjcGlfYnV0dG9uMDogPFNs ZWVwIEJ1dHRvbj4gb24gYWNwaTANCmF0a2JkYzA6IDxLZXlib2FyZCBjb250 cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2NCwweDYwIGlycSAxIG9uIGFjcGkw DQphdGtiZDA6IDxBVCBLZXlib2FyZD4gZmxhZ3MgMHgxIGlycSAxIG9uIGF0 a2JkYzANCmtiZDAgYXQgYXRrYmQwDQpwc20wOiA8UFMvMiBNb3VzZT4gaXJx IDEyIG9uIGF0a2JkYzANCnBzbTA6IG1vZGVsIEdlbmVyaWMgUFMvMiBtb3Vz ZSwgZGV2aWNlIElEIDANCmFjcGlfZWMwOiA8ZW1iZWRkZWQgY29udHJvbGxl cj4gcG9ydCAweDY2LDB4NjIgb24gYWNwaTANCnBwYzAgcG9ydCAweDc3OC0w eDc3ZiwweDM3OC0weDM3ZiBpcnEgNyBkcnEgMyBvbiBhY3BpMA0KcHBjMDog R2VuZXJpYyBjaGlwc2V0IChFQ1AvUFMyL05JQkJMRSkgaW4gQ09NUEFUSUJM RSBtb2RlDQpwcGMwOiBGSUZPIHdpdGggMTYvMTYvOCBieXRlcyB0aHJlc2hv bGQNCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMwDQpwbGlw MDogPFBMSVAgbmV0d29yayBpbnRlcmZhY2U+IG9uIHBwYnVzMA0KbHB0MDog PFByaW50ZXI+IG9uIHBwYnVzMA0KbHB0MDogSW50ZXJydXB0LWRyaXZlbiBw b3J0DQpwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1czANCmZkYzA6IDxF bmhhbmNlZCBmbG9wcHkgY29udHJvbGxlciAoaTgyMDc3LCBORTcyMDY1IG9y IGNsb25lKT4gcG9ydCAweDNmNywweDNmMC0weDNmNSBpcnEgNiBkcnEgMiBv biBhY3BpMA0KZmRjMDogRklGTyBlbmFibGVkLCA4IGJ5dGVzIHRocmVzaG9s ZA0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZlIDAN Cm9ybTA6IDxPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjZjgwMC0weGNmZmZm LDB4YzAwMDAtMHhjY2ZmZiBvbiBpc2EwDQpwbXRpbWVyMCBvbiBpc2EwDQpz YzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0K c2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0K c2lvMDogY29uZmlndXJlZCBpcnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2Jl ZCBpcnFzIDANCnNpbzA6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkDQpzaW8w IGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBpc2Ew DQpzaW8wOiB0eXBlIDgyNTAgb3Igbm90IHJlc3BvbmRpbmcNCnNpbzE6IGNv bmZpZ3VyZWQgaXJxIDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAw DQpzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZA0KdmdhMDogPEdlbmVy aWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAw LTB4YmZmZmYgb24gaXNhMA0KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMTAu MDAwIG1zZWMNCmZ3b2hjaTA6IEJVUyByZXNldA0KZndvaGNpMDogbm9kZV9p ZD0weGMwMDBmZmMwLCBnZW49MSwgQ1lDTEVNQVNURVIgbW9kZQ0KZmlyZXdp cmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwgY2FibGUgSVJNID0gMCAobWUp DQpmaXJld2lyZTA6IGJ1cyBtYW5hZ2VyIDAgKG1lKQ0KYWNwaV9jcHU6IHRo cm90dGxpbmcgZW5hYmxlZCwgOCBzdGVwcyAoMTAwJSB0byAxMi41JSksIGN1 cnJlbnRseSAxMDAuMCUNCmNiYjA6IFVuc3VwcG9ydGVkIGNhcmQgdHlwZSBk ZXRlY3RlZA0KYWQwOiAyODYxNU1CIDxJQzI1TjAzMEFUQ1MwNC0wPiBbNTgx NDAvMTYvNjNdIGF0IGF0YTAtbWFzdGVyIFVETUExMDANCmFjZDA6IENELVJX IDxRU0kgQ0QtUlcvRFZELVJPTSBTQlctMjQxPiBhdCBhdGExLW1hc3RlciBQ SU80DQogICAgQUNQSS0wNDMyOiAqKiogRXJyb3I6IEhhbmRsZXIgZm9yIFtF bWJlZGRlZENvbnRyb2xdIHJldHVybmVkIEFFX0VSUk9SDQogICAgQUNQSS0x Mjg3OiAqKiogRXJyb3I6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9U Wl8uVEhSTS5fVE1QXSAoTm9kZSAweGMyNjIyNDIwKSwgQUVfRVJST1INCiAg ICBBQ1BJLTA0MzI6ICoqKiBFcnJvcjogSGFuZGxlciBmb3IgW0VtYmVkZGVk Q29udHJvbF0gcmV0dXJuZWQgQUVfRVJST1INCiAgICBBQ1BJLTEyODc6ICoq KiBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5QQ0kw LkxQQzAuRUMwXy5fUTIwXSAoTm9kZSAweGMyNjFkMTQwKSwgQUVfQU1MX05P X1JFVFVSTl9WQUxVRQ0KICAgIEFDUEktMDQzMjogKioqIEVycm9yOiBIYW5k bGVyIGZvciBbRW1iZWRkZWRDb250cm9sXSByZXR1cm5lZCBBRV9FUlJPUg0K ICAgIEFDUEktMTI4NzogKioqIEVycm9yOiBNZXRob2QgZXhlY3V0aW9uIGZh aWxlZCBbXFxfU0JfLlBDSTAuTFBDMC5FQzBfLl9RMjBdIChOb2RlIDB4YzI2 MWQxNDApLCBBRV9BTUxfTk9fUkVUVVJOX1ZBTFVFDQogICAgQUNQSS0wNDMy OiAqKiogRXJyb3I6IEhhbmRsZXIgZm9yIFtFbWJlZGRlZENvbnRyb2xdIHJl dHVybmVkIEFFX0VSUk9SDQogICAgQUNQSS0xMjg3OiAqKiogRXJyb3I6IE1l dGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uUENJMC5MUEMwLkVDMF8u X1EyMF0gKE5vZGUgMHhjMjYxZDE0MCksIEFFX0FNTF9OT19SRVRVUk5fVkFM VUUNCiAgICBBQ1BJLTA0MzI6ICoqKiBFcnJvcjogSGFuZGxlciBmb3IgW0Vt YmVkZGVkQ29udHJvbF0gcmV0dXJuZWQgQUVfRVJST1INCiAgICBBQ1BJLTEy ODc6ICoqKiBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1xcX1NC Xy5QQ0kwLkxQQzAuRUMwXy5fUTIwXSAoTm9kZSAweGMyNjFkMTQwKSwgQUVf QU1MX05PX1JFVFVSTl9WQUxVRQ0KTW91bnRpbmcgcm9vdCBmcm9tIHVmczov ZGV2L2FkMHMyYQ0KV0FSTklORzogLyB3YXMgbm90IHByb3Blcmx5IGRpc21v dW50ZWQNCldBUk5JTkc6IC90bXAgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3Vu dGVkDQovdG1wOiBzdXBlcmJsb2NrIHN1bW1hcnkgcmVjb21wdXRlZA0KV0FS TklORzogL3VzciB3YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQNCi91c3I6 IG1vdW50IHBlbmRpbmcgZXJyb3I6IGJsb2NrcyA3NiBmaWxlcyAzMQ0KL3Vz cjogc3VwZXJibG9jayBzdW1tYXJ5IHJlY29tcHV0ZWQNCldBUk5JTkc6IC92 YXIgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkDQppbnRlcmZhY2UgZndl LjEgYWxyZWFkeSBwcmVzZW50IGluIHRoZSBLTEQgJ2tlcm5lbCchDQptb2R1 bGVfcmVnaXN0ZXI6IG1vZHVsZSBwY2kvZnhwIGFscmVhZHkgZXhpc3RzIQ0K TW9kdWxlIHBjaS9meHAgZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNw0KbW9kdWxl X3JlZ2lzdGVyOiBtb2R1bGUgY2FyZGJ1cy9meHAgYWxyZWFkeSBleGlzdHMh DQpNb2R1bGUgY2FyZGJ1cy9meHAgZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNw0K bW9kdWxlX3JlZ2lzdGVyOiBtb2R1bGUgZnhwL21paWJ1cyBhbHJlYWR5IGV4 aXN0cyENCk1vZHVsZSBmeHAvbWlpYnVzIGZhaWxlZCB0byByZWdpc3Rlcjog MTcNCmNhbid0IHJlLXVzZSBhIGxlYWYgKGZ4cF9ybnIpIQ0KY2FuJ3QgcmUt dXNlIGEgbGVhZiAoZnhwX25vZmxvdykhDQpDb3B5cmlnaHQgKGMpIDE5OTIt MjAwMyBUaGUgRnJlZUJTRCBQcm9qZWN0Lg0KQ29weXJpZ2h0IChjKSAxOTc5 LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0DQoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2Yg Q2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCkZyZWVCU0QgNS4x LUJFVEEgIzA6IEZyaSBNYXkgMjMgMTI6Mjg6MTYgR01UIDIwMDMNCiAgICBy b290QGJlZ2Vtb3QuZHluZG5zLm9yZzovdXNyL3NyYy9zeXMvaTM4Ni9jb21w aWxlL0dFTkVSSUMNClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJu ZWwva2VybmVsIiBhdCAweGMwNzFhMDAwLg0KUHJlbG9hZGVkIGVsZiBtb2R1 bGUgIi9ib290L2tlcm5lbC9hY3BpLmtvIiBhdCAweGMwNzFhMGE4Lg0KVGlt ZWNvdW50ZXIgImk4MjU0IiAgZnJlcXVlbmN5IDExOTMxODIgSHoNClRpbWVj b3VudGVyICJUU0MiICBmcmVxdWVuY3kgMjM5Mjk0ODgwOCBIeg0KQ1BVOiBJ bnRlbChSKSBQZW50aXVtKFIpIDQgQ1BVIDIuNDBHSHogKDIzOTIuOTUtTUh6 IDY4Ni1jbGFzcyBDUFUpDQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJ ZCA9IDB4ZjI3ICBTdGVwcGluZyA9IDcNCiAgRmVhdHVyZXM9MHhiZmViZjlm ZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LFNFUCxNVFJS LFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgs RlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJFPg0KcmVhbCBtZW1vcnkgID0g MjY3OTExMTY4ICgyNTUgTUIpDQphdmFpbCBtZW1vcnkgPSAyNTI0ODk3Mjgg KDI0MCBNQikNClBlbnRpdW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFibGVkDQpu cHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9uIG1vdGhlcmJvYXJkDQpucHgwOiBJ TlQgMTYgaW50ZXJmYWNlDQphY3BpMDogPEdBVEVXQSA0MDAgICAgID4gb24g bW90aGVyYm9hcmQNCnBjaWJpb3M6IEJJT1MgdmVyc2lvbiAyLjEwDQpVc2lu ZyAkUElSIHRhYmxlLCAxMSBlbnRyaWVzIGF0IDB4YzAwZmRmMTANCmFjcGkw OiBwb3dlciBidXR0b24gaXMgaGFuZGxlZCBhcyBhIGZpeGVkIGZlYXR1cmUg cHJvZ3JhbW1pbmcgbW9kZWwuDQpUaW1lY291bnRlciAiQUNQSS1mYXN0IiAg ZnJlcXVlbmN5IDM1Nzk1NDUgSHoNCmFjcGlfdGltZXIwOiA8MjQtYml0IHRp bWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24gYWNw aTANCmFjcGlfY3B1MDogPENQVT4gb24gYWNwaTANCmFjcGlfdHowOiA8dGhl cm1hbCB6b25lPiBvbiBhY3BpMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0KcGNpMDogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjANCmFncDA6IDxJbnRlbCA4Mjg0NSBob3N0IHRv IEFHUCBicmlkZ2U+IG1lbSAweGVjMDAwMDAwLTB4ZWZmZmZmZmYgYXQgZGV2 aWNlIDAuMCBvbiBwY2kwDQpwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSAxLjAgb24gcGNpMA0KcGNpMTogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjENCnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAwLjAg KG5vIGRyaXZlciBhdHRhY2hlZCkNCnVoY2kwOiA8SW50ZWwgODI4MDFDQS9D QU0gKElDSDMpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4MTgwMC0w eDE4MWYgaXJxIDEwIGF0IGRldmljZSAyOS4wIG9uIHBjaTANCnVzYjA6IDxJ bnRlbCA4MjgwMUNBL0NBTSAoSUNIMykgVVNCIGNvbnRyb2xsZXIgVVNCLUE+ IG9uIHVoY2kwDQp1c2IwOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMDogSW50 ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBh ZGRyIDENCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZA0KcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMzAuMCBvbiBwY2kwDQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li Mg0KY2JiMDogPE8yTWljcm8gT1o2OTEyLzY5NzIgUENJLUNhcmRCdXMgQnJp ZGdlPiBpcnEgMTAgYXQgZGV2aWNlIDIuMCBvbiBwY2kyDQpjYXJkYnVzMDog PENhcmRCdXMgYnVzPiBvbiBjYmIwDQpwY2NhcmQwOiA8MTYtYml0IFBDQ2Fy ZCBidXM+IG9uIGNiYjANCnBjaTI6IDxtdWx0aW1lZGlhLCBhdWRpbz4gYXQg ZGV2aWNlIDMuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KZndvaGNpMDogdmVu ZG9yPTEwNGMsIGRldj04MDI2DQpmd29oY2kwOiA8MTM5NCBPcGVuIEhvc3Qg Q29udHJvbGxlciBJbnRlcmZhY2U+IG1lbSAweGU4MjAwMDAwLTB4ZTgyMDNm ZmYsMHhlODIwNjAwMC0weGU4MjA2N2ZmIGlycSAxMCBhdCBkZXZpY2UgNS4w IG9uIHBjaTINCmZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAxLjEwIChST009MSkN CmZ3b2hjaTA6IE5vLiBvZiBJc29jaHJvbm91cyBjaGFubmVsIGlzIDQuDQpm d29oY2kwOiBFVUk2NCAwMDplMDpiODowNDowMTowMTplYzpmMQ0KZndvaGNp MDogUGh5IDEzOTRhIGF2YWlsYWJsZSBTNDAwLCAxIHBvcnRzLg0KZndvaGNp MDogTGluayBTNDAwLCBtYXhfcmVjIDIwNDggYnl0ZXMuDQpmaXJld2lyZTA6 IDxJRUVFMTM5NChGaXJlV2lyZSkgYnVzPiBvbiBmd29oY2kwDQppZl9md2Uw OiA8RXRoZXJuZXQgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwDQppZl9m d2UwOiBGYWtlIEV0aGVybmV0IGFkZHJlc3M6IDAyOmUwOmI4OjAxOmVjOmYx DQpzYnAwOiA8U0JQMi9TQ1NJIG92ZXIgZmlyZXdpcmU+IG9uIGZpcmV3aXJl MA0KZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0DQpmeHAwOiA8SW50ZWwg ODI4MDFDQU0gKElDSDMpIFByby8xMDAgVkUgRXRoZXJuZXQ+IHBvcnQgMHgz YzAwLTB4M2MzZiBtZW0gMHhlODIwNTAwMC0weGU4MjA1ZmZmIGlycSAxMCBh dCBkZXZpY2UgOC4wIG9uIHBjaTINCmZ4cDA6IEV0aGVybmV0IGFkZHJlc3Mg MDA6ZTA6Yjg6NTA6MjM6N2INCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBmeHAw DQppbnBoeTA6IDxpODI1NjJFVCAxMC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBv biBtaWlidXMwDQppbnBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAw YmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvDQppc2FiMDogPFBDSS1JU0Eg YnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1 cz4gb24gaXNhYjANCmF0YXBjaTA6IDxJbnRlbCBJQ0gzIFVETUExMDAgY29u dHJvbGxlcj4gcG9ydCAweDE4MjAtMHgxODJmLDB4Mzc0LTB4Mzc3LDB4MTcw LTB4MTc3LDB4M2Y0LTB4M2Y3LDB4MWYwLTB4MWY3IG1lbSAweGU4MDAwMDAw LTB4ZTgwMDAzZmYgYXQgZGV2aWNlIDMxLjEgb24gcGNpMA0KYXRhMDogYXQg MHgxZjAgaXJxIDE0IG9uIGF0YXBjaTANCmF0YTE6IGF0IDB4MTcwIGlycSAx NSBvbiBhdGFwY2kwDQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRl dmljZSAzMS4zIChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2kwOiA8c2ltcGxl IGNvbW1zPiBhdCBkZXZpY2UgMzEuNiAobm8gZHJpdmVyIGF0dGFjaGVkKQ0K YWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRjaD4gb24gYWNw aTANCiAgICBBQ1BJLTEyODc6ICoqKiBFcnJvcjogTWV0aG9kIGV4ZWN1dGlv biBmYWlsZWQgW1xcX1NCXy5MSURfLl9QU1ddIChOb2RlIDB4YzI2MjJlODAp LCBBRV9OT1RfRVhJU1QNCmFjcGlfYWNhZDA6IDxBQyBhZGFwdGVyPiBvbiBh Y3BpMA0KYWNwaV9jbWJhdDA6IDxDb250cm9sIG1ldGhvZCBCYXR0ZXJ5PiBv biBhY3BpMA0KYWNwaV9idXR0b24wOiA8U2xlZXAgQnV0dG9uPiBvbiBhY3Bp MA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9y dCAweDY0LDB4NjAgaXJxIDEgb24gYWNwaTANCmF0a2JkMDogPEFUIEtleWJv YXJkPiBmbGFncyAweDEgaXJxIDEgb24gYXRrYmRjMA0Ka2JkMCBhdCBhdGti ZDANCnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMA0KcHNt MDogbW9kZWwgR2VuZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQgMA0KYWNw aV9lYzA6IDxlbWJlZGRlZCBjb250cm9sbGVyPiBwb3J0IDB4NjYsMHg2MiBv biBhY3BpMA0KcHBjMCBwb3J0IDB4Nzc4LTB4NzdmLDB4Mzc4LTB4MzdmIGly cSA3IGRycSAzIG9uIGFjcGkwDQpwcGMwOiBHZW5lcmljIGNoaXBzZXQgKEVD UC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUNCnBwYzA6IEZJRk8g d2l0aCAxNi8xNi84IGJ5dGVzIHRocmVzaG9sZA0KcHBidXMwOiA8UGFyYWxs ZWwgcG9ydCBidXM+IG9uIHBwYzANCnBsaXAwOiA8UExJUCBuZXR3b3JrIGlu dGVyZmFjZT4gb24gcHBidXMwDQpscHQwOiA8UHJpbnRlcj4gb24gcHBidXMw DQpscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQNCnBwaTA6IDxQYXJhbGxl bCBJL08+IG9uIHBwYnVzMA0KZmRjMDogPEVuaGFuY2VkIGZsb3BweSBjb250 cm9sbGVyIChpODIwNzcsIE5FNzIwNjUgb3IgY2xvbmUpPiBwb3J0IDB4M2Y3 LDB4M2YwLTB4M2Y1IGlycSA2IGRycSAyIG9uIGFjcGkwDQpmZGMwOiBGSUZP IGVuYWJsZWQsIDggYnl0ZXMgdGhyZXNob2xkDQpmZDA6IDwxNDQwLUtCIDMu NSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMA0Kb3JtMDogPE9wdGlvbiBST01z PiBhdCBpb21lbSAweGNmODAwLTB4Y2ZmZmYsMHhjMDAwMC0weGNjZmZmIG9u IGlzYTANCnBtdGltZXIwIG9uIGlzYTANCnNjMDogPFN5c3RlbSBjb25zb2xl PiBhdCBmbGFncyAweDEwMCBvbiBpc2EwDQpzYzA6IFZHQSA8MTYgdmlydHVh bCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+DQpzaW8wOiBjb25maWd1cmVkIGly cSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMA0Kc2lvMDogcG9y dCBtYXkgbm90IGJlIGVuYWJsZWQNCnNpbzAgYXQgcG9ydCAweDNmOC0weDNm ZiBpcnEgNCBmbGFncyAweDEwIG9uIGlzYTANCnNpbzA6IHR5cGUgODI1MCBv ciBub3QgcmVzcG9uZGluZw0Kc2lvMTogY29uZmlndXJlZCBpcnEgMyBub3Qg aW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDANCnNpbzE6IHBvcnQgbWF5IG5v dCBiZSBlbmFibGVkDQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0 IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQpU aW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAgbXNlYw0KZndvaGNpMDog QlVTIHJlc2V0DQpmd29oY2kwOiBub2RlX2lkPTB4YzAwMGZmYzAsIGdlbj0x LCBDWUNMRU1BU1RFUiBtb2RlDQpmaXJld2lyZTA6IDEgbm9kZXMsIG1heGhv cCA8PSAwLCBjYWJsZSBJUk0gPSAwIChtZSkNCmZpcmV3aXJlMDogYnVzIG1h bmFnZXIgMCAobWUpDQphY3BpX2NwdTogdGhyb3R0bGluZyBlbmFibGVkLCA4 IHN0ZXBzICgxMDAlIHRvIDEyLjUlKSwgY3VycmVudGx5IDEwMC4wJQ0KY2Ji MDogVW5zdXBwb3J0ZWQgY2FyZCB0eXBlIGRldGVjdGVkDQphZDA6IDI4NjE1 TUIgPElDMjVOMDMwQVRDUzA0LTA+IFs1ODE0MC8xNi82M10gYXQgYXRhMC1t YXN0ZXIgVURNQTEwMA0KYWNkMDogQ0QtUlcgPFFTSSBDRC1SVy9EVkQtUk9N IFNCVy0yNDE+IGF0IGF0YTEtbWFzdGVyIFBJTzQNCiAgICBBQ1BJLTA0MzI6 ICoqKiBFcnJvcjogSGFuZGxlciBmb3IgW0VtYmVkZGVkQ29udHJvbF0gcmV0 dXJuZWQgQUVfRVJST1INCiAgICBBQ1BJLTEyODc6ICoqKiBFcnJvcjogTWV0 aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1xcX1RaXy5USFJNLl9UTVBdIChOb2Rl IDB4YzI2MjI0MjApLCBBRV9FUlJPUg0KICAgIEFDUEktMDQzMjogKioqIEVy cm9yOiBIYW5kbGVyIGZvciBbRW1iZWRkZWRDb250cm9sXSByZXR1cm5lZCBB RV9FUlJPUg0KICAgIEFDUEktMTI4NzogKioqIEVycm9yOiBNZXRob2QgZXhl Y3V0aW9uIGZhaWxlZCBbXFxfU0JfLlBDSTAuTFBDMC5FQzBfLl9RMjBdIChO b2RlIDB4YzI2MWQxNDApLCBBRV9BTUxfTk9fUkVUVVJOX1ZBTFVFDQogICAg QUNQSS0wNDMyOiAqKiogRXJyb3I6IEhhbmRsZXIgZm9yIFtFbWJlZGRlZENv bnRyb2xdIHJldHVybmVkIEFFX0VSUk9SDQogICAgQUNQSS0xMjg3OiAqKiog RXJyb3I6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uUENJMC5M UEMwLkVDMF8uX1EyMF0gKE5vZGUgMHhjMjYxZDE0MCksIEFFX0FNTF9OT19S RVRVUk5fVkFMVUUNCiAgICBBQ1BJLTA0MzI6ICoqKiBFcnJvcjogSGFuZGxl ciBmb3IgW0VtYmVkZGVkQ29udHJvbF0gcmV0dXJuZWQgQUVfRVJST1INCiAg ICBBQ1BJLTEyODc6ICoqKiBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWls ZWQgW1xcX1NCXy5QQ0kwLkxQQzAuRUMwXy5fUTIwXSAoTm9kZSAweGMyNjFk MTQwKSwgQUVfQU1MX05PX1JFVFVSTl9WQUxVRQ0KICAgIEFDUEktMDQzMjog KioqIEVycm9yOiBIYW5kbGVyIGZvciBbRW1iZWRkZWRDb250cm9sXSByZXR1 cm5lZCBBRV9FUlJPUg0KICAgIEFDUEktMTI4NzogKioqIEVycm9yOiBNZXRo b2QgZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLlBDSTAuTFBDMC5FQzBfLl9R MjBdIChOb2RlIDB4YzI2MWQxNDApLCBBRV9BTUxfTk9fUkVUVVJOX1ZBTFVF DQpNb3VudGluZyByb290IGZyb20gdWZzOi9kZXYvYWQwczJhDQpXQVJOSU5H OiAvIHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRlZA0KV0FSTklORzogL3Rt cCB3YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQNCldBUk5JTkc6IC91c3Ig d2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkDQovdXNyOiBtb3VudCBwZW5k aW5nIGVycm9yOiBibG9ja3MgNTYgZmlsZXMgMQ0KL3Vzcjogc3VwZXJibG9j ayBzdW1tYXJ5IHJlY29tcHV0ZWQNCldBUk5JTkc6IC92YXIgd2FzIG5vdCBw cm9wZXJseSBkaXNtb3VudGVkDQppbnRlcmZhY2UgZndlLjEgYWxyZWFkeSBw cmVzZW50IGluIHRoZSBLTEQgJ2tlcm5lbCchDQptb2R1bGVfcmVnaXN0ZXI6 IG1vZHVsZSBwY2kvZnhwIGFscmVhZHkgZXhpc3RzIQ0KTW9kdWxlIHBjaS9m eHAgZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNw0KbW9kdWxlX3JlZ2lzdGVyOiBt b2R1bGUgY2FyZGJ1cy9meHAgYWxyZWFkeSBleGlzdHMhDQpNb2R1bGUgY2Fy ZGJ1cy9meHAgZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNw0KbW9kdWxlX3JlZ2lz dGVyOiBtb2R1bGUgZnhwL21paWJ1cyBhbHJlYWR5IGV4aXN0cyENCk1vZHVs ZSBmeHAvbWlpYnVzIGZhaWxlZCB0byByZWdpc3RlcjogMTcNCmNhbid0IHJl LXVzZSBhIGxlYWYgKGZ4cF9ybnIpIQ0KY2FuJ3QgcmUtdXNlIGEgbGVhZiAo ZnhwX25vZmxvdykhDQpkcm0wOiA8QVRJIFJhZGVvbiBMWSBNb2JpbGl0eSBN Nj4gcG9ydCAweDIwMDAtMHgyMGZmIG1lbSAweGU4MTAwMDAwLTB4ZTgxMGZm ZmYsMHhmMDAwMDAwMC0weGY3ZmZmZmZmIGlycSAxMCBhdCBkZXZpY2UgMC4w IG9uIHBjaTENCmluZm86IFtkcm1dIEFHUCBhdCAweGVjMDAwMDAwIDY0TUIN CmluZm86IFtkcm1dIEluaXRpYWxpemVkIHJhZGVvbiAxLjguMCAyMDAyMDgy OCBvbiBtaW5vciAwDQpsb2NrIG9yZGVyIHJldmVyc2FsDQogMXN0IDB4YzJj ZmZkNGMgdm0gb2JqZWN0ICh2bSBvYmplY3QpIEAgdm0vdm1fb2JqZWN0LmM6 NTEyDQogMm5kIDB4YzA4MmYxMTAgc3lzdGVtIG1hcCAoc3lzdGVtIG1hcCkg QCB2bS92bV9rZXJuLmM6MzI1DQpTdGFjayBiYWNrdHJhY2U6DQo= --1082257411-464521798-1053722970=:7062-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 15:01:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8C8B37B401 for ; Fri, 23 May 2003 15:01:26 -0700 (PDT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF30743F3F for ; Fri, 23 May 2003 15:01:23 -0700 (PDT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.8/8.12.8) with ESMTP id h4NM09Vo065594; Sat, 24 May 2003 00:00:09 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.8/8.12.8/Submit) id h4NM09ih065593; Sat, 24 May 2003 00:00:09 +0200 (CEST) Date: Sat, 24 May 2003 00:00:09 +0200 From: Stijn Hoop To: Tim Kientzle Message-ID: <20030523220009.GA64352@pcwin002.win.tue.nl> References: <3ECE800F.9040104@acm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <3ECE800F.9040104@acm.org> User-Agent: Mutt/1.4.1i X-Bright-Idea: Let's abolish HTML mail! cc: freebsd-hackers@freebsd.org Subject: Re: pkg_add and osreldate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 22:01:27 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 23, 2003 at 01:09:51PM -0700, Tim Kientzle wrote: > Problem: If someone runs this on a 4.5-STABLE > system, for instance (osreldate=3D450100), then > they will be directed to "packages-4-stable". That's not a problem is it? I thought that all ports and packages should work on reasonably current -STABLE systems, although I think 'reasonably' is pretty undefined :) > It seems that packages-4.5-release would > be more appropriate. So users would default to installing packages with security holes? I think that's not a good idea. > Similarly, this logic claims > that a 3.x system should be using packages from > 5-stable! (Though I don't consider that > a serious problem, of course. ;-) Heh. > I'm considering a simpler scheme: choose the > first item with version <=3D osreldate. > This would seem to provide cleaner handling > of the various borderline cases. I'd think you'd need to encode the branch, ie 400000 <=3D osreldate < 500000 means 'use packages-4-stable', and fall back to packages-4.x-release if -stable is not available. --Stijn --=20 SIGSIG -- signature too long (core dumped) --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+zpnpY3r/tLQmfWcRAmTmAKCPXDMrckNx0Lk/Yh9/mCq1SQ7EIQCgmTw/ RXcQuL3QgLkvgaQ2LTci1oY= =B4tv -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 15:36:45 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE62E37B401 for ; Fri, 23 May 2003 15:36:45 -0700 (PDT) Received: from adsl-64-161-78-226.dsl.lsan03.pacbell.net (adsl-64-161-78-226.dsl.lsan03.pacbell.net [64.161.78.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 69E9943F93 for ; Fri, 23 May 2003 15:36:44 -0700 (PDT) (envelope-from oremanj@adsl-64-161-78-226.dsl.lsan03.pacbell.net) Received: (qmail 41494 invoked by uid 1001); 23 May 2003 22:37:51 -0000 Date: Fri, 23 May 2003 15:37:51 -0700 From: Joshua Oreman To: Mikhail Kruk Message-ID: <20030523223751.GA41427@webserver.get-linux.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: hackers@freebsd.org Subject: Re: current crashes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 22:36:46 -0000 On Fri, May 23, 2003 at 04:49:30PM -0400 or thereabouts, Mikhail Kruk seemed to write: > Hello, > I'm trying to get a Gateway laptop working on CURRENT. See dmesg.txt for > hardware details. Also notice the lock order reversal complaint, but it's > not my main problem. The main problem is that it crashes quite often. It > always crashes in one of the acpi threads, but not always in the same. > I've seen it happen in both acpi_task? and in acpi_thermal. I can run for > quite a long time, but eventually it happens. The most reliable way to > provoke crash is to start buildworld. As a result I'm running with > 5.0-RELEASE system and 5.1-BETA kernel (took arount 10 attempts to build > the kernel). Now when it crashes I get into debugger, but I couldn't > figure out how to make it dump core. I tried givin 'panic' command and it > seemed like it was dumping core, but it's not in /var/crash. Am I doing it > wrong? > Anyway, here is the trace (typed it in manually): > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x80790ab0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc06ea4d0 ^^^^^^^^^^ This value is important, but meaningless in its current form. Please see chapter 18 of the FAQ. Read it, do what it says, give us the symbol(s). -- Josh > stack pointer = 0x10:0xcd10bbf0 > frame pointer = 0x19:0xcd10bbf0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 6 (acpi_task1) > kernel: type 12 trap, code=0 > Stopped at AcpiNsMapHandleToNode+0x20: cmpb $0xaa,0(%edx) > > trace: > AcpiNsMapHandleToNode > AcpiGetHandle > acpi_pwer_switch_consumer > acpi_tz_switch_cooler_on > acpi_ForeachPackageObject > acpi_tz_monitor > atcpi_task_thread > fork_exit > fork_trampoline > > > Please excuse me if this is wrong place to send this and thanks in avance! > -m > Copyright (c) 1992-2003 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.1-BETA #0: Fri May 23 12:28:16 GMT 2003 > root@begemot.dyndns.org:/usr/src/sys/i386/compile/GENERIC > Preloaded elf kernel "/boot/kernel/kernel" at 0xc071a000. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc071a0a8. > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 2392954684 Hz > CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2392.95-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > Features=0xbfebf9ff > real memory = 267911168 (255 MB) > avail memory = 252489728 (240 MB) > Pentium Pro MTRR support enabled > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > pcibios: BIOS version 2.10 > Using $PIR table, 11 entries at 0xc00fdf10 > acpi0: power button is handled as a fixed feature programming model. > Timecounter "ACPI-fast" frequency 3579545 Hz > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_cpu0: on acpi0 > acpi_tz0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: mem 0xec000000-0xefffffff at device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > uhci0: port 0x1800-0x181f irq 10 at device 29.0 on pci0 > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > cbb0: irq 10 at device 2.0 on pci2 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > pci2: at device 3.0 (no driver attached) > fwohci0: vendor=104c, dev=8026 > fwohci0: <1394 Open Host Controller Interface> mem 0xe8200000-0xe8203fff,0xe8206000-0xe82067ff irq 10 at device 5.0 on pci2 > fwohci0: OHCI version 1.10 (ROM=1) > fwohci0: No. of Isochronous channel is 4. > fwohci0: EUI64 00:e0:b8:04:01:01:ec:f1 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > if_fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:e0:b8:01:ec:f1 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fxp0: port 0x3c00-0x3c3f mem 0xe8205000-0xe8205fff irq 10 at device 8.0 on pci2 > fxp0: Ethernet address 00:e0:b8:50:23:7b > miibus0: on fxp0 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1820-0x182f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 mem 0xe8000000-0xe80003ff at device 31.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > pci0: at device 31.3 (no driver attached) > pci0: at device 31.6 (no driver attached) > acpi_lid0: on acpi0 > ACPI-1287: *** Error: Method execution failed [\\_SB_.LID_._PSW] (Node 0xc2622e80), AE_NOT_EXIST > acpi_acad0: on acpi0 > acpi_cmbat0: on acpi0 > acpi_button0: on acpi0 > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > acpi_ec0: port 0x66,0x62 on acpi0 > ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 > ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > orm0: